[BUG] Claude Code ignores permissions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5140
2. https://github.com/anthropics/claude-code/issues/6850
3. https://github.com/anthropics/claude-code/issues/5710

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

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

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

1. 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.
```

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue is still occuring for me on windows in vscode with the claude code plugin. It seemed to start after the new UI was rolled out (when it was a terminal experience it worked fine)
I have not had a chance to dig into the detail of the problem on my machine but this issue appears to have very good detail and the OP has done extensive analysis already.

Additional data point: Project inside ~/.claude/skills/

I'm experiencing the same issue with a project located at ~/.claude/skills/helix-memory/. The nested location inside the main .claude directory might be an additional factor.

What we've tried (all failed):

In ~/.claude/settings.json (global):

"Update(~/.claude/**)",
"Write(~/.claude/**)",
"Read(~/.claude/**)"

In ~/.claude/skills/helix-memory/.claude/settings.local.json (project local):

"Edit(scripts/*)",
"Edit(scripts/**)",
"Edit(hooks/*)",
"Edit(hooks/**)",
"Edit(**/*.py)",
"Edit(*.py)",
"Update(scripts/*)",
"Update(scripts/**)",
"Update(hooks/*)",
"Update(hooks/**)",
"Write(scripts/*)",
"Write(hooks/*)",
"Update(**/*.py)",
"Write(**/*.py)"

Observations:

• The CLI shows Update(scripts/memory_helper.py) when prompting, confirming the internal tool name is "Update"
• We tried both Edit() and Update() patterns
• Tried **/*, **, and explicit directory patterns like scripts/**
• Session restarts after each settings change
• Read operations work fine, only Update/Edit prompts

Hypothesis:

Having a project inside ~/.claude/skills/ might cause path resolution issues since:

1. Global settings are at ~/.claude/settings.json
2. Project settings are at ~/.claude/skills/helix-memory/.claude/settings.local.json

The nested .claude directories could confuse the permission matching logic.

Version: Claude Code CLI (latest as of Jan 2026)

@kornysietsma found a workaround: https://github.com/kornysietsma/claude-code-permissions-hook

I ended up not waiting for Anthropic to fix all their permissions issues. I wrote a drop-in replacement using hooks: https://github.com/arnonmoscona/toolguard

Very easy to set up. Adding some new feature soon to overcome even more weird behaviors. It seems to work for me. I'd welcome feedback on it.

Escalation — Feb 19, 2026: "No" on permission prompt is ignored entirely

This has escalated beyond "allow rules not matching correctly." In my case, Claude prompts for permission, the user explicitly selects No, and Claude executes the command anyway.

This is not a misconfigured settings file — this is the interactive permission prompt's deny path being non-functional. Filed separately as #27002 since it's a distinct (and more severe) failure mode.

Combined with the compaction instruction loss (#9796), this means:

1. Claude forgets safety procedures after compaction
2. User catches it and denies the dangerous command
3. Claude runs it anyway
4. Machine crashes (documented in #9796 — OOM, dwm.exe killed)

The permission system is the last line of defense and it's broken at every level: allow rules don't match (#15742), settings get corrupted (__NEW_LINE__ tokens), and now explicit denial is ignored (#27002).

This is still broken.

Still Happening — Permission System Has Multiple Failure Modes

Adding fresh data: as of v2.1.55 (Feb 25, 2026), permission bypass is still occurring. Documented:

• Explicit "No" on permission prompt ignored (#27002, bot-closed as dup of #26980)
• Multi-line commands bypass all allow rules (#15742)
• Compaction loses safety instructions, leading to unauthorized actions (#9796)
• Autonomous file deletion with no prompt at all (#27507, #23913, #27063, #26913)

5 reporters on this issue alone. The community pattern across all permission bugs now includes wiped codebases, dropped databases, and lost compute results.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.