[BUG] /permissions silently drops existing rules with lowercase tool names when adding a new rule

### Preflight Checklist

- [ ] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

When .claude/settings.json already contains permission rules using a lowercase tool name (e.g. bash(...) instead of Bash(...)), running /permissions to add a new, correctly-cased rule causes the existing lowercase rules to be silently discarded instead of preserved or flagged as invalid.

Steps to Reproduce

Manually create .claude/settings.json with:
json
{
"permissions": {
"allow": [],
"ask": ["bash(git push *)"],
"deny": ["bash(rm -rf *)"]
}
}
Start Claude Code in that project.
Run /permissions and add a new rule, e.g. allow Bash(git commit *) under "ask".
Inspect .claude/settings.json after the change.

### What Should Happen?

The existing ask/deny rules are preserved as-is even though their casing is non-standard, or
Claude Code warns the user that bash(...) is invalid (case-sensitive, should be Bash(...)) and asks whether to fix or remove it.

### Error Messages/Logs

```shell
Actual Behavior

The existing rules disappear without warning:

json
{
"permissions": {
"allow": [],
"deny": [],
"ask": [
"Bash(git commit *)"
]
}
}
```

### Steps to Reproduce

Both the ask: bash(git push *) and deny: bash(rm -rf *) rules are gone. Only the newly added, correctly-cased rule remains.

Impact

This is a silent data-loss / security issue: a user could have a deny rule intended to block a dangerous command (e.g. rm -rf *), and adding an unrelated permission via /permissions will quietly remove that protection with no error, confirmation, or log message.

Environment

Claude Code version: (fill in claude --version)
OS: (fill in)
Settings file: .claude/settings.json (project-level, shared)

Suggested Fix

Validate tool-name casing when parsing rules, and either normalize (bash → Bash) or warn rather than dropping silently.
When /permissions rewrites the settings file, preserve any rule it doesn't recognize rather than omitting it, so unrecognized-but-present configuration isn't lost.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.261 (Claude Code)

### Platform

Other

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Start at the /permissions command and its handling of .claude/settings.json, then reproduce the case-sensitive lowercase bash(...) rules described in the issue. Trace how existing allow, ask, and deny entries are parsed and rewritten. Done means adding a correctly cased rule no longer silently removes existing entries, with preservation or an explicit warning for invalid casing.

Written by the indexing model from the issue text.