macOS TCC Automation grants not preserved across CC versions — Settings panel accumulates one row per release

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.

1. CC auto-updates to version B (2.1.91).
2. Run the same osascript action. macOS prompts again — TCC treats it

as a new app.

1. 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.