[BUG] settings.local.json allow not working - keeps asking and wanting to add existing items again

[tonydehnke]

Environment

• Platform (select one):
  • [ ] Anthropic API
  • [ ] AWS Bedrock
  • [ ] Google Vertex AI
  • [x] Other: Claude Code on MacOS in VS Code
• Claude CLI version: 1.0.98 (Claude Code)
• Operating System: MacOS 15.6.1 (24G90)
• Terminal: Apple Terminal

Bug Description

Claude Code keeps asking permission to run commands already saved in the settings.local.json file, even suggesting to add allow again with the exact same format. Have rebooted etc, same result. Happen across multiple commands.

Steps to Reproduce

Get Claude Code to do an action, it will ask permission to do things that are in the allow section already.

Expected Behavior

Don't ask to do things that are covered in the settings allow section

Actual Behavior

Keeps asking for permission, despite it being pre-approved

Additional Context

This was reported before, but closed without resolution:
ttps://github.com/anthropics/claude-code/issues/2560

[github-actions[bot]]

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/819
2. https://github.com/anthropics/claude-code/issues/2560
3. https://github.com/anthropics/claude-code/issues/5140

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

[luck02]

Looks like a widespread issue, having the same thing on Fedora Linux 42 / vscode, after asking me for the same read permission on the same directory 4x I had this in my settings.json

{
  "permissions": {
    "allow": [
      "Read(/home/garylucas/.local/share/Steam/steamapps/common/Avorion/Documentation/**)",
      "Read(/home/garylucas/.local/share/Steam/steamapps/common/Avorion/Documentation/**)",
      "Read(/home/garylucas/.local/share/Steam/steamapps/common/Avorion/Documentation/**)",
      "Read(/home/garylucas/.local/share/Steam/steamapps/common/Avorion/Documentation/**)"
    ],
    "deny": [],
    "ask": []
  }
}

[ZivBA]

Not sure in which of the many identical issues to put this, so I'm hoping someone catches it here: I believe the issue stems from inconsistent expansion of the ~ sign (home folder). Sometimes Claude will try to read from the relative path (~/someFolder), and when you approve the action, the actual permission written to the settings will be "Read(/home//someFolder/**)" But when Claude tries again to read from ~/someFolder, it will not match the rule in the settings JSON. Manually adding the relative path (as ~/someFolder) to permissions (from Claude /permissions or directly to settings json) will resolve the issue.

I believe a proper solution would be for claude to identify home-folder paths, and add both the relative and absolute paths to the 'allowed' list, so both versions will work (or for Claude to always expand homefolder paths behind the scenes?)

[bogini]

Hey @tonydehnke! I think you're encountering this because of wrong path format in your permissions. See https://docs.anthropic.com/en/docs/claude-code/iam#tool-specific-permission-rules.

The fix: Use // for absolute paths on macOS:

// Instead of this:
"Read (/Users/tdehnke/.agent-os/**)",

// Use this:
"Read (//Users/tdehnke/.agent-os/**)",

Quick cheat sheet:

• //path → absolute path (use for /Users/...)
• ~/path → from home directory
• /path → relative to settings file (this is what's tripping you up)

Update your settings.local.json with the double slashes and the repeated prompts should stop immediately.

[ryan-williams]

Thanks @bogini, but claude itself is adding these incorrect lines (see more examples in #7015).

Update: I'm also not seeing the manual fix (two leading slashes) have any effect, I'm still getting prompted for reads that should be covered by them.

[trungkien2003ntk]

I don't know if anyone met this, auto accept edit also not working with Claude Code version 1.0.103 this morning

[zipyo]

I have a same problem too.

[An-u-rag]

I have randomly started experiencing this today too. If you are running CC on windows, you can try referencing your path for the permission this way:

  "Read(RelativePath/to/someFolder/**)",
  "Edit(RelativePath/to/someFolder/**)",

However, I think this underlines a bigger issue with the CC startup. It seems to somehow lose the linkage when restarted even within the same home directory of the codebase. Not sure why.

Edit: Obviously downgrading will fix the issue, but my answer is for people who want to have access to the latest CC version and new features.

[liuzhenjluccst]

Hey @tonydehnke! I think you're encountering this because of wrong path format in your permissions. See https://docs.anthropic.com/en/docs/claude-code/iam#tool-specific-permission-rules.

The fix: Use // for absolute paths on macOS:

// Instead of this: "Read (/Users/tdehnke/.agent-os/**)",

// Use this: "Read (//Users/tdehnke/.agent-os/**)", Quick cheat sheet:

• //path → absolute path (use for /Users/...)
• ~/path → from home directory
• /path → relative to settings file (this is what's tripping you up)

Update your settings.local.json with the double slashes and the repeated prompts should stop immediately.

worked for me thks very much！

And anyone can try this: Read(**)

[danilo-01]

Not sure in which of the many identical issues to put this, so I'm hoping someone catches it here: I believe the issue stems from inconsistent expansion of the ~ sign (home folder). Sometimes Claude will try to read from the relative path (~/someFolder), and when you approve the action, the actual permission written to the settings will be "Read(/home//someFolder/**)" But when Claude tries again to read from ~/someFolder, it will not match the rule in the settings JSON. Manually adding the relative path (as ~/someFolder) to permissions (from Claude /permissions or directly to settings json) will resolve the issue.

I believe a proper solution would be for claude to identify home-folder paths, and add both the relative and absolute paths to the 'allowed' list, so both versions will work (or for Claude to always expand homefolder paths behind the scenes?)

Yes this worked!

I put this in my workspaces .claude folder

.claude/settings.local.json

{
  "permissions": {
    "allow": [
      "Read(./**)"
    ]
  }
}

[janosmathe]

Non of the recommended workaround work for me on Windows. I tried

• "Read(**)"
• "Read(~/**)"
• "Read(./**)"
• "Read(/../**)"
• "Read(/.\../**)"

[trungkien2003ntk]

Non of the recommended workaround work for me on Windows. I tried

• "Read(**)"
• "Read(~/**)"
• "Read(./**)"
• "Read(/../**)"
• "Read(/.../**)"

Have you updated your Claude Code yet? the issue was already resolved in newest version.

[roverby-inmar]

Have you updated your Claude Code yet? the issue was already resolved in newest version.

I'm on the latest version and still have these problems. #7207

[vhardy]

For what it is worth, I was not able to get the simpler permissions matching to work with the prefix matching either, i.e., the issue discussed here. However, I was able to use a hook to filter my 'grunt test:*' content.

If that helps, here is the configuration I used:

settings.json

Added the following:

"hooks": {
    "PreToolUse": [
        {
            "matcher": "Bash",
            "hooks": [
                {
                    "type": "command",
                    "command": "$CLAUDE_PROJECT_DIR/.claude/grunt_test_hook.sh",
                    "timeout": 30
                }
            ]
        }
    ]
}

and my script:

#!/usr/bin/env bash set -euo pipefail

Read JSON from stdin

input="$(cat)"

tool_name="$(jq -r '.tool_name // ""' <<<"$input")" cmd="$(jq -r '.tool_input.command // ""' <<<"$input")"

Only handle Bash tool

if [[ "$tool_name" == "Bash" && "$cmd" == grunt\ test* ]]; then cat <<'JSON' { "hookSpecificOutput": { "hookEventName": "PreToolUse", "permissionDecision": "allow", "permissionDecisionReason": "Auto-allowing grunt test*" } } JSON else

Do nothing; normal permission system applies

echo "{}" fi

The relevant documentation: https://docs.claude.com/en/docs/claude-code/hooks and https://docs.claude.com/en/docs/claude-code/hooks-guide.

[keithdan]

I'm experiencing what appears to be a related issue with permissions being overridden. I have explicit "ask" permissions configured in my .claude/settings.local.json for git operations: "ask": [ "Bash(git add*)", "Bash(git commit*)", "Bash(git push*)" ] However, Claude is executing git add and git commit commands without requesting approval. When I asked Claude what permissions it sees in its system instructions, it reported having Bash(git add:) (with a colon) in the allow list, despite this not being present in my settings file. This suggests either: 1) a pattern-matching issue where git add in my "ask" list doesn't match git add:* that the system is checking against, or 2) permissions are being cached/inherited from a previous session. This occurred in a "continued conversation" (a session resumed after a previous conversation ran out of context). It's possible that continued conversations are inheriting old permissions from prior sessions rather than reloading the current settings file. This is a critical issue since it allows Claude to modify git repository state without user consent, completely bypassing explicitly configured permission guards. The expected behavior is that any "ask" permission should always require user approval, regardless of pattern variations or session continuation.

[vhardy]

@keithdan it may be a typo in your message, but it reads "Bash(git add*)",and it should be "Bash(git add:*)", with the semicolon. I noticed that typos in the config file make the whole config be silently ignored.

[ytzhakov]

any update on this issue? calude 2.0.27 STILL ignores settings.local.json allow permissions. it keeps asking and (sometimes) adding the commands to the list (when I hit "2") but completely ignores them

[vhardy]

@ytzhakov Not sure if this helps, but it took me a while to realize that errors in settings files do not cause errors on claude start up, but if you invoke the /status command, you will see if there is an error in the file. For example, you'll see something like:

System Diagnostics ⚠ Found invalid settings files: /.claude/settings.json. They will be ignored.

This can give the sense that settings are ignored, where in fact, it may be due to a typo. I have found these hard to debug because the error message is not specific about the error, but I was able to fix the issue.

[ytzhakov]

@vhardy this is what status shows at the bottom: System Diagnostics ⚠ Found invalid settings files: . They will be ignored.

im not sure what it means because there is no file name. Additionaly, calude itself adds the "allow" permissions to settings.local.json when I hit "2" (always allow....). I've tried removing all permissions and let calude add them on its own again - same issue. it just wouldnt honor these settings. I tried using wildcards as well, for example: "Bash(MSYS_NO_PATHCONV=1 "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/MSBuild/Current/Bin/MSBuild.exe":)", "Bash(MSYS_NO_PATHCONV=1 "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe":)",

nothing seems to work. it just keeps asking me every time it wants to build the project

[arnonmoscona]

Detailed Investigation Report: Permissions Ignored Despite Explicit Configuration

Environment

• Claude Code Version: 2.0.34
• Platform: macOS (Darwin 22.6.0)
• Project: Local project with .claude/settings.local.json

Problem Statement

Claude Code repeatedly requests permissions for actions explicitly allowed in .claude/settings.local.json, including:

• Bash commands: uv run ruff check, uv run ruff format, uv run python -m py_compile
• MCP tools: mcp__basic-memory__edit_note, mcp__basic-memory__write_note, etc.

All of these permissions were explicitly listed in the permissions.allow array.

Investigation Steps

Theory 1: Path Format Issue (Single vs Double Slash)

Based on issue #6850 and #6881, we hypothesized that absolute paths needed double slashes (//) on macOS.

Changes Made:

// Before
"Read(/Users/arnon/projects/**)"
"Bash(/Users/arnon/bin/send_text:*)"

// After
"Read(//Users/arnon/projects/**)"
"Bash(//Users/arnon/bin/send_text:*)"

Result: ❌ Failed - Still requested permissions

Test Method: Fresh Claude instance, asked to run uv run ruff check on a file
Outcome: Permission prompt appeared despite pattern being in allow list

Theory 2: Wildcard Syntax Issue (Colon vs Space)

Based on issue #819, we hypothesized that command:* syntax doesn't match space-separated arguments.

Changes Made:
// Before
"Bash(uv run ruff check:*)"
"Bash(uv run ruff format:*)"

// After  
"Bash(uv run ruff *)"

Result: ❌ Failed - Still requested permissions

Test Method: New Claude instance after configuration change
Outcome: Still prompted for permission to run uv run ruff check bin/checked_bash.py

Theory 3: Configuration File Corruption

Rolled back .claude/settings.local.json to a known-good version from Oct 27 (commit a079a14) using git.

Result: ❌ Failed - Still requested permissions with old configuration

Test Method: Fresh Claude instance with rolled-back configuration
Outcome: Permissions still requested, ruling out configuration file as the cause

Evidence of Core Bug

1. MCP Tool Permissions Ignored:
  - Tool mcp__basic-memory__edit_note explicitly listed on line 40 of settings
  - Claude still prompted: "Do you want to proceed? ... for basic-memory - edit_note commands"
  - No wildcards, no paths, exact string match - still failed
2. Fresh Instance Behavior:
  - Problem occurs in brand new Claude instances running for <10 seconds
  - Rules out issues from #10028 about periodic clearing after hours of use
  - Indicates permission matching is broken at initialization
3. Pattern Independence:
  - Failed with single slash paths
  - Failed with double slash paths
  - Failed with colon wildcards
  - Failed with space wildcards
  - Failed with exact MCP tool names (no wildcards at all)

Verification Steps Taken

# Verified settings file exists and contains permissions
$ grep -n "edit_note" .claude/settings.local.json
39:      "mcp__basic-memory__edit_note",

# Verified only one settings file in project
$ ls -la .claude/settings*.json
-rw-r--r--@ 1 arnon  staff  2845 Nov  6 12:09 .claude/settings.local.json

# Tested with git history
$ git log --oneline -- .claude/settings.local.json
ffe4d62 FLO-72: Add customers table page with sortable columns
99fa209 FLO-72: Implement users table page infrastructure
a079a14 FLO-72: prep for implementing table pages

# Rolled back and tested
$ git checkout a079a14 -- .claude/settings.local.json
# Result: Still prompted for permissions

Screenshot Evidence

Permission prompt appeared for uv run ruff check bin/checked_bash.py despite:
- Settings containing "Bash(uv run ruff check:*)" (later changed to "Bash(uv run ruff *)")
- Fresh Claude instance
- File explicitly shown in working directory

Conclusion

The permission system in Claude Code 2.0.34 does not read or respect .claude/settings.local.json at all, or the pattern matching is completely broken for all pattern types.

This is not caused by:
- Path format (single vs double slash)
- Wildcard syntax (colon vs space)
- Configuration file corruption
- Duplicate entries
- Periodic clearing (happens immediately)

This appears to be a fundamental bug in the permission system initialization or matching logic affecting:
- All Bash command patterns
- All MCP tool permissions
- Both wildcard and exact-match patterns

The system prompts for permissions on every fresh instance regardless of configuration, making the settings file effectively non-functional.

Reproducibility

100% reproducible on every fresh Claude Code instance with any configuration pattern tested.

[arnonmoscona]

This critical security bug has been open for 3 months with no progress. Permission system is completely non-functional in v2.0.34. Escalating to [email protected] and [email protected]

[amcdavid]

@vhardy this is what status shows at the bottom: System Diagnostics ⚠ Found invalid settings files: . They will be ignored.

I just encountered this -- I had an old-style hook in settings.json, which was deprecated (without any warning 😧 ) in 2.0.32. This caused the entire settings.json to be ignored-- I guess not technically "silently" since there is a brief message on startup. But that's a pretty dangerous failure mechanism, since it means that upon an upgrade, suddenly project-wide guardrails will be dropped.

[pzgz]

This critical security bug has been open for 3 months with no progress. Permission system is completely non-functional in v2.0.34. Escalating to [email protected] and [email protected]

Now with v2.0.50, the issue is still there, cannot believe that, the issue was there since day one of v2, it just cannot be fixed?

[andmanea]

Still an issue. I feel like this should be THE top priority issue. The permission system basically does not work for me. I can't leave it unattended for more than 15 seconds...

[tonydehnke]

One thing I'm finding is if there is an error in setting.local.json, claude keeps trying and asking permission. It would be much better if it said "There is an error in the permissions file, would you like me to fix it, fix it yourself, or fix later".