[BUG] Task .output files in /private/tmp/claude-{uid}/ never cleaned — 537 GB from single session, recurring 6+ times in 30 days

[samnurmi]

Environment

• Claude Code: v2.1.47
• OS: macOS 26.2 (Darwin 25.2.0)
• Hardware: Mac Studio M4 Max, 64 GB RAM, 2 TB APFS SSD
• Node: v25.2.1

Bug Description

Claude Code writes Task/subagent output to /private/tmp/claude-501/{cwd-slug}/tasks/{task_id}.output files. These files persist indefinitely — there is no TTL, no session cleanup, and no size cap.

A single research-heavy session generated 537 GB of .output files today, completely filling a 2 TB disk. This has caused disk-full emergencies 6+ times in 30 days (Jan 20 – Feb 19, 2026).

The .output files are written by the Task tool (subagent system) and grow large when agents do web fetches, code exploration, or other data-heavy operations. They accumulate across tasks within a session and are never cleaned up — not when the task completes, not when the session ends, not on next launch.

Evidence (live capture, Feb 19, 2026)

$ du -sh /private/tmp/claude-501/*/ | sort -hr | head -5
537G    /private/tmp/claude-501/-Users-neo14-code-sn-root-20260218-1553-ui-tests/
154M    /private/tmp/claude-501/-Users-neo14-code-30-6002-43-context-agent-.../

$ find /private/tmp/claude-501/ -name "*.output" -size +100M | head
/private/tmp/claude-501/-Users-neo14-code-sn-root-20260218-1553-ui-tests/tasks/b19f9ea.output
/private/tmp/claude-501/-Users-neo14-code-30-6002-43-context-agent-.../tasks/b5fd4f3.output

$ find /private/tmp/claude-501/ -name "*.output" | wc -l
1247

Previous occurrences

Date	Size	Session type
Feb 19 (today)	537 GB	UI test research (web-fetch heavy)
Feb 19 (earlier)	513 GB	MPA research session
Multiple earlier (6+ total)	disk full each time	Various research/explore sessions

The pattern is consistent: any session that makes heavy use of the Task tool (subagents for exploration, web fetching, or code search) generates hundreds of GB of .output files that are never reclaimed.

Workaround

rm -rf /private/tmp/claude-501/

Claude Code recreates the directory structure as needed. But users shouldn't have to do this manually.

Expected behavior

1. Session cleanup: Task .output files should be deleted when the session/conversation ends
2. Size cap: A per-session or per-task size limit (e.g., 1 GB total) would prevent runaway accumulation
3. TTL: At minimum, files older than N hours should be automatically purged
4. claude clean command: A user-facing command to purge temp data (see Add claude clean command to manage cache and logs #11646)

Any one of these would prevent the recurring disk-full emergencies.

Related issues

• Massive files being created in /tmp directory #195 (closed) — Massive files in /tmp
• [BUG] Claude Code generating massive temp files #16130 (closed) — Generating massive temp files
• Memory leak: Missing cleanup for /tmp/claude-*-cwd working directory tracking files #8856 (open) — -cwd tracking file leak (different files, same /private/tmp/claude-{uid}/ directory)
• [BUG] No disk space management: ~/.claude grows unbounded, cascade failure destroys settings and auth at 0 bytes free #24207 (open) — ~/.claude grows unbounded
• Add claude clean command to manage cache and logs #11646 (open) — Feature request: claude clean command

These previous issues were either closed or cover different file types. None specifically addresses task .output file accumulation at the 500 GB+ scale documented here.

[tainora]

Confirming: 271 GB single .output file — subagent JSONL concatenation variant

Environment

• Claude Code: v2.1.70
• macOS: 15.7.5 (Sequoia) on MacBook Pro M3 Max (36 GB RAM, 1 TB SSD)
• Disk state at discovery: 4.8 GB free (from 284 GB)

What happened

A single background task output file grew to 271 GB in approximately 2 hours:

/private/tmp/claude-501/-Users-terryli-eon-cc-skills/tasks/b593kacy4.output  271G

The file was generated by a background Bash task in a cc-skills session (session 658d8a60) that concatenated all subagent JSONL transcripts. The content was structured as:

=== a09d5c81a88244073.output ===
{"parentUuid":"...","type":"progress","data":{"type":"hook_progress","hookEvent":"PostToolUse",...}}
{"parentUuid":"...","type":"progress","data":{"type":"hook_progress",...}}
...

Each line is a full JSONL progress entry from subagent execution, including hook invocations (PostToolUse hooks fire on every tool call). With ~15 hooks per tool use × many subagents × many tool calls, the file grew at roughly 2 GB/minute.

Symptoms

• macOS became sluggish, then hit no space left on device
• The tail of the file literally ended with: zsh:5: no space left on device: /var/folders/.../claude-fa7f-cwd
• No warning from Claude Code before disk exhaustion

Additional data points

• The remaining 21 task files in the same directory totaled only 29 MB
• 4 other .output files from the same session: 13M, 6.6M, 3.4M, 101K — normal sizes
• The 271 GB file was the only runaway; it was a consolidated dump, not individual subagent files

Root cause analysis

This appears to be a distinct variant from the web-fetch/code-exploration pattern described in the original issue. Here, the growth driver is:

1. Background task runs a command that concatenates subagent outputs
2. Each subagent produces JSONL with full normalizedMessages arrays (related: [BUG] Session files grow to multi-GB due to normalizedMessages duplication in subagent progress entries #19040)
3. PostToolUse hooks fire on every tool use, each generating progress entries
4. No size cap, no circuit breaker, no TTL on the .output file

Workaround applied

# No process had the file open
lsof /private/tmp/claude-501/-Users-terryli-eon-cc-skills/tasks/b593kacy4.output  # empty
rm /private/tmp/claude-501/-Users-terryli-eon-cc-skills/tasks/b593kacy4.output
# 4.8 GB → 284 GB free

Suggested mitigations (reinforcing original proposal)

1. Hard size cap per .output file — e.g. 1 GB, then truncate with a marker ([TRUNCATED: exceeded 1GB limit]). This alone would have prevented 270/271 GB of waste.
2. Session-end cleanup — delete .output files when the parent session exits. No process had our file open; the session had already ended.
3. Rate-limiting progress writes — the file grew at ~2 GB/min because every hook invocation on every tool use generated a progress entry. Debouncing or sampling would dramatically reduce output volume.
4. Disk usage watchdog — if Claude Code's own temp files exceed N% of free disk, pause and warn.

This is the single most impactful bug I've encountered in Claude Code — 271 GB consumed in 2 hours with zero warning, nearly bricking the system.

[OlaPietka]

I have the same issue. Mine went up to 740 GB. Is there any update on fixing this bug, or are we left with doing it manually?

[wellDan28]

Experienced this as well, a single biq6stjb7.output file in /private/tmp/claude-502/ grew to 311GB, filling the disk. Claude Code v2.1.73 on macOS. The file was receiving the full session JSONL log stream from a subagent. No process had the file open after the task completed, but the file was never cleaned up.