macOS TCC permission prompts show "2.1.201" as the app name, and grants reset on every version update
On macOS, TCC permission popups triggered by Claude Code are titled with the bare version number ("2.1.201" would like to access files in your Downloads folder) instead of "Claude Code". The native installer puts the binary at ~/.local/share/claude/versions/2.1.201, and Claude Code registers that path as the TCC responsible process (identifier com.anthropic.claude-code), so macOS falls back to the filename for the prompt title. Because grants are keyed to that per-version path, every update invalidates them and re-prompts under a new number. Personal-data services (Photos, Calendar, Contacts) never prompt at all, tccd silently denies them because the bare binary lacks the hardened-runtime entitlements ("Policy disallows prompt ... access to kTCCServicePhotos denied"). Repro: native install, then any file search touching ~/Downloads. Expected: prompts say "Claude Code" and grants survive updates. Seen on 2.1.201, macOS 15.6, Apple Silicon.
3 Comments
Still reproduces on 2.1.236 (macOS 15.7.7 / Darwin 24.6.0, Apple Silicon, native installer).
Today macOS showed "2.1.236 would like to access..." prompts for iCloud Drive and other protected folders. From the user's side this is indistinguishable from malware — a bare number asking for iCloud access — and it made me stop and audit the machine before realizing it was Claude Code itself.
Details from that audit, in case they help:
~/.local/share/claude/versions/2.1.236(bare Mach-O, no bundle metadata), even though sessions are spawned viaClaudeCode.app/Contents/MacOS/claude— the pty hostexecs the versioned binary directly, so TCC keys the grant (and the prompt title) to it.Developer ID Application: Anthropic PBC (Q6L2SF6YDW)), butspctl -t executenotes it is not an app bundle, which is why the prompt falls back to the filename.Suggested fix as in the OP: run session processes through the
ClaudeCode.appbundle identity (or give versioned binaries anInfo.plist/stable responsible-process path) so prompts say "Claude Code" and grants survive updates.Confirmed still reproducing on 2.1.241 (macOS, native installer). Same root cause —
TCC.dbshows theclientcolumn keyed to the literal versioned path (~/.local/share/claude/versions/2.1.241) instead of the bundle IDcom.anthropic.claude-code, so grants reset per service on every update.One data point not mentioned yet in either thread: it is not limited to Microphone/Documents/Downloads —
kTCCServiceMediaLibrary(Music library access) resets the same way. A normal update cycle triggers ~4 separate re-prompts (Microphone, Media Library, Downloads, Documents) back to back.Also flagging that this same root cause is spread across a large duplicate cluster: #74068, #86706, #79867, #76615, #84948, #80899, #76246, #77734, #88576, #86091, #79053, #74234, #86715, #84071, #88805.
Still reproducing on 2.1.289 (native install, macOS 26.7.1).
Right after the auto-update to 2.1.289, macOS showed a TCC prompt asking for access to the Desktop folder, with the requesting app named only
"2.1.289". The executable is~/.local/share/claude/versions/2.1.289, so macOS falls back to the file name.From the user's side there is no way to tell from the dialog that this request comes from Claude Code — it looks like an unknown process asking for file access, which is exactly the kind of prompt people are trained to deny. I had to check
psand the versions directory to confirm it was Claude Code.Please make the prompt identify the app as "Claude Code" (e.g. a stable bundle identifier / Info.plist with
CFBundleName/CFBundleDisplayName, or a stable launcher path), so that users can make an informed decision and grants don't reset on every update.