macOS 26: "claude.app would like to access data from other apps" re-prompts on every Claude Code session launch and cannot be cleared

Bug: "claude.app would like to access data from other apps" re-prompts per Claude Code session and cannot be cleared

Summary

On macOS 26, Claude Desktop launches every Claude Code session through
/Applications/Claude.app/Contents/Helpers/disclaimer, which execs a binary belonging to a
different, nested app bundle (com.anthropic.claude-code, located at
~/Library/Application Support/Claude/claude-code/<version>/claude.app).

That cross-bundle launch triggers the macOS app-data consent dialog
(""claude.app" would like to access data from other apps"). The consent is not persisted or
reused across launches, so every session start raises its own dialog. A user running several
sessions gets one dialog per session, stacked — answering one immediately reveals the next, which
reads as "I accept it and it appears again, I can't close it."

Environment

| | |
|---|---|
| macOS | 26.5.1 (build 25F80), Apple Silicon |
| Claude Desktop | 1.24012.9 — com.anthropic.claudefordesktop |
| Claude Code | 2.1.219 — com.anthropic.claude-code |
| Claude Code bundle path | ~/Library/Application Support/Claude/claude-code/2.1.219/claude.app |
| Signature (nested bundle) | Developer ID Application: Anthropic PBC (Q6L2SF6YDW), notarized, ticket stapled |
| Launcher | /Applications/Claude.app/Contents/Helpers/disclaimer (universal Mach-O, 136 KB) |

Evidence

1. Every Claude Code session is parented by its own disclaimer wrapper.
15 sessions running, 15 disclaimer processes, all children of the single Claude Desktop
pid 70155, each disclaimer the direct parent of one claude process:

disclaimer pid  ->  claude pid   uptime
     8953        ->    8954       1d 01h
    70492        ->   70493       1d 04h
    21264        ->   21265         22h
    84896        ->   84897       8h 45m
    ... (15 pairs total, all ppid=70155)

This is a per-launch wrapper, not a leak — but it means the consent prompt is raised
once per session launch, and the count of outstanding dialogs scales with session count.

2. The consent is not being cached. Sessions started hours apart each raised a fresh prompt.
No com.apple.TCC subsystem entries mentioning claude appear in the last 2h of log show,
so the grant does not appear to be recorded against a stable subject.

3. Likely cause of non-persistence — version-scoped bundle path. The requesting bundle lives at
.../claude-code/2.1.219/claude.app. The version is part of the path, so the TCC subject changes
on every Claude Code update, invalidating any grant the user previously gave. A nested .app
inside Application Support is also a fragile TCC subject generally.

4. The dialog offers no durable answer. Neither button resolves it for future launches:
"Allow" is not reused by the next session, and "Don't Allow" does not suppress re-prompting.

Steps to reproduce

1. macOS 26.x, Claude Desktop 1.24012.9.
2. Open several Claude Code sessions from the desktop app (the more concurrent sessions, the more

obvious the effect).

1. Observe one "would like to access data from other apps" dialog per session launch.
2. Click Allow. Start another session — the dialog returns.

Expected

The app-data consent is requested at most once and persists across sessions and across Claude Code
version updates, or is not required at all for launching Anthropic's own bundled helper.

Actual

The dialog is raised on every session launch, cannot be permanently dismissed by either button, and
stacks so that dismissing one reveals another.

Suggested fixes

• Launch the Claude Code binary under Claude Desktop's own bundle identity, or embed it inside

/Applications/Claude.app/Contents/ so no cross-bundle app-data access is involved.

• If the nested bundle must stay in Application Support, use a version-stable path

(e.g. a current/ symlink target that keeps the TCC subject identical across updates) so a
granted consent survives Claude Code upgrades.

• Coalesce the prompt: request consent once per Claude Desktop launch rather than once per

Claude Code session, so N concurrent sessions cannot produce N stacked dialogs.

Note for triage

The reporter also could not read ~/Library/Application Support/com.apple.TCC/TCC.db to confirm the
recorded grant state — that read is itself gated by the same permission mechanism and hung until
killed (exit 144). So the "grant not recorded" conclusion is inferred from re-prompt behavior and
the absent TCC log entries, not read directly from the TCC database.