Native-install auto-update rotates the versioned binary path, invalidating macOS TCC grants attributed to Claude Code (Calendar/Reminders observed)

Environment

• Claude Code native install: ~/.local/bin/claude → symlink to ~/.local/share/claude/versions/<version> (observed: 2.1.206; versions 2.1.202–2.1.206 co-exist on disk)
• macOS 27.0 (Build 26A5378j)

Problem

Claude Code's native install runs the actual executable from a versioned path; ~/.local/bin/claude is only a symlink. In our observed EventKit MCP setup, macOS TCC attributes the authorization context to the responsible process — the Claude Code host binary — and keys that grant to its absolute path (the standard TCC behavior for unbundled executables without a stable code-signing identity).

Consequence of every auto-update:

1. The executable path rotates (versions/2.1.205 → versions/2.1.206 → …)
2. Existing TCC grants (Calendar/Reminders in our case) remain keyed to the old path and become stale for the current executable
3. MCP servers relying on host-context authorization start failing with access denied — "worked yesterday, broken right after an update", with no visible cause
4. System Settings → Privacy & Security accumulates entries shown only as bare version numbers (2.1.202, 2.1.203, …), which users cannot reasonably interpret

Reproduction

1. Under Claude Code (native install), grant Calendar access to an EventKit-based MCP server (macOS prompts once; the grant lands on the versioned claude binary path)
2. Update Claude Code (auto-update, or install a newer version manually)
3. Invoke the same MCP tool → EventKit reports denied/notDetermined under the new binary path; System Settings still shows the old version-number entry toggled ON (now stale for the current executable)

Evidence chain (public repos): PsychQuant/che-ical-mcp#168 (empirical confirmation that EKEventStore.authorizationStatus follows the responsible-process context) and PsychQuant/che-ical-mcp#170 (this rotation issue).

Note on ClaudeCode.app: we have observed a ClaudeCode.app in some process chains — if the app-bundle distribution already gives TCC a stable identity, this issue may only affect the native (CLI) install path; the report still applies to that install base. Clarification on which install channels carry a stable TCC identity would itself be valuable.

Suggested fixes (any one would resolve it)

• Stable executable path: update in place (version elsewhere), so the TCC client key never rotates
• Stable code-signing identity: sign the executable with a stable Identifier + Team ID / designated requirement. Downstream empirical support: our Developer-ID-signed MCP binary's TCC row is keyed to its csreq (Identifier + TeamID, not cdhash) and survives binary replacement (PsychQuant/che-ical-mcp#166 method notes) — the same mechanism should hold for a signed host CLI, though we have not verified it for Claude Code itself
• Post-update UX mitigation (if identity change is unavoidable): detect that the TCC identity changed and proactively surface a re-grant flow — e.g. trigger a fresh permission request and warn that macOS permissions may need re-granting

Impact

macOS users on the native versioned-path install, running MCP servers whose TCC authorization is attributed to the Claude Code host (EventKit-based Calendar/Reminders servers observed; potentially other TCC-protected resources), may lose those grants after each auto-update. Downstream servers can only mitigate with docs and detection banners; the root cause is the rotating attribution identity.