Task runner reports ENOSPC on subprocess output despite disk having free space

Bug

Claude Code's Bash tool reports ENOSPC when capturing any subprocess stdout, silently losing all command output. Commands with no output succeed; commands with any output fail.

Error message

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

Environment

• macOS Darwin 24.6.0
• Shell: zsh
• CLAUDE_CODE_TMPDIR=/tmp/claude-501 (already set — resolves to /private/tmp/claude-501 via symlink on macOS)

Diagnostics

• df -h on the tasks directory: 23 GB free on /dev/disk1s2 (APFS, 90% used)
• APFS container free: 24.6 GB
• du -sh /private/tmp/claude-501/: 8 KB (essentially empty)
• Task .output files are created at 0 bytes — write never completes
• Direct shell writes to the same directory succeed: echo "test" > .../tasks/test.txt → 5 bytes, readable
• quota -v → no quota
• ulimit -f → unlimited
• No extended attributes on the tasks directory

Key observation

The session UUID is per-conversation — the same UUID appears across multiple Claude Code relaunches within the same conversation. Once the UUID enters this broken state, all subsequent Bash tool invocations in that conversation lose their output. Starting a new conversation gets a new UUID and clears the problem.

Impact

All Bash tool command output is silently lost for the duration of the affected conversation. The tool appears to succeed (exit 0) but returns no output.

Hypothesis

The task runner's subprocess-to-file pipe write is returning ENOSPC at the OS level despite available disk space. Possible causes: (1) incorrect internal "available space" tracking that hits 0 before the real disk does, (2) a pipe buffer issue where the reader isn't draining concurrently with subprocess execution, or (3) a per-session-UUID state corruption.