Coding-agent permission modes: plan, auto-edit, or full access?

Giving a coding agent the broadest permissions can speed up a task, but it also enlarges the blast radius of a bad command. Requiring approval for every step looks safer, yet on a long job it can turn the operator into someone who clicks "approve" without reading. A better default is to match permissions to the changes the task must make.

Short answer: start with plan or read-only in an unfamiliar repository. Allow workspace edits for a bounded change that is under version control and cheap to test. Keep package installation, network access, migrations, secrets, deployment, and production actions behind separate approval gates. Consider full access only inside a disposable container or VM with a clear rollback path.

The three tools do not use the same names

OpenAI treats the Codex sandbox and approval policy as separate controls. The sandbox determines where a command can write and whether it can reach the network; the approval policy determines when the agent must stop and ask. Codex's local Auto preset can read, edit, and run commands in the workspace, then asks before writing outside it or accessing the network. OpenAI does not recommend "dangerous full access" as the default because it removes the sandbox and approval boundaries.[1]

Anthropic's current documentation says Manual (`default`) automatically allows reads only. `acceptEdits` adds file edits and common filesystem commands, `plan` supports exploration and planning, and `auto` lets a background safety classifier review actions. Anthropic positions `bypassPermissions` for isolated containers and VMs only. Those are Anthropic's product behavior and recommendations, not a promise that every action will be safe in every repository.[2][3]

Gemini CLI's `default` mode asks about tool calls, `auto_edit` automatically approves editing tools, and `plan` is read-only. `yolo` automatically approves all tool calls and can only be enabled from the command line. Google's Plan Mode documentation describes a read-only workflow for researching a codebase and reviewing an implementation plan before edits begin.[4][5]

Do not map those labels one to one. "Auto" may mean a workspace sandbox in one tool and a separate classifier in another. Make the choice from four permissions instead: reading, file writes, command execution, and network or external-system access.

Which permission fits which task?

1. Unfamiliar repository, architecture decision, or bug investigation

Choose plan/read-only. Let the agent inspect code and configuration, map the likely impact, and propose a change plan. It does not need write access yet. This works well for tasks framed as "find the problem first, then compare approaches."

Use a concrete exit condition: switch to editing only when the agent can name the files it expects to change, the tests it will run, and the rollback path. If the plan still says "update the relevant places," do not widen permissions.

2. Bounded local change

Workspace-write or auto-edit is the practical default. Examples include adding a test that follows an existing pattern, fixing one component, doing a local refactor, or resolving a lint error.

The repository boundary matters more than the mode label. Work on a separate branch. Put the acceptance criteria and test command in the prompt. Keep `.env`, key files, and paths outside the workspace closed. The agent may edit, but it should not deploy or write to an external service.

3. Package installation, network access, migration, or deployment

Keep an on-request/manual gate. `npm install`, an unfamiliar script, a database migration, Git push, CMS publication, and cloud deployment carry different risks, but each creates effects beyond a local diff.

Approve the action, not a vague request to "continue": which command will run, which target will change, and how can it be rolled back? Do not grant secrets, production writes, or broad network access as one bundle just because the agent's explanation sounds confident.

4. Long unattended CI job

Use a narrow allowlist in an isolated environment. Claude Code offers `dontAsk` for locked-down CI with pre-approved tools; Codex documents non-interactive combinations that remain read-only or stay inside workspace-write. The vendor guidance points to the same boundary: unattended does not mean unrestricted host access.[1][2]

Use an ephemeral runner. Allow only the commands and destinations the task needs. Keep tokens short-lived and least-privileged. Produce a pull request or artifact, then put production writes behind a separate system approval.

5. Full access

This is an exception, not an everyday development mode. It makes sense only when the environment is already disposable: an ephemeral container or VM with no sensitive data, a narrow network policy, and deletion at the end of the job.

Your main machine, home directory, or a runner holding production credentials does not qualify. Full access does not make a model reason better. It only lets a wrong decision travel farther.

A five-question rule

1. Can the agent make progress by reading and planning? Use plan/read-only.

1. Will `git diff` and tests expose a bad edit quickly? Use workspace-write or auto-edit.

1. Does the task need network, packages, secrets, migration, push, or deployment? Approve that action separately.

1. Will it run unattended? Use an isolated runner with command and destination allowlists.

1. Can you delete and rebuild the environment? If not, do not grant full access.

Permissions, models, and reasoning are separate choices. Use the GPT-5.6 Sol–Terra–Luna pillar guide to choose the model tier for the task. Use the Codex CLI vs Claude Code vs Gemini CLI task guide to choose the terminal agent, then run the seven-step output verification checklist before shipping. A stronger model or higher reasoning setting does not make unnecessarily broad permissions safe.

Singrey note

My default is boring but clear: plan first, allow workspace writes second, and approve each necessary external action at the end. I do not treat full access as a speed setting. When an agent can do more without asking, the workflow feels smoother, but an error I missed can travel farther too. I choose the permission level by how quickly I can undo a mistake, not by how much I trust the agent.