Tahoe regression #57024 expands: Claude Code's macl stamping now poisons sibling tool dirs (Cline) via parent propagation, breaking multi-harness backup pipelines

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?

Filing as a follow-up to #57024. The original report is open and unaddressed. This issue documents a second confirmed victim and a worse-than-expected propagation pattern, plus the workflow damage it is now actively causing.

Claude Code (CLI 2.1.132 / Desktop 1.6259.1) writes to files under ~/Documents/ in a way that triggers macOS's sandbox-aware macl-claim tracking, adding Claude Code's bundle UUIDs to com.apple.macl on the affected directories — and propagating that claim up to ancestor directories Claude Code never directly wrote to. macOS Tahoe (26.4.1) then enforces the macl ACL and silently locks every other process on the system out of those paths.

This is no longer a Claude-Code-edits-Claude-files problem. It is a Claude-Code-touches-anything-near-~/Documents/-and-the-whole-folder-becomes-Claude's problem. It is wrecking my daily backup pipeline and any non-Anthropic agentic coding harness (Cline, Cursor, etc.) whose config tree lives in ~/Documents/.

Note on terminology / cause-effect chain. Claude Code is almost certainly not calling setxattr() directly for com.apple.macl. The likely chain is: Claude Code's writer uses a macOS Foundation file-write API (NSFileManager, NSURL writeToURL:, etc.) → macOS's framework code sets the macl as part of sandbox-aware tracking → macl claim accumulates on the parent directory → Tahoe enforces it. The trigger is still Claude Code's write path. 2.1.128 did not cause this. 2.1.132 does. Whatever changed in Claude Code's write path between those two releases is the trigger, regardless of which Foundation entry-point ultimately performs the setxattr. Please don't get hung up on whether Claude Code is "the one stamping" — the OS is doing the literal write; Claude Code is what brought the write path into being.

What Should Happen?

A Claude Code write into a single subdir of ~/Documents/<harness>/<subdir>/ should not propagate com.apple.macl claims onto the parent ~/Documents/<harness>/ directory. The write should leave sibling subdirectories — and the parent itself — readable to every other process holding the relevant FDA + TCC grants. As of pre-1.6259.1 Desktop / 2.1.128 CLI, this was the behaviour.

Error Messages/Logs

Daily rsync backup from ~/Documents/Cline/ → backup repo, run from iTerm2:

rsync(22139): error: open /Users/jj/Documents/Cline/: Operation not permitted

This is the iTerm2 process being denied open() on a directory that I own, that iTerm2 has Full Disk Access for, that macOS TCC explicitly grants Documents access to (kTCCServiceSystemPolicyDocumentsFolder = 2), and that Claude Code never directly wrote to.

Steps to Reproduce

1. On macOS Tahoe, install Claude Code 2.1.132 / Claude Desktop 1.6259.1
2. Have any sibling tool's config tree at ~/Documents/<tool>/ (Cline, Cursor, anything)
3. Use Claude Code to write or edit any file in any subdirectory of ~/Documents/<tool>/
4. From iTerm2 / Terminal / any non-Anthropic-bundle process, run rsync -a ~/Documents/<tool>/ /tmp/test/ or ls ~/Documents/<tool>/
5. Observe Operation not permitted on a directory that you own, that has FDA, and that has TCC Documents-folder grant

The directory is now Anthropic's, not yours.

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) — auto-installed 2026-05-07 ~08:20. Note the actual writer process for this regression is Claude Desktop 1.6259.1, not the CLI.

Platform

Anthropic API

Operating System

macOS 26.4.1 (build 25E253), Darwin 25.4.0 ARM64 — M4 MacBook Air. No macOS update since 2026-04-09 — this is purely an Anthropic-side regression.

Terminal/Shell

iTerm2 (also reproduces in Apple Terminal.app); shell tested: zsh. Both have FDA + Documents-folder TCC grant verified (tccutil shows kTCCServiceSystemPolicyDocumentsFolder = 2).

Additional Information

Forensics

$ /bin/ls -la@ /Users/jj/Documents/Cline | head
total 24
drwxr-xr-x@ 10 jj  staff    320 Mar 24 17:28 .
	com.apple.macl	  288
drwx------@ 53 jj  staff   1696 Apr 19 12:51 ..
	com.apple.macl	  144
-rw-r--r--@  1 jj  staff  10244 Apr 11 18:46 .DS_Store
	com.apple.FinderInfo	   32
drwxr-xr-x@  4 jj  staff    128 Feb 24 23:44 .groupcode
	com.apple.provenance	   11

• ~/Documents/Cline/ parent dir: com.apple.macl = 288 bytes = 18 bundle UUIDs
• The only Claude-touched child is .groupcode/, which received com.apple.provenance after Claude Code wrote into it
• iTerm2's bundle UUID is not in the parent's macl list → all iTerm2-initiated reads on ~/Documents/Cline/ fail with EPERM, despite FDA + Documents grant
• Same mechanism documented in #57024 — but here, Claude Code never edited a single file in Cline/. It only wrote inside one descendant subdirectory, and the macl propagated up to the parent, taking the entire Cline configuration tree hostage.

This is the new failure mode: macl propagation is upward and lateral. Touching ~/Documents/Cline/.groupcode/anything poisoned ~/Documents/Cline/ for every other process in my entire system.

Sweep across ~/Documents/ shows the contagion pattern:

| Subdir | macl size | provenance | Status |
|---|---|---|---|
| Cline/ | 288 B | 0 | Broken — iTerm2/rsync blocked |
| Jeeves/ (a Claude-Code-driven project tree, not a harness) | 20 B | 3 B | Broken — already documented in #57024 |
| Cursor/ | 0 | 0 | OK (Claude Code hasn't touched it) |
| Antigravity/ | 0 | 0 | OK |
| Kiro/ | 0 | 0 | OK |
| Copilot/ | 0 | 0 | OK |
| AI-Toolkit/ | 0 | 0 | OK |

It is purely a function of whether Claude Code has written anywhere inside that subtree. Once it has, that subtree is gone from the rest of the system.

xattr -d is theatre

$ xattr -d com.apple.macl /Users/jj/Documents/Cline
$ echo $?
0
$ /bin/ls -la@ /Users/jj/Documents/Cline | head -3
drwxr-xr-x@ 10 jj  staff    320 Mar 24 17:28 .
	com.apple.macl	   72
	com.apple.provenance	   11

Returned 0. Macl shrank 288 → 72 bytes. And com.apple.provenance got freshly added during the strip operation itself — the strip ran from inside a Claude Code session, and Claude Code's write path re-triggered the OS-level macl/provenance set during the very operation meant to clear it. Any subsequent Claude Code write to the same subtree re-triggers the claim. SIP prevents stripping the xattrs from outside Claude Code's bundle; from inside, Claude Code's write path re-triggers the macl set during the strip. Catch-22.

Workflow damage

This is not a niche edge case. It is breaking the standard developer setup of "I use multiple AI coding harnesses side-by-side and back them up nightly":

1. Daily rsync backup is dead for any ~/Documents/ subtree Claude Code has ever touched. My daily backup repo is the canonical archive of every tool's config, rules, skills, and workflows. It used to run cleanly nightly. Now it errors on Cline and Jeeves and silently desyncs the rest of the world from those subtrees.

1. Multi-harness coexistence is broken. I use Claude Code alongside Cline, Cursor, Antigravity, Kiro, Copilot, and a few other agentic coding harnesses — most of which keep their config trees under ~/Documents/<harness>/. The expectation is that these tools coexist peacefully there with my normal shell, editor, backup tooling, and git. Claude Code's write path is making a sandbox-style macl claim on every subtree it writes to, and macOS Tahoe's enforcement of those claims excludes every other process — including the user's own shell — from those paths. No other Anthropic tool, no other AI coding tool, and no Apple guidance suggests any app should behave this way. Apps don't get to revoke the user's own shell from reading the user's own files.

1. Cross-harness file sharing is broken. I keep shared rule sets and prompt libraries under ~/Documents/ so Claude Code, Cline, Cursor, etc. can all read them. The moment Claude Code touches one, everyone else loses read access via their normal CLI. The "fix" — move everything out of ~/Documents/ — is asking every other tool I use to follow Claude Code into exile because Claude Code can't share a directory.

1. The blast radius keeps growing. #57024 documented direct writes. This issue documents writes-near. Today it's ~/Documents/Cline/ because of .groupcode/. Tomorrow it'll be the next harness whose parent dir Claude Code has any reason to operate adjacent to. There is no way for me to predict which subtree gets nuked next, because the propagation rules aren't documented and I have no way to opt out.

1. The workaround is migration debt. Per #57024, I've already had to migrate one affected project tree out of ~/Documents/ into ~/. Now I have to do the same for Cline. Cursor, Antigravity, Kiro, Copilot are next as soon as Claude Code touches anywhere in their trees. I am being asked to redesign my entire ~/Documents/ layout because of one Anthropic tool's xattr behaviour. This is unacceptable for a CLI that bills itself as a developer-friendly coding assistant.

1. Silent corruption. The failures are silent unless you happen to run a process that errors loudly (rsync, find with -delete, etc.). Editors, shells, language servers, language runtimes, build tools — many will swallow the EPERM as "file not found" and you won't notice until something downstream is wrong. I shudder to think what other workflows are silently desyncing right now.

Asks

1. Change Claude Code's write path so it stops triggering macOS's sandbox-aware macl-claim tracking on user files in ~/Documents/. Whatever Foundation API or sandbox configuration changed between 2.1.128 (worked fine) and 2.1.132 (this) is the regression surface. No other Anthropic product does this. No other major AI coding tool does this. The ~/Documents/ TCC enforcement is for app sandboxes and document-vending apps, not for general-purpose developer CLI tools. Claude Code is the latter — and if Claude Code's runtime really needs a sandbox claim on the files it writes, that claim should extend to the user's other FDA-granted apps (Terminal, iTerm2, the user's editor, the user's backup tool), or be opt-in rather than always-on.

1. If there is a security rationale, document it and make it opt-in. Right now it's invisible, undocumented, retroactively destructive, and impossible to disable. At minimum users need a disable-document-acl setting, and probably also a claude xattr-clean <path> command that actually clears them (using whatever bundle privilege Claude has).

1. Do not let macl claims propagate up to parent directories from descendant writes. That is the single most damaging behaviour pattern documented above. If the macOS sandbox-tracking mechanism must record a macl claim on the file Claude Code writes, fine — confine it to that file. Don't let the claim propagate to the ancestor chain. Whatever in Claude Code's write path is causing that propagation (sandbox container shape, working-directory configuration, an enclosing-folder permission grant, etc.) is what needs to change.

1. Acknowledge #57024. It has been open since this morning with full forensics, no triage label, no Anthropic response. This regression is actively breaking real workflows. It deserves attention.

1. Provide a path back for already-poisoned directories that does not require disabling SIP, booting Recovery, or moving every config tree out of ~/Documents/. Even something like "next Claude Code release will run an xattr cleanup pass on ~/Documents on first launch" would be vastly better than the current "live with it forever" state.

Cross-references

#57024 (original Tahoe regression report).