[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.