Use plan mode in Claude Code

Link copied

Attach video time

Plan mode came up when we walked through the differnet permission modes, but it's worth a lesson of its own, because it's where you should be spending most of your time. Claude Code researches your ask and writes up exactly what it intends to do, and not a single file gets touched until you say so.

Getting into plan mode

Tap Shift + Tab until the mode indicator under your prompt reads:

⏸ plan mode on

You can also start a session in it with claude --permission-mode plan, or set "defaultMode": "plan" in the settings of a project where you always want to plan first.

What Claude does while planning

In plan mode, Claude Code is read-only. It reads files, searches your codebase, runs read-only commands like git log, looks things up on the web, and dispatches explorer subagents to investigate your project. What it can't do is edit a file or run any command that changes something.

That constraint is the point. You can hand it the messy, oversized version of your ask -- the kind you'd never turn loose in auto mode -- and the worst that happens is a plan you disagree with. So give it the messy version.

Read the plan before you approve it

When it's done, you'll get a prompt titled "Ready to code?" with the plan laid out and a few options:

Yes, auto-accept edits
Yes, manually approve edits
No, keep planning

Here's where most developers make their first mistake: they skim the plan, decide it looks reasonable, and hit yes.

A wrong plan is far cheaper to fix now than after a dozen files have been rewritten. Read it step-by-step and look for:

• Files it plans to touch that you weren't expecting

• Steps that skip something you care about, like tests or a migration

• Assumptions about your stack or conventions that aren't true

• The thing you actually asked for somehow not being in there

Push back and keep planning

Choose "No, keep planning" any time something feels off, and tell it what's wrong. Use markdown formatting to structure your feedback -- line breaks, bullet points, numbered steps -- and the more structure you give it, the more precisely it revises. Still not getting through on a point? Type that requirement in ALL CAPS. It works surprisingly well.

Expect to go around a few times. Twenty or thirty minutes here on a feature of any substance is normal, and it's cheaper than the debugging session you'd be having otherwise.

If planning ran long, or your context is filling up, have Claude Code write the finished plan out to a file before you execute it:

Write this plan out to docs/plans/todo-categories.md

Now it's a real file. You can edit it by hand, commit it alongside the work, or start a fresh session and have it implemented with a clean context window. For larger features, this is how I work almost every time.

Approving the plan

"Yes, manually approve edits" drops you into manual mode, where you approve each edit as it happens. "Yes, auto-accept edits" drops you into accept edits mode, where Claude Code works through the plan on its own and you review the result in git diff.

If the plan touches something you care deeply about, take the manual option. Otherwise let it run -- you already did the hard part.

Pro tip: Plan mode is worth using even when you have no intention of writing code. Toggle it on and ask "how does authentication work in this project?" for a well-researched answer, with zero risk of anything being modified along the way.