Permissions & plan review
Approval cards, plan review before a file changes, and what each of the six permission modes actually does — including why “Never interrupt” is the most restrictive.
Agents ask in the chat, not in a terminal prompt you have to go find. Tool calls arrive as approval cards, plans arrive as something you sign off before a file changes, and questions arrive as option pills.
Approval cards
When a session needs permission for a tool call — a command, an edit, a web request — it surfaces in the transcript where the work is happening. Approve or deny each one.
For tools you trust, always allow writes a rule so routine work stops interrupting you. Rules are per session and persist across turns.
Plan review
Ask for a plan and the agent proposes one as a card. Nothing is edited until you approve it. This is the cheapest intervention point in the whole loop: correcting an approach costs one message, correcting an implementation costs a review cycle.
Permission modes
A session's mode decides how much it can do without asking. There are six, listed here in the order the picker shows them — loosely most permissive first.
| Mode | Behaviour |
|---|---|
| Allow all | Runs every tool without asking, except when it has a question for you. |
| Auto-decide | Allows what it judges safe and asks you about the rest. Claude only. |
| Ask every time | Every gated tool call needs your approval. This is the default for new sessions. |
| Edits only | File edits auto-approved; MCPs and bash denied; still asks if it has a question for you. |
| Never interrupt | Never prompts — anything that would need approval is denied instead. |
| Plan only | Read-only — no writes, no tool side-effects. |
"Never interrupt" is the most restrictive mode, not the most permissive. The name reads like "stop bothering me, just get on with it", and it does the opposite: it never prompts and never allows, so anything that would have needed approval is denied. If what you want is fewer interruptions, you want Auto-decide or Edits only.
Two more worth knowing:
- Edits only denies rather than prompts. MCP tools and bash calls aren't escalated to you — they're refused. It is narrower than "edits go through and everything else asks".
- Auto-decide is Claude-only. It runs the CLI's own classifier, and Codex has no equivalent, so the option doesn't appear for Codex sessions.
These behaviours were measured against the real CLI rather than read off its documentation, because the names alone do not predict them.
If you work with the CLI directly you'll also meet the underlying identifiers — bypassPermissions, auto, default, acceptEdits, dontAsk and plan, in the same order as the table above.
Choosing a posture
Match the mode to the task, not to how much you trust the agent in general:
- Exploring an unfamiliar repo — Ask every time. You want to see every command until you know what it's doing.
- A well-specified change in code you know — Edits only. Edits flow; bash and MCP calls are refused, so the agent stays inside the files.
- Unattended work (schedules, fan-out lanes) — Allow all, in an isolated worktree or branch so the blast radius is bounded by where it runs rather than by what it may do.
- A session you want to reason but not act — Plan only.
Nothing waits silently
A blocked agent raises a hand: it appears in the needs-attention inbox and can fire an OS notification. The failure mode this exists to prevent is an agent sitting on a permission prompt for twenty minutes while you assume it's working.
Peer messages and permission
Permission posture also governs what a session will accept from another session — a peer message auto-delivers only between matching postures. See session messaging for why that rule exists and how to change a session's inbound gate.