[BUG] macOS App Management accumulates one permission row per release; stable signing identity defeated by version-named binary paths (follow-up to #38722)

Impact (why this deserves priority)

This is not cosmetic and not limited to one Settings pane. On one machine, TCC database inspection shows version-named Claude Code clients registered across SEVEN permission services: App Management, Files & Folders (Desktop, Documents, Downloads), File Provider, Media Library, Microphone, and App Data. 23 of 23 user-database rows pointed at binaries that no longer exist, meaning users carry stale permission grants (including Microphone) attributed to deleted executables. Every macOS native-installer user accumulates this on every release, at a near-daily release cadence, with an opaque version-number prompt each time; users who hit Don't Allow silently break auto-update. There is no supported user-side cleanup for the system-database rows short of resetting the entire service for all apps.

Description

The native installer ships every release as a bare executable whose filename is the version string, e.g. ~/.local/share/claude/versions/2.1.207. macOS TCC keys App Management (kTCCServiceSystemPolicyAppBundles) clients by binary path, so each release registers a brand-new client. Result: one new row in System Settings > Privacy & Security > App Management per release, named only 2.1.x, plus one opaque permission prompt per update ("\"2.1.207\" would like to update other applications"). With near-daily releases the pane accumulates dozens of rows (screenshot available: 2.1.191 through 2.1.207 on one machine).

New evidence beyond the prior reports

1. The grant SHOULD already carry across updates. codesign -dvv on multiple installed versions shows the identical stable identity: Identifier=com.anthropic.claude-code, Developer ID Application: Anthropic PBC (Q6L2SF6YDW), and byte-identical designated requirements. The macOS machinery for carrying a TCC grant across updates exists and is correctly configured at the signing layer; the per-release binary path is what defeats it.

1. Users cannot clean this up themselves. tccutil reset SystemPolicyAppBundles com.anthropic.claude-code fails with OSStatus -10814 because a bare (non-bundle) binary has no LaunchServices registration; tccutil has no per-path targeting; and the system TCC.db is SIP-protected against direct edits. The only cleanup that works is a full sudo tccutil reset SystemPolicyAppBundles, which also revokes App Management for every other app on the machine (Cursor, Google Drive, etc. all re-prompt).

Steps to reproduce

1. Install Claude Code via the native installer on macOS 13+.
2. Grant the App Management prompt.
3. Let several auto-updates occur.
4. Open System Settings > Privacy & Security > App Management: one 2.1.x row per release.

Expected

A single persistent "Claude Code" entry that survives updates, as with Chrome or VS Code. Any layout where the TCC client path is stable would fix it, for example a stable launcher binary that execs the versioned binary, or shipping an .app bundle.

Environment

• Claude Code 2.1.207, native installer (~/.local/share/claude/versions/)
• macOS 26.3 (25D125)

Prior reports

#38722 (this exact accumulation; closed NOT_PLANNED by the inactivity bot, which invited a fresh issue). Same root cause family: #59608, #54016, #58713, #43562 (prompt shows the version string as the app name and re-prompts every update).