{"slug": "copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts", "title": "Copilot CLI in Late 2026: The Flags I Actually Use in Scripts", "summary": "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.", "body_md": "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.\n\nThis 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.\n\nOne 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.\n\nInstall is the same as it has been:\n\n`brew install copilot-cli` or `curl -fsSL https://gh.io/copilot-install | bash`\n`winget install GitHub.Copilot`\n`npm install -g @github/copilot`\nEach 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.\n\nThe 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`.\n\nHere is the short list I keep pinned. All of these come from the current command reference.\n\n| Flag | What it does | When I reach for it | \n|---|---|---|\n| `-p` ,`--prompt` | Runs one prompt and exits | Every scripted run | \n| `-s` ,`--silent` | Prints only the agent response, no usage stats | When stdout feeds another tool | \n| `--output-format=json` | Emits JSONL, one object per line | Logging runs for later inspection | \n| `--allow-all-tools` | Runs tools without confirmation | The reference lists it as required for programmatic use | \n| `--deny-tool=...` | Blocks specific tools or commands | Always, alongside the line above | \n| `--autopilot` | Keeps going until the agent calls `task_complete` | Multi-step fixes | \n| `--max-autopilot-continues=N` | Caps autopilot continuation messages | Every autopilot run | \n| `--plan --mode autopilot` | Plans first, then implements without waiting for approval | Larger changes where I want a plan in the log | \n| `-w` ,`--worktree[=NAME]` | Starts the session in an isolated git worktree | Anything that edits code unattended | \n| `--no-ask-user` | Disables the `ask_user` tool | Headless runs, so it never waits on stdin | \n| `--share=PATH` | Writes the session to Markdown after a `-p` run | CI artifacts and review | \n| `--model=auto` | Lets Copilot pick the model | When I don't care which model runs | \n| `--max-ai-credits=N` | Soft cap on AI Credits per response | Cost guardrails on scheduled jobs | \n\nA few of those need more than a table cell.\n\nThis 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.\n\nThe pattern syntax is small:\n\n`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.\nThe reference example is exactly the shape I use: allow all of git, deny push.\n\n```\ncopilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'\n```\n\nFor multiple rules, pass a quoted, comma-separated list. Malformed patterns are rejected with an error rather than silently ignored, which I appreciate.\n\n`--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\".\n\nAutopilot (`--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.\n\nOne 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`.\n\n`--worktree` used to require experimental mode. It no longer does. It creates or reuses a worktree under `<repo>.worktrees/` and starts the session there. A `worktreeBaseRef` setting decides whether it branches from `HEAD` (now the default) or the remote default branch. `worktreePathTemplate` lets you put worktrees somewhere else, with placeholders like `{repo}` and `{branch}`.\n\nThis is the skeleton of a nightly \"fix the flaky test\" job. The prompt varies; the guardrails don't.\n\n``` bash\n#!/usr/bin/env bash\nset -euo pipefail\n\n# Fine-grained PAT with the \"Copilot Requests\" permission.\nexport COPILOT_GITHUB_TOKEN=\"${COPILOT_PAT:?missing COPILOT_PAT}\"\n\ncopilot \\\n  -p \"Read test-results/junit.xml, find the root cause of the failing test, fix it, and run the test suite again. Only edit files under src/ and tests/.\" \\\n  --worktree=nightly-flaky-fix \\\n  --allow-all-tools \\\n  --deny-tool='shell(git push),shell(rm:*)' \\\n  --no-ask-user \\\n  --autopilot \\\n  --max-autopilot-continues=8 \\\n  --silent \\\n  --share=./artifacts/copilot-session.md\n```\n\nWhy each piece is there:\n\n`--worktree` means whatever it does lands on a separate branch I can diff in the morning.`--deny-tool` blocks pushes and `rm`. Because deny wins, `--allow-all-tools` can't override it.`--no-ask-user` stops the run from hanging on a question nobody will answer.`--share` gives me the full transcript as a build artifact. Prompt mode exits non-zero if that export fails, so a broken artifact fails the job instead of passing quietly.\nIf a background shell or subagent outlives the turn, `-p` honors `COPILOT_TASK_WAIT_TIMEOUT_SECONDS`, which is worth setting on CI so a stuck process can't hold the runner.\n\nThese weren't in the guides I first learned from:\n\n`/every 1h Run frontend tests and report any failures` repeats a prompt. `/after` runs one once after a delay. Handy for watching a long migration from a session you leave open.`/sandbox enable` restricts what the commands Copilot runs can touch on your filesystem and network. The CLI process itself isn't sandboxed. `copilot --cloud` runs the whole session remotely in an isolated environment. The per-run `--sandbox` flag is experimental-only for now.`copilot config`.`/settings`.`/agent`.`/usage` reports AI Credits used per session, and `--max-ai-credits` plus `/limits` let you cap them.\nThings that haven't changed: `@path` adds a file to the prompt, `!cmd` runs a shell command without calling the model, `/add-dir` and `/cwd` manage directories, and `copilot --continue` resumes the most recent session. Instructions still load from `.github/copilot-instructions.md`, `.github/instructions/**/*.instructions.md` and `AGENTS.md`. Pass `--no-custom-instructions` when you want a clean run.\n\nFor the full list, `copilot help permissions` and `copilot help environment` are faster than searching. The [official usage guide](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/overview) is the canonical reference.\n\n`VERSION=` in the install script (or the npm version) on CI. Then a default change shows up in a PR, not as a surprise in a nightly job.\n**Is Copilot CLI the same as `gh copilot`?**\n\nNo. This guide covers the standalone `copilot` command from the `github/copilot-cli` repo. It's an agent that can edit files and run commands. The GitHub CLI (`gh`) is a separate tool.\n\n**Can I use Copilot CLI without a paid plan?**\n\nThe docs say it's available on all Copilot plans. If you get Copilot through an organization, an admin must also enable the Copilot CLI policy, or you can't use it even with a seat.\n\n**How do I run Copilot CLI non-interactively in CI?**\n\nUse `-p` with a prompt, authenticate with `COPILOT_GITHUB_TOKEN`, and add `--allow-all-tools` with explicit `--deny-tool` rules. Add `--no-ask-user` so it never waits for input, and `--silent` or `--output-format=json` for clean output.\n\n**How do I stop autopilot from running forever?**\n\nSet `--max-autopilot-continues` every time. The current reference lists its default as unlimited.\n\nThe prompts are the easy part of Copilot CLI. The guardrails are the real work: deny rules, a continuation cap, a worktree, and a transcript you can read later. Get those four in place and headless runs stop being scary.\n\nAnd when a request turns out to be \"we need a whole new site or app\" rather than \"fix this repo\", I don't try to make a terminal agent do it. That goes to [Begin](https://begin.sh/?utm_source=devto&utm_medium=ugc&utm_campaign=selinorlov&utm_content=copilot-cli-outro), which builds a website, iOS app, Android app or Chrome extension from a prompt.", "url": "https://wpnews.pro/news/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts", "canonical_source": "https://dev.to/selinorlov/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts-4b0g", "published_at": "2026-10-07 03:13:48+00:00", "updated_at": "2026-10-07 03:17:54.914262+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents"], "entities": ["GitHub", "GitHub Copilot", "Copilot CLI", "Begin"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts", "markdown": "https://wpnews.pro/news/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts.md", "text": "https://wpnews.pro/news/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts.txt", "jsonld": "https://wpnews.pro/news/copilot-cli-in-late-2026-the-flags-i-actually-use-in-scripts.jsonld"}}