GitHub gives enterprises a kill switch for Copilot's yolo mode

You handed an AI agent a shell. (You also asked it nicely to behave.) Somewhere in that arrangement, between the prompt and the next rm, sits a toggle labelled approve every command without asking — and your developers found it about the same week you read about it. As of June 17 GitHub is letting administrators take the toggle away from them, centrally, with one key in a JSON file.

The setting itself

The new key is disableBypassPermissionsMode. Set it to "disable" in enterprise-managed settings and Copilot CLI plus the VS Code Copilot extension lose the ability to skip the per-command approval prompt — what the GitHub documentation now openly calls yolo mode (also written up as "auto-approve"). The change applies to users licensed through Copilot Business or Copilot Enterprise. VS Code needs to be on a recent build for the policy to take effect.

It also happens to be the first governance capability that ships in enterprise-managed settings at all. Until today that configuration plane was vendor defaults plus developer convenience. Now it carries policy.

Why your platform team cares

Bypass mode is the failure case every supply-chain review has been quietly afraid of: an LLM running shell commands with no human in the loop, deciding on its own whether to curl, npm install, or write into ~/.ssh. The thing you could not quite forbid because there was nowhere to forbid it. Now there is.

What moved is not the agent's trust boundary. It is the developer's. Until this week an enterprise could tell engineers "do not run Copilot CLI in yolo mode" in a wiki page and rely on culture to do the rest. Today it can flip one bit, file it next to SSO and branch protection, and move on. Same policy plane, same review pipeline, same humans approving the change.

Down in the JSON

The setting lives where the rest of the enterprise-managed Copilot configuration lives — a JSON file inside the .github-private repository the enterprise has already wired up for custom agents:

{
  "disableBypassPermissionsMode": "disable"
}

Two paths are recognised: the original copilot/settings.json and a newer copilot/managed-settings.json. Both work; the newer one is the one to reach for if you are configuring this fresh. Verification lives under AI controls → Agents in enterprise settings, where the active configuration is shown back to you.

What this is not

A few things to keep honest, because the framing will get loose in some retellings.

This does not disable Copilot. It does not stop the agent from running commands. It forces the approval prompt back into the loop — that is the entire mechanism. A distracted engineer will still click yes. If your threat model is human-in-the-loop is asleep at the keyboard, this is a guardrail. If it is the laptop is already compromised, this is theatre. Useful theatre, but theatre.

The scope is also narrow on purpose: Copilot CLI and the VS Code extension. Third-party coding agents installed on the same workstation, the half-dozen MCP servers your team spun up last sprint, the homegrown shell wrapper around an LLM API — none of those see this setting. Governance for those is still on you.

How peers handle the same question

Across the rest of the agent-runtime ecosystem the controls are uneven. Most coding-agent runtimes ship some form of per-command confirmation prompt, an auto-approve toggle, and a coarse allow-list for "safe" commands. What varies is whether that toggle can be enforced from above. Some vendors lean on OS-level sandboxing — containers, ephemeral VMs — and treat approval prompts as belt-and-braces. Others route every agent-invoked command through a policy engine (OPA, Cedar) on the runner, so the question becomes does the rule say yes rather than did the human click yes.

Each model has a different failure mode. Prompts depend on human attention. Sandboxes depend on escape resistance. Policy engines depend on someone actually writing rules that match the threat. GitHub picked the simplest of the three for this release — turn the dangerous mode off centrally — which is also the model most likely to be flipped on in practice.

The hard part of agent governance was never the control. It was finding a place to put it.