- In short
- Plan mode is a read-only Claude Code permission mode that tells the model to research a task and propose an implementation plan without editing any files. You use it when the approach is uncertain, the change touches many files, or an architectural decision has to be made before code is written.
What Claude Code plan mode actually is
Claude Code plan mode is a permission mode that changes one thing about how the agent behaves: it is allowed to read but not to write. When you enter plan mode, Claude reads files, runs read-only shell commands to explore, and assembles a step-by-step implementation plan, but it does not touch your source until you explicitly approve that plan and switch back to an editing mode. The official documentation describes it as a way to "analyze before you edit," and that framing is the whole point of this knowledge point.
The reason a dedicated mode exists is that an agent which can edit will usually start editing. Given a goal, the model's natural pull is toward action, and on a task where the right approach is not yet obvious that pull produces code that solves the wrong problem. Plan mode removes the temptation by removing the capability. With writes off the table, the only thing Claude can do is understand the problem and tell you how it intends to solve it.
- Plan mode
- A read-only Claude Code permission mode in which the agent researches a task and proposes an implementation plan without editing any files, leaving the decision to proceed with you.
Why plan mode matters for the Claude Certified Architect exam
Domain 3 carries twenty percent of the exam, and Task Statement 3.4 asks you to determine when to use plan mode versus direct execution. This first knowledge point sits underneath that decision: before you can choose between modes, you have to know what each mode is for. The exam frames this at the understand level, which means questions describe a situation and ask whether planning is warranted, rather than asking you to recite a definition.
The judgement being assessed is essentially about cost and uncertainty. Planning is not free; it spends a round of reading and reasoning before any code appears. The exam rewards architects who can tell when that spend buys you something, a safer change, a considered design, a shared understanding, and when it is pure overhead. Getting this right is the foundation for the harder, apply- and evaluate-level knowledge points later in the task statement.
The four use cases that call for plan mode
There are four situations where the documentation and Anthropic's own teams consistently reach for planning. The first is a large-scale change. When the work spans a meaningful chunk of the codebase, jumping straight in risks a half-built change that has to be unwound. Planning lets Claude map the full surface area first.
The second is a multi-file modification. A migration that rewrites imports across forty-five files is not hard in any single place, but it is easy to miss a file or apply an inconsistent transformation. A plan enumerates every file in scope so nothing is left half-migrated.
The third is an architectural decision. When the task forces a choice about structure, which layer owns a responsibility, how a new module wires into the old ones, that decision deserves to be made deliberately and reviewed before it hardens into code. Plan mode produces an artefact you can read and edit before Claude commits to it.
The fourth is multiple viable approaches. When more than one reasonable design exists, you want them compared, not for the agent to silently pick one and build it. Planning surfaces the trade-offs so the choice is made with eyes open. A fifth practical trigger, called out in the best-practices guide, is simply working in code you are unfamiliar with: when you cannot predict the diff yourself, let Claude explore and propose before it edits.
How plan mode works under the hood
In the CLI you enter plan mode by pressing Shift+Tab to cycle the permission mode, by prefixing a single prompt with /plan, or by launching with claude --permission-mode plan. While the mode is active, Claude can read every file and run exploratory commands, but file edits stay blocked exactly as they would in default mode. That read-only guarantee is what makes plan mode safe to run against a production codebase or unfamiliar code: the model physically cannot change anything.
When the plan is ready, Claude presents it and asks how to proceed. From there you can approve it and switch into an editing mode, keep refining the plan with feedback, or open the plan in your editor to adjust it directly before Claude continues. Approving a plan is the moment the session leaves plan mode and the agent is finally allowed to write. That hand-off, investigate under read-only constraints, then approve and execute, is the seam that the hybrid plan-then-execute pattern is built on.
Worked example
A team wants to migrate their logging library across a 45-file service, replacing every call site and updating configuration.
The developer is tempted to just say "swap our logger for the new one and fix the call sites." In default mode Claude would begin editing the first file it found, and by the time anyone reviewed the work it might already be ten files deep with an inconsistent pattern.
Instead the developer presses Shift+Tab into plan mode and asks the same question. Claude now reads the codebase: it greps for every import of the old logger, inspects the configuration, and notices that three files wrap the logger in a custom adapter that the naive replacement would break. None of those files are touched, because plan mode forbids it.
Claude returns a plan: forty-five call sites grouped by pattern, a note that the three adapter files need a different transformation, and a suggested order that does the shared configuration first so the rest compiles as it goes. The developer reads it, tweaks one ordering decision in their editor, and approves. Only then does Claude leave plan mode and start editing, now executing a vetted plan rather than improvising across forty-five files. The planning step cost a minute and prevented a tangled, half-migrated branch.
Common misreadings to avoid
The exam likes to probe two specific misunderstandings about when planning is appropriate.
Misconception
Plan mode is the safe default, so I should use it for every task to avoid mistakes.
What's actually true
Misconception
Entering plan mode is a way to tell Claude to be careful while it still makes edits.
What's actually true
What planning costs, and what it buys
Every honest case for plan mode has to account for its price, because the exam tests the trade-off directly. Planning spends a full round of reading and reasoning before a single line of code appears, and on the wrong task that round is simply dead time. The four triggers matter precisely because each names a situation where the price is small next to what it prevents: a large-scale change that has to be unwound, a file set left half-migrated, an architectural mistake baked into the codebase, or the wrong design chosen silently by default. When none of those losses is on the table, the planning round buys nothing and the overhead is all you are left holding.
What you get back when the triggers do apply is an artefact you can inspect before it hardens into code. A plan is reviewable in a way that a live stream of edits is not. You can read it end to end, catch a wrong assumption while it is still cheap to fix, and reorder the work so the change compiles as it proceeds. Pressing Ctrl+G opens the proposed plan in your editor so you can change it directly before Claude continues, which turns the plan into a genuine collaboration point rather than a take-it-or-leave-it proposal.
The approval step carries choices that matter too. When Claude presents a plan it asks how to proceed, and you can approve it into an automatic editing mode, approve it into a mode that accepts edits while you watch, approve it with manual review of each edit, or keep refining the plan with feedback. Each option trades oversight for speed, and picking the right one is itself part of using plan mode well. You can also make plan mode a project default by setting the permission mode in your settings, which is sensible for a repository where most work genuinely warrants investigation before any edit.
Finally, it is worth naming the behaviour plan mode corrects. An agent that can edit tends to start editing, because action is the shortest path it sees to a goal. That bias is an asset on a clear task and a liability on an ambiguous one, where the first edit commits the agent to an approach before anyone has weighed it. Plan mode neutralises the bias not through instruction but through capability: with writes disabled, the only move available is to think and propose. This is why telling Claude to be careful is no substitute for plan mode, since care is advice whereas read-only is a guarantee.
Plan mode in the cloud, and a context-window caveat
Plan mode is not confined to the local terminal. Claude Code documents a cloud planning flow called Ultraplan, which hands the planning phase to a Claude Code on the web session running in plan mode. You describe the task, the hosted session reads the repository and produces an implementation plan under the same read-only constraint, and you then review the plan and choose where to execute it. For an architect the lesson is that the explore-and-propose contract is identical whether planning happens in your terminal or in a hosted session, only the location of the read-only investigation changes.
One precision point the exam can probe concerns context size. You might assume that because plan mode reads widely across a codebase it automatically receives the largest possible context window. It does not. The documented plan-mode Opus phase uses the standard 200K-token context window, and the automatic 1M-token upgrade that Extended context applies elsewhere does not extend to that phase. The practical consequence is that on a very large repository you still scope what Claude reads while planning rather than assuming it can ingest everything at once. The read-only guarantee protects your files, but it does not enlarge the window.
How plan mode is tested on the exam
Scenario 2 (Code Generation with Claude Code) and Scenario 4 (Developer Productivity) are where this knowledge point lives. A question typically describes a piece of work, a single null-pointer fix, a monolith restructuring, a cross-cutting migration, and asks whether the engineer should plan first or execute directly. The right answer comes from matching the work to the four triggers: scale, file count, architectural weight, and the presence of competing approaches. If none of those apply and the fix is obvious, planning is the wrong call, and the direct execution use cases knowledge point covers that other half of the decision.
Understanding plan mode in isolation is necessary but not sufficient. The task statement ultimately wants you to classify tasks under pressure, which is why this concept unlocks the mode selection scenario classification knowledge point. Get the four triggers fixed in your mind here, and the classification questions become a matter of pattern-matching rather than guesswork.
An architect is about to restructure a monolithic service into three modules, a change that will move code across roughly thirty files and force several decisions about which module owns which responsibility. Which mode best fits the start of this task, and why?
People also ask
When should I use plan mode in Claude Code?
Does plan mode make any changes to my files?
How do I turn on plan mode in Claude Code?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Claude Code Dynamic Workflows Clearly Explained
Why watch: Contrasts plan mode against direct execution and shows when complex, multi-file work warrants planning first.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.