[Bug] macOS TCC permission ghost entries accumulate on every update — affects Desktop App AND Claude Code, root issue never fixed
Summary
Every Claude Code / Desktop App update adds another ghost entry to Privacy & Security → Automation on macOS, with no mechanism to clean them up. The root cause has never been fixed. This is a re-open of #30608 (closed as inactive) and #46859 (closed as duplicate of #30608).
Root cause
macOS TCC (Transparency, Consent, and Control) keys Automation permissions by the full binary path, which includes the version number in Claude's case. Each update installs a new binary at a new path, so macOS registers it as a new app identity requiring a fresh permission grant — and leaves the old entry as an orphan. After N updates, there are N ghost entries.
Steps to observe
- Open System Settings → Privacy & Security → Automation
- Find Claude — expand it
- Count the entries. Each represents a prior Claude version; only the newest is active.
- Update Claude Code. Observe a new permission prompt appear, and a new entry added.
Impact
- Every update prompts the user to re-grant Automation permission
- The permission list accumulates entries indefinitely with no in-product cleanup path
- Successfully reset AppleEvents approval status for com.anthropic.claudefordesktop clears all entries (workaround), but the user must then re-grant from scratch and the accumulation restarts immediately on next update
Fix direction
The standard solution is code-signing with a stable bundle identifier that doesn't embed the version in the binary path, so TCC sees the same identity across updates. This is how most auto-updating macOS apps handle it. Alternatively, the installer/updater could run followed by a re-grant flow on each update to keep the list clean.
Environment
- macOS Sequoia 15.x (most aggressive re-prompting behavior observed here, but issue exists on earlier versions)
- Claude Desktop App + Claude Code CLI (both affected — both install to version-stamped paths)
- Confirmed: issue reproduces on every update regardless of version
Why this isn't a duplicate of #30608 or #46859
#30608 was closed as inactive — not fixed. #46859 was closed as a duplicate of #30608 by the auto-triage bot — which then also closed without a fix. Both closures were process outcomes, not engineering outcomes. The root cause is unchanged and the bug actively affects every user who updates regularly.
This report adds:
- Explicit root-cause diagnosis (binary-path-keyed TCC identity, not a permission-caching issue)
- Confirmation that the Desktop App and CLI are both affected
- The
tccutil resetworkaround for users who want to clean up immediately - Version: confirmed present as of Claude Code v2.1.170 / macOS 15.x
3 Comments
Same issue. However, every version shows as a separate application, not nested within Claude (see below). macOS permission prompts also only show the version number without any attribution to Claude.
<img width="1442" height="1526" alt="Image" src="https://github.com/user-attachments/assets/c57e20a1-1720-46f7-afd7-3d8425f8031c" />
Periodic verification — July 2026
Checked against Claude Code v2.1.216 (latest release as of 2026-07-21).
Reproduction test: ✅ Still present.
Querying the local TCC database (
SELECT DISTINCT service, client FROM access WHERE client LIKE '%claude-code%') shows 16 distinct version-numbered binary paths still registered as separate TCC identities — the exact accumulation this issue describes:.../Claude/claude-code/2.1.5/claude,2.1.8,2.1.15,2.1.22,2.1.30,2.1.34,2.1.40,2.1.41,2.1.45,2.1.49,2.1.51,2.1.63,2.1.64,2.1.72,2.1.74,2.1.76— each replicated across
kTCCServiceFileProviderDomain,kTCCServiceMediaLibrary,kTCCServiceSystemPolicyAppData,kTCCServiceSystemPolicyDocumentsFolder,kTCCServiceSystemPolicyDownloadsFolder,kTCCServiceSystemPolicyDesktopFolder, andkTCCServiceSystemPolicyRemovableVolumes. Because the binary path embeds the version number, every update mints a fresh TCC identity and the old grants are orphaned rather than migrated. Root cause unchanged.Release notes through v2.1.216: no mention of a fix.
This comment is posted automatically every ~20 days to prevent stale-bot closure (threshold: 28 days). Reporter (@blwfish) will close upon confirming resolved.
Periodic verification — August 2026 ⚠️ Partially addressed — residue remains
Checked against Claude Code v2.1.238 (latest release as of 2026-08-21).
Reproduction test: ⚠️ Accumulation appears to have stopped; the accumulated ghost entries were never cleaned up.
Querying
TCC.dbon this machine today:.../claude-code/2.1.5/claudethrough.../claude-code/2.1.76/claude, acrosskTCCServiceFileProviderDomain,kTCCServiceMediaLibrary,kTCCServiceSystemPolicyAppData,kTCCServiceSystemPolicyDesktopFolderandkTCCServiceSystemPolicyAppBundles.kTCCServiceAppleEventsnow resolves to a single stable client,com.anthropic.claude-code(3 rows, differing only byindirect_object_identifier— the target app being controlled, which is normal). The stable bundle ID also now appears alongside the ghosts under the other services.So the ongoing accumulation this issue reported has stopped, but the 16 stale identities it produced are still present with no cleanup path — a user who granted permissions across those versions still carries 62 orphaned TCC rows.
Reporter: consider whether to close this and file the leftover-cleanup half separately, or keep it open until the residue is reaped.
Release notes through v2.1.238: no explicit mention of TCC or permission-entry cleanup.
This comment is posted automatically every ~20 days to prevent stale-bot closure (threshold: 28 days). Reporter (@blwfish) will close upon confirming resolved.