Match the permission mode to the risk of the task. For sensitive work, use the mode that asks about each action. For iterating on code you review, auto-approving file edits is reasonable. For CI, use a mode that denies anything unlisted. Use the mode that skips every check inside isolated containers or virtual machines only.
Definitions
A permission mode sets which actions an agent can take without asking you. The table below uses Claude Code's documented modes as an example. Other agents use different names for similar ideas.
| Mode | What runs without asking | Documented fit |
|---|---|---|
| Manual (config value default) | Reads only | Reviewing every action, sensitive work |
| Accept edits | Reads, file edits and common file commands such as mkdir, mv and cp | Iterating on code you are reviewing |
| Plan | Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it |
| Auto | Everything, with background safety checks by a separate classifier model | Long tasks, reducing prompt fatigue |
| Don't ask | Reads in working directories and pre-approved tools, anything else denied | Locked-down CI and scripts |
| Bypass permissions | Everything | Isolated containers and VMs only |
How to choose, step by step
- Classify the repository. Production infrastructure, customer data or signing keys call for manual mode and a sandbox.
- Classify the task. Reading and planning are low risk. Running installs, deleting files and network calls are higher.
- Start strict and widen with evidence. Add allow rules for commands you approve repeatedly instead of switching the whole session to a looser mode.
- Layer deny rules. The documentation says deny rules block in every mode, including bypass, while allow rules have no effect in bypass.
- Use a sandbox when you reduce prompts. Fewer prompts need a boundary the operating system enforces.
- Put CI in the locked-down mode. Anything not pre-approved is denied, which is what you want for unattended runs.
- Reserve bypass for disposable environments with no real credentials and limited network.
- Write down who may pick the mode for which repositories, and enforce it with organization settings where you can.
Cautions
- A mode reduces prompts. It does not reduce what a manipulated agent could do within its permissions.
- Auto mode relies on a classifier model to review actions. It is a safety check, not a guarantee, and the vendor says no system is immune to all attacks.
- The documentation says some actions are never auto approved in any mode, such as removals targeting critical paths and tools matched by an explicit ask rule.
- Settings in a project file may not be able to switch on the riskiest modes. The documentation says auto and bypass values in shared project settings do not take effect.
Quick check
Is auto mode safe enough for production repositories?
That is a risk decision for you. Auto mode has safety checks, but for production infrastructure many teams keep manual mode and a sandbox.
Why not allow every command I approve often?
You can allow specific commands. A narrow allow rule beats a looser mode because it keeps everything else behind a prompt.
Who should be allowed to use bypass mode?
Anyone, but only in a throwaway container or VM with no sensitive credentials mounted.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for agent activity, and dependency scanning that runs on whatever the agent changes. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
