EPERM cascade on Read/Edit/FileHistory for session-created files in long-running autonomous sessions

Summary

After extended autonomous Claude Code sessions (multi-hour, multiple background sub-agents creating many files), the session enters a state where:

• FileHistory backup fails with EPERM: operation not permitted on copyfile for all files created during the session
• Read and Edit tools subsequently fail with the same EPERM on those same files
• The failures are consistent on a fixed set of files (those created/modified mid-session) and consistent across message-snapshot boundaries
• Files NOT touched by Claude Code during the session continue to read/write normally
• User-home ~/.claude/settings.json reads fine; project-local .claude/settings.json EPERMs

This is blocking a user's intended workflow of running longer-horizon (overnight, multi-day) autonomous agent chains on macOS.

Environment

• Claude Code CLI 2.1.150.583 (per debug log cc_version header)
• macOS host
• Model: claude-opus-4-7[1m] (1M context window)
• Project: regular git repo under ~/Documents/
• Session ID: 02df1c6c-4765-4d31-ba9d-2fc8ed2baf55
• Session duration at first EPERM: ~16+ hours, ~60 git commits, ~9 background sub-agents spawned across the night

Reproduction context

Long-running session with extensive autonomous agent activity:

• 9 background general-purpose / manager / stenographer agents spawned sequentially through the night
• ~60 git commits from various sub-agents
• 40+ new files created in wiki/competitor-intelligence/vendors/*.md
• 8+ new strategic docs in wiki/Strategy/competitor-intelligence-subunit-setup-2026-05/*.md
• Total tracked files in FileHistory at first failure: 52

Debug log evidence

From ~/.claude/debug/02df1c6c-4765-4d31-ba9d-2fc8ed2baf55.txt:

2026-05-26T14:38:49.911Z [ERROR] FileHistory: Failed to back up wiki/Strategy/competitor-intelligence-subunit-setup-2026-05/_phase-3-strategic-synthesis-2026-05-26.md: Error: EPERM: operation not permitted, copyfile '/Users/.../wiki/.../...md' -> '/Users/.../.claude/file-history/02df1c6c-4765-4d31-ba9d-2fc8ed2baf55/9091f5258b8886f8@v2'

... [30+ similar errors clustered at single message snapshot] ...

2026-05-26T14:38:49.918Z [DEBUG] FileHistory: Added snapshot for c5fe6c57-442f-4a2d-9686-c3fc903d79e4, tracking 52 files

Same files re-fail at next message snapshot (~1 min later, 14:39:48). The pattern is persistent, not transient.

Read tool then fails with same EPERM:

2026-05-26T14:38:59.807Z [WARN] [Stall] tool_dispatch_end tool=Read toolUseId=... outcome=error durationMs=17
2026-05-26T14:38:59.807Z [DEBUG] Read tool error (17ms): EPERM: operation not permitted, open '/Users/.../Capitol-Labs-Wiki/.claude/settings.json'

Counts in debug log: 66 EPERM occurrences, 68 FileHistory references.

Pattern observations

1. Affected files are exclusively those created/modified by Claude Code during this session
2. Failures are kernel-level (12-17ms hard-fail, not slow rejection)
3. Failures persist across message snapshots — not transient
4. Operator observation: failures correlate with context token size, but not 1:1. Hypothesis from operator perspective: cumulative session load (token count, agent spawn count, FileHistory tracked-file count are all correlated) crosses some threshold that triggers the EPERM cascade.

What I've ruled out (per claude-code-guide subagent search)

• Not documented in changelog, error reference, or troubleshooting guides
• Doesn't match known FileHistory issues (those manifest as SIGTRAP/memory exhaustion, not EPERM)
• Doesn't match known EPERM bugs (#61343 cowork sandbox, #57540 SMB volumes, #58001 Windows roots) — none match this pattern
• Not a quarantine issue (xattr -cr would have been the standard fix for that)

Hypothesized cause

Cumulative FileHistory load (file count × snapshot count) triggers a permission-state inconsistency. Possible mechanisms:

• macOS sandbox profile (sandbox-exec) renews mid-session and recomputation excludes session-created files
• Node.js file descriptor pressure causes copyfile to fail
• Claude Code permission-state hash recomputes and loses track of mid-session-created file grants

The token-count correlation the user observes is probably a proxy for cumulative session activity, with FileHistory tracked-file count as the actual driver.

Impact

This blocks the user's intended workflow of longer-horizon autonomous agent chains:

• Single-day autonomous chains (~6-8 hours, dozens of files) trigger this
• The user explicitly wants to run multi-day chains for project-scale autonomous execution
• Each chain that hits EPERM essentially requires full session restart to recover, losing in-progress state
• The structural ceiling on autonomous run length is currently being set by this failure mode, not by model capability or token budget

Recovery attempts

• Restart CLI: not yet tested for this specific session
• xattr -cr from external terminal: candidate fix
• chmod -R u+rw: candidate fix
• Purge FileHistory session directory: candidate fix

Asks

1. Is this a known failure mode internally? (Not in public docs per my search.)
2. Is there a recommended pattern for long-running autonomous sessions that avoids this? (Worktree isolation per chain is my user's current best guess.)
3. Is there a debug command that exposes the FileHistory permission state mid-session for self-diagnosis before EPERM cascade hits?
4. Could FileHistory be made resilient to copyfile EPERM (continue tracking with warning rather than persistent error logging)?

Operator note

This is a recurring problem now blocking a legitimate, high-value workflow pattern (autonomous overnight chains for structured project execution). Happy to provide additional logs, session traces, or repro steps if useful. Session debug log is preserved at ~/.claude/debug/02df1c6c-4765-4d31-ba9d-2fc8ed2baf55.txt if Anthropic wants to inspect.

Reporter is using Claude Code intensively for solo-operator productivity (Capitol Labs Consulting / articleOne). This is a structural capability concern, not a transient annoyance.