Desktop app spawns a full-disk `find` that triggers repeated "access data from other apps" (TCC) prompts

# Bug report: Claude Code desktop app spawns a full-disk `find` that triggers repeated macOS privacy prompts

## Summary

The Claude Code desktop app repeatedly spawns a child `/usr/bin/find` process that
walks the filesystem starting at the root (`/`). Because the walk descends into
every TCC-protected location, macOS raises repeated "**"claude" would like to access
data from other apps**" consent prompts (and would raise Contacts, Desktop, and Full
Disk Access prompts as well), and logs a stream of sandbox denials. The scan is not
scoped to any open project or working directory — it starts at `/` — so it fires
regardless of what the user is doing in any session.

## Environment

- **App:** `com.anthropic.claude-code`, version **2.1.266**
(bundle at `~/Library/Application Support//claude-code/2.1.266/claude.app`)
- **OS:** macOS (Darwin 25.6.0), Apple Silicon (`darwin-arm64`)
- **Shared app process:** a single `claude` process (observed pid 27877) is the
responsible process for every request; it is shared across all open sessions.

## Impact

1. **Repeated user-facing consent prompts.** The user sees the "access data from
other apps" dialog again and again. The same walk also reaches folders governed by
Contacts, Desktop, and Full Disk Access, producing further prompts / denials.
2. **Privacy surface.** The walk reaches into Contacts, Call History, FaceTime,
Safari data, iCloud/CloudDocs, and other applications' private containers — none
of which a coding tool needs to read.
3. **Noise and overhead.** A recurring full-disk traversal generates many sandbox
denials and unnecessary I/O; observed bursts recurred roughly every 1.5–3 minutes.

## Reproduction

Occurs during normal use with the app open; no user action in a session is required
to trigger it (it is the app's own background scan). It recurs on a timer.

## Evidence

### 1. The `find` is spawned by the app and reaches protected app data (unified log, `com.apple.TCC`)

The responsible process is the app; the accessing process is `find`; the requested
service `kTCCServiceSystemPolicyAppData` is exactly the "access data from other apps"
prompt:

```
Handling access request to kTCCServiceSystemPolicyAppData, from
Sub:{com.anthropic.claude-code}
Resp:{identifier=com.anthropic.claude-code, pid=27877,
responsible_path=...//claude-code/2.1.266/claude.app/Contents/MacOS/claude}
accessing={identifier=com.apple.find, binary_path=/usr/bin/find}
requesting={identifier=com.apple.sandboxd}
```

Related services requested by the same walk in the same bursts:
`kTCCServiceSystemPolicyAllFiles`, `kTCCServiceSystemPolicyDesktopFolder`,
`kTCCServiceAddressBook`.

### 2. The walk is rooted at `/` (kernel sandbox denials, `find(pid)`)

A single `find` process was denied `file-read-data` on top-of-disk paths and on
essentially every protected user folder — proving the traversal root is `/`, not a
project directory:

```
find(93174) deny(1) file-read-data /System/Volumes/Data/home
find(93174) deny(1) file-read-data /Library/Application Support/com.apple.TCC
find(93174) deny(1) file-read-data /System/Library/AssetsV2/com_apple_MobileAsset_UAF_FM_GenerativeModels
find(93174) deny(1) file-read-data /Users//Desktop
find(93174) deny(1) file-read-data /Users//Documents
find(93174) deny(1) file-read-data /Users//.Trash
find(93174) deny(1) file-read-data /Users//Library/Application Support/AddressBook
find(93174) deny(1) file-read-data /Users//Library/Application Support/CallHistoryDB
find(93174) deny(1) file-read-data /Users//Library/Application Support/CloudDocs
find(93174) deny(1) file-read-data /Users//Library/Caches/com.apple.Safari
find(93174) deny(1) file-read-data /Users//Library/Caches/com.apple.HomeKit
... (many more protected ~/Library subpaths)
```

### 3. Exact command line

The `find` processes are extremely short-lived (each completes its traversal in
well under ~20ms, being denied immediately at each protected boundary), so a
non-privileged `ps` sampler cannot reliably catch one. Capturing the argument
vector requires privileged process-exec tracing, e.g.:

```
sudo eslogger exec 2>/dev/null | grep --line-buffered '/usr/bin/find'
```

(The `args` array of each matching JSON event is the exact command.)

This detail is corroborating only — the root-scoped traversal is already
established conclusively by the sandbox denial paths in section 2.

```

```

## What we ruled out

- **Not the user's shell hooks or project config** — no user-configured hook runs a
broad `find`; the traversal root is `/`, unrelated to any session's working
directory.
- **Not a single session's activity** — the responsible process is the shared app
process, and the scan recurs on a timer independent of session activity.

## The user cannot suppress this from their side

Setting the app to "Not Allowed" under Privacy & Security (Files and Folders,
App Management, Contacts) does **not** stop the prompts. In the TCC log, these
requests resolve with `DB Action:None` — macOS records no stored decision — and
the requesting process is a transient `find` child, with the app only as the
"responsible" process:

```
Handling access request to kTCCServiceSystemPolicyDesktopFolder ...
ReqResult(Auth Right: Denied (User Consent), promptType: 1, DB Action:None)
Handling access request to kTCCServiceSystemPolicyAppData ...
ReqResult(Auth Right: Unknown (None), promptType: 1, DB Action:None)
```

`kTCCServiceSystemPolicyAppData` ("access data from other apps") is a distinct
service from the user-facing Files-and-Folders / App-Management toggles, so the
user's denials apply to the app identity while each scan burst re-issues the
request through a short-lived child. The practical consequence: there appears to
be no clean user-side way to stop this specific prompt — the fix has to be
app-side (stop the full-disk walk).

## Expected behavior

The app should not traverse the whole filesystem. Any file scanning (e.g. for a file
picker or `@`-mention index) should be scoped to the current workspace / project
directories and must not descend into TCC-protected locations such as Contacts, Call
History, Safari data, or other applications' containers.

## Suggested fixes

- Scope any `find`/indexing to the active project root(s); never start at `/` or `$HOME`.
- Prune known-protected paths (`~/Library/Containers`, `~/Library/Application Support/AddressBook`,
`~/Desktop`, `~/Documents`, `~/.Trash`, `~/Library/Caches/com.apple.*`) from the walk.
- If a broad search is ever intended, gate it behind explicit user opt-in rather than a
recurring background timer.

Start by reproducing on macOS with the desktop app open and watching TCC logs plus `sudo eslogger exec 2>/dev/null | grep --line-buffered '/usr/bin/find'`. Look for the app code path that schedules background file scanning or indexing. Done means the app no longer launches a recurring `/usr/bin/find` rooted at `/`, scans are scoped to project roots, and the TCC prompts stop.

索引モデルが issue の本文から書いたものです。