Skip to main content
Plan approvals gate the changes the agent proposes to your infrastructure. Auto-authorization (Auto Mode) works one level down — on the individual shell commands the agent runs while it investigates and executes, both in its sandbox and as local commands. Without it, either every command runs unattended, or you approve each one by hand. Auto-authorization gives you the middle: safe commands run on their own, risky ones pause for you, and you decide where that line sits.

​
How a command is judged

When enabled, every command the agent runs passes through a layered check, in order:
  1. Read-only fast-path — commands that only read (kubectl get, ls, cat, a plain curl GET) run immediately. This is a deterministic check, not a model call, and a command only takes this path when it is unambiguously a read; anything the analyzer can’t be sure about falls through.
  2. Grants you already gave — a standing rule naming this exact command, or a command you approved earlier in this conversation, runs without asking again.
  3. The judge — an LLM checks the command against your standing rules (see below). It matches on effect, not on the mechanism: a curl PUT that updates a Grafana dashboard counts as modifying a Grafana dashboard. It reads rules narrowly and will not widen “restart staging deployments” to cover a delete or production. When it is genuinely unsure whether something mutates state, it asks you.
  4. Ask you — anything else pauses for a human decision.
If the judge is ever unavailable, Auto-authorization fails safe: the command pauses for approval rather than running unchecked. The same is true when no judge is configured — every non-read command asks.
There is no fixed list of operations that can never be auto-allowed. Destructive work — deleting namespaces, databases, volumes or buckets, terraform destroy, force-pushing, IAM changes — requires your authorization unless one of your own standing rules explicitly covers that class of operation. We removed the hard-coded floor we used to ship: pattern matching on command text let differently-phrased destructive commands through while blocking harmless ones that happened to match, and a list like that reads as a guarantee it can’t keep. What you get instead is a judge told to ask whenever it is uncertain, rules you write and activate yourself, and a journal of every decision. Be deliberate about which rules you activate.

​
Approving a command

When a command needs your yes, the turn pauses at that step — the agent stops and the command card shows four choices:

Approve once

Run this one command, this once.

Approve for session

Auto-allow this exact command for the rest of this conversation.

Always allow

Create a standing rule so this class of command auto-runs from now on, in every conversation.

Deny

Don’t run it — the agent stands down and suggests another approach.
Approving resumes the turn and the agent re-runs the command; denying leaves it stopped. “Approve for session” matches that exact command for the rest of the conversation. A retry with a tweaked flag is a different command and goes back through the judge, which is given your session approvals as context.

​
Bypass Permissions

There is an escape hatch. Bypass Permissions is a per-conversation switch that turns the gate off entirely: every governed command runs, with no fast-path, no rule matching and no judge. It exists because the alternative is worse — someone who needs to move now will otherwise leave the product and do the work by hand, where nothing is recorded at all. So the switch is built to leave a trail:
  • It is scoped to one conversation and never carries into another.
  • Turning it on and off is itself journaled, so the unguarded window has a start and an end you can point at afterwards.
  • Every command run under it is journaled with the bypass layer, not silently as an ordinary auto-allow.
  • The record expires 7 days after its last use, so a switch left on doesn’t stay on indefinitely.

​
Standing rules

Rules are how you move the line permanently. A rule is a plain-language description of a class of operations you trust the agent to run without asking — for example “restart deployments in the staging namespace”. They are per-user and apply across all your conversations. You can create rules two ways:
  • In Settings → Auto-authorization — add, review, and delete your rules in one list.
  • From chat — tell the agent “from now on you don’t need to ask before restarting staging deployments” and it will propose a matching rule. A proposed rule does nothing until you activate it in Settings — the agent can never weaken its own authorization.
Write rules for the narrowest class you actually mean. The judge won’t stretch a broad rule to cover destructive work, but it will honour a rule that names one explicitly — so “delete failed pods in staging” does what it says, and there is no second gate behind it.

​
Seeing why a command ran

Every auto-authorized command is annotated with why it was allowed — read-only, a rule you set (named), or a command you approved earlier in the session. Expand the command card to see it, so there’s never any doubt about what ran on its own and under whose authority. These decisions are also written to the audit trail.
Start strict: leave Auto-authorization off (or with no rules) so everything pauses, then add a rule the first time the agent asks about a command you’re happy to let it run unattended. Approving with Always allow writes that rule for you.