Claude Code plan mode: approve the work before it exists

You ask Claude Code to move billing onto the new invoice service. It reads two files, says something agreeable, and starts editing. Four minutes later there is a 500-line diff: a migration you did not ask for, a renamed interface, and, buried in minute one, the decision to keep the legacy adapter alive, which quietly shaped every line that followed.

You catch that decision at review time, because review is where you were first consulted. Now the only way to change one early sentence is to reject an hour of finished work.

The expensive part of an agent task is not the typing. It is the first wrong decision compounding at machine speed. Claude Code plan mode exists to put a checkpoint in front of exactly that.

What Claude Code plan mode actually does

Press Shift+Tab twice and the session flips into a read-only state. The agent can still do everything that makes it useful as a researcher: open files, trace call sites, run searches, weigh trade-offs. What it cannot do is modify anything. Instead of a diff, it comes back with a plan: what it intends to change, in which files, in what order, and what it is unsure about. Nothing gets written until you approve. To start every session that way, launch with claude --permission-mode plan; the official docs cover the variants.

The mechanics matter less than the contract: research first, propose second, build only after a yes. Anthropic's best practices guide calls this explore, plan, code rhythm the biggest quality lever in agentic coding. Plan mode is that advice built into the tool, so following it no longer depends on remembering to.

The cheapest review you will ever do

A plan is thirty lines. The diff it becomes is eight hundred. Both contain the same decisions, and reviewing the diff means excavating them from under the code: you answer "is this the right approach?" and "is this implemented correctly?" at the same time, on the version where changing course is most expensive.

Reviewing the plan splits those questions. Direction gets settled while a wrong turn still costs one sentence to fix ("extend the adapter, do not replace it"), and the later diff review collapses into the second question alone: does the code do what the plan said?

If you already write specs for your agents, the plan is the missing middle step: it shows you how your brief was understood before that understanding hardens into code. Every gap between what you meant and what the agent read surfaces while it is still a paragraph, not a pull request.

When plan mode pays off (and when it is ceremony)

Reach for it when:

• The task spans more files than you can list from memory. A multi-file refactor is one early decision repeated forty times. Settle it once, on paper.
• The brief is one sentence. A vague ask forces the agent to resolve ambiguity. Plan mode makes it resolve visibly, in a proposal, instead of silently, in code.
• The codebase is new to you. Read-only is the right permission level for a session that is mostly about building your own understanding.
• The change is hard to walk back. Schema migrations, deletes, public API shape. Gates belong in front of one-way doors.

Skip it when:

• The diff is the plan. A typo fix or a one-file rename reads faster as code than as a proposal about code. The gate would double the cost of a two-minute task.
• A failing test already defines done. You have a gate; it is just automated. Adding an approval step in front of it is theater.
• The work is already broken into small cards. If you break tasks down far enough, each diff reviews directly, and planning moves up a level: it is how you produced the cards in the first place.

Where plan mode goes wrong

The honest section, because the failure modes are real:

• Approval fatigue. The ninth plan of the day gets skimmed and approved on autopilot, and a gate you rubber-stamp is worse than no gate: it launders unread decisions into approved ones. Reserve the ceremony for tasks above a real threshold.
• Approved is not implemented. Mid-build, the agent can hit a surprise (an interface that does not exist, a test that will not pass) and improvise off-plan without flagging it. Review the diff against the plan you approved, and say up front: if reality disagrees with the plan, stop and re-plan.
• A plan can be confidently wrong. Plan mode output reads beautifully whether or not it is grounded in your actual code. Check the file list against what you know before you bless it. Plausible is not the same as true.
• The plan evaporates on approval. It is a chat message. It scrolls away, and the next session has never heard of it. Plan mode has no memory layer; that part is on you.

A plan needs somewhere to land

That last failure is the operational one: plan mode produces a good decision, then hands you nothing to run it with. Six approved steps sit in a scrolled-away message, and somebody still has to open sessions, hand out the steps, and check the results.

That operator layer is what SanuDesk is for. It is a desktop app that puts your Claude Code, Codex and Gemini sessions in one tiled grid, next to a Kanban board that does the dispatching: the approved plan becomes cards, each card deploys to a fresh session with one click, and every finished card parks itself in a review lane with a "what changed, how to test it" note. The plan stops being a message and becomes a board you can watch execute, one reviewed step at a time. Plans that repeat become Loops, recurring jobs that run the same brief on a schedule. It is bring-your-own-model, so the agent subscriptions you already pay for do the work, and the grid and board are in the free plan (details on pricing).

Plan mode decides what should happen. The board is how it happens, and how you prove it happened.

Try this on your next feature

Take the next task you would normally fire straight at an agent. Press Shift+Tab twice, give the same prompt, and when the plan arrives, do not approve the first version. Ask one question: "What could this break, and which part are you least sure about?" Watch the plan get more honest, then approve it and let the build run.

Count how much of the final diff you had effectively reviewed before it existed. That number is why plan mode sticks once people try it.

Download SanuDesk free to give your approved plans a board and your sessions a grid, or see how the grid, board and Loops fit together on the features page.