macOS: "access data from other apps" (SystemPolicyAppData) prompt recurs every session on the SAME version — grant stored session-scoped (desktop-bundled worker)

Summary

On macOS Tahoe, the desktop app's bundled CLI worker triggers the kTCCServiceSystemPolicyAppData ("… would like to access data from other apps") prompt, and the grant is not persisted — it re-prompts on every new Claude Code session even when the version has not changed.

This is a sharper diagnosis than the existing reports (#63130, #66216, #36832, #36675, #41297, #59608), which attribute the recurrence to the version-numbered install path changing on auto-update. On my machine the prompt recurs across multiple sessions of the exact same version (2.1.258) — so version-path churn is not the (only) cause here. The tccd log shows the real reason: the grant is being stored session-scoped.

Environment

• macOS 26.5.2 (build 25F84), Apple Silicon (arm64)
• Claude Code 2.1.258, run as the desktop app's bundled worker (not the native ~/.local installer, not npm)
• Responsible/binary path: ~/Library/Application Support/Claude/claude-code/2.1.258/claude.app/Contents/MacOS/claude
• Bundle ID: com.anthropic.claude-code; signed Developer ID Application: Anthropic PBC (Q6L2SF6YDW), hardened runtime

Evidence (from log show … process == "tccd")

Prompt fires at session start; grant is explicitly evaluated as session-scoped and invalid:

tccd  AUTHREQ_CTX: service=kTCCServiceSystemPolicyAppData, preflight=no, query=1
tccd  Session scoped auth is invalid for client: <private>
tccd  AUTHREQ_PROMPTING: service=kTCCServiceSystemPolicyAppData,
      subject=Sub:{com.anthropic.claude-code}
      Resp:{identifier=com.anthropic.claude-code,
            responsible_path=/Users/<user>/Library/Application Support/Claude/claude-code/2.1.258/claude.app/Contents/MacOS/claude}

After the user clicks Allow, a record is written…

tccd  AUTHREQ_RESULT: service=kTCCServiceSystemPolicyAppData, authValue=2, authReason=2
tccd  Publishing <TCCDEvent: type=Create, service=kTCCServiceSystemPolicyAppData,
      identifier_type=Bundle ID, identifier=com.anthropic.claude-code>

…yet a new session ~18 minutes later, same version 2.1.258, prompts again with the same Session scoped auth is invalid for client. Observed 4 prompts across 2 days, all on 2.1.258.

What triggers the AppData check

At session start the worker attempts to read a broad set of other apps' data directories under ~/Library, each denied by App Data protection (from log show … process == "kernel"):

kernel  System Policy: claude(PID) deny(1) file-read-data /Users/<user>/Library/Mail
kernel  System Policy: claude(PID) deny(1) file-read-data /Users/<user>/Library/Safari
kernel  System Policy: claude(PID) deny(1) file-read-data /Users/<user>/Library/AddressBook
kernel  System Policy: claude(PID) deny(1) file-read-data /Users/<user>/Library/Application Support/CallHistoryDB
kernel  System Policy: claude(PID) deny(1) file-read-data /Users/<user>/Library/Application Support/MobileSync
… (HomeKit, Messages, FaceTime, Suggestions, Weather, Containers, etc.)

It's unclear why the worker enumerates these unrelated app-data folders (Mail / Safari / AddressBook / call history) at startup — coding sessions never need them. That enumeration is what raises the SystemPolicyAppData prompt in the first place.

Impact

• The prompt reappears on essentially every new session/tab. Heavy users (many concurrent Code tabs) see it constantly.
• Full Disk Access on /Applications/Claude.app (the desktop app) does not help, because the responsible process is the child com.anthropic.claude-code worker, not the desktop bundle (consistent with #66216).

Two independent bugs here

1. The AppData grant is stored session-scoped, not persistent. Even a Bundle-ID type=Create record does not prevent the next same-version session from re-prompting (Session scoped auth is invalid for client). This looks like the worker being spawned as a child of the Electron desktop app (via the disclaimer helper) rather than launched as a persistently-authorizable app identity — so tccd only issues a session-scoped grant.
2. The worker reads other apps' private data (Mail/Safari/AddressBook/call-history/Containers) at startup, which is what triggers the AppData class of prompt at all. A coding tool shouldn't be touching those.

Suggested fixes

• Have the bundled worker run under a stable, persistently-authorizable identity so the AppData grant persists (a real app launch / proper responsible-process attribution), instead of a session-scoped child grant.
• Or, stop the startup enumeration of unrelated app-data directories under ~/Library, so the SystemPolicyAppData prompt is never raised. Scoping filesystem access to the project/cwd would avoid the prompt entirely.
• A discoverable escape hatch would also help (e.g. an env/config to disable the scan), per the ask in #58952.

Related

#63130 (open), #66216, #36832, #36675, #41297, #59608, #27322 — this report adds the same-version, session-scoped evidence that those attribute to version-path churn.