Deny rule Read(*/.env*) not enforced until settings.json is edited mid-session

Bug Description

A deny rule Read(*/.env*) in ~/.claude/settings.json was not enforced at session start. The Read tool successfully read a .env file despite the deny rule being present.

After editing settings.json mid-session (adding unrelated deny rules for Edit and Bash(grep)), the same Read(*/.env*) rule started working and correctly blocked subsequent Read attempts on .env files.

Steps to Reproduce

1. Add Read(*/.env*) to deny in ~/.claude/settings.json
2. Start a new Claude Code session
3. Use Read tool on a .env file (e.g. Read("/path/to/project/backend/.env"))
4. Expected: Blocked by deny rule
5. Actual: File contents are returned successfully

1. Edit settings.json mid-session (add any new deny rule)
2. Retry the same Read on the .env file
3. Result: Now correctly blocked — File is in a directory that is denied by your permission settings.

Environment

• Claude Code CLI on WSL2 (Ubuntu)
• Linux 6.6.87.2-microsoft-standard-WSL2
• settings.json had allow: ["Read"] and deny: ["Read(*/.env*)"] coexisting

Impact

Security-sensitive files (.env containing API keys, database credentials, JWT secrets) can be read by Claude despite explicit deny rules, until settings.json is modified and reloaded.

Hypothesis

The deny rules from settings.json may be cached at session start and not properly evaluated against the allow list. Editing the file mid-session triggers a reload that correctly applies deny overrides.