Bug: settings.local.json permissions overwritten when clicking 'accept, do not ask again'

Bug Description

When adding wildcard permissions (e.g., Bash(*) or Bash(git *)) to .claude/settings.local.json and then approving a new permission via the UI by clicking \"accept, do not ask again\", the entire permissions list is overwritten and replaced with only the newly approved specific permission.

Expected Behavior

When clicking \"accept, do not ask again\", the new permission should be added to the existing permissions list, not replace it. Wildcard permissions should be preserved.

Actual Behavior

All existing permissions (including wildcards) are deleted and replaced with only the specific permission that was just approved.

Reproduction Steps

1. Create or edit .claude/settings.local.json with wildcard permissions:

\\\json
{
"permissions": {
"allow": [
"Bash(ls *)",
"Bash(git *)",
"Bash(npm *)",
"Read(*)"
],
"deny": [],
"ask": []
}
}
\\\

1. Trigger a bash command that requires approval (e.g., run a command in a new session)
2. When the permission prompt appears, click "accept, do not ask again"
3. Check .claude/settings.local.json - all wildcard permissions are gone

Result after approval:
\\\json
{
"permissions": {
"allow": [
"Bash(npm --version)" // Only the specific approved command
],
"deny": [],
"ask": []
}
}
\\\

Impact

• Users cannot effectively use wildcard permissions as they get repeatedly overwritten
• Must manually restore permissions after each approval
• Defeats the purpose of the \"do not ask again\" feature
• Related to issue #3428 where Bash(*) wildcard doesn't work as expected

Environment

• Claude Code version: Latest (as of 2025-10-18)
• OS: Windows 10/11
• File location: .claude/settings.local.json in project root

Expected Fix

The permission merging logic should:

1. Preserve existing permissions when adding new ones
2. Check if wildcards already cover the new permission (avoid duplicates)
3. Append new permissions rather than replace the entire list
4. Properly support wildcard patterns like Bash(*), Bash(git *), etc.

Workaround

Currently, users must:

• Manually restore permissions from version control after each overwrite
• OR click "Accept" (one-time) instead of "accept, do not ask again"
• OR make the file read-only (prevents any updates)