Plan Mode & Permission Modes

Plan mode: look before you touch

Plan mode makes Claude read-only. It can explore your codebase — read files, search, trace call paths — but cannot edit anything. Instead it produces an implementation plan that you review and approve before any change happens. The point: catch a wrong approach when it's a paragraph you can edit, not a diff across nine files you have to unwind.

Use plan mode when:

• The change spans multiple files — wrong approaches get expensive fast.
• The code is unfamiliar — you or Claude (or both) don't know the territory yet.
• The approach is uncertain — several plausible designs exist and picking wrong matters.

Skip it when the diff is describable in one sentence — a typo fix, adding a log line, renaming a variable. Planning a one-line change is pure overhead. Match ceremony to risk.

Two mechanics worth knowing. Press Ctrl+G to open the plan in your editor and edit it directly — cut a step, reorder, add a constraint — before Claude proceeds; the edited plan becomes the contract for implementation. And plan mode delegates its research to a read-only Plan subagent, so heavy exploration (reading dozens of files) happens in a separate context window and doesn't clog your main conversation.

A worked example

Adding Google OAuth to an app with existing session handling:

1. Enter plan mode.
2. "Read /src/auth and understand how we handle sessions."
3. "Create a plan for adding Google OAuth that reuses the
   existing session layer."
4. Ctrl+G: edit the plan — cross out the proposed new session
   store; add "write tests for the callback handler."
5. Exit plan mode.
6. "Implement the flow from your plan. Run the test suite and
   fix any failures."

The expensive mistake — a parallel session system you didn't want — died in step 4, as one crossed-out line.

Permission modes: how much to approve

Orthogonal to planning is the permission question: which actions need your sign-off? Claude Code has a spectrum:

Default prompting. Claude asks before file edits and shell commands. Safest, and right for a first session in a codebase — but high-friction for long sessions.

Allowlists via /permissions. Pre-approve specific safe commands — npm run lint, npm test, git commit — so routine operations run without prompts while everything else still asks. This is the workhorse mode for daily development.

Auto mode. A classifier model reviews each action and blocks only risky ones — scope escalation, destructive commands — letting everything routine through. For trusted workflows where constant prompting adds no safety.

Sandboxing via /sandbox. OS-level isolation: filesystem and network restrictions enforced by the operating system, not by the model's judgment. The strongest guarantee, for running genuinely untrusted or experimental work.

The rubber-stamp problem

Why not just stay on default prompting forever — isn't maximum prompting maximum safety? No, and the reason is human: by the tenth approval you're not reviewing anymore, you're clicking through. Every low-stakes prompt ("run npm test?" — yes, obviously) trains you to approve reflexively, and reflexive approval is exactly the state in which the one prompt that deserved scrutiny sails past.

Fewer, meaningful prompts beat many reflexive ones. Allowlist what's routinely safe so that when a prompt does appear, it's unusual enough that you actually read it.

Matching mode to task risk

The two systems also compose over time. A typical trajectory in a new codebase: default prompting plus plan mode for the first few sessions, an allowlist growing as commands prove routine, auto mode once solid tests exist to serve as the real quality gate. Trust is granted incrementally and backed by verification — not assumed on day one, not withheld forever.

The theme of both halves: deliberate control where it pays, zero ceremony where it doesn't. Plan mode front-loads scrutiny to the cheapest moment (before code exists); permission configuration concentrates your attention on the few actions that genuinely need it.