What you will be able to do
- Explain what plan mode allows and blocks, and how to enter it
- Tell which tasks need plan mode (multi-file, architectural, several valid approaches) and which can be done directly (one well-scoped change)
- Run a task as a planning phase followed by an implementation phase
- Name the four task traits that point to plan mode: large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications
Key concept
Plan mode — A permission mode where Claude reads the codebase and writes up a proposed approach but cannot edit source files until you approve the plan. It moves design decisions to before any code changes, when changing your mind costs nothing.
1.What plan mode actually permits
Claude Code always runs in one permission mode. The mode decides which actions go ahead without asking you. Plan mode is the one built for looking around before changing anything. The docs describe it this way: in plan mode "Claude explores and proposes a plan without editing your source files." You can start a session in it from the command line, or switch to it mid-session. In the CLI, Shift+Tab cycles through the modes.
claude --permission-mode planMany people get this wrong. Plan mode doesn't stop Claude working. It stops Claude changing things. The permission-modes table says plan mode lets "Reads, plus classifier-approved commands when auto mode is available" run without asking, and lists it as best for "Exploring a codebase before changing it." So Claude can read files and search the code freely while it builds a picture of the problem. The block applies to edits, and it stays until you approve a plan. That's why the mode is safe for exploration: nothing on disk changes until you've agreed to the approach.
One detail about entering the mode is easy to miss. In the CLI, the first press of Shift+Tab doesn't go to plan mode. The support guide says to press Shift+Tab twice, noting that "the first press enters acceptEdits", which is the mode that applies edits without asking.
Checkpoint 1 of 7· Check yourself
A developer presses Shift+Tab once from the default mode, asks for a refactor, and is surprised when files start changing. What happened?
The cycle goes to acceptEdits before plan mode. Reaching plan mode takes a second press.
“the first press enters acceptEdits”Source: support.claude.com
2.When a task calls for plan mode
Plan mode costs an extra round trip: Claude researches, you review a proposal, then the work starts. That cost is worth paying when a wrong first move would be expensive to undo. The support guide gives a rule of thumb: "For anything touching more than a couple of files, press Shift+Tab twice to cycle into plan mode". It also names the payoff. Reviewing the plan first "catches misunderstandings before they turn into a twelve-file diff."
The exam's examples all fit this pattern: restructuring a microservice, migrating a library that touches dozens of files, or choosing between integration approaches with different infrastructure needs. The docs don't list these particular scenarios. They follow from the rule. When a task spans many files, has more than one reasonable design, or depends on an architectural decision, a misunderstanding spreads into every file the change touches. Settling the approach in a plan is cheaper than reworking a large diff.
The docs' own example of a planning prompt asks about scope and design before any code is written: "I want to add Google OAuth. What files need to change?" It asks which files are involved and how the session flow works, then asks Claude to create a plan.
Plan mode is designed for complex tasks, and four traits mark them out:
- Large-scale changes. The work is big enough that a wrong direction means a lot of wasted effort. - Multiple valid approaches. More than one design could work, so someone has to choose before code is written. - Architectural decisions. The choice shapes the structure of the system, such as how services are split or which integration to use. - Multi-file modifications. A change that spans multiple files, where you want to review the full scope before any edits are made.
The cost guide states the purpose directly: Claude explores the codebase and proposes an approach for your approval, "preventing expensive re-work when the initial direction is wrong." The support guide's use case for multi-file changes says the same thing from the other side: "A change spans multiple files and you want to review the full scope before any edits are made." Plan mode gives you a safe place to explore and design first. The commitment to changing code comes only after you approve the plan.
Plan how you'd add rate limiting to the public API. Don't change anything yet.Checkpoint 2 of 7· Exam question
A platform team is restructuring a monolith into three microservices, touching shared data models, service boundaries, and deployment topology, with several viable ways to split the code. Before any files are changed, which approach should the architect direct Claude Code to take?
Correct answer: B — Enter plan mode so Claude explores the codebase, evaluates the competing service boundaries, and proposes a design before any edit is approved
- A. Accept-edits mode lets Claude write files immediately, so boundary mistakes get baked into multiple files before anyone reviews the overall design.
- B. Correct. Plan mode restricts Claude to read-only exploration and requires an approved plan before edits happen, which is exactly what a multi-file architectural decision with several valid approaches needs to avoid costly rework.
- C. Picking a split without investigation discards the architectural analysis the task needs and pushes discovery of structural errors to test time, after the damage is already spread across files.
- D. bypassPermissions removes prompts and safety checks entirely, which is the opposite of the deliberate, reviewable investigation an architectural restructuring calls for.
Checkpoint 3 of 7· Check yourself
Adding a new authentication provider needs new session logic, changes to token storage, updates to five service entry points, and a choice between two libraries. What's the strongest reason to start in plan mode?
The deciding factor is scope plus design uncertainty. A wrong approach would spread across many files, and reviewing a plan catches that first.
“This catches misunderstandings before they turn into a twelve-file diff.”Source: support.claude.com
3.When to skip the plan and execute directly
"Direct execution" isn't a mode name in the docs. It means giving Claude the task in a mode that lets it make changes (default, acceptEdits or auto) without a separate planning round first. This fits well-understood changes with clear scope: one validation check in one function, or a single-file bug fix where the stack trace already points to the line.
The docs' everyday recipes show this. The bug-fix workflow ends with a direct instruction: "update user.ts to add the null check you suggested." The support guide's model prompt states the symptom and the expected result in one go: "Users with no email are crashing the validation step. Make it handle that gracefully and add a test." When the scope is clear, good context does the job a plan would otherwise do. The guide advises "Paste the full stack trace rather than summarizing it," because the exact file, line and message let Claude find the right place quickly.
| Mode | What runs without asking | Best for |
|---|---|---|
| default | Reads only | Reviewing every action yourself, sensitive work |
| acceptEdits | Reads, file edits, and common filesystem commands (mkdir, touch, mv, cp, etc.) | Iterating on code you’re reviewing |
| plan | Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it |
| auto | Everything, with background safety checks | Long tasks, reducing prompt fatigue |
The same reasoning applies outside interactive sessions. For a narrow, pre-approved change in a pipeline, the permission-modes guide points to dontAsk with an exact --allowedTools list. You get a tight allowlist, not a planning step. That setup belongs to the CI lessons. The point here is that a task with no open design questions has nothing for a plan to settle.
Checkpoint 4 of 7· Exam question
A stack trace points to a null check missing in a single function inside one file, and the fix is a one-line conditional. Which workflow best matches the scope of this change?
Correct answer: C — Direct execution, since the change is a well-scoped, single-file fix with a clear cause already identified from the trace
- A. Plan mode is for tasks with multiple valid approaches or architectural implications; forcing every bug fix through it adds friction without benefit when the fix and cause are already clear.
- B. The Explore subagent isolates verbose discovery output for large investigations; there is no substantial discovery phase here since the cause is already known from the trace.
- C. Correct. A single-file fix with a clear, already-identified cause is a well-understood, well-scoped change, which is exactly what direct execution is suited for.
- D. Breaking a one-line, already-diagnosed fix into multiple phases adds unnecessary process overhead for a change this small.
Checkpoint 5 of 7· Check yourself
Which task is the best fit for direct execution, with no planning round?
A single, well-specified change in one place has no competing designs to weigh. The other three span many files or depend on an architectural choice.
“Users with no email are crashing the validation step. Make it handle that gracefully and add a test.”Source: support.claude.com
4.Combining the two: plan, then implement
Plan mode and direct execution aren't rival choices for a whole task. Large tasks usually use both, one after the other. The best-practices guide sets out a three-step workflow. In Plan, you ask what files need to change and request a plan. In Implement, you say "implement the OAuth flow from your plan." with tests and fixes. In Commit, you ask Claude to "commit with a descriptive message and open a PR".
The support guide describes the hand-off: "Review the plan, adjust it in conversation, then switch modes" and ask Claude to do the first step. A library migration works the same way. Plan mode handles the investigation: which files use the old library and which migration approach fits. Once you've approved that approach, you switch to an editing mode and Claude carries it out. At that point the open questions are settled, so implementing it is a well-scoped job.
Checkpoint 6 of 7· Put it in order
Put the plan-then-implement workflow in order
- 1.Review the plan and adjust it in conversation
- 2.Ask Claude to commit with a descriptive message and open a PR
- 3.Enter plan mode and ask Claude to plan the change without editing anything
- 4.Switch to an editing mode and tell Claude to implement from the plan
Investigation and approval come first in plan mode. Implementation runs in a mode that can edit, and committing comes last.
“Review the plan, adjust it in conversation, then switch modes”Source: support.claude.com
Checkpoint 7 of 7· Fill the gap
Which value starts a session ready for the investigation phase of a migration?
claude --permission-mode ? plan starts the session in read-and-propose mode. Claude Code blocks edits until you approve a plan.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Plan mode asks for approval on every action, reads included, so Claude can't research on its own.Why is that wrong?
Plan mode lets reads (plus classifier-approved commands when auto mode is available) run without prompting. Only edits wait for an approved plan.
Covered in What plan mode actually permits
2.One press of Shift+Tab puts the CLI into plan mode.Why is that wrong?
The first press enters acceptEdits, which applies edits without asking. Plan mode takes a second press.
Covered in What plan mode actually permits
3.You pick plan mode or direct execution once for the whole task.Why is that wrong?
The recommended workflow plans first, then switches modes to implement the approved plan.
Covered in Combining the two: plan, then implement
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Plan: Claude explores and proposes a plan without editing your source files”
↩︎ What plan mode actually permits - 2.https://code.claude.com/docs/en/permission-modesOfficial docs
“Exploring a codebase before changing it”
↩︎ What plan mode actually permits“Claude Code blocks edits until you approve a plan”
↩︎ Combining the two: plan, then implement“Claude Code blocks edits until you approve a plan”
↩︎ Key concept“Reads, plus classifier-approved commands when auto mode is available”
↩︎ Exam trap 1“Reads, plus classifier-approved commands when auto mode is available”
↩︎ Prediction - 3.https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-promptsOfficial docs
“For anything touching more than a couple of files, press Shift+Tab twice to cycle into plan mode”
↩︎ When a task calls for plan mode“Paste the full stack trace rather than summarizing it.”
↩︎ When to skip the plan and execute directly“the first press enters acceptEdits”
↩︎ Exam trap 2“the first press enters acceptEdits”
↩︎ Checkpoint“This catches misunderstandings before they turn into a twelve-file diff.”
↩︎ Checkpoint“Users with no email are crashing the validation step. Make it handle that gracefully and add a test.”
↩︎ Checkpoint“Review the plan, adjust it in conversation, then switch modes”
↩︎ Checkpoint - 4.https://code.claude.com/docs/en/best-practicesOfficial docs
“I want to add Google OAuth. What files need to change?”
↩︎ When a task calls for plan mode“commit with a descriptive message and open a PR”
↩︎ Combining the two: plan, then implement“implement the OAuth flow from your plan.”
↩︎ Exam trap 3 - 5.https://code.claude.com/docs/en/costsOfficial docs
“Use plan mode for complex tasks: Press Shift+Tab to cycle to plan mode before implementation.”
↩︎ When a task calls for plan mode“preventing expensive re-work when the initial direction is wrong”
↩︎ When a task calls for plan mode - 6.
“A change spans multiple files and you want to review the full scope before any edits are made.”
↩︎ When a task calls for plan mode - 7.https://code.claude.com/docs/en/common-workflowsOfficial docs
“update user.ts to add the null check you suggested”
↩︎ When to skip the plan and execute directly