Plan mode silently exits / auto mode overrides "plan carefully" requests on follow-up work
Status Closed — not planned
Maintainer reply None cached
Activity 5 comments · opened Apr 25, 2026 · closed May 29, 2026
Summary
Two related plan-mode quirks observed in Claude Code:
- After an initial
ExitPlanModeis approved, subsequent rounds of work that the user explicitly asks to be planned (e.g. "please plan carefully before implementing") do not cause Claude to re-enter plan mode. Auto mode's "execute immediately" guidance silently wins, and Claude starts editing files in the same turn it writes a brief inline plan. There is no secondExitPlanModecheckpoint.
- The Claude Code UI plan-mode indicator can show "plan mode active" to the user while the system reminders the assistant receives do not include the
Plan mode is activereminder. From the assistant's side it looks like auto mode; from the user's side it looks like plan mode. The two states are out of sync.
Repro (approx.)
- Enter plan mode, build a plan, get it approved via
ExitPlanMode. - Auto mode becomes active.
- Later in the same session, the user asks for a fresh round of work and explicitly writes something like "please read the code again and plan carefully before implementing".
- Claude writes a few sentences of plan in chat, then immediately calls
Edit/Bashetc. — noExitPlanModeround-trip. - Separately, the user reports their UI shows plan mode is on, but the assistant has been making edits without complaint.
Expected
- When a user explicitly says "plan carefully" / "let's plan this" / similar after an earlier plan was approved, Claude should treat it as a new planning round and present via
ExitPlanModefor fresh approval — even if auto mode is active. - The plan-mode indicator visible to the user should be authoritative; if it's on, the assistant should know about it via system reminders.
Actual
- Inline plan + immediate execution in the same turn.
- UI / assistant state mismatch around plan mode.
Environment
- Claude Code, model
claude-opus-4-7[1m] - macOS Darwin 25.4.0, zsh
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This feels like two manifestations of the same underlying bug: the product does not have a single authoritative planning state.
If a user explicitly asks for a new planning round after a prior
ExitPlanMode, then "plan carefully" is not just stylistic guidance — it is a control-surface request to re-establish the approval boundary before execution. Auto mode should not silently collapse that into "brief inline plan + immediate edits."The UI mismatch makes it worse. Once the user sees plan mode as active while the assistant is no longer receiving the corresponding system reminder, the safety contract is broken from both sides:
So the important fix is probably not only better language triggering, but a single canonical plan-state source that both UI and model-facing reminders derive from. Otherwise users cannot trust what the indicator means, and explicit planning requests after prior approval remain ambiguous when they should not be.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Closed ? Claude still goes back to auto mode / edit mode when you're in plan mode. Constantly.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.