[BUG] VSCode Extension: `.claude/settings.local.json` permissions not respected for Bash/Write/Edit operations (even with `bypassPermissions` mode)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13028
2. https://github.com/anthropics/claude-code/issues/12261
3. https://github.com/anthropics/claude-code/issues/13340

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

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

🤖 Generated with Claude Code

No, don't close this is a terrible issue and none of the duplicates have been assigned.

Related to #15772

+1 - Experiencing the same issue. Edit/Write permissions in .claude/settings.local.json are not respected, still prompts for every edit operation. Read permissions work fine.

+1 #15772 was closed remarkably quickly so weighing in to say this issue is real. Claude CLI works as expected

Just ran into this issue, and took me a really long time to get here (Claude flailed for a LONG time adding patterns, suggesting different settings files to edit)

Same here. Having this issue and Claude ran circles around itself trying to fix until it found this.

This is not just a VSCode extension issue. I have the same issue on the command line with Claude Code on windows.

Can this be fixed please, it's hard to create a fully autonomus SDLC pipeline if the permissions are not respected

OH MY GOD ITS STILL NOT FIXED FOR MONTHS, ITS SUCH AN EASY FIX WHY ARE THEY IGNORING THIS?

Same here.. almost makes the extension unusable

Hey guys FYI I was able to work around this by using a pretooluse hook. I created a script with safe commands and pass that to the agent whenever it uses a tool (which includes Bash).

I did the same 1h after posting my first message here because I was so
frustrated with it. I created hooks with python rules. Added allowed
instructions, hundreds of them, created also another one with banned
harmful disallowed commands like command chaining and heredocs and any
commands leading to configuration or removal outside of specified and
allowed folders and I also banned any acces to certain folders on my hdd.
Claude configured them for itself. Now I have fully autonomous pipeline
with no questions asked! Worked like a charm. Claude can follow SDLC
pipeline and implement any feature end to end automatically. Different
specialised agents are invoked one by one or in parallel to do the job
done. Crazy if you ask me, it's like coding in star trek holodeck now. Lol.

On Mon, 16 Feb 2026, 20:47 nikhilsitaram, @.***> wrote:

nikhilsitaram left a comment (anthropics/claude-code#15921) <https://github.com/anthropics/claude-code/issues/15921#issuecomment-3910450791> Hey guys FYI I was able to work around this by using a pretooluse hook. I created a script with safe commands and pass that to the agent whenever it uses a tool (which includes Bash). — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/15921#issuecomment-3910450791>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQMYAQNY5DOQMWB4CBHFDDT4MIUHLAVCNFSM6AAAAACQNDWWVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMJQGQ2TANZZGE> . You are receiving this because you commented.Message ID: @.***>

Hooks really are the secret sauce to get Claude to do anything reliably!

Same here, Claude is set to "ask before edit" mode, yet reliably does the modifications directly. When asked, it tells me it'll ask next time and then proceeds to completely ignore that with the next prompt.

Same issue:

• MacOS Tahoe 26.3
• Microsoft VS Code 1.116.0
• Claude Code extension for VS Code: Opus anthropic.claude-code@2.1.109.
• "Edit Automatically" also still prompting for permission.

Same here on Linux CLI (Claude Code 2.x, Opus 4.6) — bypassPermissions mode in ~/.claude/settings.json does not suppress Edit/Write prompts.

Workaround that actually works: a PermissionRequest hook that unconditionally approves. Added to settings.json:

"PermissionRequest": [{
  "matcher": "",
  "hooks": [{"type": "command", "command": "/path/to/allow_all.sh"}]
}]

allow_all.sh:

#!/bin/bash
echo '{"hookSpecificOutput": {"hookEventName": "PermissionRequest", "decision": {"behavior": "allow"}}}'

Confirms this isn't VSCode-specific — the permission-mode plumbing is broken across platforms. The fact that users need a hook to make bypassPermissions behave as documented suggests the mode flag isn't reaching the Edit/Write/Bash gate.

Works @Kieldro https://github.com/anthropics/claude-code/issues/15921#issuecomment-4255032042 but kind of risky.

The PermissionRequest hook in VS Code is fundamentally broken — deny doesn't deny, ask doesn't prompt, it just auto-allows everything regardless. That's another data point for the bug report: the workaround from that GitHub comment doesn't work safely for selective approval.

Still having this issue and this was opened in December.

VS Code Studio extension running on Arch Linux. Latest versions.

The VS Code interface is basically unusable with it asking to grep all the time. The docs clearly state that read-only commands should not prompt, but they do. Is that covered by this issue? Why don't Anthropic just have Claude Code fix this (recommend using CLI so it can actually work without stopping all the time).

This is frustrating to the extend. Each command is asking for the permission. Even after enabling skip permission.

This thread has accumulated multiple distinct failure modes under one umbrella. I can root-cause two of them from a disassembly of claude.exe 2.1.143.a06: the Edit/Write path-globbed-rules-ignored half (per @losjoe Feb 9 and @Kieldro Apr 15) and the bypassPermissions-mode-silently-rejected half (per several commenters). The third — Bash rules being ignored specifically in the VSCode extension while working on the CLI (OP's primary symptom) — is a different layer that I haven't traced.

Root cause for the Edit/Write/CLI half

I disassembled claude.exe 2.1.143.a06 (Bun-compiled native binary) to chase a closely-related Windows reproducer. In the permission matcher, both the allow matcher v$_(ctx, tool) and the deny matcher xX8(ctx, tool) dispatch through XIq(), whose first line is:

function XIq(tool, rule, opts) {
  if (rule.ruleValue.ruleContent !== void 0) return false;  // <— this
  let toolName = Om6(tool);
  if (rule.ruleValue.toolName === toolName) return true;
  // proxy-expansion check...
}

Any rule with parens content (Edit(...), Write(...), Read(...), Glob(...), Skill(...), mcp__name(...)) is unconditionally rejected by the matcher. Only bare tool-name rules (Edit, Write, Read) ever match. The per-tool checkPermissions for filePatternTools (Read / Edit / Write / Glob / NotebookRead / NotebookEdit) doesn't compensate — it does only a working-directory scope check.

Bash(...) and PowerShell(...) rules with content do work because Bash has its own content matcher (dz8) that picomatches the command string against ruleContent directly. That's why patterns like Bash(dir:*) work on the CLI but Edit(C:/Data/**) doesn't.

Cross-platform: same matcher code in the shared JS bundle, so Linux/macOS/Windows all hit it identically. See #36884 for the full disassembly notes, four-row reproducer matrix, and --print --debug recipe.

Root cause for the bypassPermissions-mode-silently-rejected half

Same methodology, different code path. The binary contains this exact log string:

Ignoring permission update: setMode 'bypassPermissions' rejected — mode is not available (disableBypassPermissionsMode set, or session not launched in bypassPermissions mode)

The mode is gated by an isBypassPermissionsModeAvailable flag on the permission context. The default factory h0() initializes that flag to false:

var h0 = () => ({
  mode: "default",
  additionalWorkingDirectories: new Map,
  alwaysAllowRules: {},
  alwaysDenyRules: {},
  alwaysAskRules: {},
  isBypassPermissionsModeAvailable: !1
});

The flag only flips to true when the session is launched with --dangerously-skip-permissions or --permission-mode bypassPermissions on the CLI. So when someone puts "defaultMode": "bypassPermissions" in settings.json and starts a session the normal way:

1. Claude reads the setting on startup and attempts setMode("bypassPermissions").
2. The setMode gate sees isBypassPermissionsModeAvailable === false and rejects the change.
3. The rejection logs at debug level only — no UI surface, no warning.
4. The session silently stays in default mode and continues to prompt.

Workaround for this one: launch with --dangerously-skip-permissions on the CLI; defaultMode in settings.json can't bootstrap into bypass mode by design. The same opt-in-per-session gate also exists for dontAsk mode and the disableBypassPermissionsMode/disableAutoMode policy flags follow the same pattern.

This is independent of the XIq matcher bug above — it's a separate "opt-in-only gate that fails silently" issue. The fix is small in both cases but different: either let defaultMode: bypassPermissions in settings flip isBypassPermissionsModeAvailable = true automatically, or surface the rejection at warn level so users see why their setting didn't apply.

Note on the OP's Read/Glob/Grep observation

@elliottgaryusa noted Read/Glob/Grep worked while Edit/Write didn't. Worth being precise: Read/Glob/Grep on files inside the current working directory don't need a permission rule at all — the working-directory scope check grants them. The Read(**) rule isn't what's allowing those; it's the scope. Try a Read of a file outside cwd (e.g., from ~/something-else/file.md when cwd is a different project) and Read fails too, for the same XIq reason.

Workaround — same one @nikhilsitaram and @RoboLagoon already arrived at

A PreToolUse hook that inspects tool_input.file_path (or tool_input.command for Bash if you need the same for that bug) and emits a deny decision when patterns match. Independently confirms what others in this thread built — the hook layer is below the broken XIq filter, so it actually fires. The minimal Python reference is inline in the #36884 comment.

Gotcha worth flagging for Windows users: the hook command string in settings.json needs forward slashes in the script path (python C:/path/to/guard.py not python C:\\path\\to\\guard.py) — backslashes get stripped by the hook runner's shell parsing, which makes every Read/Edit/Write fail-closed with a confusing can't open file 'mangledpath' error.

What this comment does NOT explain

• Bash rules being ignored in the VSCode extension specifically (OP's primary symptom). Bash's own dz8 content matcher works on the CLI (verified — Bash(dir:*) honored, Bash(rm -rf:*) denies fire), so this is a different layer — likely the VSCode extension loading settings from a different scope or handling permissions in a separate IPC path. Possibly related to #43787 (project-level settings ignored by VSCode extension). I haven't traced the extension's code paths.

Worth maintainers splitting this thread into separate issues for distinct triage. The two bugs I've root-caused (XIq matcher reject and bypassPermissions opt-in gate) are both small, isolated fixes touching different functions; they can ship independently.

Please fix this. It is irritating and hurts productivity to be unable to shut off permission requests. Using the Claude Code VS Code plugin on Mac.

This should get platform:mac label too. Another request to fix this. I stopped using Cursor for reasons so back to VS Code. This is a productivity killer.

The amount of tickets on the same issue closed as "not planned" despite this being an obvious bug and a productivity killer is ridiculous.

Bumping to bring attention to this.

How is it possible that this ticket only gets 25 upvotes. Anthropic has 1000s of Windows users. Suggestion: build a feedback system into the vscode extension / cli. Oh now I am writing this, I recognize that there is already a feedback system. Somehow always when it presents itself I am positively satisfied 😅

Update on the two matcher bugs I reported here earlier: both are fixed in the current
native CLI (claude.exe 2.1.207, Windows), verified with a reproducer in an isolated config
sandbox.

• Path-globbed Read/Edit/Write(and related) allow and deny rules now match (they

were previously silent no-ops).

• "defaultMode": "bypassPermissions" in settings.json now activates the mode instead of

being silently rejected. (One caveat: my sandbox had already accepted the bypass-mode
warning dialog once, so first-time activation may still require that acknowledgment — I
couldn't isolate that variable.)

The fix landed silently somewhere between 2.1.145 and 2.1.207, so upgrading is the remedy if
you're on an older build.

Scope: I verified the native CLI only. This thread's original report is about
Bash/Write/Edit rules being ignored specifically in the VS Code extension — I did
not root-cause or test that surface, and I'm not claiming it's fixed. Anyone still seeing
the extension-specific behavior should treat that as open and worth a fresh reproduction on
the current extension build.

Can someone verify if this fix has landed in the macOS VS Code extension or not? I really want to stop using Cursor before the SpaceX deal goes through yet VS Code with Claude Code is unusable until this is fixed.

@joshuaiz In case it's still not fixed, this workaround works for me:
https://github.com/anthropics/claude-code/issues/18846
I just gave claude this link and said "use this workaround" and it applied it where needed.