Blog
GitHub Copilot CLI --allow-all and --yolo: what you approve, and what still says no
Copilot CLI's yolo flag is really three flags, and for most of this year there was no sandbox to pair it with. There is now, and it is off until you turn it on.
In GitHub Copilot CLI, --yolo is an alias for --allow-all, which is --allow-all-tools, --allow-all-paths and --allow-all-urls together. It removes the approval prompts and nothing else. Deny rules still win over it, and local sandboxing is a separate setting that is off by default, so a bare --yolo session runs commands with your user's full access, network and credentials. Forkbench adds the missing half: a key used through Vault never enters Copilot's environment.
One alias, three permissions
Copilot CLI asks about three different things: which tools may run, which paths may be touched, and which URLs may be fetched. --allow-all-tools, --allow-all-paths and --allow-all-urls each approve one of them. --allow-all approves all three, and --yolo is its alias, added in version 0.0.381 in January 2026.
Inside a session, /allow-all or /yolo does the same, and it sticks for the rest of the session. /reset-allowed-tools puts the prompts back.
This is the standalone copilot agent, not the older gh copilot extension, which only suggested and explained commands and never edited files or ran anything.
Deny rules are the part that survives
Before reaching for --yolo, it is worth knowing the finer tools. --allow-tool approves a pattern such as shell(git:*), and --deny-tool refuses one. GitHub's documentation is explicit that deny rules take precedence over allow rules even when --allow-all is set.
That makes a short deny list the cheapest protection you can add. Deny the commands that cannot be undone, deny writing the files that hold secrets, and --yolo stops being all or nothing.
Autopilot, which lets Copilot keep working across turns, is a separate setting again. It decides whether Copilot continues, not what it is allowed to do while it does.
The sandbox is new and starts off
Until local sandboxing is enabled, GitHub's own documentation says shell commands execute directly on your machine with the same access as your user account, can reach any network and can use your credentials without restriction. That was the only mode available from January, when --yolo arrived, until October 2026.
Local sandboxing reached general availability in version 1.0.93 on 7 October 2026. It runs commands in Microsoft's MXC container, which is Seatbelt on macOS and bubblewrap on Linux. With it on, outbound network is allowed by default and the local network is denied.
Two limits are worth knowing. The sandbox is independent of --yolo, so it only helps if you turned it on. And Copilot's own file read and write tools run inside the CLI process, checked by policy rather than by the operating system.
How this works in Forkbench
Forkbench is a desktop app for running coding agents. It runs the copilot binary in a real shell with your permissions config untouched, and Copilot reaches the Thread's notes, board and keys through the fb command on its PATH.
The gap it closes is the one in GitHub's own sentence above: use your credentials without restriction. A key in Vault is used by the command that needs it without the value entering Copilot's environment, prompt or transcript, so --yolo has nothing to spend it on. A Thread can also be locked to a set of folders at the kernel, which bounds Copilot's in-process file tools too, since the lock applies to the process itself rather than to the commands it spawns.
The limit: with outbound network allowed, a command you let run can still send what it was given. Keeping the key out of the process is the part that does not depend on that.
Related: Yolo mode in every coding agent, compared, GitHub Copilot CLI in Forkbench, Claude Code: what --dangerously-skip-permissions actually skips
Frequently asked
What does copilot --yolo do?
It is an alias for --allow-all, which combines --allow-all-tools, --allow-all-paths and --allow-all-urls. Copilot CLI stops asking before running tools, touching paths or fetching URLs. Deny rules you have set still apply.
Does --allow-all override --deny-tool in Copilot CLI?
No. GitHub's documentation states that deny rules take precedence over allow rules even when --allow-all is set, so a denied command stays denied in yolo mode.
Does GitHub Copilot CLI have a sandbox?
Yes, since version 1.0.93 in October 2026, and it is off by default. It uses Microsoft's MXC container, Seatbelt on macOS and bubblewrap on Linux, and it is independent of --yolo, so it has to be enabled separately.
How do I approve only git commands in Copilot CLI?
Use --allow-tool='shell(git:*)' instead of --allow-all. Copilot then runs git commands without asking and keeps prompting for everything else.
Can Copilot CLI read my API keys in yolo mode?
Yes, if they are in its environment or in a file it can read. Without the sandbox, commands run with your user's full access and network. Keep keys out of the process, for example through Forkbench's Vault, so there is no value in reach for an approved command to send.