Copilot CLI in Late 2026: The Flags I Actually Use in Scripts A platform engineer documented the GitHub Copilot CLI flags they rely on for headless, scripted use, based on the docs and changelog as of early October 2026 (release 1.0.92). Key findings include a changed token lookup order where COPILOT_GITHUB_TOKEN is now checked before GH_TOKEN and GITHUB_TOKEN, and the fact that deny rules always take precedence over allow rules even when --allow-all is set, which makes --allow-all-tools viable in scripts. Most Copilot CLI guides I find are prompt catalogs: "ask it to write a Terraform module", "ask it to explain a failing workflow". That part is easy. What took me longer was the boring layer underneath: which flags make GitHub Copilot CLI safe to run from a script, what changed in the last few months of releases, and where the sharp edges are. This is that layer, written against the docs and changelog as of early October 2026 the repo shipped 1.0.92 on October 5 . I run platform tooling for a small team, so my bias is headless use: cron jobs, CI steps, one-off batch fixes. If you mostly use it interactively, the permissions and worktree sections still apply. One scoping note before the flags: I don't use a terminal agent for everything. When someone needs a marketing page or a quick front end for an internal tool, I hand that to Begin https://begin.sh/?utm source=devto&utm medium=ugc&utm campaign=selinorlov&utm content=copilot-cli-intro , which builds the site with hosting and sign-in already wired, and I keep Copilot CLI for work inside existing repos. Install is the same as it has been: brew install copilot-cli or curl -fsSL https://gh.io/copilot-install | bash winget install GitHub.Copilot npm install -g @github/copilot Each has a prerelease channel copilot-cli@prerelease , GitHub.Copilot.Prerelease , @github/copilot@prerelease . The docs now say Copilot CLI is available on all Copilot plans. If you get Copilot through an org, an admin still has to enable the CLI policy. The change that bit me: token lookup order. Older posts say GH TOKEN wins over GITHUB TOKEN . The current reference checks COPILOT GITHUB TOKEN first , then GH TOKEN , then GITHUB TOKEN . On a CI runner that already exports GITHUB TOKEN for other steps, setting COPILOT GITHUB TOKEN keeps the Copilot credential separate. The token is a fine-grained PAT with the "Copilot Requests" permission. By default the CLI redacts the values of GITHUB TOKEN and COPILOT GITHUB TOKEN from its output. For anything else sensitive, there's --secret-env-vars . Here is the short list I keep pinned. All of these come from the current command reference. | Flag | What it does | When I reach for it | |---|---|---| | -p , --prompt | Runs one prompt and exits | Every scripted run | | -s , --silent | Prints only the agent response, no usage stats | When stdout feeds another tool | | --output-format=json | Emits JSONL, one object per line | Logging runs for later inspection | | --allow-all-tools | Runs tools without confirmation | The reference lists it as required for programmatic use | | --deny-tool=... | Blocks specific tools or commands | Always, alongside the line above | | --autopilot | Keeps going until the agent calls task complete | Multi-step fixes | | --max-autopilot-continues=N | Caps autopilot continuation messages | Every autopilot run | | --plan --mode autopilot | Plans first, then implements without waiting for approval | Larger changes where I want a plan in the log | | -w , --worktree =NAME | Starts the session in an isolated git worktree | Anything that edits code unattended | | --no-ask-user | Disables the ask user tool | Headless runs, so it never waits on stdin | | --share=PATH | Writes the session to Markdown after a -p run | CI artifacts and review | | --model=auto | Lets Copilot pick the model | When I don't care which model runs | | --max-ai-credits=N | Soft cap on AI Credits per response | Cost guardrails on scheduled jobs | A few of those need more than a table cell. This is the line in the docs I wish more guides quoted: deny rules always take precedence over allow rules, even when --allow-all is set. That is what makes --allow-all-tools acceptable to me in a script. I grant broadly, then carve out what must never happen. The pattern syntax is small: shell git: matches git push , git pull and so on. The : suffix matches the command stem followed by a space, so it does not match gitea . shell git push matches that exact command. write src/ .ts limits file writes by glob. url github.com scopes URL access. The reference example is exactly the shape I use: allow all of git, deny push. copilot --allow-tool='shell git: ' --deny-tool='shell git push ' For multiple rules, pass a quoted, comma-separated list. Malformed patterns are rejected with an error rather than silently ignored, which I appreciate. --yolo and --allow-all are the same switch tools + paths + URLs . There is also COPILOT ALLOW ALL for harnesses that can only set environment variables. I treat all three as "only inside a container or a throwaway worktree". Autopilot --autopilot , or Shift+Tab interactively keeps the agent working until it decides the task is done. An older changelog entry says continuations were capped at 5 by default. The current reference lists the default for --max-autopilot-continues as unlimited . I don't rely on either: every autopilot run I script sets the cap explicitly. One gotcha: --plan cannot be combined with --autopilot . If you want plan-then-execute, the supported form is --plan --mode autopilot . The session starts in plan mode and moves to autopilot once the plan is ready. For harnesses that can't pass flags, the same behavior is behind COPILOT PLAN THEN AUTOPILOT . --worktree used to require experimental mode. It no longer does. It creates or reuses a worktree under