macOS Tahoe 26.4: third-party app stamps com.apple.macl on files in ~/Documents, blocks Terminal/iTerm2 reads despite Full Disk Access

Question

macOS Tahoe 26.4: third-party app stamps com.apple.macl on files in ~/Documents, blocks Terminal/iTerm2 reads despite Full Disk Access

I'd like to confirm whether this is intended behavior in macOS Tahoe, and ask if there's any user-facing way to override it without disabling SIP.

What's happening:

I have a developer tool (a third-party Mac app) that edits files in folders I keep under ~/Documents/. After a recent update of that app, every file it writes — and every directory it operates inside — becomes unreadable from my own Terminal.app and iTerm2.

The terminals can't even list the directory:

$ ls ~/Documents/MyProject/
ls: ~/Documents/MyProject/: Operation not permitted
$ cat ~/Documents/MyProject/some-file.md
cat: ~/Documents/MyProject/some-file.md: Operation not permitted
$ cp ~/Documents/MyProject/script.sh /tmp/
cp: ~/Documents/MyProject/script.sh: Operation not permitted

What I've already verified:

Both Terminal.app and iTerm2 have Full Disk Access, granted via System Settings → Privacy & Security → Full Disk Access. The toggles are on.
Both also have explicit Documents Folder access under System Settings → Privacy & Security → Files & Folders. Confirmed via the TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) — kTCCServiceSystemPolicyDocumentsFolder shows auth_value = 2 (allowed) for both com.apple.Terminal and com.googlecode.iterm2.
The user that owns the files is me (uid 502, jj:staff), with mode -rwxr-xr-x. No restrictive ACL (/bin/ls -le shows no +), no chflags (stat shows flags=-).
csrutil status = SIP enabled. (I'm not interested in disabling SIP just to fix this.)
No macOS update happened between when this worked and when it broke — softwareupdate --history shows my last update was 2026-04-09 to 26.4.1. The breakage corresponds to a third-party app update, not an OS update.
Files outside ~/Documents/ — for example, identical files in ~/MyProject/ (in my home root, not under Documents) — are NOT blocked. iTerm2 reads them fine. So the enforcement is specifically scoped to ~/Documents/, ~/Desktop/, ~/Downloads/.

What I think is happening:

When the third-party app writes files, it stamps two extended attributes:

com.apple.provenance (11 bytes) on each written file
com.apple.macl (72 bytes — looks like 4 × 16-byte UUIDs identifying app bundles) on the parent directory

/bin/ls -leO@ on an affected dir confirms:

drwxr-xr-x@ 14 jj  staff  -  448 ...
    com.apple.macl	  72 
    com.apple.provenance	  11

The third-party app's bundle is in the macl list. Terminal.app's and iTerm2's bundles are NOT. Tahoe appears to be enforcing com.apple.macl as an exclusive-access list under the protected user folders — even when the user has explicitly granted Full Disk Access AND the per-folder grant for the protected folders to those other apps.

In other words: if any app in the macl list has stamped a parent dir under ~/Documents/, no other app gets in, regardless of the TCC grants the user has set. That's a much stricter behavior than I remember on macOS Sequoia 15.x — same xattrs existed there but FDA grants seemed to override.

Please find attached a more complete reporting (hit up against the word limit).

Overly aggressive com.apple.macl issues.log

MacBook Air 15″, macOS 26.4

Posted on May 7, 2026 8:37 AM

Reply

Answer 1

Top-ranking reply

TomCruiseMissile Author

Level 1

14 points

May 7, 2026 10:15 AM in response to etresoft

Thanks for the follow-up. Three things to ponder on:

The "Apple-owned special folders" map. Useful explicit list: ~/Documents, ~/Desktop, ~/Downloads, ~/Library/Containers, ~/Library/Group Containers. I'd already migrated the affected repo to ~/<repo>/ before posting here (it was the only path that immediately unblocked the morning's work), so the practical fix matches your suggestion. The broader rule you're framing — "Apple has additional system-level enforcement on these four/five user-accessible-but-special directories beyond what TCC alone does — don't put dev workflows in any of them" — is a good rule of thumb.
OS-changes-behind-your-back caveat. Fair point. I don't have proof the OS didn't shift between when this worked and when it broke — softwareupdate --history is the best I can see, but background rapid security responses or non-version-bump component updates wouldn't show there. So the "26.4 → 26.4.1 fix that broke a third-party workaround" scenario is plausible, even if I can't easily verify it from outside.
The "Claude Code's own sandbox" hypothesis is interesting and worth checking. Possibly relevant data: Claude Code's process exposes env vars like CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST=1, CLAUDE_AGENT_SDK_VERSION=..., and CLAUDE_CODE_ENTRYPOINT=claude-desktop — suggesting it has its own SDK/host model with sandboxing concepts. No registered Endpoint Security extension (systemextensionsctl list shows only Tailscale's), so if there's sandboxing it's app-internal not system-level. The idea that the app's sandbox claims a macl entry on file writes — and that this collaterally excludes Terminal/iTerm2 from access to those same paths — fits the observed behavior. If that's the mechanism, the right ask of Anthropic would be: "your sandbox claim should extend to the user's other FDA-granted apps, or be opt-in rather than always-on."

So... net practical answer for me: Avoid the special folders for any path Claude Code touches. Already done for the affected repo. Going forward I'll keep all Anthropic-touched repos in ~/<name>/ style (at least until/if they "fix" this upstream). The sandbox-related framing was a useful concrete model — appreciated.

Reply

Answer 2

May 7, 2026 9:22 AM in response to etresoft

Thanks for the careful read. A few clarifications, then I'll concede where you're right.

The mystery app is Claude Code (Anthropic). I've already filed a detailed bug there: https://github.com/anthropics/claude-code/issues/57024 — full forensics, exact version that introduced the regression (2.1.132, auto-installed 2026-05-07; the prior 2.1.128 worked fine), and the diff symptoms. So the third-party developer is on the hook for it — that part isn't in dispute.

On com.apple.* xattrs being Apple's, not the app's: fair point, and I think you're right. The app isn't directly calling setxattr() for com.apple.macl — it's almost certainly that one of the macOS Foundation file-write APIs the app calls (NSFileManager, NSURL writeToURL:, etc.) triggers macOS's own framework code to set the macl as part of the sandbox-aware tracking. So "stamping" is a sloppy phrase on my part — more accurate is "the app's writes trigger Apple's stamping mechanism." But the cause-effect chain still ends at the app's behavior change, since the OS hadn't moved between working and broken state.

On the iCloud Documents angle: good general advice, but in my case Documents is not iCloud-managed (brctl confirms no kFileProvider activity, no ~/Library/Mobile Documents symlink, no sync state). The folder is local-only on this machine. iCloud isn't the variable.

On "is OS version a red herring": maybe — I don't have a Sequoia machine handy to A/B against. The reason I framed it as a Tahoe question is that the same xattrs (per xattr -l on cached copies of older files) existed on this machine pre-Tahoe-update, but the access denial only started showing up with the recent app update on Tahoe 26.4.1. It could be that Tahoe always enforced this and it's purely the app's new write path that triggers it; that would still be the app's problem. The user-visible question (is there a way to inspect/edit the macl claim list?) is what I was hoping to surface here.

On "delete the offending app": unfortunately not feasible — it's a daily-driver dev tool. The right resolution is the app's developer fixing the write path (filed) plus, if it's possible, an OS-level mechanism to inspect macl. If macl really is purely an Apple-internal implementation detail with no user-facing surface, that's its own kind of answer — not a satisfying one, but useful to know.

Appreciate the engagement.

Reply

Answer 3

May 7, 2026 1:30 PM in response to etresoft

Thanks for the follow-up!

A few notes for the record (a tad pedantic, but) since this thread is likely to be the first hit when someone else runs into this:

Bash vs Zsh → That's right. macOS has defaulted to zsh since Catalina (2019). That's also my interactive shell here. The reason bash shows up in my repros is that the affected scripts target Linux VMs (Ubuntu 24.04 OCI instances) I SSH into from this Mac. They're written with #!/bin/bash shebangs because bash is canonical on the Linux side, and I invoke them locally via bash <path> to match how they execute on the remote. So bash is just the script interpreter for that cross-platform toolchain.

On the xattr "stamping" terminology: fair point!

The com.apple.* xattr details are implementation detail and aren't load-bearing for the user-side fix.

For future readers on the Seatbelt mechanism:

To flesh out the picture a bit, Seatbelt isn't a kernel extension in the modern sense → it's the userspace name for the TrustedBSD MAC framework that ships in the XNU kernel itself.

Userland API is sandbox_init(), CLI is sandbox-exec.

Any process can sandbox itself or spawn a sandboxed child without a system-level user-approval prompt.

So Claude Code's /sandbox slash command can enable it from inside the app without showing a Settings → Privacy & Security toggle.

Anthropic's official docs name Seatbelt explicitly: https://code.claude.com/docs/en/sandboxing

And the third-party write-up you found (https://www.infralovers.com/blog/2026-02-15-sandboxing-claude-code-macos/) covers the same ground.

On the sandbox-exec deprecation note:

That's a real concern even outside the current issue. Apple's man page flags sandbox-exec as Apple System Private Interface that may change without notice.

The third-party blog above puts it well: "It still works today, and Anthropic's runtime depends on it, but it's a long-term uncertainty for any tooling built on top of it."

I'll mention it on the GitHub issue as a maintenance concern for Anthropic to weigh, separate from the immediate regression.

The conceptual point you raised → "Claude Code's use of it seems to be the opposite of how it was designed... It should be the other way around. The AI is the dangerous part" = the most useful framing I've seen in this whole investigation.

macOS sandboxing is designed to reduce a sandboxed process's privileges, not grant it exclusive ownership of the paths it touches.

If the com.apple.macl claim being set on Claude-Code-touched directories is being treated by Tahoe as an exclusive-access list, the semantics are inverted: the less-trusted AI process gets exclusive access, the user's other (more trusted) apps are excluded.

That's a much cleaner way to describe what's going wrong than my earlier "stamping" language.

I'll cross-link that framing into the GitHub issue.

The proximal bug is on Anthropic's side → their writer's behaviour change between 2.1.128 and 2.1.132 is what triggered the regression, and they're best placed to fix it.

But the inverted-semantics observation is worth Apple knowing about too, in case the macl-as-exclusive-access enforcement at the OS level is intended to gate access for sandboxed processes only and is incorrectly extending to non-sandboxed tools (like the Edit/Write file tools, per Anthropic's own doc) that share the same app bundle.

Psst! If anyone from either team (Anthropic/Apple) is reading this thread, the fix on either side would resolve it.

Reply

Answer 4

leroydouglas

Level 10

202,764 points

May 7, 2026 9:20 AM in response to TomCruiseMissile

I never installed or used your third party iTerm

Have you searched iTerm support—if in doubt search the developers website or contact their: Support/Help/FAQ/Known issues/compatibility/updates…

ref: https://iterm2.com/help/#/section/home

https://iterm2.com/downloads.html

I would uninstall the the third party app and compare your results

no issue here with the Terminal.app in macOS Tahoe

ls ~/Documents/

if you have it narrowed down to some macOS bug—

To be proactive you can file a bug report / submit your Apple Feedback here:

Feedback - macOS - Apple

Reply

Answer 5

May 7, 2026 9:17 AM in response to leroydouglas

Thanks for the reply. Two clarifications since both might affect what you'd want to test:

It's not iTerm2-specific. The same Operation not permitted shows up from Terminal.app for me too — both have FDA + Documents-folder grants and both fail identically on the affected subfolder. iTerm2 was just the one in my use case. If you want to repro from Terminal.app, the steps are the same.
ls ~/Documents/ will succeed for you — that level isn't where the macl gets stamped. The block only manifests inside a subfolder that has been written to by an app that stamps com.apple.macl. A bare ~/Documents/ (untouched by such an app) reads normally, exactly as you saw.

To reproduce: install any of the third-party Mac apps that stamp com.apple.macl on user-folder writes, have it write a file into ~/Documents/<some-subfolder>/, then from Terminal.app try ls ~/Documents/<that-subfolder>/.

The ls will fail with Operation not permitted. If you compare the dir's xattrs (/bin/ls -ldeO@) before/after the app touches it, you'll see com.apple.macl appear, and that's the gate.

The reason I'm asking the community is that this enforcement appears stricter on Tahoe than on Sequoia — same xattrs, same FDA grants, different outcome.

Curious whether anyone has hit it with a different app, or whether there's an Apple-side mechanism to inspect/edit the macl claim list without disabling SIP.

The third-party developer's behaviour is its own bug; the Tahoe-side enforcement strictness is the part I'd really like to confirm or rule out.

Reply

Answer 6

etresoft

Level 9

57,972 points

May 7, 2026 10:03 AM in response to TomCruiseMissile

TomCruiseMissile wrote:

The mystery app is Claude Code (Anthropic).

Thanks! Disappointing though. I could have downloaded and inspected anything else. Ain't touching that thing.

I've already filed a detailed bug there: https://github.com/anthropics/claude-code/issues/57024

Thanks for that too. It's easier to read. This site is having some "issues" right now. Some have speculated that the cause of those issues might be AI-written code.

So "stamping" is a sloppy phrase on my part — more accurate is "the app's writes trigger Apple's stamping mechanism."

Perhaps the biggest risk with that terminology, or especially with prematurely digging into those implementation-detail rabbit holes, is that people love rabbit holes. You're likely to get replies both here and in GitHub that focus on those. Certain parts of the Apple social media world are obsessed with Apple implementation details.

But the cause-effect chain still ends at the app's behavior change, since the OS hadn't moved between working and broken state.

Maybe. Maybe not. These days, the OS can change pretty rapidly, even behind your back. A perfectly plausible scenario is that this was a change made for an OS bug introduced in 26.4, which then got "fixed" in 26.4.1, which broke the original 3rd party workaround.

On the iCloud Documents angle: good general advice, but in my case Documents is not iCloud-managed (brctl confirms no kFileProvider activity, no ~/Library/Mobile Documents symlink, no sync state). The folder is local-only on this machine. iCloud isn't the variable.

iCloud is sill a variable. Any folder with OS-level controls is risky for use in any developer capacity. Offhand, I can think of Documents, Desktop, Downloads, ~/Library/Containers, and ~/Library/Group Containers. Never let any developer tool such as git, Docker, Xcode, anything touch any of those for any reason. (Obviously running apps will use the containers, but never, ever poke into them. The only exception would be if this is an app that you developed. Then you know what it's doing in a container folder.) But that sidebar is just for the containers folders. The other folders should be avoided for other reasons. And it's not just iCloud. They have additional system-level security layers on them.

On "delete the offending app": unfortunately not feasible — it's a daily-driver dev tool. The right resolution is the app's developer fixing the write path (filed) plus, if it's possible, an OS-level mechanism to inspect macl. If macl really is purely an Apple-internal implementation detail with no user-facing surface, that's its own kind of answer — not a satisfying one, but useful to know.

It appears to be related to Claude Code's own sandbox functionality. I don't know how any of that is implemented. But it might even be the case where Claude is applying its only sandbox to command line tools and purposefully disallowing itself access to these special folders. But because Claude has put its tendrils Borg-like into the OS, you're seeing the effects in Terminal. (iTerm2 being yet another 3rd party tool to discount.) I don't know if they're doing this à la Homebrew with PATH, or by hacking around with OS-layer sandboxing capabilities. I suspect it's the latter.

I think if you just avoid those special folders, you should avoid the problem. Although you might have to perform some level of app/system reset to get there.

Reply

Answer 7

etresoft

Level 9

57,972 points

May 7, 2026 10:26 AM in response to TomCruiseMissile

I saw the sandbox mentioned in a different Github issue when I searched for something similar to your post. That took me to this page: https://code.claude.com/docs/en/sandboxing

It's using some kind of "seatbelt" framework. That's all I know.

Reply

Answer 8

May 7, 2026 8:38 AM in response to TomCruiseMissile

Looks like the attachment got chewed up. Here's the rest of my original post content:

In other words: if any app in the macl list has stamped a parent dir under ~/Documents/, no other app gets in, regardless of the TCC grants the user has set. That's a much stricter behavior than I remember on macOS Sequoia 15.x — same xattrs existed there but FDA grants seemed to override.

Why this is a real problem:

Both xattrs are SIP-protected. From user space:

$ xattr -d com.apple.macl ~/Documents/MyProject/
$ # exits 0, but the xattr persists on the next ls -leO@

So the user can't strip them. And the third-party app re-stamps them on every write.

The only workarounds I've found:

Move the affected work out of ~/Documents/ (e.g. to ~/MyProject/ in the home root). Tahoe doesn't enforce macl outside the protected user folders. This works but it means I have to abandon the ~/Documents/ location I've used for years for project work.
Roll back the third-party app to a prior version that didn't stamp aggressively. Difficult because the app auto-updates and there's no public archive of older versions.
Disable SIP. Hard no.

My questions:

Is the strict macl enforcement under ~/Documents//~/Desktop//~/Downloads/ intentional in Tahoe? It does feel like a sensible security posture in the abstract, but in practice it means a single misbehaving app can lock the user out of their own files via every other app the user has installed.
Is there any user-facing mechanism to inspect or edit com.apple.macl? Something like the existing TCC pane in System Settings, where I can see "files in this folder are claimed by App X; also allow App Y / Z to read them." If not, this seems like a feature gap.
Has anyone else hit this? I'd appreciate any pointers, especially if there's a fix path that doesn't require rolling back the third-party app or moving my files.

For transparency: I've already filed an issue with the third-party app's developer — they're the proximal cause and need to stop stamping macl under ~/Documents/ for normal user-edit operations. But the Tahoe-side enforcement is the part I'd like Apple's perspective on.

Thanks in advance for any insights.

My setup:

macOS Tahoe 26.4.1 (build 25E253)
Apple Silicon, MacBook Air M4
iTerm2 + Terminal.app — both with FDA + Documents Folder TCC grants
Issue began after a third-party developer-tool app auto-updated (May 2026)
Last working state: same OS, prior version of the third-party app, ~2 weeks ago

Reply

Answer 9

etresoft

Level 9

57,972 points

May 7, 2026 9:16 AM in response to TomCruiseMissile

TomCruiseMissile wrote:

I have a developer tool (a third-party Mac app)

What tool is that?

After a recent update of that app, every file it writes — and every directory it operates inside — becomes unreadable from my own Terminal.app and iTerm2.

Sounds like a bug in the app.

Both Terminal.app and iTerm2 have Full Disk Access, granted via System Settings → Privacy & Security → Full Disk Access. The toggles are on.

It's 2026. Toggles mean nothing. I've seen multiple reports of apps claiming to have Full Disk Access but acting like they don't. There are many possible explanations. One possible explanation is a bug in Tahoe. However, just because a certain possibility exists doesn't mean that is guaranteed. Most likely, it's a bug is this mysterious developer tool. Such tools are known to do low-level, very naughty things.

2. Both also have explicit Documents Folder access under System Settings → Privacy & Security → Files & Folders. Confirmed via the TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) — kTCCServiceSystemPolicyDocumentsFolder shows auth_value = 2 (allowed) for both com.apple.Terminal and com.googlecode.iterm2.

That would be irrelevant if Full Disk Access is enabled.

3. The user that owns the files is me (uid 502, jj:staff), with mode -rwxr-xr-x. No restrictive ACL (/bin/ls -le shows no +), no chflags (stat shows flags=-).

Note that the Documents folder is special. By far, the most important aspect of this folder is that it is often managed by iCloud or some other cloud sync service. Any debugging efforts that look only at Documents is a total waste of your time.

4. csrutil status = SIP enabled. (I'm not interested in disabling SIP just to fix this.)

Some good news.

5. No macOS update happened between when this worked and when it broke — softwareupdate --history shows my last update was 2026-04-09 to 26.4.1. The breakage corresponds to a third-party app update, not an OS update.

Seems like a cause and effect relationship.

6. Files outside ~/Documents/ — for example, identical files in ~/MyProject/ (in my home root, not under Documents) — are NOT blocked. iTerm2 reads them fine. So the enforcement is specifically scoped to ~/Documents/, ~/Desktop/, ~/Downloads/.

No surprise there.

•

What I think is happening:

When the third-party app writes files, it stamps two extended attributes:

com.apple.provenance (11 bytes) on each written file

• com.apple.macl (72 bytes — looks like 4 × 16-byte UUIDs identifying app bundles) on the parent directory

/bin/ls -leO@ on an affected dir confirms:

drwxr-xr-x@ 14 jj staff - 448 ...

com.apple.macl 72

com.apple.provenance 11

The third-party app's bundle is in the macl list. Terminal.app's and iTerm2's bundles are NOT. Tahoe appears to be enforcing com.apple.macl as an exclusive-access list under the protected user folders — even when the user has explicitly granted Full Disk Access AND the per-folder grant for the protected folders to those other apps.

Anything having the sequence of characters "com.apple." should be considered an implementation detail. It could mean literally anything. There is no way anyone outside Apple can tell you how it works. They can guess. Their guess might appear to be correct in certain, limited situations. Next week, that all changes.

In other words: if any app in the macl list has stamped a parent dir under ~/Documents/, no other app gets in, regardless of the TCC grants the user has set. That's a much stricter behavior than I remember on macOS Sequoia 15.x — same xattrs existed there but FDA grants seemed to override.

Considering the fact that you've definitely identified the 3rd party app as the cause of the problem, I think the OS version is a red herring.

Please find attached a more complete reporting

I bet not 😄

All I can tell you at this point, within my own rapidly increasing character count, it that your mystery app isn't doing any "stamping". If it says "com.apple.", then it's Apple doing the stamping.

As is often the case, it seems like the easiest and fastest solution is to simply delete the offending 3rd party app.

Reply

Answer 10

etresoft

Level 9

57,972 points

May 7, 2026 12:47 PM in response to TomCruiseMissile

My previous advice also applies to you. Forget the "stamping". It's been used for years and is entirely irrelevant.

Also note that macOS hasn't used bash in years. I don't know if that document is using "bash" to mean any interactive shell, including zsh, or what. I also don't know which statements apply to which OS versions.

Supposedly, that seatbelt framework is some kind of low-level kernel extension. If so, it's not something that could be enabled by any kind of /sandbox command. If would be something installed that needed user approval. I know how those work on a Mac.

I did a few more checks and this post strongly suggests that the seatbelt framework is the direct cause of this problem. Apparently it's the "solution" to too many user-facing approval prompts. To quote the post:

on macOS it uses sandbox-exec (Apple's Seatbelt framework), on Linux it uses bubblewrap. Both restrict filesystem writes to the current working directory and filter network access through a proxy allowlist.

One thing worth noting: Apple marks sandbox-exec as deprecated in its man page. It still works today, and Anthropic's runtime depends on it, but it's a long-term uncertainty for any tooling built on top of it.

I'm not sure why they're calling it "seatbelt". Apparently that was some internal codename decades ago. It's just sandbox-exec and it's built into the operating system. And fundamentally, Claude Code's use of it seems to be the opposite of how it was designed. When you use Claude Code to access a given folder, that prevents the rest of the system from accessing it. It should be the other way around. The AI is the dangerous part.

Reply

Answer 11

May 7, 2026 10:44 AM in response to etresoft

Thanks for the clue:

https://code.claude.com/docs/en/sandboxing is the official doc and confirms macOS Seatbelt is the underlying framework. Two clarifiers it surfaces, though, that complicate the simple "Claude's sandbox is excluding other apps" theory:

Sandboxing is opt-in, enabled via the /sandbox slash command. I never ran it, so the Seatbelt profile isn't actually active in my session.
The doc explicitly says: "The sandbox isolates Bash subprocesses. Other tools operate under different boundaries: Built-in file tools (Read, Edit, and Write) use the permission system directly rather than running through the sandbox."

The files that ended up with com.apple.macl were written by the Edit/Write tools, not by sandboxed Bash subprocesses. So the macl stamping isn't coming from the Seatbelt sandbox — it's coming from however those file-edit tools perform their writes (presumably standard Cocoa NSFileManager / NSURL writeToURL: calls from the Claude.app process). Some change to that write path between 2.1.128 and 2.1.132 — or a change in app entitlements — is the more likely vector.

Useful narrowing either way. Thanks for the heads up!

Reply