VSCode extension: 'always allow' permission grants written to tracked .claude/settings.json instead of gitignored settings.local.json

Environment:

• Surface: Claude Code VSCode native extension
• OS: Windows 11 Pro (10.0.26200)
• Repo: git-tracked project with both .claude/settings.json (shared, committed) and .claude/settings.local.json (personal, gitignored) present

Summary:
When a permission prompt is accepted with an "always allow" / "don't ask again" style response, the new rule is being persisted into the shared, git-tracked .claude/settings.json instead of the personal .claude/settings.local.json. This leaks per-session, per-user permission entries (temp file paths, one-off grep/PowerShell command patterns, scratchpad directories, etc.) into a file meant for team-wide, reviewed configuration.

Expected behavior:
Accepting a permission prompt without an explicit "share with team" action should append the new rule to .claude/settings.local.json (or prompt for scope, defaulting to personal/local), leaving the shared .claude/settings.json untouched unless the user deliberately edits it.

Actual behavior:
New allow-list entries (Bash(...), Read(...), PowerShell(...)) and permissions.additionalDirectories paths accumulate in .claude/settings.json. Confirmed via git diff/git status showing the tracked file modified with entries clearly specific to one user's session (session-scoped scratchpad temp paths, ad-hoc Jira/grep command permission strings).

Evidence this is recurring, not a one-off:

• .claude/settings.local.json's last modification timestamp is 2026-08-18, while .claude/settings.json has been repeatedly modified by normal usage since - meaning new grants have consistently landed in the wrong file for at least two weeks.
• .claude/settings.local.json itself contains leftover diagnostic commands from an apparent prior investigation of this exact issue on 2026-08-18 (e.g. a node -e snippet comparing allow array lengths between settings.json and settings.local.json, and a cleanup command removing a settings.json.pre-pull-backup file) - suggesting this has already been hit and worked around once before without a permanent fix.
• The repository has since added a pre-commit hook (Test-SharedSettingsLeakage.ps1) specifically to catch personal-looking entries before they're committed to .claude/settings.json, which is a workaround for this behavior rather than a fix.

Reproduction steps:

1. In VSCode (Claude Code extension), open a project with both .claude/settings.json (committed) and no recent activity in .claude/settings.local.json.
2. Ask Claude to run a Bash/PowerShell/Read tool call that requires a permission prompt.
3. Accept with "always allow" (or equivalent "don't ask again").
4. Run git diff .claude/settings.json - observe the new rule appended there instead of to .claude/settings.local.json.

Impact:
Personal, session-specific permission grants (including local temp paths unique to one machine/user) get committed into a shared file if not caught before commit, polluting the team's shared configuration and risking accidental commits of user-specific or sensitive-looking paths.

Suggested fix:
Default "always allow" grants to .claude/settings.local.json unless the user explicitly chooses a "share with the team" / project-scope option in the accept flow.