[BUG] False ENOSPC error reported for subprocesses with no stdout and non-zero exit code
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?
Claude Code incorrectly reports "Command output was lost... temp filesystem is full (0MB free)" with ENOSPC when a subprocess exits with a non-zero exit code AND produces no stdout/stderr output. The filesystem is not actually full.
What Should Happen?
No error message
Error Messages/Logs
Steps to Reproduce
Run any command that produces no output and exits non-zero:
```bash
grep "nonexistent_string" ~/.zshrc
Expected: Exit code 1 reported, no output (correct behavior)
Actual:
Command output was lost: the temp filesystem at /private/tmp/claude-502/.../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.
Pattern
The error is precisely gated on no stdout output + exit code 1:
┌────────────────────────────────────┬─────────────┬───────────┬─────────────────┐
│ Command │ Output │ Exit code │ Result │
├────────────────────────────────────┼─────────────┼───────────┼─────────────────┤
│ grep "nonexistent" file │ none │ 1 │ ❌ False ENOSPC │
├────────────────────────────────────┼─────────────┼───────────┼─────────────────┤
│ grep "nonexistent" file; echo done │ "done" │ 0 │ ✅ Works │
├────────────────────────────────────┼─────────────┼───────────┼─────────────────┤
│ true │ none │ 0 │ ✅ Works │
├────────────────────────────────────┼─────────────┼───────────┼─────────────────┤
│ ls /nonexistent │ stderr only │ 1 │ ✅ Works │
└────────────────────────────────────┴─────────────┴───────────┴─────────────────┘
Environment
- macOS 15 (Darwin 25.5.0)
- Main filesystem: 357 GB free, no disk quotas, not at inode limit
- Manual writes to the tasks directory succeed
- Setting CLAUDE_CODE_TMPDIR to a different path moves where the error points but does not resolve it
Impact
No actual data is lost (the affected commands genuinely have no output), but the error message is alarming and misleads users into thinking they have a disk
space problem. Users spend time "fixing" disk space that isn't the issue.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.161
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗