Claude Code: Project Permissions Not Updating - Bug Report

by Marco 59 views

Hey guys! Ever tried tweaking your Claude Code permissions mid-session, only to find it's not playing along? Yeah, me too. It seems like there's a pesky bug where the project-level settings in Claude Code aren't dynamically updating, which can seriously mess with your workflow. Let's dive into this, shall we?

Environment Setup

Before we get into the nitty-gritty, here’s a quick rundown of the environment where this bug was spotted:

  • Platform: Anthropic API. We're using the real deal here, not messing around with Bedrock or Vertex AI.
  • Claude CLI Version: 1.0.90 (Claude Code). This is the specific version where the issue was found. If you're on a different version, your mileage may vary, but keep an eye out!
  • Operating System: macOS 14.6.1. Running on a Mac, so this could be a Mac-specific issue or just a general bug. It's always good to know the OS.
  • Terminal: iTerm2. Just the terminal I'm using, in case that matters. It probably doesn't, but hey, gotta be thorough, right?

Basically, the setup is pretty standard, and the bug should, in theory, be replicable if you've got a similar environment. Let's see what's going on!

Bug Description: Settings Cache and Permission Issues

Alright, here's the deal: Claude Code appears to be caching the .claude/settings.json file's permission settings at the start of a session. This means any changes you make to that file during an active session? They're ignored. Your commands are still being blocked or allowed based on the original settings, not the updated ones.

Think of it like this: you tell your assistant, Claude, to only let you use certain tools. You start working, realize you need a new tool, and update the settings. But Claude, bless its heart, is still working with the old rulebook. Frustrating, right?

The crux of the issue is that Claude Code doesn't seem to be reloading these settings before each command execution. It should be checking in with the settings file to see if anything has changed. That's how dynamic permission management is supposed to work, but alas, not in this case.

This caching behavior is a major pain because you can't quickly adjust permissions without completely restarting the Claude Code session. That can kill your flow, especially when you're trying to experiment or debug. It impacts both security and usability, which is not ideal.

Steps to Reproduce the Bug

Let's get down to brass tacks and see how you can reproduce this bug yourself. I've got two scenarios for you, and they're pretty straightforward:

Scenario 1: Removing a Deny Rule

This first scenario tests if the settings are updated when you remove a rule from your deny list. It's like saying, "Hey Claude, you can use this tool now!"

  1. Start a session: Get your Claude Code session up and running, with a .claude/settings.json file that blocks a specific command (like Bash(echo:*)).
  2. Test the block: Try running the command you've blocked (e.g., echo 'test'). You should get the expected block.
  3. Edit settings: Now, change your .claude/settings.json file. Remove the line that denies the command. Your deny list should now be empty.
  4. Test again: Try running the same command (echo 'test') again. Even though you've changed the settings, the command should still be blocked. Why? Because Claude is using the cached settings.
  5. Verify the settings: Double-check both your global (~/.claude/settings.json) and local (.claude/settings.json) files. Ensure the deny list is empty in both. This confirms the settings have been changed in the files, just not recognized by Claude.
  6. Cached settings: The command remains blocked, proving that the session is using the initial, cached settings.

Scenario 2: Adding a Deny Rule

Okay, now let's see what happens when you try to add a rule to your deny list while a session is active. It's like saying, "Hold up, Claude, you can't use this tool anymore!"

  1. Start a session: Begin your Claude Code session with empty deny lists in both your global and local settings. This means all commands should execute without a problem.
  2. Test a command: Run a simple command (e.g., echo 'test') to make sure everything is working as expected. It should execute successfully.
  3. Edit settings: Modify your .claude/settings.json file. Add a rule to deny the command you just ran (e.g., add Bash(echo:*)).
  4. Test again: Run the same command (echo 'test'). Even though you've added a deny rule, the command should still execute successfully. Claude is using the old, cached settings.
  5. Assistant Acknowledgement: The assistant might even acknowledge the new deny rule, but the execution still proceeds based on old settings.
  6. Cached Permissions: Again, the command continues to use the cached (empty) permissions from the beginning of the session, ignoring your changes.

These scenarios clearly show that the settings aren't being dynamically updated. You're stuck with the initial settings until you restart the whole shebang.

Expected vs. Actual Behavior

Let's be clear on what should be happening, versus what is happening. This will help you see how big a problem this bug is.

Expected Behavior

  • Real-time Updates: Settings files should be reloaded before each command execution. Basically, Claude Code should always be checking the latest version of your .claude/settings.json.
  • Instant Changes: Any change you make to .claude/settings.json should take effect immediately. No waiting, no restarting, just smooth sailing.
  • Dynamic Permissions: Commands should be blocked or allowed based on the current file contents, not some old, cached values. If you change the settings, the behavior should change right away.

Actual Behavior

  • Cached Settings: Settings are loaded once at the session start and cached. Once the session begins, Claude Code is basically running on autopilot, ignoring any file changes.
  • Ignored Modifications: Modifications to .claude/settings.json during the session are completely ignored. Doesn't matter what you change; it won't make a difference until you restart.
  • Stale Rules: Commands continue to use the permission rules from when the session started. This makes dynamic adjustment impossible.
  • Restart Required: File changes only take effect after restarting the Claude Code session. It's a hard reset, which is not ideal when you're trying to work efficiently.

It's clear that the actual behavior deviates significantly from the expected one. It's like your assistant is hard of hearing and only listens to the first thing you say.

Additional Context and Impact

So, why does this matter? Well, it's more than just an annoyance. It’s a major issue for workflow and security.

I came across this problem because my hooks stopped functioning. I'm still trying to pinpoint the exact cause, but the settings update issue complicates things. Debugging becomes a nightmare when you can't trust the settings to reflect the current state.

This behavior is 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. This bug is consistent in its behavior — it always uses cached settings — and that prevents any dynamic permission management during development workflows. No matter how you tweak your settings during a session, Claude Code keeps chugging along with the old ones.

This has a real impact on both security and usability. If you can't temporarily adjust permissions without restarting Claude Code, you're limiting your ability to experiment safely. This can be especially tricky if you're working on a project that requires you to quickly test different commands and settings. It’s like constantly having to reboot your computer to access a new application.

And here’s the kicker: according to the Claude Code v1.0.90 changelog, “Settings file changes take effect immediately - no restart required” was supposed to have been implemented. But the bug demonstrates that this feature is not working as intended in v1.0.90, which makes the problem even more frustrating.

Wrapping Up

So, that's the scoop, guys. There's a clear bug in Claude Code where project-level settings aren't dynamically updating. This leads to cached permissions, ignored changes, and a serious hit to both workflow efficiency and security. Hopefully, Anthropic will address this soon because it's a pretty significant roadblock for anyone using Claude Code and trying to manage permissions on the fly. Keep an eye out for updates, and in the meantime, remember to restart your session every time you change those settings!