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/<managed-install>/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.

1. 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.

1. 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=.../<managed-install>/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/<user>/Desktop
find(93174) deny(1) file-read-data /Users/<user>/Documents
find(93174) deny(1) file-read-data /Users/<user>/.Trash
find(93174) deny(1) file-read-data /Users/<user>/Library/Application Support/AddressBook
find(93174) deny(1) file-read-data /Users/<user>/Library/Application Support/CallHistoryDB
find(93174) deny(1) file-read-data /Users/<user>/Library/Application Support/CloudDocs
find(93174) deny(1) file-read-data /Users/<user>/Library/Caches/com.apple.Safari
find(93174) deny(1) file-read-data /Users/<user>/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.

<optional: paste one captured find command line here>

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.