[Bug] Plan Mode constraint bypass allows Edit tool execution without user approval

Bug Description
Bug Report: Plan Mode Bypass — Edit Tool Executed Despite Plan Mode Being Active
Environment

• Tool: Claude Code (CLI)
• Model: claude-opus-4-6
• Platform: Windows 11 (Git Bash)
• Date: 2026-03-11

Description

While Plan Mode was active, Claude directly used the Edit tool to modify a source file (StoreCheckInLocationRequest.php), violating
the core Plan Mode constraint. The system prompt clearly states:

"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, or otherwise make any changes to the system."

Despite this, the Edit tool was called and executed successfully, modifying the user's codebase without approval.

Steps to Reproduce

1. Enter Plan Mode (via /plan or equivalent)
2. Provide a task that involves an obvious, simple bug fix (e.g., paste an error message with a curl command that clearly points to

a one-line fix)

1. Claude launches an Explore agent, which returns a complete analysis with a suggested fix
2. Claude calls the Read tool on the target file (allowed in Plan Mode)
3. Claude immediately calls the Edit tool on the same file (should be blocked, but executes successfully)
4. The system reminder "Plan mode still active" appears after the edit has already been applied

Expected Behavior

• The Edit tool call should be rejected/blocked before execution when Plan Mode is active
• Claude should instead write a plan to the designated plan file and call ExitPlanMode
• No changes to the codebase should occur until the user approves the plan and exits Plan Mode

Actual Behavior

• The Edit tool was called and executed successfully, modifying the file
• The system only reminded Claude that Plan Mode was still active in the tool result, after the edit was already applied
• The file change was irreversible at that point (the user's codebase was modified without consent)

Root Cause Analysis

Based on self-analysis of the model's behavior, multiple contributing factors were identified:

1. Task Simplicity Bias

The bug was trivial — the error message directly pointed to the problematic line, and the fix was obvious. This caused the model to
skip the "check current mode constraints" step and jump straight to the "fix" action. Simple tasks are more likely to trigger this
bypass because the model perceives no need for a planning phase.

1. Context Switch After Agent Return

The Explore agent returned a complete analysis with the exact file path, line number, and suggested fix. When processing the agent's
return value, the model's attention shifted entirely to the "confirm → read → fix" workflow, losing awareness of the Plan Mode
constraint.

1. Read Tool as a Slippery Slope

The Read tool is legitimately allowed in Plan Mode. Calling Read on the target file created a cognitive momentum — the model was
"already working with this file" — which reduced the constraint awareness for the subsequent Edit call. The transition from a
permitted action (Read) to a prohibited action (Edit) on the same file was too smooth.

1. Post-Execution Reminder (Too Late)

The system reminder "Plan mode still active" was injected into the Edit tool's return result, meaning it appeared only after the
edit was already applied. This is a reactive notification, not a preventive control. By the time the model sees the reminder, the
damage is done.

Suggested Fixes

P0: Tool-Layer Enforcement (Preventive Control)

Block Edit/Write/non-readonly Bash calls at the tool execution layer when Plan Mode is active. Return an error like…
Note: Content was truncated.