[BUG] macOS: Claude Desktop can't run hooks/git in TCC-protected folders (~/Documents) — `disclaimer` disclaims TCC responsibility, git getcwd() → "Operation not permitted"

[majak]

Preflight Checklist

• I have searched existing issues (related: [BUG] "Failed to load session" — disclaimer helper cannot access macOS Documents folder despite Full Disk Access #32584, [BUG] Claude Code in Claude Desktop fails to work with local projects (macos) #42393, Claude Desktop: disclaimer helper blocked by macOS quarantine - local sessions crash with 'Operation not permitted' #30798, [BUG] EPERM: operation not permitted accessing ~/Library/CloudStorage/ despite Full Disk Access enabled #26981) and none is an open, accurate root-cause report
• This is a single bug report
• I am using the latest version

What's Wrong?

On macOS, Claude Desktop cannot run hooks / git subprocesses for any repo located in a TCC-"protected" folder (~/Documents, and presumably ~/Desktop, ~/Downloads, iCloud Drive). Concretely, creating a new worktree session fails — the WorktreeCreate hook fires but its shell aborts:

WorktreeCreate hook failed: ... shell-init: error retrieving current directory:
  getcwd: cannot access parent directories: Operation not permitted
worktree_hook_failed

Root cause: Claude Desktop runs these subprocesses through Claude.app/Contents/Helpers/disclaimer, which calls responsibility_spawnattrs_setdisclaim() to make the spawned process its own TCC-responsible process — deliberately detaching it from the app's Full Disk Access. The resulting permission-less process can't read the protected parent folder, so git's getcwd() returns EPERM and the operation aborts. Repos outside protected folders are unaffected.

Because the disclaim intentionally strips the grant, granting Full Disk Access to Claude (or anything else) cannot fix it — confirmed by the symptoms in #32584.

Minimal Reproduction (no app UI needed)

DIS="/Applications/Claude.app/Contents/Helpers/disclaimer"

# FAILS — repo inside ~/Documents (TCC-protected)
mkdir -p ~/Documents/_wt_repro && ( cd ~/Documents/_wt_repro && git init -q )
"$DIS" /bin/bash -c 'cd ~/Documents/_wt_repro && git rev-parse --git-common-dir'
#   => fatal: Unable to read current working directory: Operation not permitted

# WORKS — same disclaimed identity, repo OUTSIDE the protected folder
mkdir -p /tmp/_wt_repro && ( cd /tmp/_wt_repro && git init -q )
"$DIS" /bin/bash -c 'cd /tmp/_wt_repro && git rev-parse --git-common-dir'
#   => /tmp/_wt_repro/.git

rm -rf ~/Documents/_wt_repro /tmp/_wt_repro

The helper's role is directly verifiable:

$ nm -u /Applications/Claude.app/Contents/Helpers/disclaimer | grep disclaim
_responsibility_spawnattrs_setdisclaim
$ /Applications/Claude.app/Contents/Helpers/disclaimer
Usage: disclaimer <command> [args...]

Diagnostic note: commands that don't force a real parent-walk getcwd() falsely appear to work even under ~/Documents — cat <abs path>, ls -d, /bin/pwd (uses $PWD), and even python3 -c 'import os; print(os.getcwd())' all succeed. Only git (and /bin/pwd -P) reliably surface the block. Worth knowing so this isn't misdiagnosed as path-specific or intermittent.

What Should Happen?

Worktree creation / hook execution should work for repos under ~/Documents. This is a regression — worktrees in ~/Documents/... created fine until ~late May 2026; the behavior broke after a subsequent desktop update and persists on the current build.

Environment

• macOS 26.5 (25F71), Apple Silicon
• Claude Desktop 1.9659.4 (also reproduced on 1.9659.2)
• Embedded claude-code 2.1.160
• git 2.50.1 (Apple Git-155)
• Repo path: ~/Documents/projects/<name>

Why the usual workarounds don't help

• Full Disk Access (Claude.app): no effect — disclaim detaches the subprocess from the app's identity. The only identity that would count is the disclaimed shell /bin/bash, a SIP-restricted Apple platform binary (com.apple.bash) that can't be granted via System Settings (and granting it would hand every shell on the system full-disk access — the exact thing the disclaim exists to prevent).
• App restart / full system reboot: no effect — this is the disclaim code path, not transient tccd state.
• Reinstall + TCC cleanup: hit-or-miss per [BUG] Claude Code in Claude Desktop fails to work with local projects (macos) #42393.
• Only reliable user-side workaround: move the repo out of ~/Documents (e.g. ~/projects/...).

Suggested Fixes

1. Don't disclaim TCC responsibility for Claude's own worktree-setup git invocations — run them with the same access the session backend already has (the session backend reads ~/Documents fine; only the pre-session worktree/hook path is disclaimed).
2. Failing that, detect a protected-folder repo and surface a clear, actionable error ("move this repo out of ~/Documents / Desktop / Downloads") instead of a raw getcwd: Operation not permitted.

Related

• [BUG] "Failed to load session" — disclaimer helper cannot access macOS Documents folder despite Full Disk Access #32584 — exact match ("disclaimer helper cannot access macOS Documents folder despite Full Disk Access"); closed as duplicate and locked.
• [BUG] Claude Code in Claude Desktop fails to work with local projects (macos) #42393 — open; "Claude Code in Claude Desktop fails to work with local projects (macOS)"; a comment reproduces the identical getcwd EPERM under ~/Documents.
• Claude Desktop: disclaimer helper blocked by macOS quarantine - local sessions crash with 'Operation not permitted' #30798, [BUG] EPERM: operation not permitted accessing ~/Library/CloudStorage/ despite Full Disk Access enabled #26981 — same disclaimer / EPERM-despite-FDA-after-update family.

[z68z4mw4z4-png]

Additional case: Code tab input never initializes for projects in ~/Documents

Adding this case as additional evidence — the failure mode here surfaces as a UI symptom that may not obviously map to the disclaimer/TCC root cause described in this issue, which could be why some affected users don't connect their problem to existing reports.

Environment

• macOS: 26.5.1
• Claude Desktop: latest as of 2026-06-08
• Claude Code binary: 2.1.165 (bundled)
• Project locations affected: ~/Documents/ClaudeCode/*

Symptom

• Code tab loads UI normally (sidebar, recents, overview stats render)
• Input field shows a ↵ glyph at the right edge instead of the orange send-arrow
• Typing into the field produces no functional input — send arrow never appears, Return does not submit
• Project session history is missing or partial in the sidebar Recents list
• Chat tab works normally; only Code tab is broken
• Reproduces across every project under ~/Documents/

Log evidence (matches this issue's root cause)

[CCD] LocalSessions.setFocusedSession: sessionId=null (repeated)
git ls-files failed; falling back to shallow BFS ...
fatal: Unable to read current working directory: Operation not permitted

Sessions never reach a non-null sessionId, so the input has nothing to attach to and the send button never renders. The getcwd() EPERM matches the responsibility_spawnattrs_setdisclaim() behavior described in this issue.

Troubleshooting that did NOT resolve

Confirms the diagnosis that FDA cannot fix this:

• Full Disk Access granted to Claude.app (verified ON)
• Full app data wipe (~/Library/Application Support/Claude, ~/Library/Caches/Claude, plist, saved state)
• Keychain entries cleared
• Full uninstall + fresh .dmg reinstall from claude.ai/download
• tccutil reset SystemPolicyAllFiles com.anthropic.claudefordesktop
• Re-auth from scratch
• .claude.json restored from backup

Resolution

Moving projects out of ~/Documents to ~/Projects/ immediately resolved all symptoms — input accepts text, send arrow appears, sessions initialize, history populates.

Suggested UX improvement

The current failure mode is silent — the only indication something is wrong is the missing send button and an obscure subprocess error buried in main.log (with the error message bizarrely encoded as a numeric character array, which makes it hard to grep). Suggested improvements:

1. Detect the EPERM at session-init time and surface a clear in-app error: "This project is in a macOS-protected directory (~/Documents). Move it to ~/Projects or ~/Desktop to use the Code tab."
2. Decode the git error string before logging it.
3. Document the limitation in the Code tab onboarding when a ~/Documents-located folder is selected.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.