Plan mode stops gating tools after a rejected ExitPlanMode call

Status Open
Reported on v2.1.237
Maintainer reply None cached
Activity 0 comments · opened Aug 25, 2026

Environment

  • claude --version: 2.1.237 (Claude Code)
  • macOS 26.5.1 (25F80)
  • Claude Desktop app (not a plain terminal CLI session) — process tree confirms .../Claude/claude-code/2.1.237/claude.app, launched from /Applications/Claude.app

How plan mode was entered

Not via Shift+Tab and not via --permission-mode plan. The agent called the EnterPlanMode tool itself, in response to a user instruction asking it to enter plan mode before proceeding with a sensitive task.

What happened

With the Plan mode indicator active in the UI (visually confirmed by the user mid-session — the mode selector showed "Plan") and a <system-reminder> present in context stating:

Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.

...the agent later called ExitPlanMode. The tool result came back as a rejection — the user replied with substantive free-text feedback and specific adjustments rather than a clean accept/decline — which should mean plan mode remained in effect.

After that rejected ExitPlanMode call, every subsequent Bash, Edit, and Write tool call executed successfully with no permission prompt and no block — across many turns and several separate user messages — including:

  • File writes/moves and edits to files other than the designated plan file
  • Read-oriented CLI calls via Bash
  • Eventually, several irreversible destructive actions performed through a CLI tool invoked via Bash (deleting multiple cloud resources)

No tool call was ever rejected or gated during this entire window. The UI continued to display "Plan" as the active mode the whole time (confirmed by a screenshot from the user partway through). A formal "Exited Plan Mode" system-reminder only appeared much later, seemingly triggered by something client-side rather than by any explicit approval flow in the transcript.

Expected

Tool calls other than reads and edits to the plan file should be blocked (or require an explicit approval prompt) while Plan mode is active — matching the documented restriction quoted above, and matching what rejecting an ExitPlanMode call should imply.

Actual

All tool calls executed without restriction for an extended period after plan mode was (per the UI and per a rejected ExitPlanMode call) still active, with no error, block, or approval prompt at any point.

Impact

Not a cosmetic bug — it allowed an agent to perform genuinely irreversible actions (deleting cloud infrastructure) while the user-facing safety indicator said the session was still in a restricted, read-only planning mode.

View original on GitHub ↗