Native installer: versioned binaries lose macOS TCC grants on every update (Documents/FDA re-prompt cycle)

Environment: macOS 26 (Darwin 25.5.0), Claude Code native installer, many concurrent long-lived sessions in a terminal multiplexer.

Problem: The native installer places each release at ~/.local/share/claude/versions/2.1.NNN and launches that binary directly. macOS TCC attributes file-access grants (Documents Folder, Full Disk Access) to the exact executable, so every update mints a new TCC identity with no grants. System Settings → Privacy & Security → Files & Folders fills up with one cryptic numbered row per version (2.1.195, 2.1.220, 2.1.221 … each needing its own Documents toggle).

Worse: long-lived sessions keep running the binary they launched on. Tonight we found seven different versions running concurrently (2.1.220 through 2.1.228); two of them (2.1.220, 2.1.222) had ended up governed by Full Disk Access with no visible toggle and no way to re-prompt, so every file operation under ~/Documents returned EPERM machine-wide for ~20 running sessions — silently. Sandboxed Bash, unsandboxed Bash, and the Read tool all fail; nothing surfaces "you lost TCC" to the user, it just looks like the filesystem broke.

Ask: launch sessions through a stable, signed shim path (e.g. ClaudeCode.app as the TCC-responsible executable for all versions) so grants survive updates — the same reason macOS apps don't lose permissions on every release. Failing that: (a) surface a clear error when EPERM comes from TCC denial rather than file permissions, and (b) have claude doctor detect per-version TCC fragmentation.

Repro: native install on macOS, grant Documents to the current version, let auto-update advance a few versions, resume an old session → EPERM on everything under ~/Documents while a freshly started session works.