[BUG] "Don't Ask Again" Overwrites Entire Permissions Array
Bug Report: "Don't Ask Again" Overwrites Entire Permissions Array
Description
When clicking "Don't ask again" for a command permission in Claude Code, the entire allow array in .claude/settings.local.json gets replaced with just the new permission, causing all previously saved permissions to be lost.
Expected Behavior
New permissions should be appended to the existing allow array, preserving all previously saved permissions.
Actual Behavior
The entire allow array is replaced with only the new permission, deleting all existing permissions.
Steps to Reproduce
- Have multiple permissions in
.claude/settings.local.json:
``json``
{
"permissions": {
"allow": [
"Bash(npm install:*)",
"Bash(npm run dev:*)",
"Bash(git status:*)"
]
}
}
- Run a new command that triggers a permission prompt (e.g.,
npx tsc) - Click "Don't ask again"
- Check
.claude/settings.local.json - The file now contains only:
``json``
{
"permissions": {
"allow": [
"Bash(npx tsc:*)"
]
}
}
Impact
- Users lose all their saved permissions every time they add a new one
- Have to manually restore permissions or re-approve commands repeatedly
- Makes the "Don't ask again" feature counterproductive
Environment
- Claude Code version: [Current version]
- OS: Windows
- Project type: Next.js/TypeScript
Workaround
Created a script to restore permissions:
// restore-permissions.js
const fs = require('fs');
const path = require('path');
const settingsPath = path.join(__dirname, '.claude', 'settings.local.json');
const desiredPermissions = [
"Bash(npm install:*)",
"Bash(npm run dev:*)",
// ... other permissions
];
const currentSettings = JSON.parse(fs.readFileSync(settingsPath, 'utf8'));
const currentAllow = currentSettings.permissions?.allow || [];
const mergedPermissions = [...new Set([...desiredPermissions, ...currentAllow])];
currentSettings.permissions.allow = mergedPermissions;
fs.writeFileSync(settingsPath, JSON.stringify(currentSettings, null, 2));Suggested Fix
When adding a new permission, the code should:
- Read the current permissions array
- Add the new permission if it doesn't exist
- Write back the merged array
Example fix:
// Instead of:
settings.permissions.allow = [newPermission];
// Should be:
settings.permissions.allow = [...new Set([...settings.permissions.allow, newPermission])];Additional Context
This happens consistently - observed multiple times in a single session where permissions were overwritten with:
Bash(npx tsc:*)Bash(taskkill:*)Bash(powershell:*)
Each time, all previous permissions were lost.
13 Comments
I am also getting this problem and it is very frustrating. Having to say yes to something I've said yes to already (multiple times now due to this bug) gets unwieldy.
My workaround is that my
.claude/settings.local.jsonfile is checked in to git, so I justgit checkout .claude/settings.local.jsonregularly, usually after I have finished a task and done a/clear. I've also quit claude at this point, re-run it, but still it manages to lose thepermissions.allowarray pretty soon, as @jessicawestbrook says, when it asks again - though I also find it asks for commands that are already allowed, so it probably just disappears upon config read even prior to asking for permission.Just to finish, why not change
permissions.allowto an object (with true values) so that object manipulation such as adding a new permission is much much easier than having to do array manipulation. Ultimately this doesn't matter if it works, but currently it doesn't.Yeah this is a very annoying issue.
This claude-settings.json corruption started to occur in v2.0.12 (Claude Code) MacOS earlier today each time the file was read.
same issue here in Current version: 2.0.20
Same for me on 2.0.22 and MacOS 26. This is so annoying.
Detailed Investigation Report: Permissions Ignored Despite Explicit Configuration
### Environment
.claude/settings.local.json### Problem Statement
Claude Code repeatedly requests permissions for actions explicitly allowed in
.claude/settings.local.json, including:uv run ruff check,uv run ruff format,uv run python -m py_compilemcp__basic-memory__edit_note,mcp__basic-memory__write_note, etc.All of these permissions were explicitly listed in the
permissions.allowarray.### 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
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:
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:
This appears to be a fundamental bug in the permission system initialization or matching logic affecting:
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 critical security bug has been open for 3 months with no assignee. Permission system is completely non-functional in v2.0.34. Escalating to
security@anthropic.com and support@anthropic.com
Friends,
Frustrating, indeed. Here is how I have been surviving.
When I start Claude Code, I instruct it to read
.claude/settings.local.json.Warm regards,
Manny
Same here and still not fixed
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.
So, arrays in
settings.local.jsonare replaced instead of merged/appended?Note then that the bug also affects
additionalDirectorieswhen using/add-dirmultiple times.Workaround
Manually edit .claude/settings.local.json to include all directories.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
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.