Subagent task output files grow unbounded in tmpfs, can exhaust system memory

Summary

When a subagent/task runs a command that produces infinite or very large output (e.g., a Rails process hitting a recursive loop), the output is captured to /tmp/claude-<uid>/.../tasks/<id>.output with no size limit or truncation.

Since /tmp is commonly mounted as tmpfs (RAM-backed) on many Linux distributions (Arch, Fedora, etc.), this can silently consume all available RAM and push the system deep into swap.

Reproduction

1. Run Claude Code on a project with a command that produces unbounded stdout (e.g., a test hitting an infinite loop)
2. Let a subagent/task capture that output
3. The .output file in /tmp/claude-<uid>/ grows without limit

Observed behavior

• Two task output files grew to 20 GB and 4.6 GB (164 million lines of repeated stack trace)
• System used 22 GB of swap on a 62 GB RAM machine
• No timeout, truncation, or size cap was applied
• User had no visibility into the issue until manually investigating swap usage

Expected behavior

Task output capture should have a maximum size limit (e.g., truncate or ring-buffer after some reasonable threshold like 10-50 MB), and ideally warn the user when a task is producing excessive output.

Environment

• Claude Code CLI on Arch Linux
• /tmp mounted as tmpfs (systemd default)