macOS: Screen Recording (TCC) permission must be re-approved on every update because the binary installs to a versioned path

Preflight Checklist

• [x] Searched existing issues (this was reported in #41297 and #53703, both now closed; filing fresh per the auto-close bot's own instruction to open a new issue if still relevant)
• [x] Running a recent version (2.1.200)
• [x] Reproducible

What's Wrong?

On macOS, Screen Recording (TCC) permission has to be re-approved on nearly every update.

macOS ties a Screen Recording grant to the exact binary that requested it. Claude Code installs each release to a new versioned path (~/.local/share/claude/versions/<version>) and repoints the ~/.local/bin/claude symlink, so every update presents macOS with a new, unrecognized binary and re-prompts. System Settings > Privacy & Security > Screen & System Audio Recording then accumulates one stale row per version (e.g. 2.1.197, 2.1.200).

For users on auto-update this means re-approving the OS consent dialog almost daily.

Previously reported in #41297 (closed not planned, auto-closed for inactivity, now locked) and #53703 (closed duplicate). The bot on #41297 explicitly says to open a new issue if still relevant. Same underlying versioned-binary identity is the root cause of the open packaging issue #12433.

What Should Happen?

The Screen Recording grant should persist across updates. That requires a stable code identity that TCC recognizes across versions, for example:

• Ship the screen-capture-facing component inside a .app bundle with a fixed bundle identifier so TCC coalesces the grant across updates (the Claude Desktop app already does this with com.anthropic.claudefordesktop and is unaffected), or
• Make the already-stable launcher at ~/.claude/launcher-bin/claude (fixed path, does not change between versions) the TCC-responsible process, instead of the versioned binary.

Error Messages/Logs

No crash. macOS simply re-shows the Screen Recording consent dialog after each update. Verified code identity is stable and correctly Developer-ID signed, so signing is not the problem; the moving install path is:

$ codesign -dv --verbose=4 ~/.local/share/claude/versions/2.1.200
Identifier=com.anthropic.claude-code
Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW)
TeamIdentifier=Q6L2SF6YDW
flags=0x10000(runtime)

Install layout (new path per release, symlink repointed, last 3 kept):

$ ls ~/.local/share/claude/versions/
2.1.198  2.1.199  2.1.200
$ readlink ~/.local/bin/claude
/Users/<me>/.local/share/claude/versions/2.1.200

Steps to Reproduce

1. On macOS, use a feature that needs Screen Recording (computer-use MCP / screenshot). Approve the macOS prompt.
2. Let Claude Code update, or run claude update, to a newer version.
3. Trigger the screen-capture feature again.
4. macOS prompts for Screen Recording again, and Settings shows an additional version-named row.

Claude Model

N/A (packaging / OS-permission behavior)

Is this a regression?

No. This is inherent to the native installer using versioned install paths.

Last Working Version

N/A

Claude Code Version

2.1.200

Platform

Mac (Apple Silicon, arm64)

Operating System

macOS 26.5.1 (build 25F80)

Terminal/Shell

iTerm2 / zsh

Additional Information

• Impact: near-daily OS re-approval for users on auto-update.
• Cosmetic side effect: pruned versions leave orphaned rows in Privacy & Security because macOS does not garbage-collect TCC entries when the binary is deleted. tccutil reset ScreenCapture com.anthropic.claude-code clears them.
• Why a config-profile workaround does not apply here: Apple restricts Screen Recording (kTCCServiceScreenCapture) so it cannot be silently pre-granted via PPPC/MDM (unlike Accessibility / Full Disk Access). The fix needs a stable code identity from the app itself.
• Related: #41297 (closed, locked), #53703 (closed duplicate), #12433 (open, same versioned-binary root cause).