darwin-x64: false "temp filesystem is full (0MB free) / ENOSPC" — statfs().bsize=0 makes the empty-output explainer always report disk-full

Summary

On Intel (x86_64) macOS, Claude Code intermittently replaces a Bash command's output with:

Command output was lost: the temp filesystem at <…>/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.

The disk is not full (reproduced with 44 GB free). The message is always spurious on this platform. Agents read it as authoritative, conclude the disk is full, and refuse or abort work — on 2026-06-03 it hit 7 concurrent sessions on one machine.

Environment

• Claude Code 2.1.161 (bundles Bun 1.3.14, darwin x64)
• macOS, Intel Core i7 (x86_64, not Rosetta), APFS, ~44 GB free

Root cause

CC's background-task handler explains an empty-output failure via a statfs helper (binary offset ~211049601):

else if (this.taskOutput.stdoutToFile && stdout === "" && exitCode !== 0 && exitCode !== <killSentinel>) {
    let K = await explainTmpFailure(this.taskOutput.path);  // runs statfs
    if (K) result.stdout = K;
}
// explainTmpFailure: q = A.bavail * A.bsize / (1024n*1024n); if (q < 10n) return "…is full (${q}MB free)…ENOSPC…"

On darwin-x64, Bun 1.3.14's fs.statfs returns bsize = 0 (legacy statfs$INODE64 layout — oven-sh/bun#31133; fix #31139 merged 2026-05-21, not yet in any release). So bavail*bsize/1MB == 0 < 10n, and the helper unconditionally returns the disk-full string.

The bug is deterministic (not load/EINTR): a standalone bun-v1.3.14 darwin-x64 statfsSync(dir,{bigint:true}) returned bsize=0 on 600,000/600,000 calls. The symptom is intermittent only because the explainer fires only when a backgrounded command exits non-zero with empty stdout (e.g. a grep with no matches).

Not a duplicate of #63877

#63877 is int32 truncation → negative MB on >17.6 TB volumes, and its fix is present here. This is bsize=0 → zero MB on a normal volume; different cause, same banner.

Suggested fix (independent of Bun's release cadence)

In the statfs explainer, treat an implausible struct as "unknown" rather than disk-full:

• if bsize === 0n (or bsize/blocks are zero/absurd), don't emit the disk-full message;
• and/or don't default to "disk full" as the explanation for an empty-output non-zero exit — surface the actual exit code instead.

Either guard fixes it for all Intel-Mac users regardless of when Bun ships #31139.