Repository navigation
[META] Bypass permissions mode is fundamentally broken — 9-month trail, 12+ duplicates, no resolution #39523
Description
Activity
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:
- Session starts in "bypass permissions on"
- Orchestrator sends a command via HTTP. Channel server delivers it as a notifications/claude/channel MCP notification
- 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" }, }, });Reacted by interconnectedMe and Cornelius RoemerSource-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.jsThe
nvYfunction (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
nvYreturnstrue, the write permission flow (Hi6) returns{safe: false}, which triggers a user prompt — even inbypassPermissionsmode.The only
.claude/subdirectory with a code-level exemption is.claude/worktrees(via abreakin theavYsensitive-directory check).Documentation vs code mismatch
The permissions documentation states:
Writes to
.claude/commands,.claude/agents, and.claude/skillsare 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.jsonYes Yes .claude/commands/test.txtYes No .claude/skills/test.txtYes No .claude/agents/test.txtYes 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, somode: "bypassPermissions"on the Agent tool doesn't help either.Suggested fix
nvYshould exclude.claude/commands,.claude/agents, and.claude/skillsfrom 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.
Reacted by interconnectedMe- added a commit that references this issue
on Mar 28, 2026 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
Reacted by interconnectedMe and Stein-Otto SvorstølWhile waiting for an official fix, a
PreToolUsehook 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
bypassPermissionsbecause:- Hooks execute deterministically — no mode drift or session resets
- You control the logic — approve Read/Edit/Write always, but keep Bash gated
- Works across all session types — interactive,
-pmode, background agents
For project-scoped bypass, put the hook in.claude/settings.jsonat project root instead of~/.claude/settings.json.
Reacted by interconnectedMeIts 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)
Reacted by interconnectedMe, Will DelHagen, Stein-Otto Svorstøl and HuskyPower 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:
- The docs explicitly promise exemptions for
.claude/skills/— we configured our settings trusting that documentation. It's not just broken; it's misleading. - Every bypass mechanism fails:
bypassPermissions,--dangerously-skip-permissions, explicitEdit(.claude/**)allow rules,additionalDirectoriespointing to~/.claude/skills— all ignored. - 9 months of reports, zero resolution. The "Fix incoming" on [BUG] v2.1.78: Protected directory prompt in bypassPermissions has no override — forces hacky workarounds #35646 regressed. Issues get closed as duplicates. The problem persists across v2.1.78 → v2.1.87.
- 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/.Reacted by Dan G, Stein-Otto Svorstøl and schicki-nicki- The docs explicitly promise exemptions for
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.mdvia 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 | bashin dev container) - Platform: Linux (WSL2, Ubuntu-based dev container)
- IDE: Cursor
- Model: claude-opus-4-6
skipDangerousModePermissionPrompt: truein~/.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.mdand.claude/skills/*/SKILL.mdas 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.
Reacted by interconnectedMe- Claude Code: latest (via
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 matchmkdir -p ~/.claude/tmp/some-subdirbecause 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
bypassPermissionsbreakage 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):
- Start session with
defaultMode: "bypassPermissions"in~/.claude/settings.json+ project-levelsettings.local.json - Session starts in bypass mode correctly
- Use Edit tool on any file inside
~/.claude/(e.g.~/.claude/commands/my-command.md) - Protected directory prompt fires → mode silently downgrades to "accept edits"
- Shift+Tab does NOT cycle back to bypass (bypass excluded from cycle per Feature Request: Add YOLO mode (bypassPermissions) to Shift+Tab permission mode cycle #15898)
- 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: trueset in global settings (has no effect on this bug).- Start session with
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
then i switch the mode back
WHYYYYYYYYYY
Reacted by Sasha and schicki-nickiThey save money with this that is why.
Reacted by Patryk Janik, orglnte, patrykjanikabilitie and schicki-nicki12 remaining items
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--win32-x64/extension.jsVorgehen (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.jsRollback: 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 funktionalJust 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:
- User is in Agent View with a background session selected
- User presses Ctrl+X, sees a confirmation prompt
- User expects the session to be archived to Disk (visible in /resume)
- 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 [BUG] Auto mode disappears after shift + tab cycle in agents view #58948 (Auto mode disappears after shift+tab cycle)
- added a commit that references this issue
on May 31, 2026 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)
- Full machine reboot, fresh VS Code launch, brand-new conversation.
- Wiped the project's
.claude/settings.local.jsonto an empty allowlist, ran a trivial Bash command — no prompt, file stayed clean. Bypass mode working correctly. - 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).
- 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.jsonstarted accumulating one-off literalBash(...)allow entries.
Both times this was observed,
~/.claude/settings.jsonwas 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.jsondown 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
permissionskey. Combined with the fact that every individually-approved Bash call writes a new entry into the local-scopesettings.local.json:- Session starts,
bypassPermissionscorrectly merged from the user scope. - 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). - That write triggers the documented live reload.
- If the reload recomputes effective permissions by treating the freshly-written local
allowlist as the complete permission set for that scope — instead of correctly re-merging it against the inheritedbypassPermissionsfrom 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: bypassPermissionsdirectly insettings.local.jsonmitigates 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.
- Claude Code VS Code extension:
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.allowDangerouslySkipPermissionsas 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 setdefaultMode: "bypassPermissions"(or only usedinitialPermissionMode)
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 (plaindefaultMode: 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 acdinto 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-permissionshas 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.jsonalso triggers the guardrail — not previously listed alongside commands/agents/skills/settings.json, so the protected-path list is broader than thenvYsnippet above shows. Ruled out the two most common false leads before concluding it's the guardrail: target directory was already inadditionalDirectories, andBash(*)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 likegrep,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
bypassPermissionsin 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.mdfor both — no entry mentionsdefaultMode,bypassPermissions, or permission-mode resolution at spawn/resume) - Windows 10 Pro
permissions.defaultMode: "bypassPermissions"in project-local.claude/settings.local.json, with non-emptyallow/ask/denyarrays 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 tobypassPermissions, 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/denyarrays 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
defaultModevalue from the same file isn't making it into the SDK query's actual runtime mode.Confirmed via the
permissionDecisionMsfield ontool_dispatch_startlog 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 (noaskrule, 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 permissionDecisionMsobservedWrite (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/denyrule of any kind, so there's nothing forbypassPermissionsto 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 ownUser/settings.jsonoverriding the project file
- Claude Code VS Code extension, reproduced on 2.1.228, re-confirmed still current on 2.1.229 (checked the real
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:
-
~/.claude/settings.jsonstill correctly has the setting that's supposed to control this:{ "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; [FEATURE] Include bypassPermissions mode in default Shift+Tab permission mode cycling #21062 referencespermissions.defaultModespecifically.) -
~/.claude.jsondoes contain a live, populatedcachedGrowthBookFeaturesblock (dozens oftengu_*-prefixed flags), confirming the server-sync mechanism [BUG] Root cause identified: GrowthBook A/B flags tengu_permission_friction + tengu_quill_harbor silently override defaultMode:bypassPermissions via periodic server sync — macOS Desktop #62205 describes is genuinely active on this install — I did not specifically confirm the two flag names [BUG] Root cause identified: GrowthBook A/B flags tengu_permission_friction + tengu_quill_harbor silently override defaultMode:bypassPermissions via periodic server sync — macOS Desktop #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. -
ps auxright 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. -
The VSCodium extension's own
package.jsondoes declareclaudeCode.allowDangerouslySkipPermissions(boolean,scope: machine) andclaudeCode.initialPermissionModeas real, documented contribution points — and mine is set totrue/bypassPermissionsrespectively in VSCodium's user settings — but new sessions from this extension still don't launch with bypass, consistent with Bypass permissions mode no longer appears in session UI on Claude Code Desktop (Mac) despite Settings toggle being enabled #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 auxat 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 autowith no bypass flag at all — samesettings.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 toauto.- Confirming what I could only guess at last time:
cachedGrowthBookFeaturesdoes containtengu_permission_friction: trueandtengu_quill_harbor: "acceptEdits", alongsidetengu_auto_mode_default_on: falseand a populatedtengu_auto_mode_configblock.
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.
- added a commit that references this issue
on Sep 3, 2026 Update, 2026-09-10, ~2.5 weeks after my last comment: recurring again, same machine/environment, and this time with a UI symptom worth adding: the mode picker doesn't just default away from bypass — "Bypass permissions" isn't listed as an option at all, only Manual / Edit automatically / Plan / Auto.
Environment: VSCodium Remote-SSH — client macOS/Apple Silicon, remote extension host Linux x86_64, now
anthropic.claude-code-2.1.251-linux-x64(up from2.1.233last time).~/.claude/settings.jsonis unchanged since my last comment:"defaultMode": "bypassPermissions"still present at top level.ps auxright now shows the same clean split by launch time as before: sessions started Sep 4 and Sep 8 still carry--permission-mode bypassPermissions --allow-dangerously-skip-permissions; every session started today (05:54 and 06:19 UTC) carries--permission-mode acceptEdits, no bypass flag at all — identical settings.json across all of them.cachedGrowthBookFeaturesin~/.claude.jsonagain hastengu_permission_friction: trueandtengu_quill_harbor: "acceptEdits"— same two flags I confirmed on 2026-08-24, still present today.- One difference from last time:
~/.claude.json's mtime (06:28:51 UTC) trails after today's downgraded launches (05:54, 06:19) rather than landing in the same minute as a launch — so either the flag was already flipped before I checked, or the sync isn't the only trigger. Not conclusive, just noting it doesn't perfectly match my earlier "caught it in the act" evidence.
Still nothing here tying the downgrade to a local config or version change — consistent with a server-side flag rather than a client regression. No maintainer response on this meta-issue since it was opened in March.
Update, 2026-10-10 — recurred a third time, now on
2.1.284(up from 2.1.251 / 2.1.233). Same VSCodium Remote-SSH setup (macOS/Apple Silicon client, Linux x86_64 extension host), no local config change on my side:~/.claude/settings.jsonstill has"defaultMode": "bypassPermissions"at top level and"skipDangerousModePermissionPrompt": true.- The session mode picker (screenshot attached to my earlier report: same list) offers only Manual / Edit automatically / Plan / Auto. "Bypass permissions" is not listed, and the session sits on "Edit automatically".
psat 07:39 UTC shows three extension-spawnedclaudeprocesses launched within 30 s of each other (07:38:04, 07:38:16, 07:38:31). Two carry--permission-mode bypassPermissions; one carries--permission-mode acceptEdits. All three carry--allow-dangerously-skip-permissions.
New vs. my 2026-09-10 report: the CLI is now launched with
--allow-dangerously-skip-permissions, so the flag being missing is not the whole story. The webview picker still drops the Bypass option, and a fresh session can still start inacceptEditsdespite the same settings. This looks like the same launch-time/webview override as #62205 and #55095, not a settings problem. Workaround for now: restart the affected tab, or start the session from the CLI.
[META] Bypass permissions mode is fundamentally broken — 9-month trail, 12+ duplicates, no resolution
Summary
bypassPermissionsmode does not bypass permissions. This has been broken in various forms since July 2025 (#2933) and remains broken on v2.1.84 (March 2026). The only official response was "Fix incoming" on #35646 (March 20) — the issue was closed, but the fix didn't hold. Users on v2.1.84 confirm the problem persists.This meta-issue maps the full dependency tree to give the team a single place to track the problem instead of playing whack-a-mole with duplicates.
Two correlated failure branches
Branch 1: Protected directories ignore bypass mode (v2.1.78 regression)
v2.1.78 introduced hardcoded protection for
.claude/,.git/,.vscode/, and.idea/directories that overrides every bypass mechanism:--dangerously-skip-permissionsCLI flagpermissions.defaultMode: "bypassPermissions"in settingsclaudeCode.initialPermissionMode: "bypassPermissions"in VSCode settingspermissionDecision: "allow"allowlist (Edit(.claude/**),Write(.claude/**))Branch 2: Permission mode resets mid-session
The permission mode spontaneously downgrades from "Bypass permissions" to "Edit automatically" during a session. Clicking "Yes, allow all edits this session" on a protected directory prompt triggers the downgrade. This has been reported since v0.2.x (May 2025) and persists through v2.1.84.
Timeline
What users need
bypassPermissionsshould mean bypass. If I've opted into the mode with the scary name, I've accepted the risk. Don't second-guess me for.claude/subdirectories.bypassProtectedPaths: [".claude/hooks/", ".claude/skills/"]would solve 90% of the pain for power users with agent workflows.Environment
claudeCode.allowDangerouslySkipPermissions: trueclaudeCode.initialPermissionMode: "bypassPermissions".claude/hooks/and.claude/skills/cc @bcherny — this has been open in various forms for 9 months. The "fix incoming" on #35646 didn't resolve it. Could this get prioritised?