[Bug] Bash tool stdout capture fails with spurious ENOSPC on macOS despite ample disk space

Bug Description
Bash tool intermittently fails with a spurious ENOSPC "temp filesystem full (0MB free)" error despite ~831 GB free disk.

SYMPTOM: Bash tool calls that emit stdout sometimes return:
"Command output was lost: the temp filesystem at
/private/tmp/claude-501/<project-slug>/<session-uuid>/tasks is full
(0MB free). The child process's stdout/stderr writes failed with ENOSPC."

EVIDENCE IT'S SPURIOUS:

• df -h /private/tmp shows the underlying volume (/dev/disk1s1s1, 1.9T) at

56% used, 831G free.

• The per-session tasks dirs are tiny (~200 KB total). rm -rf .../tasks/*

did NOT resolve it, so it's the stdout-capture mechanism, not that
subdir's contents.

PATTERN:

• Short commands with small output sometimes succeed; longer/streaming

output (e.g. recursive grep -r) fails reliably.

• Reliable workaround: redirect the command's stdout/stderr to a file on the

main disk (cmd > /abs/path 2>&1) and read the file. Commands that rely on
the harness's own stdout capture fail; ones that produce no stdout succeed.

• Recurred across at least two sessions.

ENV: macOS Darwin 24.6.0, Claude Code, Opus 4.8 (1M context). Project lives
under ~/Dropbox (Library/CloudStorage symlink).

LIKELY CAUSE: harness stdout-capture writing to a per-session tmp under
/private/tmp/claude-501/.../tasks; the "0MB free" message appears to
misreport the real condition (possibly an inode/quota limit or stale mount),
since df on the underlying volume shows ample space.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.162
• Feedback ID: d508d291-7bc0-44f0-bdd1-f3b98e1b7050

Errors

[]