Claude Code Plan Mode: Make It Think Before It Types

Ask Claude Code to "add team accounts" to your app and it will start immediately. Twenty minutes and fourteen files later, you discover it modelled teams in a way that doesn't fit your billing system, and most of the work has to be undone.

The code wasn't bad. The direction was wrong, and nobody checked the direction before the code was written. Plan mode is the checkpoint for exactly that.

Details reflect Claude Code as of September 2026. See the permission modes documentation for current specifics.

What plan mode does

In plan mode, Claude researches and proposes, but doesn't change your code. It can read files, search, and run commands to explore. It can't edit your source. When it's done, it presents a plan and waits for you to approve it.

Three ways in:

Press Shift+Tab to cycle permission modes until the status bar shows ⏸ plan mode on.
Prefix a single prompt with /plan.
Start a session in it: claude --permission-mode plan.

Press Shift+Tab again to leave without approving anything.

Approving a plan

When the plan is ready, you choose:

Approve and let it run — Claude starts implementing, with edits auto-accepted (or reviewed by auto mode, where that's available).
Approve, but review each edit — Claude implements, asking before each change.
Keep planning — stay in plan mode and say what to change.

Before approving, you can press Ctrl+G to open the plan in your text editor and change it directly. That's often faster than describing the change in chat: delete the step you don't want, reorder two others, add a constraint, save.

How to review a plan

A plan is only useful if you actually read it. What to look for:

1. Did it understand the goal? The first paragraph should restate what you asked for. If it restated something slightly different, stop there — everything after is built on the misunderstanding.

2. Does it fit what already exists? Does it reuse your existing patterns, or invent new ones? A plan that adds a new state-management library, a new way of calling the API, or a parallel version of a module you already have is a plan that ignored the codebase.

3. What is it changing that you didn't ask it to? Watch for scope creep: "while I'm here, I'll also refactor…" That might be fine. It should be a decision, not a surprise.

4. What about the data? Any plan that changes the database schema deserves the closest reading. Is there a migration? Is it reversible? What happens to existing rows? This is the part that's hardest to undo — see What Are Database Migrations?.

5. How will it know it worked? A good plan ends with verification: which tests it'll add or run, what it'll check in the running app. "Implement X" with no verification step is a plan to hand you something unchecked.

6. What's it unsure about? Ask directly: "What assumptions are you making? What would you want to confirm with me first?" The answer is often the most useful part of the whole exercise.

When plan mode is worth it

Features that touch several parts of the app. The more files involved, the more a wrong direction costs.
Anything involving the database schema, authentication, or payments. High cost of error, hard to undo.
Unfamiliar codebases. Plan mode forces a research phase, and you learn the codebase from the plan.
Refactors. Agree on the target shape before anything moves.
Before a long unattended run. If you're going to let it work for an hour while you're away, spend five minutes agreeing on what "done" looks like first. (More on unattended work: Running Claude Code Unattended.)
When you're not sure what you want. Plan mode is a cheap way to think out loud with something that can read the code.

When it's overkill

Fixing a typo, renaming a variable, adjusting a style.
A bug where the fix is obvious once found.
Work you'd happily throw away if it went wrong.

For small tasks, plan mode just adds a round-trip. The skill is recognising when a task is small enough to just do.

Plans as documents

A plan that took real thought is worth keeping. Two habits:

Save it into the repo — docs/plans/team-accounts.md — before implementation starts. It becomes the spec, the PR description, and the thing a new session reads to catch up.
Use it to hand off. A plan written in one session can be implemented in another, or split across parallel agents in git worktrees, each taking a section.

Approving a plan also names the session after it, which makes it easy to find again with claude --resume.

Why it saves money, not just time

Anthropic's own cost guidance recommends plan mode for complex tasks, and the reason is simple arithmetic. Exploration is cheap: reading files and proposing an approach. Re-work is expensive: writing code, finding it's wrong, reading it all back, and writing it again — with the failed attempt still sitting in the conversation, carried by every later message.

Five minutes of planning that prevents one wrong direction pays for itself many times over. How to Keep Claude Code Costs Down has the rest of the picture.

The habit

For anything bigger than a small fix: Shift+Tab into plan mode, describe the goal and the constraints, read the plan properly, edit it with Ctrl+G, then approve. It feels slower for the first minute and is faster for every minute after.

EasySpawn runs Claude Code in a persistent workspace with your code, database, and running app together — so plans are made against the real environment, and approved work can run to completion while you're away. See how it works or join the waitlist.