[BUG] settings.json or settings.local.json do NOT suppress permission prompts

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68835
2. https://github.com/anthropics/claude-code/issues/57746
3. https://github.com/anthropics/claude-code/issues/6881

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

Confirmed fix

Downgrading the extension from 2.1.197 to 2.1.195 fully restores correct behavior.
Regression was introduced between 2.1.195 and 2.1.197.

I have encountered this same issue and for me the fix was to downgrade to version 2.1.191 of the extension. I all versions after 2.1.191 I tested and have this bug for me.

I noticed that settings.local.json stops being applied correctly after I open an additional chat and work in two chats simultaneously.

It’s very annoying. It is necessary to add permission for each mcp call. An entry like "mcp__myptoject-mcp" in the allowed permissions doesn't automatically grant access to everything—such as "mcp__myptoject-mcp__create", "mcp__myptoject-mcp__read", and so on. This doesn't work in the "settings.json" file either.

I worked with Claude to test out my own version of what seems like the same bug, and asked it to write the comment, given below:

Hitting what looks like the same regression on a different config shape — adding a repro that isolates it further.

Environment: Claude Code 2.1.205, VS Code extension (CLAUDE_CODE_ENTRYPOINT=claude-vscode), Windows 10 Pro 10.0.19045, Git Bash. Project is not inside a git repo. So this regression is still present at least 8 point releases after 2.1.197.

Config:

Global ~/.claude/settings.json (relevant excerpt):

{
  "permissions": {
    "allow": [
      "Bash(ls *)"
    ]
  }
}

Project .claude/settings.local.json:

{
  "permissions": {
    "additionalDirectories": [
      "C:\\Users\\<user>\\Desktop\\Temp Stuff"
    ],
    "allow": [
      "Bash(ls -la \"/c/Users/<user>/Desktop/Temp Stuff\"*)",
      "Bash(ls -la \"//c/Users/<user>/Desktop/Temp Stuff\"*)"
    ]
  }
}

No deny/ask rules anywhere, no sandbox config, no managed-settings.json present.

What I isolated: it's not just that additionalDirectories fails to suppress the prompt (matches what's reported here) — even a plain ls on that exact directory still prompts despite two other independent mechanisms that should each suppress it on their own:

1. ls is documented as a built-in read-only command that bypasses the permission prompt "in every mode," unconditionally.
2. The global Bash(ls *) allow rule should match ls "C:\Users\<user>\Desktop\Temp Stuff" as a plain string, with no directory-scoping described for Bash command-pattern rules in the docs.

I ran three controlled tests in one session, confirming each via the actual on-screen dialog (not just tool-result success, since a returned result isn't proof a prompt didn't appear):

| Test | Command | Path status | Result |
|---|---|---|---|
| A | ls on the project's own working directory | inside cwd | No prompt (correct) |
| B | ls "/c/Users/<user>/Desktop" | outside cwd, never granted by any rule | Prompted (expected) |
| C | ls "C:\Users\<user>\Desktop\Temp Stuff" | outside cwd, listed verbatim in additionalDirectories, using the exact native Windows-style path string as configured | Prompted (unexpected) |

Test C also rules out a POSIX-vs-Windows path-format mismatch as an explanation — I used the literal string from additionalDirectories, not a translated form, and it still prompted. Also confirmed this survives a full VS Code restart with only a single window open, ruling out session-staleness or multi-window interference as causes.

So on top of what's already reported here (that additionalDirectories alone doesn't suppress prompts), it looks like the read-only-command bypass and plain Bash allow-list matching are also not being applied for paths outside the working directory — suggesting the underlying bug may be broader than additionalDirectories specifically, more like "any Bash permission-matching path outside cwd is being force-prompted regardless of which mechanism should normally allow it."

Happy to provide the full settings files or a screen recording of the prompt if useful.

Same family of failure on the CLI (not the VS Code extension) — Claude Code 2.1.185, Windows 11 Home, PowerShell/Git Bash — so this isn't extension-specific.

Project .claude/settings.json allow list: Write(TODOS.md), Write(sessions/**), Write(./sessions/**), with defaultMode: "default".

• Write to TODOS.md → no prompt (literal rule matches)
• Write to sessions/probe2.md → prompts, despite both glob spellings covering it and /permissions showing all three rules loaded in the Allow list

The sessions/ directory existed on disk at the time of the write. Reproduced across two separate sessions.

Note the failing path is only one segment deep, so this reproduces even under the "** matches exactly one segment" theory above — for Write allow rules on the CLI, ** appears to match nothing at all. Deny and ask rules behave correctly; only allow-tier globs fail. Fails safe (over-prompts) but makes glob allow rules unusable on Windows.

Correction to my comment above: after a CLI update, Claude Code now emits startup warnings that explain my result differently —

Permission allow rule (.claude\settings.json): Write(sessions/) is not matched by file permission checks — only Edit(path) rules are. Use Edit(sessions/) instead (Edit rules cover all file-editing tools).

Re-reading my repro in that light: Write(TODOS.md) "working" was actually a coincidental Edit(TODOS.md) rule in the same allow list matching, and my Write(sessions/**) rules were simply inert — not a glob bug in my case at all. Write() rules apparently are never consulted by file permission checks.

Leaving this here since other configs in this thread also mix rule types — worth checking whether your allow rules are Write()/Read() forms that the file-permission path never consults. (The **-not-recursive findings above are Read() rules, so those may be a genuinely separate bug.)

This bug still exists in the latest Claude code extension version. This is incredibly annoying as I have been stuck on version 2.1.191 to avoid this bug but now there are things which have begun to not render correctly in the chat as the Claude model is changed and updated. Has anyone found a workaround for the versions newer than 2.1.191?