Copilot Dynamic Workflows Split App and CLI as gh-aw v0.90.3 Fails Closed

Today’s news is two GitHub changes that land on Monday work: a workflow preview that behaves differently in the app and the CLI, and an agentic-workflows release that turns loose tokens and missing targets into errors. Treat today as the day to turn experimental on only where you will run a named workflow, pass --allow-tool=read until a workflow needs a write, and compile on the gh-aw v0.90.3 pre-release in a branch before you move the week’s queue to it.

Top Stories

1. Dynamic workflows are on in the Copilot app and experimental in the CLI

GitHub shipped dynamic workflows on 1 Oct 2026 as a public preview in Copilot CLI, the GitHub Copilot app and the Copilot SDK, on all Copilot plans. A dynamic workflow is a program inside a Copilot extension that mixes automated steps with one or more agents, and its steps can run in sequence or in parallel, pass structured results, ask subagents to verify findings and pause at a checkpoint. The app needs no setup, while the CLI needs --experimental on the command line or /experimental on in a session, and GitHub documents /update as the way to update the CLI.

GitHub’s docs also separate it from /fleet: fleet delegates work to subagents and coordinates them, while a dynamic workflow runs a process defined in code. To see what you have, the how-to suggests asking “What dynamic workflows are available?” The important caveat is that a non-interactive copilot workflow run does not display permission prompts, so you grant permissions first with flags such as --allow-tool or --allow-url, and any request that cannot be approved automatically is denied. Three of the how-to’s examples put --allow-tool after the workflow name, but in our checks on stable v1.0.91 and the v1.0.92-4 pre-release that placement returned unexpected argument '--allow-tool', so put it before workflow run, as the docs’ scripting example does.

Practical dev impact: An app session and a CLI session are different gates, since the app already has the feature and the CLI does not until experimental is on. Keep the first CLI run on --allow-tool=read, as GitHub’s docs write it, and name a write tool only when the workflow needs one, and run a workflow once with that allow-list before it replaces a GitHub Actions job.

2. The gh-aw v0.90.3 pre-release fails closed on token scope, comment targets and loose MCP

GitHub Agentic Workflows v0.90.3 was published as a GitHub pre-release at 9:39 PM ET on 2 Oct, while the latest non-pre-release is still v0.89.21, and the project’s 5 Oct weekly update summarizes it for operators. The release adds built-in log, set, map, table and counter ledgers and Git-backed work-queue operator commands. It renames the work coordinator tool and CLI to work-queue, removes work-pool ledger support and renames the claims ledger to notes. For the Copilot engine it adds task-level model routing, the reasoning efforts none and max, and a run-wide tool-call budget for Copilot SDK agents.

Only one behavior change shows up at compile: GitHub App tokens now need explicit scopes. Two more show up at run time: Claude defaults to strict MCP configuration, and add-comment fails when the triggering target cannot be resolved. A separate fix retries Copilot 5xx failures instead of treating them as quota exhaustion. In our test compile, a hand-written actions/create-github-app-token step with no permission-* inputs failed with an error telling you to add only the scopes you need under with: so the installation token is not fully scoped, while the built-in github-app: setting compiled and filled in its scopes.

Practical dev impact: Recompile before you trust a queued job, because a step that mints a GitHub App token without naming scopes now fails at compile instead of quietly minting a fully scoped installation token. A comment step that assumed a triggering issue or pull request will fail the run instead of finishing green without posting, and a Claude MCP setup that leaned on the loose default needs a strict-compatible config. If a workflow used the work-pool or claims ledgers, check it against the new names before it runs.

3. Copilot CLI v1.0.92-4 adds copilot config on the pre-release channel only

GitHub published v1.0.92-4 as a pre-release at 3:32 PM ET on 4 Oct, and npm still lists latest as v1.0.91 with prerelease at v1.0.92-4. The release adds copilot config to list, read, set and remove settings in dot notation, for example copilot config footer.showQuota off, with --list, --rm, --repo and --local options. Sandboxed shells now withhold an ambient GITHUB_TOKEN unless you configure it, and a change to experimental mode made with /experimental or /settings takes effect after a restart even when the launch used the opposite flag.

Practical dev impact: Leave fleets on v1.0.91 and try copilot config only on a pre-release pilot. Stable v1.0.91 already has --experimental and workflow run, so dynamic workflows do not need the pre-release.

Practical Impact Analysis

The decision today is which preview leaves the laptop and which compile errors to expect, not which model to pin, because no Claude Code, Copilot CLI stable or Codex stable tag moved overnight. A team that writes Copilot extensions should treat the app and the CLI as separate gates: author in the app if that is where people work, and for the CLI and CI turn experimental on deliberately, keep --allow-tool=read until a write is named, and remember that copilot workflow run denies anything it cannot approve automatically.

A team that moves to the v0.90.3 pre-release should compile on a branch and fix any App token scope error first, then watch the first runs for strict MCP and add-comment failures, since the new ledgers are no reason to skip that check. A fleet on Copilot CLI v1.0.91 can run dynamic workflows once experimental is on, and the new copilot config command is a pre-release convenience rather than a reason to move the fleet.

Tutorial

Steps 1, 3, 4 and 5 are in the script below, and step 2 happens inside a Copilot CLI session.

1. Confirm the channels before you upgrade anything. As of about 6:10 AM ET on 5 Oct, Claude Code latest and next were v2.1.289 with stable at v2.1.285, Copilot CLI latest was v1.0.91 with prerelease at v1.0.92-4, and Codex latest was v0.160.0. Do not install the Copilot pre-release for these steps.
2. On Copilot CLI v1.0.91 or later, start copilot --experimental, or run /experimental on if you started without the flag, then ask “What dynamic workflows are available?”
3. Run a named workflow non-interactively with a read allow-list, with the global flags before the subcommand. Swap in the name and JSON of a workflow you actually published. If you created the workflow inside a chat session, copy its extension to ~/.copilot/extensions/ or .github/extensions/ first, then start a new session. We confirmed the flag placement on Copilot CLI v1.0.91 and v1.0.92-4 but did not run this against a real published workflow.
4. On a branch, install the v0.90.3 pre-release (a plain extension upgrade may stop at v0.89.21, the latest non-pre-release) and compile. Expect a compile error only for a hand-written App token step with no explicit scopes. Strict MCP and an unresolved add-comment target fail at run time, so watch the first run. We compiled test workflows but not a real repository, and did not mint a live App token, so treat this as a test of your own.
5. Optional, pre-release pilots only: list settings with copilot config --list without changing anything, and leave production on v1.0.91.

#!/usr/bin/env bash
set -u

# Step 1: channel tags before you upgrade anything
npm view @anthropic-ai/claude-code dist-tags --json
npm view @github/copilot dist-tags --json
npm view @openai/codex dist-tags --json

# Step 3: one published workflow with a read allow-list.
# Global flags go before the subcommand; use your own name and args.
workflow="java-security-checks"
copilot --experimental --allow-tool=read workflow run "$workflow" \
  --args '{"directories":["java/src","java/tests"]}'

# Step 4: confirm gh-aw reports v0.90.3, then compile

... click "Show full code" below to expand

#!/usr/bin/env bash
set -u

# Step 1: channel tags before you upgrade anything
npm view @anthropic-ai/claude-code dist-tags --json
npm view @github/copilot dist-tags --json
npm view @openai/codex dist-tags --json

# Step 3: one published workflow with a read allow-list.
# Global flags go before the subcommand; use your own name and args.
workflow="java-security-checks"
copilot --experimental --allow-tool=read workflow run "$workflow" \
  --args '{"directories":["java/src","java/tests"]}'

# Step 4: confirm gh-aw reports v0.90.3, then compile
gh aw --version
gh aw compile

# Step 5, pre-release pilots only: list settings without changing them
# copilot config --list

Recommended AI prompt

Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever AI you use.

I run a team on GitHub Copilot and GitHub Agentic Workflows. Dynamic workflows are in public preview in the Copilot app and in Copilot CLI, and the CLI needs --experimental or /experimental on. A non-interactive copilot workflow run does not prompt for permissions, so tool permissions must be set on the command line, and --allow-tool is a global flag that goes before workflow run. The gh-aw v0.90.3 pre-release requires explicit GitHub App token scopes at compile time, defaults Claude to strict MCP configuration, and fails add-comment when the triggering target cannot be resolved. Write me a one-page checklist, in order, covering how to confirm our Copilot CLI version and whether experimental is on, how to list available dynamic workflows, how to run one with --allow-tool=read, how to confirm gh aw --version reports v0.90.3, which compile error to expect and fix first, and which two run-time failures to watch for on the first run. Name the exact command or setting for each step and the risk it avoids. If you need our Copilot plan, whether we use the Copilot app or only the CLI, or where our gh-aw workflows live, ask me instead of guessing.