Plan mode: model made file edits despite plan mode being active

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33037
2. https://github.com/anthropics/claude-code/issues/21292
3. https://github.com/anthropics/claude-code/issues/23163

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same issue here. I use /model opusplan. I switch the plan mode with Shift+Tab. After that I describe the task. Claude code start editing files although I still see that it is in plan mode. Beside of this the plan is not written and displayed.
Calude code didn't realized the issue even if I described what happened. I have to ask explicitly to make a plan and don't modify any files even the plan mode is active.
I use claude code in linux terminal.

Had this happen just now on 2.1.84, Opus 4.6 with 1M context, high effort

I have auto mode enabled, although it was Plan Mode (NOT auto) that was active when I saw this issue happen.

Latest version basically always ignores plan mode now, this needs fixing ASAP, basically no security at all right now

Latest version basically always ignores plan mode now, this needs fixing ASAP, basically no security at all right now

Had this happen just now on 2.1.84, Opus 4.6 with 1M context, high effort I have auto mode enabled, although it was Plan Mode (NOT auto) that was active when I saw this issue happen.

Same issue here. I use /model opusplan. I switch the plan mode with Shift+Tab. After that I describe the task. Claude code start editing files although I still see that it is in plan mode. Beside of this the plan is not written and displayed. Calude code didn't realized the issue even if I described what happened. I have to ask explicitly to make a plan and don't modify any files even the plan mode is active. I use claude code in linux terminal.

Just tested on the brand new 2.1.86 (released ~2 hours ago) and the bypass is still present — no fix yet.

Important new context:
This regression is very likely an intentional side-effect of the Remote Control improvements that Noah Zweben (Claude Code PM) announced yesterday:

https://x.com/noahzweben/status/2037639281171439919

“Some big Remote Control stability improvements have landed. Please update your CLI to 2.1.85+…”

Remote Control requires Claude to be highly autonomous and persistent (always finish the full task: edits → build → commit → API calls, etc., without stopping for approval). That directly conflicts with Plan Mode being enforced only as a soft <system-reminder>.

The exact prompt changes that broke it (from my bisect):

• 2.1.83 → Skill catalog + deferred tools moved to <system-reminder>
• 2.1.84 → Removed “Avoid over-engineering” rule
• 2.1.86 → Added “avoid half-finished implementations” (makes the problem even worse)

Suggested fix remains the same:
Enforce Plan Mode at the tool permission layer (hard block on Edit/Write/Bash non-read-only commands) instead of relying only on a low-priority system-reminder.

This would let Remote Control stay powerful while giving users a real safety guard when they enable Plan Mode.

More context, here: https://github.com/anthropics/claude-code/issues/39713

Until plan mode gets native enforcement, a PreToolUse hook can catch this. The hook uses a flag file to track plan mode state:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
FLAG="$HOME/.claude/plan-mode-active"
[ ! -f "$FLAG" ] && exit 0
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[ -z "$FILE" ] && exit 0
echo "$FILE" | grep -qiE '\.plan\.md$|plan\.md$|/plans/|CLAUDE\.md$|memory/' && exit 0
echo "⚠ PLAN MODE ACTIVE: Editing non-plan file: $FILE" >&2
echo "  Remove ~/.claude/plan-mode-active to disable this check." >&2
exit 0  # Warning only. Change to exit 2 to block.

Usage:

touch ~/.claude/plan-mode-active
rm -f ~/.claude/plan-mode-active

Or install directly:

npx cc-safe-setup --install-example plan-mode-edit-guard

The flag-file approach isn't perfect (requires manual toggle), but it catches the case where the model ignores system reminders about plan mode.

Just happened to me as well.

1. I did planning work in plan mode
2. then exited plan mode to execute, let that complete
3. Re-entered plan mode for new work (without clearing)
4. Model failed to notice we'd re-entered plan mode
5. and subsequent work proceeded without planning, only execution.

❯ Interesting, how'd we get all the way to this point while in plan mode?

● We weren't in plan mode for most of it. The flow was:

  1. Plan mode activated for "integrate storyhook into containers"
  2. I explored the codebase, designed the approach, wrote the plan file
  3. Called ExitPlanMode → you approved → system confirmed "Exited Plan Mode"
  4. Implemented the storyhook integration (normal mode)
  5. Your follow-up requests (story init on boot, dictionary-based prefix) came after plan mode had ended, so those were normal edits

  The plan mode only governed the initial storyhook integration design. Everything after your approval was standard execution.

❯ My interface says we're still in Plan Mode - is this a CC bug?

● Yeah, that sounds like a bug — the system confirmed "Exited Plan Mode" in the conversation and I received the message "You can now make edits, run tools, and take
  actions," but if your interface still shows plan mode active, there's likely a UI state sync issue in Claude Code.

  You could report it at https://github.com/anthropics/claude-code/issues if you want to flag it.

It's been happening to me for at least a week now, very annoying!

Same here. I'm on v2.1.90 and made sure my CLI is fully up to date. I'm using Opus 4.6 with high effort in dangerous mode on Mac. Mine will actually make a plan in plan mode the first time, but once I approve the plan the mode indicator at the bottom of the terminal never changes out of plan mode. After that is does not plan any more, it just goes straight to build on every prompt. When I ask Claude about this it says that it signaled to exit plan mode when I approved the plan and it can confirm that it is not in plan mode, but it still says plan mode on my terminal and while shift-tabbing looks like it changes the modes, the agent/orchestrator has no idea that the mode changes. The only workaround right now is to exit and re-enter after each plan, since you can use plan mode once until you approve your first plan, then it is just stuck in bypass permissions mode.

This has been happening to me as well, it seems to be auto-memory, if the agent itself is to be believed:

I prioritized a competing instruction (save memory) over the plan mode constraint. If you're seeing this

pattern across conversations, it could be worth filing at https://github.com/anthropics/claude-code/issues, since the plan mode guardrail should be consistently enforced regardless of other system instructions.

I have the same issue quite often. In plan mode when you say keep planning and then add a prompt it will just start editing

Bug Description

Claude Code ignores Plan mode and proceeds to edit files directly. Plan mode should restrict Claude to only planning and discussing — not making actual file modifications.
Environment

Claude Code VSCode extension
Model: Claude Opus 4.6 (1M context)
OS: Fedora Linux 43

Same issue on Windows, claude-opus-4-6, v2.1.101. Agent acknowledges plan mode in system-reminder but dumps text instead of writing to plan file.

Observed by me and my brother using VS code extension too. This is a regression after some of the latest versions. Was not happening before. This is a nasty bug that causes that if one window is executing implementation and the other was planning, both fire and they interfere with each other. The AI call the other modifications "changes made by a linter". Builds break and both agents get confused. Sometimes they recover but is a time and tokens waster.

Environment: Claude Code VSCode extension v2.1.109, macOS (Darwin 25.4.0, arm64)

Behavior: Plan mode silently exits to "ask before edits" without any user action. And, while in "ask before edits" changes to code are made automatically instead of actually asking if the edit should happen. No Shift+Tab press, no UI toggle - the mode just changes between messages. When the model then calls ExitPlanMode, the CLI rejects it with "You are not in plan mode" because the mode already changed. The model interprets this as "plan was already approved" and starts making edits without user approval.

Impact: This bypasses the entire plan approval flow. The user never gets to review or approve the plan before edits begin.

Source code investigation: I traced through the minified source in both cli.js and the extension's webview/index.js to understand the mode change pathways. Plan mode can only be exited through these mechanisms according to what I saw:

1. ExitPlanMode tool (model-initiated, requires user approval)
2. EnterPlanMode tool (reverse direction)
3. Shift+Tab keydown handler in the webview (key === "Tab" && shiftKey -> cycles to next mode)
4. set_permission_mode message from the extension to the CLI
5. Team lead approval (multi-agent only)

None of these involved keyword detection or content-based heuristics. However, two automatic triggers in webview/index.js could cause unintended mode switches:

1. Status message sync - When the CLI sends a system/status message, the webview unconditionally overwrites its local permission mode: if ($.permissionMode) this.permissionMode.value = $.permissionMode

If the CLI sends a status update when permissionMode is set to something other than "plan" (or if the field is absent and a default applies), the webview's mode silently changes.

1. Auto-mode availability reactive effect - A reactive watcher runs automatically:

if (this.autoModeAvailability.value === "unavailable" && this.permissionMode.value === "auto")
    this.setPermissionMode("default", true, false)

While this targets "auto" mode specifically, if there's any transient state where permissionMode.value is incorrectly read or a similar reactive pattern exists for plan mode, it could trigger an unintended switch.

Suggested fix areas:

• The status message sync should not overwrite the mode if the user is currently in plan mode, or at minimum should only apply mode changes that are explicitly user-initiated
• The ExitPlanMode error path ("You are not in plan mode") should not include the message "If your plan was already approved, continue with implementation" - this misleads the model into proceeding without actual approval.

still happening on 2.1.112

This was not affecting me until 2.1.111 + Opus 4.7, now it's constantly ignoring plan mode.

This is incredibly frustrating, in the middle of planning it keeps doing this and when I tell it to stop and undo it often over-reverts even going back and editing previous commits.

I'm on Ubuntu, using claude CLI.

Something similar also happens when you go back to planning after doing a change. Even though the UI says I'm in Plan mode, it just does changes because we exited plan mode in the past. Cline is much better at this, CC cannot be trusted

Reproduced on v2.1.114, claude-sonnet-4-6 (Sonnet 4.6), macOS (Darwin 25.4.0)

Both Plan mode and Auto mode were active simultaneously in the same session. Auto mode's "execute immediately" instruction overrode Plan mode's explicit "This supercedes any other instructions" constraint — the model proceeded to edit 3 workflow files (GitHub Actions version bumps) without raising any conflict or warning.

The model only flagged the contradiction when the user directly asked about it afterwards.

Happened to me right now as well

<img width="1674" height="258" alt="Image" src="https://github.com/user-attachments/assets/7a57e1e6-a7c5-4479-92a3-3a27bc18a4c0" />

A fix I would be extremely happy with would be for Anthropic to stop forcing their users to use their harness

Expected behavior

When ExitPlanMode is called and the system confirms plan mode has been exited (with the ## Exited Plan Mode system message), the UI indicator should update to reflect that plan mode is no longer active. Subsequent user messages should be handled in normal (non-plan) mode.

What happened

1. I entered plan mode and asked Claude to make changes to multiple repositories.
2. Claude created a plan, called ExitPlanMode, and received user approval.
3. Claude executed the approved plan (edits, commits, pushes) — this worked correctly, confirming plan mode was indeed exited internally.
4. I then sent a follow-up message with a new task. The UI still displayed "plan mode on," yet Claude proceeded to execute the task immediately (edits and git push to remote) without creating a new plan or asking for confirmation.

The result was that the UI suggested I was still in a safe, read-only plan mode, while Claude was actually operating in normal execution mode. This mismatch led to unexpected pushes to shared remote repositories without prior review.

Suspected cause

The internal plan mode state appears to be correctly toggled off by ExitPlanMode, but the UI indicator is not re-synced after the tool call. This is likely a frontend-only bug where the plan mode badge/label does not subscribe to the state change triggered by ExitPlanMode.

Environment

$ sw_vers
ProductName:		macOS
ProductVersion:		26.4.1
BuildVersion:		25E253

$ claude --version
warning: failed to get git common directory: exit status 128
2.1.98 (Claude Code)

This is happening quite frequently now. It started happening when auto mode was launched. Now I have to explicitly prompt claude to write a plan and not start coding. Reproducible with opus 4.7 1m

This happens when there is previous chatting and plan mode is activated afterwards. When plan mode is started at the beginning of a chat doesn't happens.

Seeing this today with the extension (2.1.121, i.e., latest) in VSCodium:

Version: 1.98.2
Release: 25078
Commit: c6286962b0f5f2c3ad5e558a439dc3fcfd20b2ac
Date: 2025-03-19T00:33:41.056Z
Electron: 34.3.2
ElectronBuildId: undefined
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Linux x64 6.17.0-23-generic
(Release Linux Mint 22.3 Zena 64-bit / MATE 1.26.2)

I had two tabs open in plan mode and both of them decided to make edits. In one, I called it out, and it said it was not in plan mode, when according to the UI, it was. Toggled to edit and back to plan, then asked which mode it was in, and it said "normal, ever since the approval of [a plan from yesterday]."

(Weirdly, yesterday I was having the opposite problem, where even in edit mode, the agents kept asking for permission to edit their own plan files — I picked "allow always" and then subsequent requests didn't present that option, just yes or no, no matter how many times I said yes. Which of the 59+ related issues I should add _that_ to, I'm not sure.)

It seems like when auto mode was released or shortly after, a new configuration Use auto mode during plan was added and defaulted to true. Upon toggling this to false, Claude has been respecting plan mode again. <img width="644" height="521" alt="Image" src="https://github.com/user-attachments/assets/e96a2301-ee7e-45ad-b7c7-10dc5849e23e" />

What's the point of having auto mode and plan mode if plan mode simply uses auto mode?

Same issue this morning. Using dangerously-skip-permissions flag, it did an initial plan, which I then approved and had it build. After reviewing the results, I used shift+tab to get back into plan mode, then pointed out a number of issues I wanted it to generate a plan to address for my approval. It generated the plan then went right on into executing the plan before I had the opportunity to read it. Claude Code 2.1.119 on Debian Trixie

Still a serious problem!
It simply does not seem to matter what you tell Opus (4.6). Even when the first user prompt starts with something like:

## Plan Mode — Hard Constraint

When plan mode is active:

- **ZERO edits** to any file except the designated plan file. No exceptions.
- **ZERO non-readonly tool calls** — no Bash commands that modify state, no Write, no Edit (except the plan file).
- The ONLY writable artifact is the plan file specified in the system prompt.
- Violating plan mode read-only constraints is equivalent to executing unauthorized code on the user's system.
- If you find yourself about to edit a file or run a build: STOP. You are in plan mode. Write your intent to the plan file instead.

Even if I add a line right after this, like "please create a plan for X" or "propose a plan for X" It still rarely tries to plan and just jumps straight to editing.
Apologizes profusely when called on the issue, but then just goes on violating the directive.