[BUG] "Don't ask again" approvals write to project-shared .claude/settings.json instead of .claude/settings.local.json

Open 💬 0 comments Opened Jul 14, 2026 by konstantinrud

Summary

When approving a permission prompt with "Yes, and don't ask again", Claude Code writes the new allow-rule to the project-shared .claude/settings.json instead of the project-local, gitignored .claude/settings.local.json.

Because .claude/settings.json is the file intended to be committed/shared with a team, personal machine-local approvals silently become candidates for commit — leaking one person's ad-hoc approvals into shared version control and PR diffs. The default project .gitignore only ignores .claude/*.local.json, so .claude/settings.json shows up as an untracked, committable file.

Expected

Interactive "don't ask again" approvals save to a non-committed scope by default — either the project-local .claude/settings.local.json (which the settings docs describe as the target, and which older versions used) or the user-level ~/.claude/settings.json.

Actual

The rule is written to .claude/settings.json (project-shared scope). Example of what lands there after a single approval:

{
  "permissions": {
    "allow": [
      "Read(//path/to/approved/thing/**)"
    ]
  }
}

This file is not ignored by the default project .gitignore and appears as untracked/committable.

Steps to reproduce

  1. In a project directory, trigger any permission prompt (a tool call requiring approval).
  2. Choose "Yes, and don't ask again."
  3. Observe: the rule is written to .claude/settings.json, not .claude/settings.local.json.

Impact

  • Personal, machine-local approvals become committable → they pollute shared config and PR diffs.
  • Teams that rely on .claude/settings.json as the shared, curated config now get individual users' ad-hoc approvals mixed in.
  • Workaround required: manually sweep .claude/settings.json.claude/settings.local.json after each session, or add .claude/settings.json to a global gitignore as a backstop.

Notes

  • The settings documentation still describes approvals saving to the local/user scope, so this looks like an unintended change rather than a documented behavior shift.
  • There does not appear to be any setting to control the write target for interactive approvals.

Environment

  • Claude Code 2.1.170
  • macOS 26.4
  • VS Code extension

View original on GitHub ↗