Review a plan and choose how Claude executes it

The plan is on screen: require an Idempotency-Key header, add a table, dedupe before the gateway call, handle the in-flight case. This is the moment plan mode exists for — you’re reviewing a decision, in plain language, before any code commits you to it. Read it like a design review, not a formality. The whole value of the mode evaporates if you rubber-stamp a plan you didn’t actually check.

The approval menu

When the plan is ready, Claude presents it and asks how to proceed. You get a menu, and each choice does a meaningfully different thing:

  How would you like to proceed?

  1. Approve and start in auto mode
  2. Approve and accept edits
  3. Approve and review each edit manually
  4. Keep planning with feedback
  5. No, refine with Ultraplan on Claude Code on the web

The first three are all approve — they differ only in which permission mode the session drops into once building starts, and that’s a deliberate choice you should make per task:

• Approve and review each edit manually — drops you back to default, every edit prompts. The cautious choice for a change that touches money, like this one.
• Approve and accept edits — edits fly, you review the diff after. Right when you trust the plan and the change is contained.
• Approve and start in auto mode — hands-off with the classifier net you met last chapter. For a long plan you want to walk away from.

Approving exits plan mode and switches the session to that mode, so Claude starts building immediately against the plan you just read. Notice the through-line with the last chapter: a plan doesn’t just say what to do, it lets you set how freely it gets done — in one decision, at the one moment you have the most context.

For our double-charge fix, the stakes pick themselves: this is billing code, so you choose review each edit manually. The plan is agreed; the leash stays short while it lands.

Fix the plan before you run it

Two options exist precisely because a plan is rarely perfect on the first pass.

Keep planning with feedback sends Claude back to revise — you tell it what’s wrong (“the in-flight case needs a row lock, not just a status check”) and it researches and re-proposes. Iterate as many rounds as the change deserves; it’s still free, still zero code.

And when the fix is small enough that you’d rather just edit the plan yourself than explain it, press Ctrl+G to open the proposed plan in your text editor. Change the wording, delete a step, add a constraint, save — and Claude proceeds against your edited version. It’s the fastest way to correct a plan that’s 90% right: don’t describe the change, make it.

One setting worth knowing if you plan often: with showClearContextOnPlanAccept enabled, each approve option also offers to clear the planning context first — so the build starts on a clean window instead of carrying all the research chatter that planning generated. That ties directly into the context discipline from the Sessions chapter: the exploration was useful for making the plan, but it’s noise once the plan exists. A small detail, but the kind that keeps long sessions sharp. (One nicety you’ll notice for free: approving a plan auto-names the session from the plan’s content, unless you already named it — which matters in the next lesson, when you go to find it again.)

You’ve now got the core loop: research in plan mode, review the proposal, correct it, approve it into the right build mode. But that approved plan currently lives in one conversation — close the laptop or clear the context and the agreed approach is gone. For a change you might not finish today, that’s a problem. Let’s put the plan somewhere it survives.