[BUG] FileSpiller continues writing identical content after bash process exits (480GB from 81KB of actual output)

Resolved 💬 3 comments Opened Mar 15, 2026 by mshappyflow Closed Apr 13, 2026

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?

A background task's .output file grew from 81KB of legitimate output to 480GB in 94 minutes. Unlike related reports
(#31048, #32964, #34397) where the underlying process was still producing output, in this case the bash process had
already exited. The file contains the same 8,755-byte block repeated ~59 million times — verified by MD5 at 0GB, 1GB,
100GB, and 400GB offsets.

This points to a bug in the FileSpiller.append() path that continues writing after the source process has terminated,
separate from the missing size cap issue.

What Should Happen?

Once the bash process exits, no more data should be written to the .output file. The file should have been ~81KB (the
actual command output).

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

  1. Launch 5+ background Agent tasks (creates .output symlinks in the tasks directory)
  2. Run a foreground Bash command that reads files in the same tasks directory:

for f in /private/tmp/claude-501/.../tasks/*.output; do
echo "=== $(basename $f) ==="
tail -3 "$f" 2>/dev/null
echo
done

  1. Command takes >2s (tail on large JSONL files) and gets auto-promoted to background task
  2. Bash for-loop completes normally (runs once, exits)
  3. The .output file keeps growing at ~87 MB/s until disk is full

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Warp

Additional Information

Evidence that this is a FileSpiller bug, not a runaway process:

  • tail -3 (without -f) reads once and exits — cannot produce continuous output
  • The for-loop glob runs once over sorted files — no repetition mechanism in bash
  • The self-referencing glob (command's own .output matched by *.output) adds exactly one extra 8.7KB cycle — not 59

million

  • Every cycle is byte-for-byte identical (MD5 verified across the full 480GB file)
  • A subsequent cat on the growing file was also auto-backgrounded. Its output file (64MB, 44 seconds) shows the exact

same repeating block — confirming the bug is systematic

Analysis from minified source (TaskOutput class / Cq):

  1. On backgrounding, spillToDisk() is forced — buffer flushed to file
  2. startPolling() reads last 4096 bytes every 1000ms (read-only, not the cause)
  3. writeStdout() → FileSpiller.append() is the only write path
  4. After bash exits, writeStdout() should not be called — but the file grows for 94 minutes
  5. The bug likely lives in FileSpiller.append() or its interaction with the process exit/cleanup handlers

Difference from related issues:

┌────────┬───────┬────────────────┬────────────────────────┬──────────────────────────┐
│ Issue │ Size │ Process alive? │ Unique content? │ Root cause │
├────────┼───────┼────────────────┼────────────────────────┼──────────────────────────┤
│ #31048 │ 107GB │ Yes │ Yes (unique JSONL) │ No size cap │
├────────┼───────┼────────────────┼────────────────────────┼──────────────────────────┤
│ #32964 │ 2.5TB │ Yes (orphaned) │ Yes │ No size cap + no cleanup │
├────────┼───────┼────────────────┼────────────────────────┼──────────────────────────┤
│ #34397 │ 297GB │ Unclear │ Unclear │ No size cap │
├────────┼───────┼────────────────┼────────────────────────┼──────────────────────────┤
│ This │ 480GB │ No — exited │ No — identical repeats │ FileSpiller write-loop │
└────────┴───────┴────────────────┴────────────────────────┴──────────────────────────┘

A size cap would limit the damage but would not fix this bug — the FileSpiller should not be writing at all after the
process exits.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗