Permission modes and plan mode

01The goal

Pick the right permission mode for a task, switch modes mid-session with Shift+Tab, and approve a plan in plan mode before Claude touches a single file.

02The idea

A permission mode decides which actions Claude can take without asking you first. You switch with Shift+Tab (Alt+M if Shift+Tab does nothing for you), and the status bar under the prompt always shows the mode in force. Four matter:

Manual for sensitive work and unfamiliar code, where you review every action. Auto for long tasks where approving each step is the bottleneck. Accept edits sits between: edits flow, everything else asks.

Plan mode is the habit to build first, and the one we would keep if we could keep only one. Claude explores, thinks, and hands you the whole change as a plan before anything moves. It is the cheapest review surface there is: reading a plan costs seconds, unwinding a wrong implementation costs the afternoon. Our delivery board takes the same stance one level up — nothing an implementer produces counts until a separate review approves it — and plan mode is the session-sized version of that gate.

Permission answers can be sticky. When Claude asks to run something and you answer "Yes, and don’t ask again", you have just edited your own guardrails. In this course, answer plain Yes or No — the modes are the guardrails, and they should stay yours.

03The walkthrough

1. 01Start claude in your repo; a new session usually starts in auto mode. Look at the status bar and confirm what you are riding in.
2. 02Shift+Tab through the cycle and watch the status bar change. From auto, one press gives manual, the next accept edits, the next plan.
3. 03In plan mode, ask for a small change, such as: "Make the config parser reject an empty file with a clear error message, and add a test for it," adjusted to fit your repository.
4. 04Claude reads files and may run commands to explore, but edits nothing. If it needs a decision first, it asks a multiple-choice question — pick an option or type your own. Then it presents the plan with three choices: "Yes, and use auto mode", "Yes, manually approve edits", and a text field the docs call "No, keep planning" (the prompt shows it as Tell Claude what to change). The first is highlighted — the highlight is a default, not a recommendation.
5. 05Send the plan back once, even if it already looks right, to build the reflex. Down-arrow to the text field, type one correction — "Keep the change to the parser and its test file. Don’t add new files." — and press Enter. Claude revises and shows the menu again.
6. 06Approve with "Yes, manually approve edits". The session leaves plan mode into manual: Claude now asks before each edit and before most commands. Read each request. Plain Yes when it does what the plan needs; No, and say what to do instead, when it does more than the plan needs.
7. 07When Claude finishes, run git status: every changed path should be one the plan named. A path that changed without the plan naming it is the finding of this exercise — note it.

04Your turn

The same run with a change of your own, plus the discipline: while the final plan is on screen, save git status --porcelain to a file (before.txt) in a second terminal. Approve, work through the prompts, then save it again (after.txt). Compare: everything in the after-list should be a path the plan named. Then set the change aside (git stash push --include-untracked) or keep it — your repo, your call. Stop before committing; the next lesson owns the commit.

Watch out for the highlighted first choice in the plan menu: it hands the rest to auto mode. And a "Yes, and don’t ask again" answer mid-session outlives the moment — keep the modes as the guardrails.