user_permanent approval for git push not persisting across sessions on Windows (v2.1.161–2.1.162)

Summary

git push (plain and with origin <branch>) continues to prompt for approval on subsequent sessions even after a user_permanent approval has been granted. This occurs on Windows only, in versions 2.1.161 and 2.1.162, despite Bash(git:*) being present in the enterprise permissions.allow list.

Environment

• OS: Windows 10 (builds 26100 and 26200)
• Claude Code versions affected: 2.1.161, 2.1.162
• Entrypoints: CLI and VS Code extension
• Terminal types: windows-terminal and NULL (non-standard/undetected terminal)
• macOS / Linux: Not affected — no occurrences observed in the same dataset

Steps to Reproduce

1. On Windows 10, run Claude Code v2.1.161 or v2.1.162.
2. Enterprise config includes Bash(git:*) in permissions.allow.
3. Issue git push or git push origin <branch> from the CLI or VS Code extension.
4. When prompted, select "Yes, don't ask again" (user_permanent).
5. End the session.
6. Start a new session and run git push again.

Observed Behavior

The approval prompt reappears in subsequent sessions. The user_permanent decision is not honored — neither across sessions nor (in some cases) within the same session after the initial grant.

Expected Behavior

• Because Bash(git:*) is in permissions.allow, git push should auto-approve without any prompt.
• If for any reason the config allowlist is not applied, a user_permanent grant should suppress all future prompts for the same command pattern without requiring re-approval each session.

Evidence

• 9 occurrences across 3 distinct Windows machines over 5 days (June 3–8, 2026).
• A user_permanent approval was recorded on June 4; the same command prompted again on June 7 and June 8 — confirming the decision was not persisted across sessions.
• git status, git log, and git diff on the same machines and same versions did not prompt — only git push.
• No regression observed on macOS or Linux in the same fleet over the same period.

Hypothesis

git push may be subject to a special-case safety check for write/network operations that overrides both:

1. The permissions.allow config allowlist, and
2. Persisted user_permanent decisions.

The special-casing appears to be either Windows-specific or introduced/regressed in versions 2.1.161–2.1.162, since other git subcommands on the same machines do not exhibit this behavior.

Additional Notes

• The fact that git status, git log, and git diff pass through without prompting while git push does not suggests the filtering may be keyed on whether the subcommand performs a write or network operation rather than the literal Bash(git:*) glob.
• May be related to the compound-command allowlist regression (see companion issue) if both share a Windows-specific permission evaluation code path.