Coding Agent Permission Modes Explained: Trust, Auto, Plan, and Full-Auto

Published September 28, 2026 · by the AQ team

A permission mode sets which actions an AI coding agent can take without stopping to ask you first: reading files, editing them, running shell commands, reaching the network. Every major agent CLI has one, under different names: Claude Code has six modes from Manual to bypassPermissions, Codex splits it into a sandbox level and an approval policy, Cursor CLI auto-applies file edits but prompts for shell commands, Devin CLI puts a workspace trust prompt in front of five modes, and OpenCode uses a per-tool allow, ask, or deny table. This guide maps all five, with the exact flag or setting for each, verified on each vendor's documentation as of September 2026, and ends with the one rule that makes any of them safe to loosen: the fewer questions the agent asks, the smaller its blast radius must be.

What a permission mode actually controls

Two layers decide what an agent can do. The approval layer decides whether the agent pauses for a human before an action; the containment layer (an OS sandbox, a container, a VM, an isolated git worktree) decides what the action can reach once it runs. A permission mode only moves the approval layer between "ask about everything" and "ask about nothing"; it does not, by itself, stop a bad command from doing damage. Read each mode below as a statement about who reviews each action: you, a smaller model, a static allowlist, or nobody.

Claude Code: six modes, from Manual to bypassPermissions

As of September 2026, Claude Code has six permission modes, set with the --permission-mode flag, cycled in a session with Shift+Tab, or defaulted via permissions.defaultMode in a settings file:

• default (labeled Manual in the UI): only reads run without asking; everything else prompts.
• acceptEdits: reads, file edits, and common filesystem commands (mkdir, touch, mv, cp) run without prompting; other shell commands still ask.
• plan: read-only exploration; edits are blocked until you approve a proposed plan.
• auto: a second model, a safety classifier, reviews actions instead of you. With Claude Code v2.1.283 or later it is the built-in starting mode for interactive terminal and VS Code sessions; organizations can turn it off (disableAutoMode).
• dontAsk: reads and explicitly pre-approved tools run; anything that would have prompted is denied instead. Built for CI, paired with --allowedTools.
• bypassPermissions: everything runs. Started with --dangerously-skip-permissions, and Anthropic's docs say to use it only in isolated containers or VMs, as a non-root user.

Permission rules layer on top: allow rules pre-approve specific tools, ask rules force a prompt, and deny rules block in every mode, including bypassPermissions.

Codex: a sandbox level times an approval policy

OpenAI's Codex CLI does not have one mode ladder. It has two independent knobs, and the combination is the mode. The --sandbox flag picks what commands can touch: read-only (read files, write nothing), workspace-write (write inside the current repo and temp directories, network off by default, with Git internals and agent config directories kept read-only), or danger-full-access (no filesystem or network restriction). The --ask-for-approval flag picks when you are asked: on-request prompts only when a command needs to escalate past the sandbox (a write outside the workspace, network access), never disables prompts, and a granular policy in config.toml prompts by category.

What people call "Codex auto mode" is the Auto preset: workspace-write plus on-request, Codex's recommended default in a version-controlled folder (without version control it starts read-only). Codex edits and runs commands freely inside the repo and interrupts you only at the boundary. The old --full-auto shortcut for that combination is deprecated as of September 2026; use the explicit flags. The everything-off switch is --dangerously-bypass-approvals-and-sandbox (alias --yolo): no prompts, no sandbox.

# The Auto preset, spelled out
codex --sandbox workspace-write --ask-for-approval on-request

Cursor CLI: edits are free, commands prompt, --force opens both

Cursor's cursor-agent inverts the usual default. As of September 2026, reads and searches need no approval and workspace file edits are applied and saved without prompting (configuration files excepted); your undo is version control. Shell commands and MCP tools are what prompt. Control comes from allow and deny rules in ~/.cursor/cli-config.json (global) or .cursor/cli.json (per project), written as patterns like Shell(git), Write(path), or Mcp(server:tool), with deny always beating allow. The --force flag (alias --yolo) allows everything not explicitly denied. Non-interactive print mode (-p) flips to safe-by-default: without --force the agent only proposes changes, with it they are applied.

Devin CLI: trust the workspace first, then pick a mode

Cognition's Devin CLI puts a gate in front of the mode question. The first time you run it in a folder, it asks whether you trust the workspace; approve once and the answer is remembered for future sessions in that folder. Non-interactive --print runs cannot show the prompt, so they fail in an untrusted directory; pass --respect-workspace-trust false to skip the check in scripts and CI, and only for directories your pipeline controls.

After trust, the --permission-mode flag (or the DEVIN_PERMISSION_MODE environment variable) picks one of five modes, as of September 2026:

• normal (the default; its alias is auto): reads are auto-approved, and every file edit or shell command prompts. If you searched "devin cli auto mode" expecting a bypass: auto is just the default mode's other name.
• accept-edits: workspace file edits are auto-approved; shell commands and writes outside the workspace still prompt.
• smart: a fast safety model judges each action and auto-runs only what it deems safe, prompting otherwise.
• dangerous (aliases yolo and bypass): every prompt is auto-approved. Organization-level deny and ask rules set by an admin still apply.
• autonomous: requires --sandbox, which wraps tool processes in an OS-level sandbox (Seatbelt on macOS, bwrap plus seccomp on Linux) and auto-approves within it; it is the only mode available when --sandbox is set.

OpenCode: no modes, a permission table

OpenCode skips named modes entirely. A permission block in opencode.json assigns allow, ask, or deny to each tool (edit, bash, webfetch, read, and more), with glob patterns per command or path, and per-agent overrides. The default posture is permissive: as of September 2026, most tools, including edit and bash, default to allow, with guardrail exceptions (access outside the project directory asks, a tool call repeating identically three or more times asks, and .env files are denied). An OpenCode setup that prompts like Claude Code's Manual mode is something you write yourself:

{
  "permission": {
    "edit": "ask",
    "bash": { "*": "ask", "git status": "allow", "npm test": "allow" }
  }
}

The five harnesses at a glance

Data as of September 2026, from each vendor's documentation.

The rule: the looser the mode, the smaller the blast radius

Every ladder above trades review for speed, and the trade is only sound when containment rises as approval falls. Manual or plan mode on your laptop needs nothing extra: you are the containment. An accept-edits tier is fine in a dedicated git worktree, where a bad edit is a branch you delete. But any bypass tier (bypassPermissions, --yolo, dangerous, a blanket allow table) should meet three conditions first: the agent works in an isolated worktree so the damage ceiling is one branch, it runs on an isolated machine (a container or VM, not the laptop with your SSH keys and browser sessions), and the session is visible afterward, so someone can establish what actually ran. Limiting what a coding agent can destroy covers containment in depth, and safe AI coding agents on your own repos covers the repo side. Teams running agents unattended, as in overnight runs, live at the loose end of the ladder and need the strong end of the isolation.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. AQ does not replace any mode above; the CLIs run as themselves, in persistent tmux sessions on your team's VM, so whatever permission mode you pick is the one that runs. What AQ supplies is the containment side of the rule: every workspace gets its own isolated git worktree (branch ai/{id}-{slug}), the machine is your team's VM or a dedicated AQ-managed one rather than anyone's laptop, and there is no shared multi-tenant execution tier. Visibility comes with it: sessions stream live to the browser, and teammates can open the same workspace and watch the same live session (typing into someone else's terminal requires the owner approving a control request). A Devin CLI session in dangerous mode is a different risk on an isolated VM with the team watching than alone on a laptop.

Each person logs into the CLIs with their own Claude or OpenAI account, and AQ never marks up usage on your own subscriptions. The Free plan is a personal sandbox with nothing to install: AQ creates a private machine in an isolated network, with no time limit, so you can try a looser mode somewhere it genuinely cannot hurt you.