macOS: recurring TCC permission dialogs labeled with a version number; grants voided by every auto-update

Summary

On macOS, Claude Code repeatedly triggers TCC permission dialogs that are (a) labeled with a bare version number instead of an app name, and (b) impossible to answer permanently, because auto-update moves the binary and TCC keys the grant to the executable path.

I have been dismissing these roughly 1–2× per day for a week. There is no way to make them stop, because macOS records no persistent "deny" for these services and any "allow" is voided by the next update.

The dialogs

Three distinct families, all attributed to com.anthropic.claude-code:

| Dialog text | TCC service |
|---|---|
| "2.1.224" wants to access files managed by "Google Drive - user@example.com" | kTCCServiceFileProviderDomain |
| "2.1.224" wants to access files managed by "iCloud Drive" | kTCCServiceFileProviderDomain |
| Desktop / Documents / Downloads folder access | kTCCServiceSystemPolicy{Desktop,Documents,Downloads}Folder |
| "2.1.224" would like to access data from other apps. | kTCCServiceSystemPolicyAppData |

Each connected cloud account is its own File Provider domain, so a user with several Google accounts plus iCloud Drive gets a separate dialog per account.

Bug 1 — the dialog is labeled with a version string

The installed binary is a bare Mach-O executable at ~/.local/share/claude/versions/<version>, with no .app bundle and no Info.plist, so macOS falls back to the filename for the display name. The user sees:

"2.1.224" would like to access data from other apps.

Nothing identifies this as Claude Code. An unexplained version number asking for access to other applications' data reads as malware, and the reasonable response is to deny — which is what I did every time, for days, before working out what it was.

Bug 2 — grants cannot persist, because the binary path changes on every update

tccd records the grant by path, not by code signature:

Publishing <TCCDEvent: type=Create, service=kTCCServiceSystemPolicyAppData,
  identifier_type=Path,
  identifier=/Users/<user>/.local/share/claude/versions/2.1.224>

Auto-update writes each release to a new versioned path:

2.1.224  Aug 7      2.1.223  Aug 6      2.1.222  Aug 4
2.1.221  Aug 3      2.1.220  Jul 24

Five versions in two weeks, four in the final week. Every update is a new identity as far as TCC is concerned, so every previously granted permission is silently voided and the full set of dialogs returns. Clicking Allow buys a day or two at most.

Combined with the fact that macOS stores no persistent deny for these services, there is no answer to the dialog that makes it stop.

Bug 3 — AppData is requested when nothing needs it

The kTCCServiceSystemPolicyAppData prompt fires with no user-initiated command touching any app container. Sample, with no shell command running:

2026-08-10 09:28:40.354  tccd  AUTHREQ_CTX: function=TCCAccessRequest,
  service=kTCCServiceSystemPolicyAppData, preflight=no, query=1
2026-08-10 09:28:40.364  tccd  AUTHREQ_PROMPTING:
  service=kTCCServiceSystemPolicyAppData,
  subject=Sub:{/Users/<user>/.local/share/claude/versions/2.1.224}
  Resp:{identifier=com.anthropic.claude-code, ...},
  requesting={identifier=com.apple.sandboxd, binary_path=/usr/libexec/sandboxd}

Requests also arrive in bursts — Downloads, Desktop, Documents and the File Provider domain within ~40ms — which looks like the sandbox enumerating protected scopes at startup rather than responding to an actual file access.

My work with Claude Code is confined to a project directory under ~; it never needs Google Drive, iCloud Drive, or another application's container. If the scopes are being probed rather than genuinely required, that is the bug.

Reproduction

1. macOS with iCloud Drive enabled, "Desktop & Documents Folders" sync on, and Google Drive for Desktop signed into one or more accounts.
2. Install Claude Code via the native installer (~/.local/share/claude/versions/<version>).
3. Use it over several days, spanning at least one auto-update.
4. Dialogs appear ~1–2× per day. Answering them does not reduce the rate.

Google Drive for Desktop also drops ~/<account> - Google Drive symlinks into the home folder, so any command that enumerates ~ traverses into a File Provider domain and prompts. That amplifies the issue but is not its cause — the Desktop/Documents/Downloads and AppData prompts happen without it.

Environment

• macOS Darwin 25.5.0, Apple Silicon (M1 Pro)
• Claude Code 2.1.224, native installer
• Shell: bash/zsh, sandboxed Bash tool enabled
• iCloud Drive with Desktop & Documents sync enabled
• Google Drive for Desktop with 4 accounts

Suggested fixes

1. Ship a signed .app bundle, or set a proper CFBundleName, so the dialog says "Claude Code" rather than a version number. This alone would remove most of the alarm.
2. Give TCC a stable identity across updates — key the grant to the code signature, or install to a stable path and version the payload behind it, so a granted permission survives auto-update.
3. Don't request FileProviderDomain or SystemPolicyAppData unless a command actually needs them. Requesting them at sandbox startup means every user with a cloud drive gets prompts regardless of what they are doing.