Versioned install path causes TCC re-prompts on every Claude Code update (breaks MDM PPPC; CoWork scheduled actions may be affected)

Summary
Claude Code installs each version to ~/.local/share/claude/versions/<version>/ as a raw executable, not a .app bundle. macOS TCC identifies unbundled executables by absolute path — so every version bump re-prompts every user for any TCC scope Claude Code has touched. The prompt also labels the requester with the version string (e.g. "2.1.152 would like to access Apple Music...") because TCC falls back to the path's last segment when there's no bundle name.
Reproduction

Install Claude Code, version A.
Use it in a way that triggers any TCC-protected scope (in my case: Media Library).
Allow the prompt.
Update Claude Code to version B (new versions/<X>/ directory).
The same TCC scope re-prompts, this time labeled with the version string.

Evidence
From my user TCC.db after a 2.1.139 → 2.1.152 update:
sqlite3 "$HOME/Library/Application Support/com.apple.TCC/TCC.db" \
"SELECT client, client_type, service, auth_value, datetime(last_modified, 'unixepoch') FROM access WHERE service='kTCCServiceMediaLibrary' ORDER BY last_modified DESC;"

/Users/<user>/.local/share/claude/versions/2.1.152|1|kTCCServiceMediaLibrary|0|2026-05-29 13:34:11
/Users/<user>/.local/share/claude/versions/2.1.139|1|kTCCServiceMediaLibrary|2|2026-05-15 13:05:26
com.anthropic.claude-code|0|kTCCServiceMediaLibrary|0|2026-05-01 15:46:37

client_type=1 = TCC identifies the requester by absolute path.
The older com.anthropic.claude-code row (client_type=0) shows Claude Code was previously identified by bundle ID. The layout changed at some point and lost that stable identity.

Impact
This affects more than IT fleet deployment:

MDM PPPC profile can't be made stable. A PPPC config profile granting Claude Code TCC scopes has to identify the binary by bundle ID (doesn't exist) or path (changes per version). No stable identity to match — admins can't pre-grant TCC permissions at the MDM layer. Real for our ~750-user Jamf deployment.
CoWork scheduled actions may be affected. If CoWork inherits Claude Code's binary identity or a similar versioned install layout, scheduled/unattended runs would hit a TCC prompt with no user available to click Allow — silently failing or hanging on each version bump. Worth verifying internally; flagging it because if it does apply, the failure mode is silent.
User-facing prompts label the requester with a version string. "2.1.152 would like to access Apple Music" looks suspicious enough that I spent real time identifying it on my own machine. At fleet scale this generates IT tickets and trains users to click Don't Allow on legitimate prompts.

Proposed fixes (any one would work)

Ship Claude Code as a code-signed .app bundle with a stable bundle ID.
Install the actual binary at a stable path and treat the versioned directory as implementation detail behind it. TCC must see the stable path as the binary's identity, not as a symlink dereferenced to the version dir.
Publish a stable designated code requirement (output of codesign -d -r-) that admins can use in PPPC profiles to match Claude Code by signed identity across versions.

Environment

macOS Sequoia 15.x, Apple Silicon
Claude Code 2.1.152, installed via the official installer
Jamf-managed corporate fleet (~750 users)
Anthropic plan: Team