Edit tool calls intermittently rejected even after adding a matching permissions.allow rule

Summary

During a single session/turn, repeated Edit tool calls to ordinary project source files were rejected with "The user doesn't want to proceed with this tool use" — without the user having intentionally rejected them. This happened even after adding an explicit allow-rule to .claude/settings.local.json.

Observed sequence

1. Several Edit calls to a TypeScript source file were rejected in a row. The user reported not intentionally rejecting them ("I just gave you permission to edit. Why don't you pick it up??").
2. Session appeared to be running in the auto permission mode (classifier-based per-action allow/deny), which may explain inconsistent behavior between near-identical calls.
3. As a possible mitigation, .claude/settings.local.json was edited to add:

``json
{ "permissions": { "allow": ["Edit", "Write"] } }
``

1. A separate, apparently-intentional guard was also observed: attempting to have Claude Code edit .claude/settings.local.json itself (to add the above rule) was hard-denied by "the Claude Code auto mode classifier" as a self-modifying-permissions action — this part seems like reasonable, deliberate behavior, not a bug.
2. After the allow-rule was added by the user directly (not via Claude), subsequent Edit calls to the same file continued to be rejected at least once more before eventually succeeding, with no clear signal to either the user or the assistant about why a given call was allowed vs. rejected, or whether the new setting had taken effect.

Question / suspected issue

• Is there a known gap where a permissions.allow rule added mid-session to .claude/settings.local.json does not take effect without a reload/restart, or is not consulted at all while auto mode's classifier is active?
• Separately: earlier in the same session, EnterPlanMode had been invoked and later informally abandoned (the user redirected the assistant to write output to a different, non-ephemeral file rather than approving ExitPlanMode). It's possible plan-mode's read-only restriction remained latently active afterward, which could also explain intermittent Edit rejections — but this is a hypothesis, not confirmed.

Expected behavior

Permission-rule changes and/or mode state should be consistently and transparently applied, and it should be discoverable (to the user, and ideally surfaced to the assistant) why a given tool call was blocked, especially when it doesn't match the user's actual intent.

Environment

• Claude Code CLI, VSCode extension context
• macOS (Darwin 25.5.0)