Plan Mode: Separating Thinking from Doing

The issue: Claude Code in agentic mode can take sequences of actions — reading files, writing files, running commands — without stopping to ask. For routine tasks that is a feature. For anything consequential, it is a risk: the action happens before you have evaluated whether it was the right one. Plan mode is the built-in mechanism that separates "Claude proposes what to do" from "Claude does it" — inserting a human decision point between design and execution.

What plan mode is

In plan mode, Claude:

Reads files and explores the codebase or project
Designs an approach and writes it out as a structured plan
Stops — it does not execute anything

You read the plan, judge it, redirect if needed, and explicitly approve before Claude proceeds. The actions happen after your decision, not before it.

Without plan mode, Claude proposes and acts in the same motion. With plan mode, proposal and action are separated by your judgment.

The four-phase workflow

The official Claude Code best practices name a four-phase sequence that makes plan mode concrete:

Explore — Claude reads files, examines the project, and gathers context. You are in plan mode; Claude is not acting yet.
Plan — Claude proposes an approach. You read it, question it, redirect it. The plan becomes the contract.
Implement — Claude executes the approved plan.
Commit — Changes are saved (to disk, to git, to an output file). The session has a documented endpoint.

The key discipline: keep Explore and Plan strictly separate from Implement. Once you approve a plan and Claude moves to implementation, the leverage point has passed — changes become corrections. The value of plan mode is front-loading the evaluation before any implementation begins.

Ctrl+G — when Claude is presenting a plan, press Ctrl+G to open the plan text in your default editor. This lets you edit, annotate, or rewrite the plan before approving it — useful for complex multi-step plans where you want to make precise adjustments rather than directing Claude through chat.

How to activate it

Shift+Tab — toggles plan mode on/off from any Claude Code session.

Ask Claude directly:

Before doing anything, write a plan and wait for my approval.

In your task description:

Plan first, don't execute until I confirm.

Once in plan mode, Claude will explicitly signal that it is ready and waiting — it will not proceed until you approve.

When to use it

Use plan mode whenever:

The task involves writing, moving, or deleting files you care about
You are not sure exactly what Claude will do
The task has multiple steps and an error in step 2 would require unwinding step 1
You are working with data that is hard to reconstruct (original sources, transcripts, coded datasets)
You are at the beginning of a new type of task and want to review the approach before it runs

You can skip plan mode for:

Read-only tasks (summarise, analyse, extract — but no file writes)
Highly routine tasks you have run many times and understand well
Short single-step actions with obvious, easily reversible effects

The rough rule: if the thought "wait, was that right?" could arise after the action completes, use plan mode so it arises before instead.

The researcher framing

Research materials are often irreplaceable: original transcripts, manually coded datasets, annotated sources, draft manuscripts with tracked changes. The cost of an unintended edit or deletion is not just time — it may be data that cannot be recovered.

Plan mode is the practical implementation of the supervision principle: Claude Code can act agentically, but consequential actions should be reviewed before they happen, not after. This is the same logic behind the rule in A.concept.agents — "never modify originals unsupervised" — made structural rather than something you have to remember to enforce.

It also changes the intellectual dynamic. When Claude presents a plan and waits, you are in a different epistemic position than when it presents a completed output:

You can evaluate the approach before seeing the result — which is the moment when redirection is cheapest
You are forced to read the plan, not just the output, which keeps you inside the reasoning rather than downstream of it
A plan that looks wrong is easy to redirect; an output that is wrong requires diagnosis, undo, and redo

A practical pattern

1. Describe the task, invoke plan mode:

I want to extract all person names and dates from the 40 PDFs in /sources, output as a CSV with one row per mention. Plan first, don't execute until I confirm.

2. Claude explores and plans: Claude reads a sample of the PDFs, proposes an extraction approach, describes what the output file will look like, and lists any edge cases it has noticed. It stops.

3. You review:

Does the proposed approach match what you actually wanted?
Are there edge cases the plan missed?
Is the output format right?
Any files you do not want touched?

4. Redirect or approve:

If something is wrong: The date format should be ISO 8601, not the format you described. Also skip any PDF with "draft" in the filename. Update the plan.
If it looks right: Approved, proceed.

5. Claude executes the approved plan.

The plan is the contract between you and the agent. Approving it means you have read it and judged it. If the execution diverges from the plan, that is a problem with execution — not with your original judgment about the approach.

Plan mode and the confirmation loop risk

One subtle benefit: plan mode creates a natural interruption in the sycophancy dynamic. When Claude presents a plan rather than a finished output, you evaluate it before any effort has been invested — which makes it easier to say "this is wrong" without the psychological inertia of having accepted intermediate steps. See B.epistemics for the fuller account of why that inertia is a risk worth designing against.

Official documentation: code.claude.com/docs — plan mode reference, Ctrl+G shortcut, and the four-phase workflow.

A.concept.agents — the supervision spectrum; plan mode operationalises the "supervised" end of that spectrum
A.issue.bounding — how to define a task so the plan has clear edges to work within; bounding and plan mode are complementary
B.trust — verification as architecture, not afterthought; plan mode builds the verification checkpoint into the workflow before execution starts
A.issue.context-scope — the framing effect: what you include in a task shapes what Claude plans; plan mode makes that shaping visible before it becomes action
B.epistemics — the confirmation loop risk; plan mode as a natural interruption point before sycophantic completion dynamics take hold