[BUG] Claude reports negative free space on large disks, due to integer overflow

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

It's a 32-bit integer overflow in the harness's free-space check, triggered by how large this pod's filesystem is. My computed value (-5,033,896 MB) matches the harness's reported -5,034,291 MB to within 414 MB — exactly the ~400 MB I freed since the error. Let me clean up the diagnostic scratch and check your settings file so I can give you the fix. Read 1 file, ran 1 shell command Root cause found, and it's not a real disk-space issue — the disk is 3% full, writes succeed, inodes are at 1%, there are no quotas and no deleted-file leaks. It's a 32-bit integer overflow in the harness's free-space preflight check, triggered by the sheer size of this pod's filesystem. What's actually happening /tmp lives on the pod's overlay root (/), which is 27.9 TB with 4 KB blocks → 7.3 billion free blocks. The harness's free-space guard reads statvfs.f_bavail into a signed 32-bit int, which maxes out at ~2.1 billion. So the count wraps: true free blocks = 7,301,257,124 (29.9 TB free — fine) mod 2^32 = 3,006,289,828 (> 2^31 → reads as negative) as int32 = -1,288,677,468 blocks × 4096 / 1 MB = -5,033,896 MB harness reported = -5,034,291 MB ← matches to within 414 MB That 414 MB gap is exactly the space I freed since the error fired — i.e. it's the same filesystem, confirming the overflow. The guard sees "negative free space," concludes the disk is full, and refuses to write task stdout → ENOSPC. Why it "keeps failing" and isn't transient: whether the truncated value lands positive or negative depends on where the node-wide free-block count sits relative to the 2³¹-block boundary. This is a shared multi-tenant CoreWeave node, so as other tenants' usage drifts, f_bavail crosses that boundary. Right now it's parked in the band that truncates negative, so it fails consistently. Clearing /tmp can't fix it — free blocks stay ~7.3 B (≫ 2³²) no matter how much you delete; the wrap is structural. The fix: point the harness temp at a smaller-block-count filesystem The overflow only happens because the overlay has >2³¹ free blocks.

What Should Happen?

Claude should be able to run commands without running out of disk space

Error Messages/Logs

● Bash(grep -rln "eps_timestep_w" /mnt/clusterstorage/workspace/kevin/ml-monorepo --include=*.py 2>/dev/null)
Command output was lost: the temp filesystem at /tmp/claude-1000/-mnt-clusterstorage-workspace-kevin/649c2a47-861e-4981-88ca-5394e01a5a4c/tasks is full (-5034291MB 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.

Steps to Reproduce

Run claude code on a huge disk:

Trigger condition

The bug is in the harness's tmpdir free-space preflight, which reads statvfs.f_bavail (the count of free blocks) into a signed 32-bit int. It overflows when:

f_bavail  >  2^31 - 1  (2,147,483,647 free blocks)

f_bavail is in units of f_frsize. With the standard 4 KiB block size, that threshold is:

▎ free space > 8 TiB (≈ 8.80 TB) on the filesystem backing CLAUDE_CODE_TMPDIR.

It's free space, not total — so you need a filesystem that is both larger than 8 TiB and has >8 TiB unused.

Which sizes fail deterministically

Because it wraps at 2³² and is then read as signed, the reported free value flips sign by band (4 KiB blocks):

┌─────────────┬────────────────────────────────────┬────────────────────┐
│ actual free │          int32-read free           │       result       │
├─────────────┼────────────────────────────────────┼────────────────────┤
│ < 8 TiB     │ correct, positive                  │ ok                 │
├─────────────┼────────────────────────────────────┼────────────────────┤
│ 8–16 TiB    │ negative                           │ fails (ENOSPC)     │
├─────────────┼────────────────────────────────────┼────────────────────┤
│ 16–24 TiB   │ positive but wrong (under-reports) │ silently incorrect │
├─────────────┼────────────────────────────────────┼────────────────────┤
│ 24–32 TiB   │ negative                           │ fails              │
├─────────────┼────────────────────────────────────┼────────────────────┤
│ 32–40 TiB   │ positive but wrong                 │ silently incorrect │
└─────────────┴────────────────────────────────────┴────────────────────┘

Claude suggests this repro, which I cannot run:

# 1. Create a 12 TiB SPARSE image (real disk cost ~tens of MB, just metadata)
truncate -s 12T /var/tmp/big.img
mkfs.ext4 -q -E lazy_itable_init=1,lazy_journal_init=1 /var/tmp/big.img

# 2. Mount it
sudo mkdir -p /mnt/bigfs
sudo mount -o loop /var/tmp/big.img /mnt/bigfs
sudo chown "$(id -u):$(id -g)" /mnt/bigfs

# 3. Confirm the trigger: free blocks must exceed 2^31 = 2,147,483,647
python3 - <<'EOF'
import os
s = os.statvfs("/mnt/bigfs")
free_blocks = s.f_bavail
t = free_blocks % 2**32
i32 = t - 2**32 if t >= 2**31 else t          # how a signed-int32 read sees it
print(f"f_frsize       = {s.f_frsize}")
print(f"f_bavail       = {free_blocks:,} free blocks ({free_blocks*s.f_frsize/2**40:.2f} TiB)")
print(f"exceeds 2^31?  = {free_blocks > 2**31-1}")
print(f"int32 read     = {i32:,} blocks  ->  {i32*s.f_frsize/1024/1024:,.0f} MB free  (negative = bug fires)")
EOF
# real vs apparent size — proves the image is sparse:
du -h /var/tmp/big.img; du -h --apparent-size /var/tmp/big.img

# 4. Reproduce: point the harness temp at the big fs and run any command
CLAUDE_CODE_TMPDIR=/mnt/bigfs claude -p "run: echo hello"
#   -> spurious: "temp filesystem ... is full (-NNNNNN MB free)", ENOSPC on child stdout,
#      even though `df -h /mnt/bigfs` shows ~12T free and writes physically succeed.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

the one from a week ago

Claude Code Version

2.1.159 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_