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.

Start with the VSCode native extension's permission-prompt handling and the persistence paths for .claude/settings.json and .claude/settings.local.json. Reproduce the always-allow flow using the listed Bash, PowerShell, or Read examples, then inspect Test-SharedSettingsLeakage.ps1. Done means personal grants and additional directories go to settings.local.json while the tracked settings.json remains unchanged unless sharing is explicit.

Escrito por el modelo de indexación a partir del texto del issue.