Key Takeaway
Claude Code permission modes set how much the agent can do before it stops to ask. Default prompts for risky actions, acceptEdits auto-approves file edits, plan mode is read-only, and bypassPermissions skips approvals entirely. Choosing the right mode for each task is the main dial between moving fast and staying safe.
Every action an AI coding agent takes sits somewhere on a line between harmless and irreversible. Reading a file is safe; editing one is usually fine; running a shell command that deletes data or calls the network is not something you want to happen without your say-so. Permission modes are how Claude Code lets you set where that line falls.
Rather than one fixed policy, Claude Code gives you a small set of modes that trade approval prompts for autonomy in different amounts. This guide explains each mode, how to switch between them, and how to match the mode to the task so you are neither rubber-stamping every edit nor handing the agent a blank cheque.
The permission modes
Claude Code groups its behaviour into a handful of modes, each defining what happens automatically and what pauses for your approval. Knowing the four you will actually use covers almost every situation.
From most cautious to most permissive, they are:
- Plan mode is read-only: the agent can explore and propose an approach but cannot edit files or run commands, which makes it ideal for thinking before touching anything.
- Default mode lets it work but prompts you before risky actions such as editing files or running shell commands, keeping a human in the loop on anything with consequences.
- The acceptEdits mode automatically approves file edits so you are not clicking through every change, while still gating the more dangerous operations.
- The bypassPermissions mode skips approval prompts altogether, letting the agent run unattended, which is powerful and the easiest way to cause real damage.
How to switch modes
You can change modes on the fly inside a session or set them up front. Interactively, pressing Shift+Tab cycles through the modes, so you can drop into plan mode to design and then step up to a working mode once you agree on the approach. For headless and scripted runs you pass the mode as a flag.
You can also express standing policy in settings rather than choosing every time. An allow-and-deny list in your project settings names exactly which tools and commands are permitted, so the agent behaves consistently across the team:
{
"permissions": {
"allow": [
"Read",
"Edit",
"Bash(npm run test:*)"
],
"deny": [
"Bash(rm -rf:*)",
"WebFetch"
]
}
}Start almost every non-trivial task in plan mode. Letting the agent read the code and lay out its approach before it can change anything catches misunderstandings while they are still free to fix, and it means that when you do switch to a working mode, it is executing a plan you already agreed to rather than improvising.
Match the mode to the task
The right mode is a function of how reversible the work is and how much you trust the environment it runs in. A few defaults cover most days.
- Exploring an unfamiliar codebase or planning a change: plan mode, so nothing is edited while you think.
- Normal feature work at your terminal: default mode, approving the handful of risky steps as they come up.
- A long, well-scoped refactor you are actively watching: acceptEdits, to skip the flood of edit prompts without losing command approvals.
- Fully unattended automation: bypassPermissions only inside a sandbox or disposable environment, never against a machine with production access.
The autonomy-versus-safety trade-off
Each step toward more autonomy removes a checkpoint where a human would have caught a mistake. That is the whole appeal and the whole risk: fewer prompts mean faster work and less friction, but also fewer chances to stop a bad action before it lands.
The danger is not evenly spread across actions. Editing a file is easy to review and easy to undo; a shell command or a network call can be neither. That is why the modes keep gating commands even when they stop gating edits, and why the jump to skipping all approvals is a genuine change in risk rather than just more convenience.
Treat bypassPermissions as a mode for sandboxes, not for your main working machine. With approvals off, a single instruction hidden in a file the agent reads or a page it fetches can run commands with your full access. If you need unattended autonomy, get it from an isolated environment, not by disabling the checks on a trusted one.
Build safe defaults
Permission modes work best as part of a standing setup rather than a decision you improvise under pressure each session.
- Commit an allow-and-deny list to your project so every teammate and CI run inherits the same boundaries by default.
- Default to the most restrictive mode that still lets the task move, and step up autonomy only when the work clearly warrants it.
- Pair any permissive mode with a sandbox, so the safety comes from the environment and not only from your attention.
Permission modes are the single most important safety dial in Claude Code. Learn the four, cycle with Shift+Tab, encode standing rules in an allow-and-deny list, and keep the most permissive modes locked inside sandboxes. The goal is not maximum autonomy or maximum caution but the least autonomy each task actually needs, which is where speed and safety stop fighting each other.

