Bug report: temp-filesystem preflight false-positives "ENOSPC" on large (>17.6 TB) filesystems

Product: Claude Code CLI Affected versions: 2.1.153 → 2.1.158 (latest at time of writing). Not present in ≤ 2.1.152. Severity: Tool execution aborts ("Command output was lost") on filesystems that are nowhere near full.

Summary

Since 2.1.153, Claude Code runs a free-space preflight before capturing a child process's stdout/stderr to its temp filesystem. On a filesystem with more than ~17.6 TB of free space, the check computes a negative free-MB value (due to a 32-bit truncation of f_bavail in the JS runtime's fs.statfs binding) and aborts with:

Command output was lost: the temp filesystem at <dir> is full (-4469490MB 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 filesystem is not full — the write would have succeeded. Versions ≤ 2.1.152 (which had no preflight) ran on the exact same machine for weeks with no issue.

Root cause

The preflight (decompiled from 2.1.158) is:

const q = await statfs(dir);
const K = Math.floor(q.bavail * q.bsize / 1048576); // free MB
if (K < 10) return `…is full (${K}MB free)… ENOSPC…`;
if (q.files > 0 && q.ffree < 1000) return `…out of inodes…`;

q.bavail comes from the runtime's fs.statfs, which truncates the kernel's 64-bit f_bavail to a signed 32-bit int. Measured on the affected host (a containerd overlay rootfs, 112 TB / 45.8 TB free):

The truncation is exact:

11,740,712,350 mod 2^32 = 3,150,777,758
3,150,777,758 > 2^31  →  as int32 = −1,144,189,538   ✓

So any filesystem with > 2^32 free 4 KB-blocks (≈ 17.6 TB free) trips K < 10 and aborts. Large overlay/NFS/scratch filesystems are common on build boxes, GPU nodes, and CI runners.

Reproduction

On a host with a >17.6 TB-free filesystem (or any fs whose fs.statfs().bavail wraps negative — verify with the table below):

# kernel says plenty free:
python3 -c "import os;s=os.statvfs('/tmp');print(s.f_bavail*s.f_bsize//1048576,'MB')"
# runtime truncates to negative:
node -e "const s=require('fs').statfsSync('/tmp');console.log(Math.floor(s.bavail*s.bsize/1048576),'MB')"
# (bun reproduces it identically)

Then run any Bash tool that produces stdout — Claude Code aborts with the false ENOSPC.

Suggested fixes (either is sufficient)

1. Guard the preflight against bogus/negative values — treat a negative (or otherwise nonsensical) free figure as "unknown, proceed" rather than "full". Minimal:

   const K = Math.floor(q.bavail * q.bsize / 1048576);
   if (K >= 0 && K < 10) return `…is full…`;   // skip the guard when K < 0

   The actual write() already surfaces a real ENOSPC if the disk is truly full, so a negative preflight reading should never block.

2. Fix the underlying fs.statfs truncation in the bundled runtime so f_bavail/f_blocks/f_bfree are read as 64-bit (this is a Node/Bun-level binding issue; report there too).

Workaround (current)

Set CLAUDE_CODE_TMPDIR to a directory on a filesystem with < ~17.6 TB free (any tmpfs such as /dev/shm qualifies), so the block count stays within 32 bits and the preflight reads a sane value.