claude-code - 💡(How to fix) Fix macOS Tahoe: Claude Code 2.1.132+ writes block all non-Anthropic apps from reading files in ~/Documents (regression vs 2.1.128)

Summary

After auto-updating Claude Code from 2.1.128 → 2.1.132 (and Claude Desktop to 1.6259.1), every file that Claude Code writes or every directory it operates on under ~/Documents/ becomes unreadable from non-Anthropic-bundled apps — including iTerm2, Terminal.app, and the standalone claude CLI when invoked from a non-Anthropic shell — even though those apps have macOS Full Disk Access AND Documents Folder TCC grants.

The block manifests as Operation not permitted on plain reads. xattrs are SIP-protected so users can't strip them. This worked fine in 2.1.128 and earlier; broke today.

Environment

• macOS Tahoe 26.4.1 (build 25E253) — no OS update between working and broken state
• Claude Code CLI 2.1.132 (~/.local/share/claude/versions/2.1.132, mtime 2026-05-07 08:20)
  • Prior versions: 2.1.126 (mtime Apr 30) → 2.1.128 (mtime May 4, last working) → 2.1.132 (mtime May 7, regression)
• Claude Desktop 1.6259.1 (mtime 2026-05-06 03:38)
• Apple Silicon (M4)
• iTerm2 + Terminal.app: both have FDA + Documents/Desktop/Downloads TCC grants verified via ~/Library/Application Support/com.apple.TCC/TCC.db
• Repo location: ~/Documents/<some-repo>/
• SIP enabled (csrutil status = enabled)

Repro

1. macOS Tahoe 26.4+ with Claude Code 2.1.132 / Desktop 1.6259.1
2. From Claude Code, edit any file in a repo under ~/Documents/<repo>/ (or just have Claude Code List/Read/Bash-touch files there — even read-only ops appear to stamp)
3. From iTerm2 (with FDA + Documents grant) try:
   • bash ~/Documents/<repo>/scripts/some-script.sh
   • cp ~/Documents/<repo>/scripts/some-script.sh /tmp/
   • cat ~/Documents/<repo>/some-file.md
   • ls ~/Documents/<repo>/ (this also fails — entire dir is unreadable)
4. → All return Operation not permitted

Forensics

• Files written by Claude Code 2.1.132 carry com.apple.provenance xattr (11 bytes)
• Parent directories also gain com.apple.macl xattr (72 bytes = 4 × 16-byte UUIDs)
• One of those UUIDs is Anthropic's app bundle; user's Terminal/iTerm2 bundles are NOT in the list
• macOS Tahoe enforces macl as an exclusive-access-list for files under ~/Documents/, ~/Desktop/, ~/Downloads/ — this enforcement appears to be NEW or STRICTER in Tahoe vs Sequoia
• Both xattrs are SIP-protected: xattr -dreturns exit 0 but the xattr persists
• Files outside ~/Documents/ (e.g. ~/<repo>/) are NOT enforcement-blocked even when they carry the same xattrs — Tahoe only enforces in the protected user folders
• No Anthropic Endpoint Security extension is registered (systemextensionsctl list) — the stamping is performed inline by Claude's own writer code path, not a separate ES daemon

xattr inventory on a typical affected file:

``` $ /bin/ls -leO@ ~/Documents/some-repo/scripts/some-script.sh -rwxr-xr-x@ 1 jj staff - 5805 May 2 18:27 ... com.apple.provenance 11 ```

xattr inventory on the parent dir:

``` $ /bin/ls -ldeO@ ~/Documents/some-repo drwxr-xr-x@ 14 jj staff - 448 May 2 19:34 ... com.apple.macl 72 com.apple.provenance 11 ```

What's not the cause

• Not an OS update — softwareupdate --history shows last entry 2026-04-09 (26.4.1)
• Not a TCC database issue — ~/Library/Application Support/com.apple.TCC/TCC.db shows iTerm2 and Terminal.app both have kTCCServiceSystemPolicyDocumentsFolder = 2 (allowed)
• Not a quarantine flag — com.apple.quarantine is not present
• Not an ACL — chmod -N would be unblocked but file has no ACL (/bin/ls -le shows no +)
• Not an chflags flag — flags=- (no schg/uchg/restricted)
• Not file ownership — file is uid=502 jj:staff (the user)
• Not a missing FDA grant — verified, both terminals have it
• Reverting ~/.local/bin/claude symlink to 2.1.128 doesn't help because Claude Desktop 1.6259.1 (com.anthropic.claudefordesktop) is the actual writer when running through Claude Code Desktop entrypoint (CLAUDE_CODE_ENTRYPOINT=claude-desktop)

Workaround

Move repos out of ~/Documents/ into ~/<repo>/. Tahoe doesn't enforce TCC stamps in the home root. Files Claude Code writes in ~/<repo>/ still carry the xattrs but aren't blocked from other apps' reads.

This is what I had to do today to update production servers (bash ~/Documents/some-repo/scripts/update-server.sh failed; bash ~/<same-repo-cloned-to-home>/scripts/update-server.sh worked). Lost ~30 minutes diagnosing and re-cloning.

Why this matters

The Claude Code "edit a file in my project" flow is broken for users who keep projects in ~/Documents/. After Claude Code edits any file:

• Other dev tools can no longer read the file (build scripts fail, IDEs report read errors, CI runners fail)
• Pasted shell commands from Claude Code's output (e.g. bash <path>) fail with cryptic "Operation not permitted"
• Even copying the file to /tmp/ for inspection fails

There's no in-app indication that this is happening. The user only sees the failure when their other tools try to read the touched files.

Suggested fixes

Any one of these would resolve:

1. Don't stamp com.apple.provenance on writes. It's not required for Claude Code's functionality. Most CLI tools (git, vim, bash heredoc redirection, etc.) don't stamp it; their writes are equally readable to the rest of the system.
2. Provide an opt-out: CLAUDE_CODE_DISABLE_PROVENANCE_STAMPING=1 env var, or a ~/.claude/settings.json flag.
3. Don't claim parent-dir com.apple.macl ownership. macl is meant for app-private file ownership (pasteboard items, document-scoped state); it's the wrong primitive for general-purpose file editing.
4. Use a less-restrictive write path: equivalent of NSURLFileNoTrackingKey, or write via O_NOFOLLOW with explicit non-tagged FD.

The 2.1.128 → 2.1.132 diff would show what changed; this regression is recent.

Reproducibility offer

Happy to provide more diagnostic data — full xattr binary dumps via xattr -px, TCC.db row dumps, sysdiagnose snippets, before/after of the same file written by 2.1.128 vs 2.1.132 (if I can get the 2.1.128 binary back), etc. Mention what would be useful.

Severity

For users with projects in ~/Documents/: breaks the basic edit-then-run loop — bash/cp/cat all fail on Claude Code-touched files. Workaround exists (move repos to ~/) but it's a real disruption to existing workflows. I had operator runbooks, scripts, and a swarm of production deploy tooling all in ~/Documents/Jeeves/ and now none of it is reachable from my normal terminal.

Filed by a long-time Claude Code user; happy to test patches.