DEV Community

Cover image for GitHub Copilot's assisted permissions went GA: an LLM now decides which commands run without asking you
Piekwerk
Piekwerk

Posted on

GitHub Copilot's assisted permissions went GA: an LLM now decides which commands run without asking you

On October 26 GitHub made assisted permissions generally available in GitHub Copilot CLI, the GitHub Copilot app, and VS Code. The mechanism is one sentence: when Copilot asks permission to run a command, access a file system path, or open a URL, a large language model evaluates the request, and requests it classifies as clearly safe proceed without asking you. Everything else still waits for a click.

I have spent two months writing about agent permission layers, from Claude Code's deny rules and sandbox fixes to Copilot's default policy timer. An LLM sitting inside the approval loop is a change of kind, not just another toggle. Here is what shipped, where the switches live, and the parts I would not lean on.

What actually shipped

Assisted permissions sit between the two modes everyone already knows. Manual approval asks for every tool use. Allow All asks for nothing. Assisted asks a model first, and the model's verdict of clearly safe is what skips the prompt.

The evaluation covers three request types: commands, file system paths, and URLs. That scope matters. Shell commands are the obvious case, but the classifier also decides which files the agent may read and which hosts it may contact, which are exactly the two channels a leaking agent would use.

Where you turn it on

The changelog gives one enablement path per surface:

Copilot CLI:   run /permissions, then select assisted
Copilot app:   mode picker, then Tool permissions, then Assisted
VS Code:       permissions picker, then Assisted permissions
Enter fullscreen mode Exit fullscreen mode

Per person and per surface, this is opt-in today. The interesting lever is not these clicks, it is the enterprise layer underneath them.

The enterprise controls matter more than the toggle

Enterprise-managed settings can do three things here:

  • Block Allow All while keeping Assisted available.
  • Disable Assisted separately.
  • Choose the default permission mode for new sessions.

Developers can still pick any other mode the policy permits. And if the default mode is unavailable or prohibited by policy, the session starts with manual approval. That fallback direction is the detail I like most: when policy is ambiguous, the product fails toward asking, not toward silence.

What clearly safe can miss

My concern is not the exotic prompt injection story. It is the boring, context-dependent request. git clean -fd is a reasonable command in a clean clone and a small disaster in a tree with uncommitted work. Reading .env is just a file read, until the contents land somewhere with a longer memory than your terminal. A URL can be fine at 9am and hostile at 9:15. The classifier sees the request. It does not see your afternoon.

The changelog publishes no rule set and no false-approval rate, so treat assisted mode as a probability, not a policy. Deterministic rules have their own failure mode, though. Anthropic shipped fixes for 15 guardrail bypasses across two Claude Code releases in one week earlier this month, which is evidence that hand-written rules rot too. The honest position is layering: a classifier for the boring majority, a short deny list for the fatal few, and a periodic look at what actually ran.

The checklist I would run before telling a team

1. Set the org-wide default mode before individuals discover Allow All.
2. Block Allow All and keep Assisted. The changelog ships this exact control.
3. Write down the five commands you never want auto-run, and pin them to ask.
4. Once a week for the first month, review what auto-ran and where it differed from your expectation.
5. Re-check the default after every CLI release. This layer is still moving.
Enter fullscreen mode Exit fullscreen mode

None of that is clever. All of it is cheaper than unwinding an approved command you did not want.

Everyone is converging on the same shape

The same week shows the direction. Codex 0.164, out October 23, takes inline arguments on /permissions and named permission profiles, so the approval mode becomes something you configure per task instead of per session. Claude Code already logs which guardrail blocked an action through its safety_event output. And on the same October 26, GPT-6.1 Terra went generally available in Copilot, a cheaper model aimed at everyday terminal work. More terminal agent runs per team per day means more permission prompts to absorb, and a classifier is how you absorb them without turning permissions off. Classifier for volume, deterministic floor for the dangerous few, policy for the fleet. Three vendors, one shape.

What I am doing with it

I turned assisted on where the blast radius is small: scratch repos, containers, anything disposable. Where a repo holds secrets, keys, or infrastructure definitions, I keep manual approval and a written deny list, because the cost asymmetry is brutal. The advice from the default policy piece still stands, one layer up: decide the mode on purpose, or the product's default decides for you.

Top comments (0)