[Bug] interactive TUI crashes with "An internal error occurred (EPERM)" when CWD is inside iCloud-synced ~/Documents (macOS)

Bug: interactive TUI crashes with "An internal error occurred (EPERM)" when CWD is inside iCloud-synced ~/Documents (macOS)

Summary

On macOS, an interactive claude session crashes immediately at startup with
error: An internal error occurred (EPERM) whenever the working directory is
anywhere inside ~/Documents while iCloud "Desktop & Documents Folders" sync is
enabled (~/Documents is a firmlink onto a separate APFS/CloudDocs volume). It
crashes before the folder-trust prompt and before --debug writes any log.
Headless (claude -p) is unaffected; any non-~/Documents cwd is unaffected.

Environment

• Claude Code 2.1.181 (Homebrew cask, arm64) — also the latest brew offers
• macOS 26.5.1 (build 25F80), Apple Silicon (M1)
• iCloud Drive → Desktop & Documents Folders sync: ON (~/Documents is a firmlink

to a separate APFS volume, disk3s5)

Reproduction (deterministic)

1. iCloud "Desktop & Documents Folders" sync ON.
2. mkdir -p ~/Documents/cc-eperm-test && cd ~/Documents/cc-eperm-test
3. claude

→ Immediately prints error: An internal error occurred (EPERM) and exits. The
trust prompt and TUI never render. Reproduces in a brand-new empty folder.

These all work (same machine, same binary, same moment):

• cd /private/tmp/x && claude → normal trust prompt + TUI
• cd ~ && claude → normal
• cd ~/Documents/anything && claude -p "hi" → normal (headless)
• cd ~ && claude --add-dir ~/Documents/Cowork\ OS → normal (Documents dir added, not cwd)

Expected vs actual

• Expected: interactive claude starts regardless of whether cwd is inside

iCloud-synced ~/Documents (it did until ~2026-06-27).

• Actual: immediate EPERM crash before the trust prompt.

Scoping — already ruled out

• Not cwd content: an empty, brand-new ~/Documents folder reproduces it.
• Not permissions/TCC: process has Full Disk Access; no TCC denial in the unified

log (subsystem com.apple.TCC) and no sandbox denial logged at crash time.

• Not headless: claude -p in the same dir works.
• Not the shell/launcher: reproduces from a plain login shell, from tmux, and

from a bare script pty.

• Not git / symlinks / dataless-iCloud files: empty dir has none of these.
• Not resources: ~370 procs vs maxprocperuid 2666; fds/ports fine; no lock contention.
• Not a toggleable feature: still crashes with every CLAUDE_CODE_DISABLE_* I could

find set at once (auto_memory, memory_bulk_inflate, memory_periodic_resync,
file_checkpointing, background_tasks, workflows, artifact, agent_view,
bundled_skills, claude_mds, cron, virtual_scroll, nonessential_traffic) plus
CLAUDE_CODE_AUTO_CONNECT_IDE=0.

• Timing: crashes before --debug creates its log file (no ~/.claude/debug/*.txt

is produced for the crash) → extremely early interactive init, before the trust gate.

Likely a server-side flag rollout, not the binary

The exact same binary (2.1.181) worked on 2026-06-27 and broke on 2026-06-28 with
no update. A long-running interactive session started before the change is still
healthy. Points to a server-delivered flag enabling an early-interactive-init
filesystem op on the cwd that returns EPERM on the iCloud firmlink path (e.g.
clonefile/realpath/getattrlist, or a sandbox profile referencing the cwd).
Headless and --add-dir (non-cwd) paths don't hit it. Likely also affects
~/Desktop (the other synced folder) — not separately verified.

Workaround in use

Launch from a non-~/Documents cwd and add the Documents project via --add-dir,
with CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 so the added project's
CLAUDE.md still loads.