Every Claude Code session runs under a permission mode whether you've picked one on purpose or not. It's the setting that decides how much confirmation stands between "Claude wants to do this" and "Claude did this" — and getting it wrong in either direction either slows you to a crawl or hands an agent the keys to your filesystem without a second look.
There are four modes worth knowing, and most confusion comes from treating them as one dial instead of four genuinely different postures. Here's what each one actually controls, and how they interact with hooks and slash commands — the other two levers on agent behavior.
Default Mode: Ask Before Acting
Out of the box, Claude Code asks before anything that changes state — writing a file, running a shell command, calling a tool with side effects. Read-only actions (reading files, searching, listing directories) don't require confirmation, because there's nothing to undo. The moment an action could modify something outside the conversation, you get a prompt, and you approve or deny it.
This is the right default for exactly the reason it's the default: you don't know yet whether the agent's plan for a task matches your own, and the cheapest place to catch a mismatch is before the first file gets touched, not after five files got touched wrong.
Plan Mode: Read-Only by Design
Plan mode goes a step further than asking — it removes the ability to write or execute entirely, for the whole session, not action by action. Claude can read, search, and explore as much as it wants, but every write and every command gets held back until you exit plan mode. Instead of proposing one file at a time, the agent researches the full scope of a task and presents a complete plan up front: what it's going to change, in what order, and why.
The value here isn't caution for its own sake. It's that a plan is reviewable as a single unit in a way that a stream of individual file-edit approvals isn't. You can catch "this is going to touch six files I didn't expect" in one read, instead of discovering it three approvals deep when it's already half-done and awkward to unwind.
Use plan mode for anything where the shape of the change matters as much as the content — refactors that touch multiple files, unfamiliar codebases, or any task where you'd rather review the whole approach before a single line changes.
Auto-Accept Edits: Fast Iteration, Still Guarded
Auto-accept mode flips file edits from ask-every-time to approved-by-default, while leaving everything else — shell commands, anything with side effects beyond the file itself — still gated behind a prompt. This is the mode for tight, iterative loops: you already trust the direction, you want the agent to make a change, you check the diff, you move on, without a confirmation click breaking your flow every ten seconds.
The distinction that matters: auto-accept is scoped to edits specifically. It is not a blanket "stop asking me things" switch. A command that deletes a directory or force-pushes a branch still stops and asks, because those are a different risk category than "this function now has a different implementation."
Bypass Permissions: What It Actually Skips
Bypass mode removes confirmation prompts across the board — file writes, shell commands, everything. It exists for a specific use case: fully sandboxed environments, like a disposable container or CI job, where there's nothing on the other side of the agent worth protecting, and a human isn't going to be watching in real time anyway.
Running bypass mode on a machine with real credentials, real production access, or anything you'd mind losing is the single most common way people get burned by agentic coding tools — not because the model is malicious, but because it will confidently execute a wrong plan just as fast as a right one when nothing is checking its work. If you wouldn't hand a stranger unsupervised shell access to the same machine, don't hand it to bypass mode either.
Switching Modes Mid-Session
You're not locked into whatever mode you started with. Plan mode in particular is designed to be entered and exited within a single conversation — research and propose in plan mode, then exit into a normal ask-first (or auto-accept) mode to actually execute the approved plan. This two-phase pattern — plan, then act — is usually the safer default for anything nontrivial, because it separates "did the agent understand the task" from "is the agent executing it correctly," which are different failure modes that deserve different checkpoints.
Permission Modes vs. Hooks vs. allowed-tools
These get conflated because they all restrict agent behavior, but they operate at different layers. Permission mode is a session-wide posture — how much confirmation is required, full stop. Hooks are conditional and specific — a shell command that fires on an event and can block one particular action regardless of what permission mode is active. A slash command's allowed-tools frontmatter field scopes what a single custom command can touch, independent of the session's broader mode.
The practical takeaway: permission mode is your blast-radius dial for the whole session. Hooks are your hard rules that apply no matter what mode you're in — a hook that blocks writes to .env files should fire in auto-accept mode exactly as reliably as in default mode. Don't rely on permission mode alone to enforce something you actually need enforced; that's what hooks are for.
Which Mode for Which Task
- Default (ask-first) — general work, unfamiliar territory, anything where you want visibility into every individual change.
- Plan mode — multi-file refactors, first pass through a new codebase, any task where reviewing the full approach matters more than reviewing each file.
- Auto-accept edits — tight iterative loops on work you already trust the direction of, where you're checking diffs yourself rather than approving each one individually.
- Bypass permissions — sandboxed, disposable environments only. CI runners, throwaway containers, nothing with real credentials attached.
Common Mistakes
The recurring failure isn't picking the wrong mode once — it's leaving a permissive mode on by habit after the task that justified it is done. Auto-accept that made sense for one refactor becomes a liability on the next unrelated task in the same session. Bypass mode enabled for a CI job that later gets reused, unmodified, for local development on a machine with real secrets. Permission mode is a setting for the task in front of you, not a session-long default you set once and forget — reset to default (or plan) when the task that justified loosening it is finished.