[BUG] macOS: Desktop-hosted Claude Code is spawned via Helpers/disclaimer, so all TCC-protected folders return EPERM — unfixable by Full Disk Access, and no FDA was ever granted

Summary

When Claude Code is launched from inside the Claude Desktop app, its process is spawned through /Applications/Claude.app/Contents/Helpers/disclaimer, which disclaims macOS TCC responsibility for the child. The resulting session gets EPERM on every TCC-protected folder — ~/Desktop, ~/Documents, ~/Downloads, ~/Library/CloudStorage — for both the Bash tool and the in-process Read tool.

This is not fixable with Full Disk Access, and no permission prompt is ever shown, because a disclaimed process cannot trigger one.

The distinguishing evidence versus #26981 and #64685: Full Disk Access was never granted to any application on this machine, and access worked correctly for weeks regardless. So this is not a lost or stale FDA grant — the disclaimed spawn is sufficient on its own to break it.

Environment

| | |
|---|---|
| macOS | 15.7.4 (24G517), arm64 |
| Claude Desktop | 1.37937.3 |
| Claude Code | 2.1.246 installed; 2.1.237 in the running session's path |
| Full Disk Access | no applications granted, including Claude |

The cause, from the process ancestry

/bin/zsh
 └ …/Application Support/Claude/claude-code/2.1.237/claude.app/…/claude
  └ /Applications/Claude.app/Contents/Helpers/disclaimer     <-- disclaims TCC responsibility
   └ /Applications/Claude.app/Contents/MacOS/Claude

disclaimer is a real 136 KB binary, mtime 2026-08-26 20:02 — which falls exactly inside the window where behaviour changed (see timeline).

Reproduction

From a Claude-Desktop-hosted session, against any path under a protected folder:

$ head -c 1 ~/Library/CloudStorage/OneDrive-<Org>/<dir>/<file>
head: …: Operation not permitted

$ python3 -c "open('<same path>','rb').read(1)"
PermissionError: [Errno 1] Operation not permitted

Note errno 1 (EPERM), not errno 13 (EACCES) — this is the sandbox/privacy layer, not filesystem permissions.

Observations that narrow it

1. stat succeeds, read fails. os.stat() returns correct size and mtime for a file whose contents cannot be opened.
2. Exactly the protected set fails. Denied: ~/Desktop, ~/Documents, ~/Downloads, ~/Library/CloudStorage (all 7 provider directories). Readable: ~/Library/Preferences, ~/Library/Application Support, ~/Library/Logs, ~/.config, ~/.claude, /tmp, and arbitrary project directories far outside the session's working directory. So this is not working-directory scoping.
3. Symlinks do not help. A symlink in /tmp pointing into ~/Library/CloudStorage fails identically. Matches #26981.
4. The Read tool fails too, not only Bash. Both the spawned shell and the in-process file read return EPERM, consistent with the whole Claude Code process being disclaimed rather than just its children.
5. dangerouslyDisableSandbox makes no difference — expected, since this is above Claude's own sandbox.
6. Two concurrent sessions on the same machine disagree. A Claude Code session hosted in Terminal reads the exact same file successfully at the same moment. The only difference is ancestry: the working one has no disclaimer in its chain.
7. The in-app directory-grant tool reports success but changes nothing. Requesting access to the folder returns "Folder access granted", after which reads still fail — it records an internal grant that cannot override the OS.

Timeline

Same machine, same path, same working directory, same command form throughout:

| Date | Result |
|---|---|
| 2026-08-18 → 2026-08-23 | reads succeed (5 separate sessions) |
| 2026-08-26 20:02 | Helpers/disclaimer mtime — app update |
| 2026-08-28 | every read fails with EPERM |

Full Disk Access was absent the entire time, before and after.

Impact

Any Desktop-hosted session cannot read project files, reference documentation, or configuration under a protected folder. For repositories or tooling kept in ~/Documents or a cloud-synced folder, the session is unable to do the work at all, with an error that looks like a machine misconfiguration rather than a launcher issue. Users are then advised — including by Claude itself, and by the existing issues — to grant Full Disk Access, which cannot possibly help, because the grant is disclaimed before it applies.

Expected

A Desktop-hosted Claude Code session should have the same file access as a Terminal-hosted one, either by not disclaiming responsibility, or by acquiring its own TCC grant so that macOS can prompt and the grant can persist.

Related

• #26981 — same EPERM on ~/Library/CloudStorage, same "worked before an update" regression; closed as not planned. That report assumed FDA was relevant. This one shows the failure occurs with no FDA anywhere, and identifies disclaimer in the ancestry.
• #64685 — identifies the disclaim mechanism for ~/Documents and git getcwd(). This adds that the in-process Read tool is affected as well, so it is not limited to spawned subprocesses.