macOS: per-call file ops intermittently EPERM on TCC-protected workspace (~/Desktop) for running sessions; app's own file-index worker also denied; self-recovers in ~5-35 min

Summary

During multi-session use of the Claude desktop app (Claude Code sessions), an already-running session's per-call file operations begin returning EPERM: operation not permitted on existing files under the workspace, which lives in the TCC-protected ~/Desktop container. The condition is intermittent, self-recovers after ~5–35 minutes, and has been occurring for days at escalating frequency, mostly invisibly.

Environment

• Claude Code 2.1.219 (desktop app, macOS)
• macOS Darwin 25.5.0
• 8 GB RAM machine, typically running 3+ concurrent sessions in one workspace
• Workspace: a git repo under ~/Desktop/<workspace>

Symptom signature (measured during a live 30-minute outage window)

During the window:

• Harness Read and Edit tools fail with EPERM: operation not permitted, open '<path>' on existing workspace files — including files the same session read/edited successfully minutes earlier
• Sandboxed Bash: cat/head/append on existing files fail with "Operation not permitted"; ls ~/Desktop itself fails
• New-file creation inside the workspace still works, and a file created during the window can be re-read
• Non-Desktop paths (~/, other repos) are unaffected
• MCP servers spawned at app start (e.g. a stdio server launched hours earlier) retain full workspace access throughout — only per-call/newly-attributed operations are denied
• ~/Documents and ~/Downloads were unaffected when tested after recovery

Evidence that it's OS-level, not session logic

At the exact onset minute, the app's own file-index worker logged:

[warn] [file-index-worker] git ls-files failed; falling back to shallow BFS (deep paths may be missing in @-mention autocomplete): fatal: Unable to read current working directory: Operation not permitted

Counting Operation not permitted lines in ~/Library/Logs/Claude/main.log per day shows a chronic, escalating pattern: 2 → 31 → 6 → 42 → 46 over five consecutive days. Most windows go unnoticed; a session only observes the failure if it happens to touch the workspace during one.

What we ruled out with controlled tests

• Not permission-mode/config: both permission modes tested during the 07-29 occurrence; no change. No settings were modified around onset.
• Not "any new session birth": a headless scheduled-task session birth during a probe loop (10s cadence read of an existing workspace file) did NOT trigger the condition; an earlier interactive session birth also left a concurrently-running session unaffected.
• Not sibling-resume: waking an idle concurrent session did not trigger it.
• Not sibling-process lifetime: the concurrent session's CLI process (born at onset minute) was still alive after access had recovered.

Correlations (aggravators, not deterministic causes)

• Both observed onsets coincide with interactive session warm-ups ([WarmLifecycle:preview] Warming up session … in main.log at the onset timestamps)
• The machine runs under chronic memory pressure (43–70 MB raw free, constant [CliGovernor] memory pressure warnings, 51–76 app child processes); recovery from the measured window coincided with ~1.7 GB freeing (visible in [process-memory] lines)

Suspected area

TCC / sandbox-extension issuance for per-call child processes and harness file operations failing intermittently under memory pressure in a large Electron process tree — long-lived children keep their grants, newly-attributed operations are denied, and lexical write-create allowances still pass (which would explain new-file creation surviving).

Impact

A running session silently loses the ability to read or edit its own workspace mid-task. Because new-file creation still works and the error is a plain EPERM, it presents as confusing partial permission loss; unattended/scheduled runs hitting a window would produce silent no-ops.

A separate security-relevant observation about credential handling in session process arguments was sent privately to Anthropic's security contact rather than included here.