`acceptEdits` ("Edit Automatically") mode prompts to persist permissions to shared project settings.json; `auto` mode doesn't prompt at all — leads to shared-repo config pollution

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: acceptEdits ("Edit Automatically") mode prompts to persist permissions to shared project settings.json; auto mode doesn't prompt at all — leads to shared-repo config pollution

Summary

In acceptEdits mode (labeled "Edit Automatically" in the VS Code extension), when a permission approval is persisted ("don't ask again" / equivalent), the UI presents an explicit scope choice between:

• the project-shared, git-tracked .claude/settings.json, and
• the project-local, gitignored .claude/settings.local.json.

In auto mode, this same persistence flow does not present a scope choice at all — no prompt appears.

Impact

On a shared git repo, working in acceptEdits mode causes permission entries — including machine-specific ones (hardcoded absolute paths, temp directories, usernames, e.g. Windows paths like C:\Users\<name>\...\AppData\Local\Temp\...) — to end up written into the shared, version-controlled .claude/settings.json. Because it's a normal tracked file, these entries then get committed and pushed by whoever was in that mode, polluting the shared config for the whole team with entries that are meaningless (and often broken/unusable paths) on anyone else's machine.

This seems to happen either because:

• the toggle in acceptEdits mode doesn't default to (or make obviously safer) the local scope, or
• the mode itself probably shouldn't be surfacing a project-vs-local scoping decision on every persisted permission in the first place, given it's designed to reduce friction.

Related issues

• #11073 ("Cycleable Scope for 'Don't Ask Again' Permission Prompts") — related UX area (scope selection for persisted permissions) but is a feature request for scope-cycling, not a report of this mode-dependent inconsistency.
• #28905 ("'Don't ask again' permission not persisted when project settings.json doesn't exist") — a related persistence bug, but about persistence failing outright, not about which scope gets offered/chosen.

Environment

• Client: Claude Code VS Code extension
• Permission modes involved: acceptEdits ("Edit Automatically"), auto
• (Please fill in: claude --version output, OS, extension version)

What Should Happen?

Expected behavior

Either:

• Persisted-permission scope choice should default to (or only be offered for) the local, gitignored settings.local.json, since that's the file explicitly designed to avoid this exact problem, or
• The scope-choice UI should be consistent across permission modes (not silently present in one mode and absent in another), so behavior is predictable regardless of which mode a session is in.

Actual behavior

Scope-choice behavior for permission persistence differs depending on which permission mode (acceptEdits vs auto) the session is in, and acceptEdits mode's toggle makes it easy to end up polluting the shared, tracked .claude/settings.json on a team repo.

Error Messages/Logs

Steps to Reproduce

1. Open a git-tracked project in Claude Code (VS Code extension) that already has a .claude/settings.json committed.
2. Switch permission mode to acceptEdits ("Edit Automatically").
3. Trigger a tool-permission prompt and choose to persist the approval ("don't ask again").
4. Observe: a scope toggle appears, offering to save to the shared .claude/settings.json vs the local .claude/settings.local.json.
5. Switch permission mode to auto and repeat steps 3–4.
6. Observe: no scope toggle/prompt appears at all.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.98

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_