Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Plan mode indicator shows on, but Edit/Write still execute — no bypass involved, no defaultMode set [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52847•Fetched 2026-04-25 06:19:18
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
sergiolopez94sergiolopez94
Participants
sergiolopez94sergiolopez94
Timeline (top)
labeled ×5
RAW_BUFFERClick to expand / collapse

Environment

  • Claude Code version: 2.1.119
  • OS: macOS, Darwin 24.0.0 (arm64)
  • Install path: ~/.local/share/claude/versions/2.1.119
  • Launch: plain claude (no CLI flags, no shell alias, no CLAUDE_* env vars that force a mode)

Behavior

Plan mode indicator reads green plan mode on in the status line. Despite this, the main loop continues to execute Edit / Write tool calls — the permission system does not block them, no approval prompt is shown, and the ExitPlanMode / AskUserQuestion artifact UIs render as plain text rather than their approval/picker surfaces.

A screenshot confirmed: a code diff (red/green) was visibly applied in the terminal while the plan-mode indicator was active.

Not related to #40623

The session has never entered bypassPermissions mode during its lifetime. The known bug where switching from bypass → plan leaves bypass silently active does not apply here.

Settings / environment ruled out

~/.claude/settings.json relevant keys:

  • No permissions.defaultMode set (we previously had it set to an auto-accept value, then to "default", then removed entirely — behavior persisted until full removal, but the bug has recurred in a later session even with the key absent from the start).
  • "skipAutoPermissionPrompt": true (the "don't re-ask about setting auto as default" flag) — benign, unrelated.
  • "skipDangerousModePermissionPrompt": true was present; has been removed this session. Bug reproduces with or without it.

Other vectors ruled out:

  • No hooks manipulate permission modes.
  • No --permission-mode or --dangerously-skip-permissions flag in use.
  • No shell alias for claude.
  • No CLAUDE_PERMISSION_MODE / CLAUDE_AUTO_APPROVE env var set.

Reproduction

  1. Launch claude in a project directory.
  2. Enter plan mode via Shift+Tab. Indicator turns green, reads plan mode on.
  3. Ask Claude to perform an edit (e.g. "add a line to README.md").
  4. Observed: the Edit tool call executes. No approval prompt. No plan artifact. No AskUserQuestion picker.

Happens across multiple projects and fresh sessions.

Additional notes

  • Multiple concurrent claude processes running on the machine (5 terminals). Unclear if mode state leaks between sessions.
  • When permissions.defaultMode had previously been set, changing its value to "default" did NOT restore normal behavior — only removing the key entirely did. That sticky behavior may be related.

Requested

  • Confirmation that plan mode is expected to gate Edit/Write/Bash even when skipDangerousModePermissionPrompt is set and when defaultMode has ever been configured historically.
  • Clarification of exactly which settings / history states can cause plan mode to silently not enforce while the indicator reads green.
  • Fix for the sticky behavior and the indicator-vs-actual-state mismatch.

extent analysis

TL;DR

The plan mode in Claude may not be properly enforced due to a sticky behavior caused by historical configuration settings, leading to the execution of Edit/Write tool calls without approval prompts.

Guidance

  • Verify that the permissions.defaultMode key is completely removed from the ~/.claude/settings.json file to ensure it doesn't influence the current behavior.
  • Check for any potential mode state leaks between concurrent claude processes by testing the plan mode behavior with only one instance running.
  • Investigate the relationship between the skipDangerousModePermissionPrompt setting and plan mode enforcement to determine if it's a contributing factor.
  • Test the plan mode behavior with a clean configuration (i.e., no historical settings or environment variables) to isolate the issue.

Example

No code snippet is provided as the issue seems to be related to configuration and settings rather than code.

Notes

The issue may be related to the historical configuration of permissions.defaultMode and its removal, as well as the presence of skipDangerousModePermissionPrompt. The behavior of plan mode when multiple claude processes are running concurrently is also unclear.

Recommendation

Apply a workaround by ensuring that all relevant settings are reset to their default values and testing the plan mode behavior in isolation to identify the root cause of the issue. This approach is chosen due to the uncertainty surrounding the interaction between different settings and the potential for mode state leaks between processes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#container setup#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING