Claude Desktop: embedded claude-code engine at a versioned path breaks macOS TCC grants on every update

Summary

Claude Desktop on macOS ships an embedded Claude Code engine at a version-numbered path:

~/Library/Application Support/Claude/claude-code/<version>/claude.app

Because the version number is part of the executed path, every Desktop auto-update creates a new TCC identity. macOS cannot persist a privacy grant across updates, so this dialog reappears indefinitely:

"claude.app" would like to access data from other apps.

Each superseded version also leaves a permanent, un-removable row in the Privacy & Security panes.

This is the same root cause as #12433, but in a different location. #12433 covers the standalone CLI at ~/.local/share/claude/versions/<version>. This report is about the engine embedded inside Claude Desktop, and it reproduces even when the standalone CLI is never used.

Environment

• macOS 26.6.2 (25G83), Apple Silicon
• Claude Desktop 1.37937.3 — /Applications/Claude.app, bundle id com.anthropic.claudefordesktop
• Embedded engine 2.1.246 — bundle id com.anthropic.claude-code
• Does not occur when running the standalone claude CLI in a terminal. Only via Desktop.

Evidence

tccd attributing the access request to the versioned embedded bundle:

tccd: [com.apple.TCC:access] -[TCCDAccessIdentity staticCode]: static code for:
  identifier com.anthropic.claude-code, type: 0: 0x901354000 at
  /Users/<user>/Library/Application Support/Claude/claude-code/2.1.246/claude.app

tccd: [com.apple.TCC:access] Handling access request to kTCCServiceSystemPolicyAllFiles,
  from Sub:{com.anthropic.claude-code}Resp:{TCCDProcess:
  identifier=com.anthropic.claude-code, pid=65032,
  binary_path=/Users/<user>/Library/Application Support/Claude/claude-code/2.1.246/claude.app/Contents/MacOS/claude},
  ReqResult(Auth Right: Denied (Service Policy), promptType: 1, DB Action:None)

Both bundles are correctly signed and notarized (Developer ID Application: Anthropic PBC, team Q6L2SF6YDW). This is a path-stability problem, not a code-signing one.

Stale entries accumulate permanently

Privacy & Security → Full Disk Access currently lists:

• 2.1.206 — enabled, displayed as a bare version number with a generic icon. This directory no longer exists on disk; only 2.1.246 is present. The grant is orphaned and cannot be meaningfully removed.
• claude.app — the current 2.1.246 bundle.

Every update adds one more dead row. Other users report 18+ accumulated duplicates in #12433.

A dialog identified only by a bare version number is also a poor security signal — it is indistinguishable from an unknown binary requesting broad access, and the correct user instinct is to deny it.

Automation grants never persist at all

The recurring dialog requests Apple Events (Automation) access. After clicking Allow, no Claude entry ever appears in Privacy & Security → Automation — the pane lists only unrelated apps.

That pane has no "+" button, so the permission cannot be pre-approved by hand: an entry can only be created by a grant that successfully registers, which never happens here. The result is a prompt that repeats indefinitely with no available user-side remedy.

Impact

High frequency for anyone using Desktop's local Code/Cowork sessions — the prompt fires repeatedly throughout normal use, many times per day. Granting Full Disk Access to the current versioned bundle is at best a temporary damper that expires at the next Desktop update.

Suggested fix

Same as #12433, applied to Desktop's embedded engine:

1. Install the executed binary at a stable path — e.g. .../claude-code/current/claude.app, with versioned payloads behind it — so the TCC-facing identity does not change per release; or
2. Ship a stable Designated Requirement so TCC treats every release as the same identity regardless of path.

Option 1 additionally stops the Privacy panes from filling with dead version rows.