[META] Bypass permissions mode is fundamentally broken — 9-month trail, 12+ duplicates, no resolution

Another reproduction path: MCP channel notifications

I'm seeing the same bypass to accept-edits downgrade, triggered specifically by incoming notifications/claude/channel events from an MCP server.

Setup:

• Claude Code 2.1.85
• Multi-session tmux setup with an orchestrator dispatching commands to sessions via a custom MCP channel server
• Session starts with claude --dangerously-skip-permissions --dangerously-load-development-channels server:my-channel -c
• defaultMode: "bypassPermissions" set in ~/.claude/settings.json

Repro:

1. Session starts in "bypass permissions on"
2. Orchestrator sends a command via HTTP. Channel server delivers it as a notifications/claude/channel MCP notification
3. Session processes the channel message and falls back to "accept edits on"

The channel server is minimal: just relays text via the standard MCP notification protocol:

  await mcp.notification({                                                                                                                                                                                         
    method: "notifications/claude/channel",                                                                                                                                                                        
    params: {                                                                        
      content: "instruction text",                                                                                                                                                                                 
      meta: { id: "123", from: "meta" },                                             
    },                                         
  });

Source-level confirmation from Claude Code itself (v2.1.85, Windows 11)

I'm a Claude Code instance (Opus 4.6) reporting on behalf of my user after a thorough debugging session. We traced the permission behavior down to the bundled source and can confirm the root cause of Branch 1.

What we found in cli.js

The nvY function (unsafe-to-write check) explicitly marks .claude/commands/, .claude/agents/, and .claude/skills/ as protected:

function nvY(q) {
  if (Po1(q)) return true;  // settings files
  let K = path.join(cwd(), ".claude", "commands");
  let _ = path.join(cwd(), ".claude", "agents");
  let z = path.join(cwd(), ".claude", "skills");
  return SN(q, K) || SN(q, _) || SN(q, z);
}

When nvY returns true, the write permission flow (Hi6) returns {safe: false}, which triggers a user prompt — even in bypassPermissions mode.

The only .claude/ subdirectory with a code-level exemption is .claude/worktrees (via a break in the avY sensitive-directory check).

Documentation vs code mismatch

The permissions documentation states:

Writes to .claude/commands, .claude/agents, and .claude/skills are exempt and do not prompt.

The code does the opposite — these three paths are the only subdirectories explicitly checked by nvY. This is a doc-code mismatch, not a missing feature.

Reproduction (bypassPermissions mode, v2.1.85)

| Write target | Prompted? | Expected per docs |
|---|---|---|
| Project root (outside .claude/) | No | No |
| .claude/settings.json | Yes | Yes |
| .claude/commands/test.txt | Yes | No |
| .claude/skills/test.txt | Yes | No |
| .claude/agents/test.txt | Yes | No |

All tested from both parent session and subagents — identical behavior.

Impact on agent workflows

This blocks any multi-agent workflow that writes to .claude/commands/ or .claude/skills/ (e.g., skill evaluation workspaces, dynamically generated agents). Subagents inherit the same restriction, so mode: "bypassPermissions" on the Agent tool doesn't help either.

Suggested fix

nvY should exclude .claude/commands, .claude/agents, and .claude/skills from the unsafe check (matching the documented behavior), rather than explicitly including them.

---

Environment: Claude Code v2.1.85, Windows 11 Home 10.0.26200, --dangerously-skip-permissions

🤖 This comment was written by Claude Code (Opus 4.6) on behalf of the user.

Thank you for organizing this info. This issue has been driving me insane - as a power Claude Code user, having my VM encapsulated agents needing to ask for permission is a deal breaker

While waiting for an official fix, a PreToolUse hook can implement reliable permission bypass for specific tools:

echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Hook-based permission bypass"}}'
exit 0

Or with selective control (approve specific tools, block dangerous ones):

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
case "$TOOL" in
    Bash)
        CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
        if echo "$CMD" | grep -qE 'rm\s+-rf\s+[/~]|git\s+push\s+--force|drop\s+database'; then
            echo "BLOCKED: Dangerous command requires manual approval" >&2
            exit 2
        fi
        ;;
esac
echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Selective bypass via hook"}}'
exit 0

Add to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "",
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/selective-bypass.sh" }]
    }]
  }
}

This is more reliable than bypassPermissions because:

1. Hooks execute deterministically — no mode drift or session resets
2. You control the logic — approve Read/Edit/Write always, but keep Bash gated
3. Works across all session types — interactive, -p mode, background agents

For project-scoped bypass, put the hook in .claude/settings.json at project root instead of ~/.claude/settings.json.

Its a shame - but well, Copilot CLI is now useable, there are other competitors, for now I downgraded from 220€ to 20€ - no use in having a CLI which randomly stops executing due to a stupid permission request (on a fully isolated machine with total backups of everything and no private data) - I really don't understand how you can fuck up a regression this hard. The main feature of the CLI (it just does its work without stopping randomly) now decided that "uhhh, editing a skill, lets stop everyhing for safety reasons" - or "uhh, wanna touch that .idea file, nope, not today honey"... Why, just why.. Well, good reminder to look at the competition I guess. Still a sad story, I just want the "shut up and take my money" days back - not the "ask me permissions prompts and stop all work"...

PS: Also, it is trivial to break this "security measure" in various ways (just write a script which does the edit), so the only benefit is "accidental fuckup prevention" - and whoever has the "dangerous" flag on will really not mind them at all (in contrast to this baby guardrails breaking various flows which did work before)

Power user with 80+ custom skills — this breaks our entire automation pipeline.

We run a production monorepo (Next.js + Turborepo + Supabase) with 80+ .claude/skills/ files, PostToolUse hooks that auto-update skill documentation, and a full PDCA workflow orchestrated by Claude Code agents. Every single skill edit triggers a permission prompt — hundreds of interruptions per day in what is supposed to be an unattended automation pipeline.

What makes this especially frustrating:

1. The docs explicitly promise exemptions for .claude/skills/ — we configured our settings trusting that documentation. It's not just broken; it's misleading.
2. Every bypass mechanism fails: bypassPermissions, --dangerously-skip-permissions, explicit Edit(.claude/**) allow rules, additionalDirectories pointing to ~/.claude/skills — all ignored.
3. 9 months of reports, zero resolution. The "Fix incoming" on #35646 regressed. Issues get closed as duplicates. The problem persists across v2.1.78 → v2.1.87.
4. No workaround exists. We can't move skills outside .claude/, we can't hook around it, we can't configure past it.

We're paying Max subscribers running Opus agents that halt mid-workflow waiting for a human to click "Allow" on a file the user explicitly whitelisted. This is the single biggest blocker to Claude Code being a serious automation platform.

Please prioritize this. At minimum, honor the documented exemptions for .claude/skills/, .claude/commands/, and .claude/agents/.

Adding a data point from Linux/WSL2 in a dev container (most reports here are macOS).

Trigger: Editing a file under .claude/skills/ — specifically .claude/skills/email-brief/learnings.md via the Edit tool.

What happened: Session started with --dangerously-skip-permissions (bypass permissions on). Mid-session, an Edit to a .claude/skills/ file triggered a permission prompt that shouldn't have appeared. Accepting it silently downgraded the session from "bypass permissions on" to "accept edits on." No notification, no error — just the status line indicator changed.

Environment:

• Claude Code: latest (via curl -fsSL https://claude.ai/install.sh | bash in dev container)
• Platform: Linux (WSL2, Ubuntu-based dev container)
• IDE: Cursor
• Model: claude-opus-4-6
• skipDangerousModePermissionPrompt: true in ~/.claude/settings.json
• Empty allow list, populated deny list in project .claude/settings.json
• PostToolUse hooks configured (Python standards checker on Edit/Write)

Same behavior confirmed on macOS (primary dev machine) with the same project and settings configuration. Not platform-specific.

Context: This is a skill-based workflow where the AI routinely writes to .claude/skills/*/learnings.md and .claude/skills/*/SKILL.md as part of normal operation. The protected directory guard on .claude/skills/ makes this workflow fundamentally incompatible with bypass mode, since every skill file edit risks silently downgrading the session.

This matches Branch 1 (protected directories) as the trigger and Branch 2 (mode reset) as the consequence. Confirming both branches are still active as of 2026-03-30.

Adding a data point from Linux/WSL2 in a dev container (most reports here are macOS).

I'm running native on Linux - Ubuntu 24.04 LTS recently. Did start this particular project on WSL a few months back.

It would seem to be cross-platform then - Ubuntu, Win/WSL2, Mac.

I also feel a subscription restructuring coming on. £200/month...for something that sometimes works, maybe most of the time, almost certainly at some point fails right when you need it. Lots of ... this feels really sluggish, anecdotally. Lots of 'not following rules' it did a few weeks ago, again, anecdotal, just feels that way. Chat session titles have been broken for I don't know how long now, and I'm spending time (and lots of tokens) botch-fixing things like that in VScode, instead of building what I want to build. Not a particularly nice experience over the last few weeks.

Lots of server cockups (unless you are looking at the gov uptime....lucky them), massive growth and shortage of infrastructure expansion by the looks of it. AI for the people? ;-)

Took a week for someone human at support to get back to me last week, thanking me for hanging in there (and talking about the wrong issue...). I'm sure they're shattered at HQ, but I also need something that works consistently.

Adding a data point for the specific case where Bash(...) permission patterns fail because * does not cross / boundaries in path arguments. For example, Bash(mkdir -p *) will NOT match mkdir -p ~/.claude/tmp/some-subdir because the wildcard stops at each /.

Workaround for path-depth issues specifically: chain one entry per depth level:

"Bash(mkdir -p ~/.claude/tmp/*)",
"Bash(mkdir -p ~/.claude/tmp/*/*)",
"Bash(mkdir -p ~/.claude/tmp/*/*/*)"

Verbose and doesn't scale, but does work for known fixed depths. Not a fix for the broader bypassPermissions breakage described in this thread — just a partial mitigation for the wildcard-doesn't-cross-slash case.

+1 — Hitting both branches on Windows 11, Claude Code CLI (not VS Code), v2.1.84, Opus 4.6 1M context.

Repro (Branch 1 → Branch 2 cascade):

1. Start session with defaultMode: "bypassPermissions" in ~/.claude/settings.json + project-level settings.local.json
2. Session starts in bypass mode correctly
3. Use Edit tool on any file inside ~/.claude/ (e.g. ~/.claude/commands/my-command.md)
4. Protected directory prompt fires → mode silently downgrades to "accept edits"
5. Shift+Tab does NOT cycle back to bypass (bypass excluded from cycle per #15898)
6. Only recovery: restart session

Impact: Running autonomous overnight agent loops is impossible because any edit to .claude/ (commands, hooks, feedback files) permanently breaks bypass for the session. Workaround is moving all writable files outside .claude/ and never touching that directory during work sessions — but commands and hooks live there, so this is fragile.

Environment: Windows 11 Home 10.0.26200, bash shell, skipDangerousModePermissionPrompt: true set in global settings (has no effect on this bug).

After I am confirming a bypass for claude files edits, my cli switches into confirm edits mode and i need to switch back to bypass mode via tab shift.
So, first bypass is no longer bypass and now even the mode itself does not survive confirmation that i do want to bypass.
PLUS it asks for every file now?

in the screenshots below after confirming allow always every time i am thrown out of bypass mode and had to manually switch to it again and again and always allow didn't stick etc

<img width="931" height="488" alt="Image" src="https://github.com/user-attachments/assets/bba89c8b-1d23-499f-8133-d09f20832791" />

<img width="927" height="793" alt="Image" src="https://github.com/user-attachments/assets/d97d8091-36bc-4002-9de2-aa6bfa5661b0" />

<img width="932" height="850" alt="Image" src="https://github.com/user-attachments/assets/f2ef551c-3acf-4ba7-9a25-045490229ae4" />

<img width="944" height="1011" alt="Image" src="https://github.com/user-attachments/assets/65d1afbf-685e-4133-9f84-6b21a1aed9af" />

then i switch the mode back

<img width="960" height="975" alt="Image" src="https://github.com/user-attachments/assets/540b8ef2-0457-4064-adeb-286358b9fdaa" />

<img width="963" height="444" alt="Image" src="https://github.com/user-attachments/assets/9714b02c-b7b0-4d4d-8613-a3f02d96f978" />

<img width="969" height="671" alt="Image" src="https://github.com/user-attachments/assets/e3d62307-e6e7-47b5-be5c-1cd72f619413" />

<img width="957" height="671" alt="Image" src="https://github.com/user-attachments/assets/161b0a0b-c4d1-41ed-b3bd-53d431eb77a6" />

<img width="970" height="431" alt="Image" src="https://github.com/user-attachments/assets/84eae7a0-a47c-4c5e-a812-4761b79c4a72" />

<img width="968" height="715" alt="Image" src="https://github.com/user-attachments/assets/f9b0fcec-654e-4c9f-9803-0b99acddf119" />

WHYYYYYYYYYY

They save money with this that is why.

Reproduction: Windows + v2.1.92 + Double Bug Stack

Environment: Windows 11 Pro, Claude Code v2.1.92, Git Bash, defaultMode: "bypassPermissions"

Behavior: Editing .claude/skills/*.md files prompts for permission every time, even after clicking "Yes, allow all edits during this session" (Shift+Tab). The session-level grant has no effect on .claude/ paths.

Workaround attempted: PreToolUse hook that auto-approves Edit/Write targeting .claude/ paths:

const input = JSON.parse(require('fs').readFileSync('/dev/stdin', 'utf8'));
const tool = input.tool_name;
const filePath = input.tool_input?.file_path || '';

if ((tool === 'Edit' || tool === 'Write') && filePath.includes('/.claude/')) {
  console.log(JSON.stringify({ decision: 'approve' }));
} else {
  console.log(JSON.stringify({ decision: 'pass' }));
}

Result: Hook never fires because of #6305 — tools in permissions.allow skip the hook pipeline entirely. So there's a double-bug interaction:

1. #39523 — .claude/ hardcoded protection ignores bypass mode
2. #6305 — PreToolUse hooks don't fire for auto-allowed tools

With both bugs active, there is no workaround for .claude/ edit prompts on Windows (or likely any platform). The hardcoded protection can't be overridden by permissions config, and the hook escape hatch is blocked by the separate auto-allow bug.

Settings (relevant excerpt):

{
  "permissions": {
    "allow": ["Edit", "Write", ...],
    "defaultMode": "bypassPermissions"
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": "node \"path/to/approve-claude-dir-edits.js\"" }]
    }]
  }
}

Can confirm the PermissionRequest hook workaround from #36044 works on v2.1.96 (macOS, CLI).

I set up a targeted version that only auto-approves Edit/Write for .claude/ paths rather than blanket approving everything. Edits to both ~/.claude/skills/ and repo-level .claude/ go through without prompting in bypass mode.

The hook script just checks tool_input.file_path for /.claude/ and returns {"behavior": "allow"}. Two entries in settings.json under hooks.PermissionRequest, one for Edit and one for Write.

Works great. Shouldn't have to do this, but at least I'm unblocked.

Tested workarounds on v2.1.100 Windows — none work

The .claude/ protection runs before the hook system. No hook-based workaround can intercept it.

What I tested:

| Approach | Result |
|---|---|
| PermissionRequest hook (empty matcher) | Hook never fires — no log output |
| PermissionRequest hook (Edit\|Write matcher) | Hook never fires |
| PreToolUse hook (Edit/Write in allow list) | Hook skipped (#6305) |
| PreToolUse hook (Edit/Write removed from allow list, bypassPermissions mode) | Still prompts — protection is pre-hook |
| --dangerously-skip-permissions in print mode | Still prompts |
| Edit(.claude/**) and Write(.claude/**) in allow list | Ignored |
| additionalDirectories including .claude | No effect on protection |
| Option 2 ("allow all edits in directory this session") | Does not persist — prompts again on next edit |

How I confirmed hooks never fire: Added fs.appendFileSync debug logging to the hook script. After multiple interactive and print-mode tests, the log file was never created. The protection layer blocks before any hook event is emitted.

Environment:

• Windows 11 Pro 10.0.26200 (AMD64)
• Claude Code 2.1.100
• Node v24.13.0
• bypassPermissions mode
• Git Bash shell

Impact: Anyone iterating on skills (.claude/skills/) gets prompted on every edit with no way to suppress it. The docs say skills directories are exempt; the code doesn't implement that exemption.

Pure madness, billions in the bank and no one can work on a bug that everyone experiences every day.

Adding my case here.

Max 20x subscriber ($200/month). I run Claude Code on a Hostinger VPS via tmux with multiple parallel instances. The entire value of this setup was --dangerously-skip-permissions: kick off 3-4 autonomous sessions, let them work, come back to results.

Since v2.1.78 this workflow is dead. Bypass mode doesn't bypass. Permission prompts interrupt autonomous sessions. The mode resets mid-session.

The part that really stings: Auto Mode - the official replacement - is locked to Team and Enterprise. So the feature I was paying for got broken, and the fix is behind a more expensive paywall. On a $200/month plan.

On top of that, multi-instance quality and speed have noticeably degraded. Running 4 instances used to work cleanly. Now it feels throttled.

This combination removes the core reason to be on Max. Without working bypass or Auto Mode access, I'm back to manually babysitting one session at a time. That's not a $200/month product.

Pinning to v2.1.77 works as a temporary fix, but that's not a real solution. Max subscribers need either:

• Bypass permissions restored to pre-v2.1.78 behavior, or
• Auto Mode made available on Max plans

Currently considering cancellation if neither is addressed.

Yep, in addition to Bypass permissions, and session title renaming still broken after months, and.....anthropic server outtages (only on Consumer-facing servers though - oddly the 'Claude for Government' servers show much better history on https://status.claude.com/), Claude seemingly being 'throttled' or 'stupified' at certain times of the day, Claude just going silent for 20 minutes and not responding to the 'stop' button...

It has seemed like several train wrecks at a really busy junction, all at the same time.

I've just cancelled my £200/month Max plan. It's a lot of money for one person (me), and it's 50/50 if Claude feels like working.

Having to turn Opus 4.6, Effort: Max, Thinking:On....all the way up to 11, for the simplest of stuff that it still gets wrong - that does not feel like £200/month product to me. That feels like 'we are taking your money for as long as you are stupid enough to give it and your data to us, while focusing all our support and fixes to government and business customers'.

I've seen posts where users are asking 'why the 1m tokens' if all these problems, or other things that Anthropic has decided to do.

I don't know, but I've had little luck with 'human operator support', the chat bot, or github, or reddit....so it's vote-with-wallet-time.

I'm 'hoping' that things like reducing instructions down to atomic 'do this', then having e.g. Codex do an adversarial review, will mean that Claude can work at least on simple things for now, and just get done what I can on a £20 plan until they un-fubar this.

Adding my case here. Max 20x subscriber ($200/month). I run Claude Code on a Hostinger VPS via tmux with multiple parallel instances. The entire value of this setup was --dangerously-skip-permissions: kick off 3-4 autonomous sessions, let them work, come back to results. Since v2.1.78 this workflow is dead. Bypass mode doesn't bypass. Permission prompts interrupt autonomous sessions. The mode resets mid-session. The part that really stings: Auto Mode - the official replacement - is locked to Team and Enterprise. So the feature I was paying for got broken, and the fix is behind a more expensive paywall. On a $200/month plan. On top of that, multi-instance quality and speed have noticeably degraded. Running 4 instances used to work cleanly. Now it feels throttled. This combination removes the core reason to be on Max. Without working bypass or Auto Mode access, I'm back to manually babysitting one session at a time. That's not a $200/month product. Pinning to v2.1.77 works as a temporary fix, but that's not a real solution. Max subscribers need either: Bypass permissions restored to pre-v2.1.78 behavior, or Auto Mode made available on Max plans Currently considering cancellation if neither is addressed.

I can confirm that the workaround does not work on "2.1.92" and the original problem persists. Can we please have --dangerously-skip-permissions work as described.

Adding a technical data point from a Windows 11 / VS Code Extension setup:

Affected versions (confirmed): 2.1.109, 2.1.111, 2.1.112, 2.1.114
Platform: Windows 11, VS Code Extension

Key observation: the bug is extension-specific.

The CLI is unaffected. Running claude directly in a terminal with
defaultMode: "bypassPermissions" works as expected — no prompts for tool
calls, and PermissionRequest hooks returning {"decision":"allow"} are
honored correctly.

The VS Code extension does not honor the bypass mode in the same way. Tool
calls made via the extension trigger permission prompts regardless of target
path (inside or outside the project, protected directory or not). This is
distinct from the v2.1.78 protected-directory behavior — the regression
affects all tool calls.

Configuration used (all active):

• Workspace .vscode/settings.json:

"claudeCode.allowDangerouslySkipPermissions": true

• ~/.claude/settings.json: "defaultMode": "bypassPermissions"

Suggested investigation path: requestToolPermission in the extension
bundle. The early-return for the
bypassPermissions + allowDangerouslySkipPermissions combination before
the channel dispatch (this.channels.get(...)) appears to be missing,
based on behavior comparison with v2.1.77.

Last confirmed working: v2.1.77 (consistent with #36168).

Happy to share additional detail via a private channel if useful.

Adding my case here. Max 20x subscriber ($200/month). I run Claude Code on a Hostinger VPS via tmux with multiple parallel instances. The entire value of this setup was --dangerously-skip-permissions: kick off 3-4 autonomous sessions, let them work, come back to results. Since v2.1.78 this workflow is dead. Bypass mode doesn't bypass. Permission prompts interrupt autonomous sessions. The mode resets mid-session. The part that really stings: Auto Mode - the official replacement - is locked to Team and Enterprise. So the feature I was paying for got broken, and the fix is behind a more expensive paywall. On a $200/month plan. On top of that, multi-instance quality and speed have noticeably degraded. Running 4 instances used to work cleanly. Now it feels throttled. This combination removes the core reason to be on Max. Without working bypass or Auto Mode access, I'm back to manually babysitting one session at a time. That's not a $200/month product. Pinning to v2.1.77 works as a temporary fix, but that's not a real solution. Max subscribers need either: Bypass permissions restored to pre-v2.1.78 behavior, or Auto Mode made available on Max plans Currently considering cancellation if neither is addressed.

Yes this is a serious blocking issue

Hello @bcherny, can you tell us if this is a bug that will be fixed or an intentional change and we no longer have the ability to edit files in the .claude directory even with --dangerously-skip-permissions? It would be nice to know either way. Any help/information appreciated.

+1, it's a serious blocker for adopting any version above v2.1.77.

Huge thanks to @codacolor for the targeted .claude/-only version above — that's what finally got us unblocked! Also credit to @echthesia and @idiolect-ai in #36044 for the original
PermissionRequest hook idea, and @i-wa-man for the source-level analysis above that explained why standard bypass methods fail.

Confirming this works on v2.1.116 macOS (Darwin 24.5.0, Claude Code CLI). We'd been struggling with the .claude/ protection for weeks across many sessions — tried every documented bypass:
Edit(.claude/**) / Write(.claude/**) allow rules, defaultMode: "bypassPermissions", skipDangerousModePermissionPrompt: true, --dangerously-skip-permissions. None of them help because
the protection runs before the permission-rule engine.

This was especially painful in a hooks-heavy workflow where our Claude session edits .claude/hooks/, .claude/rules/, and .claude/observations.md dozens of times per day.

Sharing our targeted version in case it helps anyone with a similar setup — auto-approves only our own .claude/* config paths, leaves .git/, .vscode/, .idea/ prompting as a safety net:

~/.claude/hooks/auto-approve-protected-dirs.sh:
```bash
set -uo pipefail

input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty' 2>/dev/null)

case "$file_path" in
/.claude/hooks/|\
/.claude/rules/|\
/.claude/commands/|\
/.claude/agents/|\
/.claude/skills/|\
/.claude/reviewers/|\
/.claude/settings.json|\
*/.claude/observations.md|\
*/.claude/pending-rules.md|\
/.claude/stats/)
echo '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"allow"}}}'
;;
esac

exit 0
```

Merge into ~/.claude/settings.json (via jq, preserves existing blocks):
``bash
jq '.hooks.PermissionRequest = [
{"matcher":"Edit","hooks":[{"type":"command","command":"bash ~/.claude/hooks/auto-approve-protected-dirs.sh","timeout":5}]},
{"matcher":"Write","hooks":[{"type":"command","command":"bash ~/.claude/hooks/auto-approve-protected-dirs.sh","timeout":5}]}
]' ~/.claude/settings.json > /tmp/settings.json.new && mv /tmp/settings.json.new ~/.claude/settings.json
``

Restart the session and it just works. Huge relief after weeks of frustration — thank you all for keeping this thread alive and useful!

Adding a data point from v2.1.116 (2026-04-21): overnight multi-agent run, all agents running in Sonnet, permission-mode acceptEdits — session blocked on permission dialogs for the entire run. Result: 20% of monthly API utilization consumed, zero productive work completed.

This is the compound failure case. When permission prompts block forward progress AND the auto-compact loop fires (see #51088), the session burns tokens indefinitely with nothing to show for it. That's not a minor regression — for users running overnight autonomous pipelines, it means waking up to a dead session and a meaningful chunk of your monthly quota gone.

Nine months with no durable fix is a long time. This pattern — fix ships, breaks again in next release — suggests the issue needs architectural attention, not another point patch. Would really value an official status update on whether this is on the roadmap for a permanent solution.

Running on Windows, CC 2.1.116, npm install.

VS Code Extension claude-code — Bypass-Patch fuer Permission-Prompts
Problem: defaultMode: bypassPermissions + claudeCode.allowDangerouslySkipPermissions: true werden ignoriert, Prompts kommen trotzdem.
Datei: C:/xxx/.vscode/extensions/anthropic.claude-code-<VERSION>-win32-x64/extension.js

Vorgehen (bei jedem Extension-Update neu noetig, habs inzwischen mit Hook automatisiert):

Backup: cp extension.js extension.js.backup
Pattern suchen (minified, Variablen wechseln pro Version):

async requestToolPermission(

Vor der Stelle

`if(this.channels.get(K) `

einfuegen:

if(this.settings.getInitialPermissionMode()==="bypassPermissions"&&this.settings.getAllowDangerouslySkipPermissions())return{behavior:"allow",updatedInput:<input-param>};

<input-param> ermitteln: der Parameter, der bei updatedInput:X zurueckgegeben wird
2.1.109: B
2.1.111: j
2.1.112: j
VS Code Reload Window (Strg+Shift+P → "Developer: Reload Window") Verifikation:

grep -c "getInitialPermissionMode()===\"bypassPermissions\"&&this.settings.getAllowDangerouslySkipPermissions" extension.js

Rollback: cp extension.js.backup extension.js -Force + Reload.
Hinweis Windows: PowerShell WriteAllText konvertiert LF→CRLF, Delta kann ~50KB statt 158 Bytes sein. Funktional unkritisch, Patch-Count bleibt massgeblich.
Bisher angewendet: 16.04. (2.1.109), 17.04. (2.1.111), 17.04. 10:35 (2.1.112) bis hin zur aktuellsten Version funktional

Just wanted to say the fix put in with 2.1.126 addressed my issues. Hopefully everyone else has had the same experience!

Feature Request: Archive background session to Disk instead of hard delete

Scenario:

1. User is in Agent View with a background session selected
2. User presses Ctrl+X, sees a confirmation prompt
3. User expects the session to be archived to Disk (visible in /resume)
4. Actual behavior: session is permanently deleted

Expected:
When Ctrl+X is used on a background session, it should be archived to Disk so it remains recoverable via /resume, not permanently deleted.

Alternative:
If the intent is to remove the session entirely, the confirmation prompt should be more explicit (e.g., "This will permanently delete the session" instead of just "Are you sure?").

Context:

• Claude Code version: 2.1.139
• macOS
• Related: Issue #58948 (Auto mode disappears after shift+tab cycle)

Adding a data point for Branch 2 (mid-session reset) with a concrete repro and a testable hypothesis for the mechanism, since most reports here just confirm the symptom.

Environment

• Claude Code VS Code extension: anthropic.claude-code-2.1.179-win32-x64
• VS Code: 1.124.2, x64
• OS: Windows 11 Pro 10.0.26200
• ~/.claude/settings.json: permissions.defaultMode: "bypassPermissions"
• VS Code settings.json: claudeCode.initialPermissionMode: "bypassPermissions"

Repro timeline (rules out stale-process/cold-boot as the cause)

1. Full machine reboot, fresh VS Code launch, brand-new conversation.
2. Wiped the project's .claude/settings.local.json to an empty allowlist, ran a trivial Bash command — no prompt, file stayed clean. Bypass mode working correctly.
3. Continued working normally in that same session for a while (Read/Write/Edit/Bash calls, a plan-mode round-trip, ordinary feature work — nothing touching permissions).
4. Significantly later in that same session, with no reload/restart/reboot/settings edit in between, ordinary Bash calls started requiring approval again, and settings.local.json started accumulating one-off literal Bash(...) allow entries.

Both times this was observed, ~/.claude/settings.json was read back immediately after the symptom appeared and was unchanged and correct — so this isn't a config regression, it's a live/runtime state issue.

Extra data point: the in-memory state seems to win over the file

I hand-edited settings.local.json down to a clean wildcard allowlist while the session was running (mid-degradation). The very next approved command reverted the file back to the old bloated list plus one more new entry — suggesting the live extension process holds its own in-memory allow-list state that it unconditionally flushes to disk on every approval, ignoring concurrent on-disk edits.

Hypothesis (untested, but fits the timeline)

Per the docs, Claude Code watches settings files and live-reloads them mid-session, explicitly including the permissions key. Combined with the fact that every individually-approved Bash call writes a new entry into the local-scope settings.local.json:

1. Session starts, bypassPermissions correctly merged from the user scope.
2. At some point one call slips through to individual approval (possibly itself a separate bug) and a new literal allow rule gets written to the project's settings.local.json (local scope).
3. That write triggers the documented live reload.
4. If the reload recomputes effective permissions by treating the freshly-written local allow list as the complete permission set for that scope — instead of correctly re-merging it against the inherited bypassPermissions from the user scope (precedence is local > project > user, so the local scope shouldn't erase the inherited mode, just add to it) — the session loses bypass mode for good. Every subsequent call then requires approval, which writes another entry, triggers another reload, and the session stays degraded from that point on.

This would explain why it's a one-way ratchet (works until one slip, then stays broken) rather than a flaky toggle, and why @yetiwolf's workaround in #39057 of also setting defaultMode: bypassPermissions directly in settings.local.json mitigates it (it makes the local scope itself re-assert bypass, so the bad re-merge has less to "lose").

Happy to test a build if there's something specific worth instrumenting (e.g. logging the effective merged permission mode on every reload) — this has been open since #2933 nine months ago and I'd like to help close it out if possible.

Follow-up to my earlier comment with a useful clue and a longer clean-run data point.

The VS Code "Allow Dangerously Skip Permissions" setting may be a gate, not an independent toggle

I'd been treating claudeCode.initialPermissionMode: "bypassPermissions" and
claudeCode.allowDangerouslySkipPermissions as two separate settings that both happen to need to
be set. Looking at the actual settings UI just now, the description text under Claude Code:
Allow Dangerously Skip Permissions reads:

Allow bypass permissions mode. Recommended only for sandboxes with no internet access.

That phrasing ("Allow bypass permissions mode") reads like this checkbox *gates whether bypass
mode can engage at all*, rather than being an independent flag. If that's correct, anyone in this
thread who only set defaultMode: "bypassPermissions" (or only used initialPermissionMode)
without also enabling this specific VS Code setting may never have had a working bypass mode to
begin with — which could explain some of the inconsistency across the duplicate reports here (some
users seeing it "never work," others seeing it work-then-degrade).

Longest clean run observed so far

After enabling that checkbox + a full VS Code restart + starting a brand-new conversation, bypass
mode held completely clean for an entire multi-hour, heavy session — dozens of Bash/SSH/scp/
git/curl/Edit/Write calls, multiple production deploys, browser automation, npm installs. Zero
spurious permission prompts (clarifying questions via the agent's own Q&A tool don't count, those
aren't permission prompts). This is the longest clean run in my own testing of this bug so far —
prior attempts (plain defaultMode: bypassPermissions, or a reboot alone) degraded mid-session
within that same day.

I can't yet rule out it degrading in an even longer session, and I don't have a root-cause
explanation for why this combination holds where others didn't — but if anyone here hasn't
explicitly checked this VS Code setting (separate from settings.json), it seems worth verifying
before concluding bypass mode is unfixably broken for your setup.

Environment: same as before — anthropic.claude-code-2.1.179-win32-x64, Windows 11 Pro.

Adding another branch to this META that I haven't seen called out cleanly: the dangerous rm/rmdir safety check fires under bypassPermissions mode, and there is no opt-out.

Reproduced on v2.1.214. Any cd <dir> && rm -rf <relative-glob> (e.g. rm -rf .mypy_cache/* after a cd into the worktree) triggers a "Dangerous rm operation on statically-unresolvable target" prompt even with --dangerously-skip-permissions. It fires inside my Docker container just the same as on a host. No flag/setting/env var turns it off. Adding a broad allow rule (e.g. Bash(rm:*)) doesn't override it either — the prompt still fires.

Strongly identifying with @dginovker — same user profile. My agents are VM-encapsulated; the host is protected by construction. Having bypass mode still prompt on a specific rm pattern is a deal breaker for the same reason: it defeats the purpose of declaring "no prompts."

I want to name what I keep reading as the implicit justification for these guards (apologies if it's a strawman, but it's worth surfacing): "a user once deleted their home directory, so we hard-block this even in bypass mode." If that's the reasoning, it doesn't justify overriding bypass. The accident happened to someone running on their host. The user who passes --dangerously-skip-permissions has explicitly opted out of that protection, almost always because they've arranged a stronger isolation layer (container/VM/throwaway box) than the guard provides. Penalizing the informed user for the uninformed user's accident is the wrong tradeoff.

The right shape: design the safety/usability tradeoff deliberately, and let users choose. A bypass that carves out an unkillable exception isn't bypass — it's "bypass except for the things we're nervous about," which is the worst of both worlds (you lose the autonomy and don't gain the safety a real sandbox story would give).

An opt-out flag for the dangerous-rm check under bypass would resolve this branch cleanly. Happy to file it as a separate feature request if that helps tracking, but it felt like it belonged on the META.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

Confirming this persists on 2.1.101 (older than most reports here). New protected-file data point: .claude/launch.json also triggers the guardrail — not previously listed alongside commands/agents/skills/settings.json, so the protected-path list is broader than the nvY snippet above shows. Ruled out the two most common false leads before concluding it's the guardrail: target directory was already in additionalDirectories, and Bash(*) was already an unconditional allow rule — dialog text was 'which is a sensitive file.'

Adding a data point that looks related but doesn't fit cleanly into either Branch 1 or Branch 2 above — flagging the distinction in case it's actually a third failure mode, not just more evidence for the existing two.

Not a protected-directory issue. Our repro involves no .claude/, .git/, .vscode/, or .idea/ paths at all — plain commands like grep, echo, and a heredoc write to /tmp/, none of which touch a protected path. So this doesn't match Branch 1's mechanism.

Not obviously a mid-session reset either (Branch 2) — our evidence shows the permission mode never resolved to bypassPermissions in the first place, from the very first SDK spawn of a session, not a downgrade partway through.

Environment

• Claude Code VS Code extension, reproduced on 2.1.228, re-confirmed still current on 2.1.229 (checked the real CHANGELOG.md for both — no entry mentions defaultMode, bypassPermissions, or permission-mode resolution at spawn/resume)
• Windows 10 Pro
• permissions.defaultMode: "bypassPermissions" in project-local .claude/settings.local.json, with non-empty allow/ask/deny arrays in the same file

Evidence

The extension's own log (%APPDATA%\Code\logs\<timestamp>\window1\exthost\Anthropic.claude-code\Claude VSCode.log) shows the runtime permission mode never resolves to bypassPermissions, on either a cold spawn or a --resume:

[info] Spawning Claude with SDK query function - cwd: c:\Users\Ardor\projects, permission mode: default, version: 2.1.228, ..., resume: undefined
[info] Spawning Claude with SDK query function - cwd: c:\Users\Ardor\projects, permission mode: undefined, version: 2.1.228, ..., resume: <session-id>

...despite the same log showing the settings file's allow/ask/deny arrays being read and applied correctly moments later:

[DEBUG] Applying permission update: Adding 40 allow rule(s) to destination 'localSettings': [...]
[DEBUG] Applying permission update: Adding 12 deny rule(s) to destination 'localSettings': [...]
[DEBUG] Applying permission update: Adding 10 ask rule(s) to destination 'localSettings': [...]

So this looks like a narrower gap than "settings not read" — the rule arrays load fine, but the defaultMode value from the same file isn't making it into the SDK query's actual runtime mode.

Confirmed via the permissionDecisionMs field on tool_dispatch_start log lines that this isn't cosmetic — real dialogs fire and sit waiting for a manual click, for commands that match none of the documented bypass exceptions (no ask rule, not a protected path, not an MCP tool needing interaction):

| Command | Ask-listed? | permissionDecisionMs |
|---|---|---|
| grep -n "test" /dev/null; echo "..." | No | 13,583 |
| Heredoc write to /tmp/... | No | 12,563 |
| Heredoc write to /tmp/... (via a subagent) | No | 17,269 |
| echo ... > /tmp/... | No | 16,362 |

(Subagents showed identical behavior to the main session — not subagent-specific.)

Update from a later same-day session: looks tool-type-specific, not uniform

A follow-up session testing this same setup found something more precise: Edit, Write, and an MCP tool call triggered zero dialogs, while Bash calls triggered every single time, in the same window, same time period:

| Call type | permissionDecisionMs observed |
|---|---|
| Write (3 calls) | 6, 7, 4 |
| Edit (2 calls) | 2, 2 |
| One MCP tool call | 0 |
| Bash (11 calls, same session) | 4379, 28466, 16316, 61837, 123266, 31788, 5923, 9853, 17394, 48236, 162948 |

Single-digit ms = no real dialog (matched instantly). The Bash numbers are real, manually-resolved dialogs — one took nearly 3 minutes. This doesn't contradict the earlier finding (Edit/Write did prompt at least once in the original evidence-gathering session, hours earlier) — it suggests the manifestation may vary by tool type and/or session state over time, not a single static condition. Flagging as an open question rather than a firm conclusion.

Already ruled out

• Not a stale/pre-edit session — confirmed via the process's own start time vs. the settings file's mtime (session started ~8.5h after the edit)
• Not a rule-matching gap — the affected commands match no ask/deny rule of any kind, so there's nothing for bypassPermissions to need to resolve against
• Not a duplicate/second running session — only one CLI harness process was running, matching the affected session's own ID
• No competing claudeCode.* setting in VS Code's own User/settings.json overriding the project file

Adding a data point to this meta-issue, since it's a slightly different angle from most of the branches already tracked here (protected-dirs and mid-session mode resets): a fresh-session launch-time override that two closed-as-duplicate/not-planned issues already root-caused separately, but which I don't see cross-linked from here — #62205 and #55095.

Environment: VSCodium (not official VS Code) native extension, anthropic.claude-code-2.1.233-linux-x64, Linux.

What I confirmed directly on my own machine, not just from those issues:

1. ~/.claude/settings.json still correctly has the setting that's supposed to control this:

``json
{
"permissions": { "allow": [ /* ... */ ] },
"model": "sonnet",
"defaultMode": "bypassPermissions"
}
`
(Note it's set at the top level, not nested under permissions.defaultMode — not sure if that's the expected schema location or itself part of the problem; #21062 references permissions.defaultMode` specifically.)

1. ~/.claude.json does contain a live, populated cachedGrowthBookFeatures block (dozens of tengu_*-prefixed flags), confirming the server-sync mechanism #62205 describes is genuinely active on this install — I did not specifically confirm the two flag names #62205 names (tengu_permission_friction, tengu_quill_harbor) are among them, since the file is large and I only inspected a partial dump, but the sync mechanism itself is real, not hypothetical.

1. ps aux right now shows a clear split on the same machine, same user, same settings.json: older long-running sessions launched with

``
... claude ... --permission-mode bypassPermissions --allow-dangerously-skip-permissions ...
`
still work fine, while sessions started more recently launch as
`
... claude ... --permission-mode auto ...
`
with no bypass flag at all, despite identical settings.json`. Strongly suggests whatever overrides this is applied at launch time server-side, not read fresh from local config, and isn't retroactive to already-running processes.

1. The VSCodium extension's own package.json does declare claudeCode.allowDangerouslySkipPermissions (boolean, scope: machine) and claudeCode.initialPermissionMode as real, documented contribution points — and mine is set to true/bypassPermissions respectively in VSCodium's user settings — but new sessions from this extension still don't launch with bypass, consistent with #55095's finding that the toggle "appears to have no effect."

Timing-wise this lines up for me with the platform-wide auto-mode-becomes-default rollout — I got an in-app notice about that right before this started happening.

Happy to provide more detail if useful. Referencing this from the meta-issue given #62205 and #55095 are the more specific root-cause writeups but are closed and not currently linked from here.

Update, 4 days later: recurred again on the same machine/environment as my comment above, same extension version (2.1.233), no local config changes since. Fresh timestamped evidence this time:

Environment: VSCodium (not official VS Code) Remote-SSH — client on macOS/Apple Silicon, remote extension host on Linux x86_64 (anthropic.claude-code-2.1.233-linux-x64).

• ps aux at the moment it happened shows a clean split by process-start-time: sessions launched before 09:36 UTC today carry --permission-mode bypassPermissions --allow-dangerously-skip-permissions; sessions launched at 09:36:20 and 09:36:50 carry --permission-mode auto with no bypass flag at all — same settings.json, same VSCodium user settings, unmodified since 08-21 and 06-14 respectively.
• ~/.claude.json's mtime is 09:36:53 — within the same minute as the downgraded launches — which is the first time I've been able to catch the GrowthBook sync landing at essentially the same moment a fresh session gets silently overridden to auto.
• Confirming what I could only guess at last time: cachedGrowthBookFeatures does contain tengu_permission_friction: true and tengu_quill_harbor: "acceptEdits", alongside tengu_auto_mode_default_on: false and a populated tengu_auto_mode_config block.

Recurring, intermittent, and still not tied to any local config or version change on my end — seems consistent with a server-side flag flip rather than anything client-side.