[BUG] Plan mode exits silently, leading agent to implement plan without user approval

Resolved 💬 3 comments Opened Apr 17, 2026 by laure-delisle Closed Apr 21, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code's agent proceeded to implement a plan and wrote a 1,000+ line file to my project directory without my approval.

The ExitPlanMode prompt shows three options — "Yes, and auto-accept edits", "Yes, and manually approve edits", "No, keep planning" — plus a text box for feedback. On two consecutive ExitPlanMode calls I selected "No, keep planning" and typed feedback into the text box. I never selected either approve option.

Despite this, plan-mode state transitioned out silently. A later ExitPlanMode call then returned "You are not in plan mode. If your plan was already approved, continue with implementation."without ever re-showing me the approval prompt. The agent interpreted that error as implicit approval and started writing files. I caught it and pushed back ("when did I approve??"), but a less attentive user, or a plan that modifies existing files rather than creating a new one, could lose work.

The core failure: the agent confidently acts on state it inferred rather than state it was told, because the tool's error message is ambiguous between "user approved, proceed" and "state changed without approval".

What Should Happen?

Any one of:

  • ExitPlanMode should return a rejection until the user has explicitly selected one of the two approve options. Silent state transitions should not be possible.
  • If plan mode is programmatically exited by some other flow (file edits, rejection count, timeout), the agent should be notified why the state changed — not given a message that can be read as "approval already happened".
  • The "not in plan mode" error should be distinguishable between "user approved → proceed" and "state transitioned without approval → stop and ask".
  • The agent's system prompt guidance around ExitPlanMode should treat ambiguous plan-mode state as "ask the user" rather than "assume approval".

Impact

The agent wrote a 1,000+ line file to the user's project directory without the user's approval. The user caught this and pushed back ("when did I approve??"). No data loss in this case — the file was a new doc and the user was present and attentive — but the failure mode is that the agent confidently proceeds to implement on state it inferred rather than state it was told. For users not watching closely, or for plans that modify existing files rather than creating new ones, this bug could cause real damage.

Environment

  • Model: Claude Opus 4.7 (claude-opus-4-7)
  • Harness: Claude Code, VSCode native extension
  • Platform: Linux 6.8.0-94-generic
  • Session included: Edit calls on the plan file by the agent, manual file edits by the user, two user rejections of ExitPlanMode.

Error Messages/Logs

## Error Messages/Logs

The ambiguous tool result that triggered the bug:


You are not in plan mode. If your plan was already approved, continue with implementation.


This was returned from an `ExitPlanMode` call where the approval UI was never shown to the user, and the user had selected "No, keep planning" on every previous prompt.

Steps to Reproduce

Approximate sequence from a live session (Opus 4.7, VSCode extension):

  1. Agent enters plan mode, writes plan to the designated plan file.
  2. Agent calls ExitPlanMode. User sees the prompt ("Yes, and auto-accept edits" / "Yes, and manually approve edits" / "No, keep planning") and selects "No, keep planning", typing feedback into the text box.
  3. Agent uses Edit on the plan file to incorporate that feedback.
  4. Agent calls ExitPlanMode a second time. User again selects "No, keep planning" with more feedback in the text box.
  5. User manually edits the plan file in the IDE to add more content (signalled to the agent via a system-reminder about plan file modifications).
  6. Agent re-reads the plan, confirms user's manual edits are integrated, and calls ExitPlanMode a third time.
  7. Third call returns: "You are not in plan mode. If your plan was already approved, continue with implementation."without ever showing the user the approval prompt for this third call. The user was never asked.
  8. Agent interprets this as approval and writes a new 1,000+ line file — which the user had not approved.

Critical: the user actively chose "No, keep planning" every time they were prompted. They never selected either approve option. Plan-mode state transitioned out without any user input, and the third ExitPlanMode call bypassed the approval UI entirely.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Opus 4.5

Claude Code Version

claude-opus-4-7

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Environment

  • Model: Claude Opus 4.7 (claude-opus-4-7)
  • Harness: Claude Code, VSCode native extension
  • Platform: Linux 6.8.0-94-generic

Session shape

  • Two ExitPlanMode calls where the user selected "No, keep planning" with feedback in the text box.
  • Agent Edit calls on the plan file between those rejections.
  • One manual user edit to the plan file in the IDE.
  • A third ExitPlanMode call that bypassed the approval UI entirely and returned the ambiguous "not in plan mode" message.

Suggested fixes

  • Make the ExitPlanMode "not in plan mode" error distinguishable between "user approved → proceed" and "state transitioned without approval → ask before acting".
  • Surface why plan mode exited (user action, file edit, timeout, etc.) in the tool result.
  • Update agent prompt guidance so ambiguous plan-mode state routes to "confirm with user" rather than "assume approved".

<img width="463" height="416" alt="Image" src="https://github.com/user-attachments/assets/e40e5e6c-02f9-4608-861d-9d4748f9510c" />

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗