[BUG] False ENOSPC error reported for subprocesses with no stdout and non-zero exit code

Resolved 💬 2 comments Opened Jun 3, 2026 by ghost Closed Jun 7, 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?

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_

View original on GitHub ↗

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