claude-code - 💡(How to fix) Fix macOS TCC Automation grants not preserved across CC versions — Settings panel accumulates one row per release [2 comments, 3 participants]

Summary

On macOS, every new release of Claude Code registers as a separate app in System Settings → Privacy & Security → Automation. Old entries from binaries that no longer exist persist indefinitely. The list grows by roughly one row per CC release where the Bash tool invokes osascript.

Reproduction

1. Run CC version A (e.g. 2.1.90) and execute a Bash call that uses osascript to control an app (Reminders, Photos, Calendar, etc.). macOS prompts for Automation permission; user clicks Allow.
2. CC auto-updates to version B (2.1.91).
3. Run the same osascript action. macOS prompts again — TCC treats it as a new app.
4. Repeat for every subsequent release.

After ~30 releases, the Automation panel shows one row per version (2.1.90, 2.1.91, … 2.1.121), each expandable to a list of controlled apps. None can be deleted via the GUI in current macOS.

Expected

CC releases should share a stable code-signing identity / designated requirement so TCC matches them as the same app. A user who grants Automation to one CC version should not be re-prompted on every update, and the panel should show a single Claude Code row.

Actual

Each version registers separately. Stale entries persist after the binary is gone. Users see repeat prompts and accumulating clutter.

Environment

• macOS 26.4.1 (build 25E253)
• Claude Code 2.1.121, with stale Automation entries back to 2.1.90
• Bash tool calling /usr/bin/osascript

Impact

• Repeat consent prompts erode the trust signal — users start clicking Allow reflexively, defeating TCC's purpose.
• The Automation panel becomes unusable for auditing what CC can actually control today versus historically.
• Cleanup paths are unattractive: tccutil reset Automation nukes all Automation grants for every app on the system; direct edits to TCC.db require Full Disk Access and are unsupported.

Likely cause

CC's signature designated requirement appears to be version-pinned rather than identifier-based. TCC uses the designated requirement to decide whether two binaries are the same app. If the requirement references the exact code signature or version, every release looks new.

Suggested fix

Audit the CC code-signing setup. The designated requirement in the signature should match by Team ID + bundle identifier (e.g. identifier "com.anthropic.claude-code" and anchor apple generic and certificate leaf[subject.OU] = "<TEAM_ID>"), not by exact binary hash, so TCC sees 2.1.90 and 2.1.121 as the same app.