[BUG] Permission "Always Allow" Selection Not Persisted - Prompts Repeat Every Execution
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] 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:
- 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"
- 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 changeC:\Users\user\OneDrive\obsidian\Arc\.claude\settings.local.json- No changeC:\Users\user\.claude\settings.json- No change (should not change anyway for project-level permission)
What Should Happen?
- Command pattern permissions should work: If
Bash(mkdir:*)is allowed, all mkdir commands should execute without prompts - Path-based permissions should persist: Selecting "always allow access to [path]" should save the permission to settings.local.json
- 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
- Command pattern permissions are ignored when accessing paths outside the project directory
- Path-based permission selections are not persisted to any configuration file
- Same permission prompts appear repeatedly for identical operations
Error Messages/Logs
Steps to Reproduce
- Add
"Bash(mkdir:*)"to both global and project settings.json - Execute:
mkdir -p "c:\Users\user\.claude\history"(path outside project) - Observe: Permission prompt appears
- Select: "Yes, and always allow access to c:\Users\user\.claude\history\ from this project"
- Check: settings.json and settings.local.json files
- Result: No new entries added
- Execute the same command again
- 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
- Is path-based permission system intentional or a bug?
- If intentional, what is the correct syntax to manually add path-based permissions?
- Why do command patterns not cover all use cases?
- 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
This issue has 11 comments on GitHub. Read the full discussion on GitHub ↗