[Bug] Spurious ENOSPC errors in task output capture with racing cleanup deletes

Bug Description
Title: Claude Code intermittently kills commands with bogus "temp filesystem full (0MB free)" ENOSPC — not disk space, not a second process, and CLAUDE_CODE_TMPDIR relocation doesn't fix it Environment: - Claude Code CLI on macOS (Darwin 24.6.0), Apple Silicon - Single active session (claude --resume) - Project on /System/Volumes/Data (APFS), 2.7 TiB free Symptom: Commands that produce stdout/stderr intermittently fail. The tool result is one of: Command output was lost: the temp filesystem at /tmp/claude-503/<project>/<session>/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. or, separately: <bash output unavailable: output file .../tasks/<id>.output could not be read (ENOENT). This usually means another Claude Code process in the same project deleted it during startup cleanup.> The command's side effects (file writes, git ops) often still execute — only the harness's stdout capture fails, so results are invisible. It is NOT disk space. df -h of the exact failing …/tasks path: /dev/disk1s1 3.6Ti 909Gi 2.7Ti 25% 7.8M 29G 0% /System/Volumes/Data 2.7 TiB free, 29G free inodes. The entire claude-503 temp tree was ~14 MB. It is NOT a second process. ps -axo pid,ppid,etime,command | grep claude showed exactly one claude process (the active session). The "another Claude Code process deleted it during startup cleanup" message fired anyway, so a session is racing/deleting its own task-capture files. CLAUDE_CODE_TMPDIR relocation does NOT fix it. I set CLAUDE_CODE_TMPDIR="$HOME/.claude-tmp" and relaunched (echo $CLAUDE_CODE_TMPDIR confirmed it took). The new, freshly-created path ~/.claude-tmp/claude-503/<project>/<session>/tasks immediately reported the same (0MB free) ENOSPC — on a brand-new empty dir on the 2.7 TiB volume. So the constraint is internal to the harness's tasks-dir handling, independent of the underlying filesystem or path. Pattern: Intermittent and output-size-correlated. Commands emitting zero stdout (everything redirected to a file outside the tasks dir, ending in true) usually succeed; commands producing captured output fail randomly. Deleting the tasks/*.output files frees it for a command or two, then it "refills" instantly with nothing running. Both foreground and run_in_background commands are affected. Impact: Routine commands (rg, ls, git, pnpm) get killed mid-execution, making the CLI largely unusable until a lucky clean window. Workaround that reliably dodges it: redirect all command output to a file outside the tasks dir (e.g. cmd > ~/out.txt 2>&1; true) and read that file, or otherwise emit zero stdout to the harness. Suspected cause: a race or false quota in the harness's per-session tasks/<id>.output capture lifecycle — a periodic/startup cleanup deleting capture files while commands write to them, surfaced as a misleading ENOSPC "(0MB free)".

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.161
• Feedback ID: 3a9d9833-433b-4748-919f-f9d926a81fe7

Errors

[]