Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

The permission system fails to persist path-based access permissions when selecting "Yes, allow access to [path] from this project" option, despite command-pattern permissions (Bash(command:*)) being already configured in settings.json.

Problem 1: Permission prompts despite command patterns being allowed

Commands like mkdir and ls repeatedly trigger permission prompts even though the command patterns are already in the allow list:

Global settings (C:\Users\user\.claude\settings.json):

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)",
      "Bash(ls:*)",
      // ... many other commands
    ]
  }
}

Project settings (C:\Users\user\OneDrive\obsidian\Arc\.claude\settings.json):

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)",
      // ... many other commands
    ]
  }
}

Despite these settings even .local.json files, the following commands still trigger permission prompts:

1. mkdir command:

mkdir -p "/c/Users/user/.claude/history"

Prompt: "Do you want to proceed? [...] Yes, and always allow access to //c/Users/user/.claude/history from this project"

2. ls command:

ls -la /c/Users/user/.claude/

Prompt: "Do you want to proceed? [...] Yes, allow reading from //c/Users/user/.claude/\ from this project"

Problem 2: Selected permissions not being persisted

When selecting option 2 ("Yes, and always allow access to [path] from this project"), the permission is:

• ✅ Applied temporarily (command executes successfully)
• ❌ NOT saved to any settings file (settings.json, settings.local.json)
• ❌ Prompted again on next execution

Files checked after selecting option 2:

• C:\Users\user\OneDrive\obsidian\Arc\.claude\settings.json - No change
• C:\Users\user\OneDrive\obsidian\Arc\.claude\settings.local.json - No change
• C:\Users\user\.claude\settings.json - No change (should not change anyway for project-level permission)

What Should Happen?

1. Command pattern permissions should work: If Bash(mkdir:*) is allowed, all mkdir commands should execute without prompts
2. Path-based permissions should persist: Selecting "always allow access to [path]" should save the permission to settings.local.json
3. Clear permission hierarchy: Documentation should clarify the relationship between:
   • Command patterns with all path (Bash(command:*))
   • Path-based permissions (Bash(command://some/paths/*))
   • How they interact

Actual Behavior

1. Command pattern permissions are ignored when accessing paths outside the project directory
2. Path-based permission selections are not persisted to any configuration file
3. Same permission prompts appear repeatedly for identical operations

Error Messages/Logs

Steps to Reproduce

1. Add "Bash(mkdir:*)" to both global and project settings.json
2. Execute: mkdir -p "c:\Users\user\.claude\history" (path outside project)
3. Observe: Permission prompt appears
4. Select: "Yes, and always allow access to c:\Users\user.claude\history\ from this project"
5. Check: settings.json and settings.local.json files
6. Result: No new entries added
7. Execute the same command again
8. Result: Same permission prompt appears again

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.1 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Questions / Clarifications Needed

1. Is path-based permission system intentional or a bug?
2. If intentional, what is the correct syntax to manually add path-based permissions?
3. Why do command patterns not cover all use cases?
4. Should option 2 save to settings.json or settings.local.json?

Workaround

Currently no workaround exists except:

• Manually selecting "Yes" on every prompt (tedious)
• Avoiding operations on paths outside project directory (limiting)
• Modifying scripts to avoid mkdir on already-existing directories (band-aid fix)

Impact

• Disrupts workflow automation (skills requiring file operations outside project)
• Forces manual intervention for every session
• Makes it impossible to create truly automated skills
• Poor user experience for repetitive tasks