[Bug] Project-level Permissions Not Dynamically Updating in Active Sessions

Resolved 💬 5 comments Opened Aug 25, 2025 by wdelhagen Closed Jan 7, 2026

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):

  1. Start session with .claude/settings.json containing "Bash(echo:*)" in deny list
  2. Run echo 'test' command - gets blocked correctly
  3. Edit .claude/settings.json to remove "Bash(echo:*)" from deny list (empty array)
  4. Run echo 'test' command - still gets blocked despite empty deny list
  5. Verify both ~/.claude/settings.json and .claude/settings.json show empty deny arrays
  6. Command remains blocked using cached settings from session start

Scenario 2 (Settings not reloaded when deny rule added):

  1. Start session with empty deny lists in both global and local settings
  2. Run echo 'test' command - executes successfully
  3. Edit .claude/settings.json to add "Bash(echo:*)" to deny list
  4. Run echo 'test' command - still executes successfully despite deny rule
  5. Assistant may acknowledge the deny rule exists but command execution proceeds
  6. 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.json should 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.json during 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.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗