Summary
On the native macOS installer, Claude Code triggers a recurring macOS TCC prompt — "<version>" wants to access data from other apps (the macOS SystemPolicyAppData permission) — every time the binary auto-updates. No user-level permission grant can make it stop, because the prompt is attributed to a version-numbered absolute path that changes on every update, and granting Full Disk Access to the bundled ClaudeCode.app does NOT help.
This is a different root cause from #64197 (which is about the npm/Homebrew claude.exe naming). This report is specifically about the native installer + the ClaudeCode.app bundle not being used as the TCC identity.
Environment
- Claude Code 2.1.168, native installer (not npm/brew)
- macOS 26.5 (25F71), arm64
- Binary:
~/.local/share/claude/versions/2.1.168
~/.local/bin/claude → ~/.local/share/claude/versions/2.1.168- Terminal: Ghostty
Symptom
Pressing ⬅️ to enter the background/agents view reliably fires:
"2.1.168" wants to access data from other apps. [Don't Allow] [Allow]
The prompt title is the version string ("2.1.168"), not "Claude Code". It reappears after every auto-update, and the Full Disk Access list accumulates dead, version-named entries (2.1.159, 2.1.168, …).
Root cause (verified locally)
-
The responsible process is the bare versioned binary, attributed by path. The prompt shows the version number, not the app name, because the worker process runs as ~/.local/share/claude/versions/<version>, which carries its own Developer ID signature + entitlements and is therefore its own TCC responsible process:
Identifier=com.anthropic.claude-code
Authority=Developer ID Application: Anthropic PBC (Q6L2SF6YDW)
flags=0x10000(runtime)
entitlements: com.apple.security.cs.disable-library-validation,
com.apple.security.cs.allow-jit,
com.apple.security.device.audio-input
For a bare (non-bundle) executable, TCC keys the grant by absolute path. The path contains the version, so every update (2.1.165 → 166 → 168, ~daily) is a brand-new, unauthorized client → the prompt returns.
-
A fixed-path bundle already exists but is not used as the TCC identity. The installer ships:
~/.local/share/claude/ClaudeCode.app (CFBundleIdentifier=com.anthropic.claude-code, LSUIElement=1, name "Claude Code")
and ClaudeCode.app/Contents/MacOS/claude is a hard link (same inode) to the current versioned binary:
inode=18219820 ClaudeCode.app/Contents/MacOS/claude
inode=18219820 versions/2.1.168
-
Granting Full Disk Access to ClaudeCode.app does NOT stop the prompt (verified: toggle ON, prompt still fires as "2.1.168"). The process tree shows the app process spawns bare versioned children that do the actual work:
ClaudeCode.app/Contents/MacOS/claude → versions/2.1.168 (child, does the file access)
So the access is attributed to the versioned path, not to the stable bundle the user authorized.
Why this is effectively unfixable for end users
macOS does not offer a non-MDM way to grant TCC by code-signing requirement to a bare CLI binary. So as long as the auto-updater keeps producing version-numbered paths and the worker runs under that path, the prompt cannot be suppressed permanently without disabling auto-update (DISABLE_AUTOUPDATER=1) and re-granting once.
Suggested fix
Make the processes that touch protected resources run under the stable ClaudeCode.app bundle identity instead of the bare versions/<version> path — e.g. exec the worker via ClaudeCode.app/Contents/MacOS/claude (the fixed path), or have spawned agent/background children inherit the bundle path rather than the versioned path. Then a single Full Disk Access / App-data grant to ClaudeCode.app (fixed path, stable bundle id) would persist across all updates.
Related
Summary
On the native macOS installer, Claude Code triggers a recurring macOS TCC prompt —
"<version>" wants to access data from other apps(the macOSSystemPolicyAppDatapermission) — every time the binary auto-updates. No user-level permission grant can make it stop, because the prompt is attributed to a version-numbered absolute path that changes on every update, and granting Full Disk Access to the bundledClaudeCode.appdoes NOT help.This is a different root cause from #64197 (which is about the npm/Homebrew
claude.exenaming). This report is specifically about the native installer + theClaudeCode.appbundle not being used as the TCC identity.Environment
~/.local/share/claude/versions/2.1.168~/.local/bin/claude→~/.local/share/claude/versions/2.1.168Symptom
Pressing ⬅️ to enter the background/agents view reliably fires:
The prompt title is the version string ("2.1.168"), not "Claude Code". It reappears after every auto-update, and the Full Disk Access list accumulates dead, version-named entries (
2.1.159,2.1.168, …).Root cause (verified locally)
The responsible process is the bare versioned binary, attributed by path. The prompt shows the version number, not the app name, because the worker process runs as
~/.local/share/claude/versions/<version>, which carries its own Developer ID signature + entitlements and is therefore its own TCC responsible process:For a bare (non-bundle) executable, TCC keys the grant by absolute path. The path contains the version, so every update (
2.1.165→166→168, ~daily) is a brand-new, unauthorized client → the prompt returns.A fixed-path bundle already exists but is not used as the TCC identity. The installer ships:
and
ClaudeCode.app/Contents/MacOS/claudeis a hard link (same inode) to the current versioned binary:Granting Full Disk Access to
ClaudeCode.appdoes NOT stop the prompt (verified: toggle ON, prompt still fires as "2.1.168"). The process tree shows the app process spawns bare versioned children that do the actual work:So the access is attributed to the versioned path, not to the stable bundle the user authorized.
Why this is effectively unfixable for end users
macOS does not offer a non-MDM way to grant TCC by code-signing requirement to a bare CLI binary. So as long as the auto-updater keeps producing version-numbered paths and the worker runs under that path, the prompt cannot be suppressed permanently without disabling auto-update (
DISABLE_AUTOUPDATER=1) and re-granting once.Suggested fix
Make the processes that touch protected resources run under the stable
ClaudeCode.appbundle identity instead of the bareversions/<version>path — e.g. exec the worker viaClaudeCode.app/Contents/MacOS/claude(the fixed path), or have spawned agent/background children inherit the bundle path rather than the versioned path. Then a single Full Disk Access / App-data grant toClaudeCode.app(fixed path, stable bundle id) would persist across all updates.Related
claude.exe, same prompt, different cause — OPEN)