[Bug] Project-level Permissions Not Dynamically Updating in Active Sessions
Claude Settings Permission Bug Report
Environment
- Platform (select one):
- [x] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [ ] Other: <!-- specify -->
- Claude CLI version: 1.0.90 (Claude Code)
- Operating System: macOS 14.6.1
- Terminal: iTerm2
Bug Description
Claude Code does not reload .claude/settings.json permission changes during an active session. Settings appear to be cached at session start and are not updated when the settings file is modified, causing commands to be blocked or allowed based on stale permission rules rather than the current file contents.
Steps to Reproduce
Scenario 1 (Settings not reloaded when deny rule removed):
- Start session with
.claude/settings.jsoncontaining"Bash(echo:*)"in deny list - Run
echo 'test'command - gets blocked correctly - Edit
.claude/settings.jsonto remove"Bash(echo:*)"from deny list (empty array) - Run
echo 'test'command - still gets blocked despite empty deny list - Verify both
~/.claude/settings.jsonand.claude/settings.jsonshow empty deny arrays - Command remains blocked using cached settings from session start
Scenario 2 (Settings not reloaded when deny rule added):
- Start session with empty deny lists in both global and local settings
- Run
echo 'test'command - executes successfully - Edit
.claude/settings.jsonto add"Bash(echo:*)"to deny list - Run
echo 'test'command - still executes successfully despite deny rule - Assistant may acknowledge the deny rule exists but command execution proceeds
- Command continues to use cached (empty) permissions from session start
Expected Behavior
- Settings files should be reloaded before each command execution
- Changes to
.claude/settings.jsonshould take effect immediately - Commands should be blocked/allowed based on current file contents, not cached values
Actual Behavior
- Settings appear to be loaded once at session start and cached
- Modifications to
.claude/settings.jsonduring the session are ignored - Commands continue to use permission rules from when the session began
- File changes only take effect after restarting the Claude Code session
Additional Context
This was discovered because multiple hooks stopped functioning. I still haven't gotten the hooks to work, but I'm not confident enough yet of the cause or able to reproduce in a coherent way partly because of this update issue.
This appears to be a settings caching issue where Claude Code loads permission configurations at session initialization but does not monitor for file changes or reload settings before command execution. The behavior is consistent - it always uses the cached settings - but this prevents dynamic permission management during development workflows.
Note: According to the Claude Code v1.0.90 changelog, "Settings file changes take effect immediately - no restart required" was implemented. However, this bug demonstrates that the feature is not working as intended in v1.0.90.
This impacts security and usability as users cannot temporarily adjust permissions during a session without restarting Claude Code entirely.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗