Bash tool aborts with "temp filesystem ... is full (0MB free)" / ENOSPC when disk is NOT full (macOS)

Summary

The Bash tool intermittently aborts a command with:

temp filesystem at /private/tmp/claude-501/<...>/tasks is full (0MB free).
The child process's stdout/stderr writes failed with ENOSPC.
Free up space or set CLAUDE_CODE_TMPDIR to a directory on a filesystem with room.

…but the filesystem is not full. The harness appears to misreport an intermittent scratch-file write failure as "disk full / 0MB free."

Environment

• macOS, Darwin 22.6.0
• Claude Code CLI (Opus 4.x session)

Evidence gathered in-session

• df: /System/Volumes/Data has 109 GiB available (94% used of 1.7 TiB)
• diskutil info /: 117.4 GB real container free space
• The scratch dir /private/tmp/claude-501 was only 9.7 MB
• tmutil listlocalsnapshots: zero local APFS/Time Machine snapshots on / and /System/Volumes/Data (so this is not purgeable-snapshot space exhaustion, the usual "df lies" cause)
• CLAUDE_CODE_TMPDIR was already set to /tmp/claude-501, which is on the volume that has 109 GB free — so the env-var suggestion in the error message was already satisfied
• The first failing command in the session had trivial output (wrangler: command not found), so the failure is not correlated with large stdout volume

Conclusion

The error is misattributed: it's an intermittent scratch-file write failure being surfaced as "0MB free." It fires semi-randomly rather than on large output, on a volume with abundant real free space and no snapshots.

Workarounds observed

• Redirecting a command's output to a file under ~ and reading that file avoids it 100% of the time.
• Restarting the CLI also clears it, suggesting accumulated harness scratch state rather than a real disk condition.

Suggestion

When this ENOSPC condition is hit, it would help to (a) verify actual free space before reporting "disk full," and (b) surface the underlying errno/path so it can be distinguished from a genuine out-of-space condition.