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:
tccd AUTHREQ_PROMPTING: service=kTCCServiceSystemPolicyAppData,
subject=Sub:{com.anthropic.claude-code}
Resp:{identifier=com.anthropic.claude-code,
responsible_path=/Users//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
```

…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//Library/Mail
kernel System Policy: claude(PID) deny(1) file-read-data /Users//Library/Safari
kernel System Policy: claude(PID) deny(1) file-read-data /Users//Library/AddressBook
kernel System Policy: claude(PID) deny(1) file-read-data /Users//Library/Application Support/CallHistoryDB
kernel System Policy: claude(PID) deny(1) file-read-data /Users//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.

Reproduce the prompt with the bundled worker at ~/Library/Application Support/Claude/claude-code/2.1.258/claude.app/Contents/MacOS/claude, then inspect the tccd and kernel logs described in the report. Trace the startup access that reaches Mail, Safari, AddressBook, and other Library directories. Done means same-version sessions no longer re-prompt, or the unrelated startup enumeration no longer occurs.

Written by the indexing model from the issue text.