Full Disk Access grant doesn't cover embedded claude-code binary, blocking OneDrive (FileProvider) access

Summary

"Local" mode sessions pointed at a folder synced via OneDrive (Files Provider domain under
~/Library/CloudStorage/OneDrive-.../) fail with "Couldn't access cloud storage" / EPERM,
even with Full Disk Access granted to Claude Desktop in System Settings.

Root cause

Claude Desktop's embedded claude-code CLI runs from a versioned path:
~/Library/Application Support/Claude/claude-code/<version>/claude.app/Contents/MacOS/claude

This binary has its own TCC identity (com.anthropic.claude-code), separate from the outer
Claude.app bundle (com.anthropic.claudefordesktop). Granting Full Disk Access to Claude.app
in System Settings does NOT extend to this embedded binary — it never appears in the Full
Disk Access list on its own unless manually added via the file picker.

When claude-code internally invokes git (via the Xcode Command Line Tools shim at
/usr/bin/git) to check repository status, macOS TCC denies the request outright because:

1. /usr/bin/git is an Apple "platform binary" — TCC categorically refuses to prompt for

platform binaries ("Platform binary prompting is 'Deny' because: is Platform Binary").

1. The target is a FileProvider extension domain (OneDrive) — a second, independent

category of denial ("extension point disallows prompting").

Without an interactive prompt, TCC falls back to whatever authorization already exists for
the responsible/calling app identity. Since com.anthropic.claude-code never received its own
Full Disk Access grant, it silently fails — no prompt is ever shown to the user, and the only
symptom is the generic "Couldn't access cloud storage" error.

Reproduction

1. Grant Claude Desktop Full Disk Access in System Settings (only the top-level Claude.app

is offered/added).

1. Start a "Local" chat session pointed at a folder inside ~/Library/CloudStorage/OneDrive-.../
2. Session fails with: "Couldn't access cloud storage... Claude Code process exited with

code 1. stderr: error: An internal error occurred (EPERM)"

1. Confirmed via log show --predicate 'subsystem == "com.apple.TCC"' during reproduction.

Fix that works (manual workaround)

Manually add the embedded claude-code app bundle to Full Disk Access:
~/Library/Application Support/Claude/claude-code/<version>/claude.app
(via Cmd+Shift+G in the Full Disk Access "+" file picker)

Why this is a real problem, not just a one-time fix

The path contains the Claude Code version number. Every Claude Desktop update installs a new
versioned folder, so this manual Full Disk Access grant has to be redone after every update.
Nothing in the app surfaces this — the user only sees a generic cloud storage error with no
indication that a second, separate Full Disk Access entry is required.

Suggested fix

• Ensure the embedded claude-code binary shares a stable code identity/entitlement with the

outer Claude Desktop app so a single Full Disk Access grant covers both, OR

• Have Claude Desktop detect and request Full Disk Access for the actual claude-code binary

path (not just the outer app) during onboarding/first run, OR

• At minimum, surface a clearer error message when this specific TCC denial occurs, pointing

the user at the embedded binary path that needs its own grant.

Environment

• macOS 26.6 (Build 25G72)
• Claude Desktop 1.25927.0
• claude-code 2.1.221
• Xcode Command Line Tools only (no full Xcode)
• OneDrive for Mac 26.129.0706 (Business/SharePoint-backed account)