[BUG] On a genuinely full disk, the Bash ENOSPC notice names the session tmpdir instead of the filesystem, and no command can then run to diagnose it

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?

On a Linux box whose /, /home and /tmp share one volume, the volume filled to 100%. Two things then went wrong, and the second is what turned a disk problem into a stuck session.

The notice names the session temp directory rather than the filesystem. It reports free space for /tmp/claude-<uid>/<project-slug>/<session-id>/tasks, so the natural reading is "my session's scratch filled up", a local and session-scoped problem. That directory was 526 MB of a 134 GB volume in the first occurrence, and about 0.2% of consumption in the second. Two sessions on that box hit this a week apart, and both spent their first hypothesis on the directory the message named.

With the volume full, no diagnostic can run. Any command writing to stdout dies with the notice and returns nothing, so df, du and ls, whose only purpose is to measure the problem, are exactly the commands that stop working. A command producing no stdout still executes: a blind rm of the session's own task files was the only thing that ran, and it was found by guessing.

This is not the false-ENOSPC family (#63909, #65880, #65086, #67623, #65166, #63877). In those the disk has space and the measurement is wrong. Here the measurement is right and the disk really is full. The bug is that the message points at a directory that is a fraction of a percent of the problem, and that nothing survives to diagnose the rest.

What Should Happen?

The notice names the filesystem that is full. The mount point, its size and its available space, next to the tmpdir path. One line such as the volume /dev/nvme0n1p6 mounted at / is full (134G total, 0 available); the session tmpdir /tmp/claude-<uid>/... lives on it sends the reader at the disk instead of at the harness.

Some diagnostic survives the condition. When the write of a command's captured output hits ENOSPC, falling back to an in-memory capture with a small truncation cap would keep df -h (roughly 200 bytes) readable, which is the whole difference between a recoverable session and a stuck one.

Error Messages/Logs

Command output was lost: the temp filesystem at
/tmp/claude-<uid>/<project-slug>/<session-id>/tasks is full (0MB free).
The child process's stdout/stderr writes failed with ENOSPC.

# what was actually full
Filesystem      Size  Used Avail Use% Mounted on
/dev/<nvme-partition>  134G  127G  296K 100% /

# measured behavior while in that state
df -h /tmp                          exit 1, notice, no output
df -h > <path on the same volume>   file created but EMPTY, exit 1
echo LITERAL > <path>               file created but EMPTY, exit 1
true                                exit 1, notice
rm -rf <the tasks dir the notice named>/*   exit 0, ran silently

Steps to Reproduce

Both occurrences arrived in production on a machine that filled by itself, so the sequence below is reconstructed from them rather than run deliberately. Filling a volume on purpose is the part that needs care, since everything else on the box is affected too.

1. On Linux, with the session's temp directory on the same volume as everything else, fill that volume until df reports 0 available (a large fallocate file on the same filesystem does it).
2. From a Claude Code session on that box, run any Bash tool command that writes to stdout, such as df -h /.
3. Observe the notice. It names /tmp/claude-<uid>/<project-slug>/<session-id>/tasks and its free space, and says nothing about the mount point that is full.
4. Try to diagnose. df, du, ls and even true all fail the same way, and redirecting to a file on the full volume creates an empty file rather than reporting anything.
5. Delete the filler file from outside the session. Normal behavior returns.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

unknown

Claude Code Version

2.1.246 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

The box runs several unattended claude -p sessions around the clock, which is how it reaches 100% without anyone watching. Both occurrences were recovered by hand: the first by guessing that a no-stdout rm would run, the second by redirecting df output to a file on a path outside the exhausted temp directory and reading it back with the Read tool, which is in-process and so unaffected. That second escape works only while a few bytes remain free; at literal zero the redirect target is created empty.

Related but distinct: #69003 covers session history lost on a genuinely full disk with no rebuild path, and asks for recovery rather than for the message to name the right scope.