1.10.0 — 2026-10-08

Release Notes

A runner says only what its agents are denied: for Copilot CLI and Claude Code, Layover supplies
the rest. A workflow can run a shared agent at its own model, effort or context, and whoever
triggers a run can name it and choose those for that run alone.

Compatibility. Additive. Existing factories — written-out command runners included — load,
validate and run unchanged, and validate warns about nothing new in them. What is different:

• A written-out command containing the literal text {name} or {args} now has it filled in —
  the chain's name, the agent's args — or left out when there is none.
• POST /flights takes optional name and agents; GET /pipelines gains each workflow's
  agents, itineraries and pending flights a name, and runs a chain_name. Run records, queued
  flights, layovers and help requests keep the chain's name and choices where it has them; older
  releases ignore them, and older records simply lack them.

Added

• Runner presets. cli = "copilot" or cli = "claude" has Layover supply everything an
  unattended run of that CLI needs — the program, the agent's model, effort and context, Copilot's
  --no-ask-user and --name, the JSON output a cost is read from, and the MCP wiring — and, for
  Copilot, --allow-all-tools --allow-all-paths --allow-all-urls, since nobody is there to answer a
  permission prompt. A runner's args then say only what it takes away. command still works, for
  Codex, a script, or a runner that wants none of a preset's defaults.
• An agent's own args, added to its runner's command for that agent alone, so an agent that
  is denied one more thing than the rest needs no runner of its own. They go where a command has
  {args}, or at the end.
• A workflow can run an agent differently. [pipelines.<name>.agents.<agent>] sets the model,
  effort or context that workflow's chains run the agent at, and args it adds, so an agent shared
  by two workflows needs neither a second agent nor a second runner. It wins over the agent's own
  values and [defaults]; a choice made when triggering wins over it. Each workflow's map, explain and
  prompt --pipeline show the agent as that workflow runs it, and run records name what it ran on.
• A run can be named when it is triggered, and agents run differently for that run only. The
  dashboard's trigger window takes a name — "Login page: retry banner" — and, per agent the workflow
  runs, a model, effort or context to use instead; POST /flights takes them as name and
  agents. Both stay with everything the chain causes: hand-offs, spawned chains, follow-ups, and
  the work a reply to its help requests continues. The name is shown on Chains, the chain's page,
  Sessions, Upcoming and Runs, kept in run records as chain_name, and passed to Copilot as the
  session's --name. A choice its runner cannot carry, for an agent the workflow never runs, or
  that is not a plain value is refused with the reason. GET /pipelines lists each workflow's
  agents with what they run at in it, and a chain's own map shows what its agents ran at in it.
• layover validate refuses a runner with neither cli nor command, both, or args beside a
  command; and warns when a runner or agent repeats an option its preset already supplies, when
  an agent's args fix a value its runner carries a placeholder for, and when args would follow a
  command's final -; refuses a workflow override for an undeclared agent and warns about one no
  chain of the workflow can reach or whose value the runner cannot carry. An agent that leaves a
  preset's effort or context unset is not warned about: the CLI's own default is what it asked for.
• examples/multi-workflow/: four workflows sharing eight agents and one Copilot runner, shaped
  after a team's factory — a manually triggered development workflow, a follow-up that resumes its
  published pull requests, a review sweep that spawns one review per pull request and runs the shared
  reviewer at a lower effort with one more deny rule, and a daily upstream watch.

Changed

• The examples use presets. news-digest, pr-review, build-and-review and
  workitem-factory run Copilot and Claude Code through cli, so their Copilot agents now also get
  --allow-all-paths --allow-all-urls --no-ask-user. planner.toml keeps written-out command
  runners for Copilot and Codex, to show that shape. The examples' Claude runners previously lacked
  the --verbose Claude Code requires beside stream-json in print mode.

Install layover-cli 1.10.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.10.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.10.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.10.0

Download layover-cli 1.10.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>