Plan Mode and Human Review

When to use plan mode's read-only research-then-approve workflow for risky or hard-to-reverse changes.

Claude Code·Lesson 5 of 6·6 min

Plan mode is a read-only mode in Claude Code: while it's active, Claude can research the codebase (read files, search, run non-mutating commands) but cannot make edits or run mutating commands. Instead, Claude uses that research to produce a proposed plan of action, which a human reviews and explicitly approves before any actual change happens.

The purpose is to insert a deliberate checkpoint before irreversible or high-blast-radius work begins. Once the plan is approved, Claude exits plan mode and executes — but the execution phase only starts after a human has seen the intended approach and signed off, rather than discovering what happened after the fact by reading a diff.

When plan mode is the right call

The exam expects you to match plan mode to a specific risk profile: changes that are risky, broad in scope, or hard to reverse, where getting the approach wrong is expensive to undo. Examples: a schema migration touching a production database, a refactor spanning dozens of files, changes to authentication or billing logic, or any change where the "best approach" is genuinely ambiguous and worth debating before code gets written.

Plan mode is not intended as the default mode for routine work. Using it for every trivial edit (fixing a typo, adding a log line) adds friction without adding safety value, since there's nothing risky to review. The judgment call is proportional: the more consequential and less reversible the change, the stronger the case for forcing a plan-then-approve cycle rather than letting Claude edit directly.

Exam trap Exam questions sometimes conflate plan mode with permissions (deny/ask rules) or with hooks. They are different mechanisms solving different problems. Permissions gate individual tool calls based on static rules; hooks deterministically enforce lifecycle behavior; plan mode is specifically about front-loading a human review of Claude's overall approach before execution begins, for a single unit of risky work. If an answer choice describes plan mode as "blocking a specific dangerous command," that's actually describing a permission deny rule or a hook, not plan mode. Plan mode's distinguishing trait is the propose-then-approve sequence at the level of an entire approach, not a single tool call.

What plan mode does not replace

Plan mode doesn't substitute for good permissions or hooks — it's a complementary layer. Even after a plan is approved, sensible permission rules and any relevant hooks still apply during execution. Plan mode addresses "is this the right approach," not "is this specific command safe to run," which is what permissions and hooks separately handle.

Scenario: An engineer asks Claude to "migrate our user table to add a new required column with a backfill, across a database with 40 million rows in production." Should this run directly, or start in plan mode? Plan mode is the right call: this is a hard-to-reverse, high-blast-radius change (a bad migration on a production table with 40 million rows is expensive or impossible to cleanly undo), and there are multiple reasonable approaches (online migration strategy, batching, locking behavior) worth a human evaluating before any SQL executes. Contrast with "rename this local variable for clarity" — low risk, trivially reversible, no need for a plan-approval cycle.

What "read-only" actually means

During plan mode, Claude can still use tools that gather information: reading files, searching the codebase, running commands that inspect state without changing it (checking git log, running a dry-run flag, querying a schema). What it cannot do is anything that mutates the repository or environment — editing files, running migrations, installing packages, committing. This distinction matters because plan mode is not "Claude can't do anything," it's "Claude can look but not touch," which is precisely why the research it does during planning tends to be more thorough than a plan proposed without that investigation — the plan is grounded in what Claude actually found in the code, not just a guess based on the request.

Approval is not a formality

The value of plan mode collapses if approval becomes reflexive. A human skimming a plan and clicking approve without actually evaluating the proposed approach gets none of the safety benefit and only the added latency. The exam frames plan mode's value around genuine human judgment being applied at the checkpoint — catching a wrong assumption, an overlooked edge case, or an approach that's technically workable but not what the team actually wants — not around the mere existence of a pause in the workflow.

Try it

Pick a real but nontrivial task in one of your projects — something like restructuring a module or changing a shared interface. Enter plan mode, let Claude research and propose an approach without editing anything, and actually read the plan critically before approving it. Notice what the read-only research phase catches that you'd have otherwise only discovered after the edits were already made.