macOS Tahoe: Claude Code 2.1.132+ writes block all non-Anthropic apps from reading files in ~/Documents (regression vs 2.1.128)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

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.

What Should Happen?

Claude Code's writes to files under ~/Documents/ (or any other Tahoe-protected user folder — ~/Desktop/, ~/Downloads/, ~/Library/Containers/, ~/Library/Group Containers/) should leave those files readable to other processes that hold the relevant FDA + TCC grants. As of 2.1.128 and earlier this was the case.

Error Messages/Logs

$ bash ~/Documents/<some-repo>/scripts/some-script.sh
bash: /Users/jj/Documents/<some-repo>/scripts/some-script.sh: Operation not permitted

$ cat ~/Documents/<some-repo>/some-file.md
cat: /Users/jj/Documents/<some-repo>/some-file.md: Operation not permitted

$ ls ~/Documents/<some-repo>/
ls: /Users/jj/Documents/<some-repo>/: Operation not permitted

Steps to Reproduce

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 mark the file)
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)

1. → All return Operation not permitted

Claude Model

Opus

Is this a regression?

Yes.

Last Working Version

Claude Code CLI 2.1.128 / Claude Desktop pre-1.6259.1. The 2.1.128 → 2.1.132 diff (or the corresponding Desktop change) is the regression surface.

Claude Code Version

2.1.132 (Claude Code) — ~/.local/share/claude/versions/2.1.132, mtime 2026-05-07 08:20. Note the actual writer process for this regression is Claude Desktop 1.6259.1 (com.anthropic.claudefordesktop, CLAUDE_CODE_ENTRYPOINT=claude-desktop), not the CLI.

Platform

Anthropic API

Operating System

macOS Tahoe 26.4.1 (build 25E253) — no OS update between working and broken state. Apple Silicon (M4).

Terminal/Shell

iTerm2 (also reproduces in Apple Terminal.app); shell tested: zsh. Both have FDA + Documents/Desktop/Downloads TCC grants verified via ~/Library/Application Support/com.apple.TCC/TCC.db.

Additional Information

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 -d returns 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 marking 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 a 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 marks 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. 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 apply 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 set 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.

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.

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. Ping me with what would be useful.

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