[BUG] ## ESCALATION: Claude Code (Opus 4.8) Bash tool emits false "temp filesystem full / 0MB free" ENOSPC despite ~148 GB free, causing wasted token spend

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?

ESCALATION: Claude Code (Opus 4.8) Bash tool emits false "temp filesystem full / 0MB free" ENOSPC despite ~148 GB free, causing wasted token spend

Severity: High
Target team: Engineering (Claude Code / agent harness)
Reported by: User (developer) via in-session report; documented by the agent
Date: 2026-06-16

Impact

• Customers affected: At least 1 confirmed (this user); likely any macOS user whose Bash tool calls route stdout/stderr through the per-session tasks temp dir. Potentially broader.
• Workflow impact: Bash tool calls intermittently return "Command output was lost: the temp filesystem at /private/tmp/claude-501/<session>/tasks is full (0MB free)" even when the command runs. The agent then misread this as a real problem and spent tokens diagnosing it (df/du/mount, retries, an attempted find -delete cleanup) instead of proceeding with the user's actual task.
• Revenue at risk: N/A directly; token/cost waste and eroded trust in the agent's judgment.
• Time in queue: Surfaced this session (2026-06-16); novel — not previously reported by this user.

Issue Description

On macOS, the Claude Code Bash tool writes each command's captured stdout/stderr to a file under /private/tmp/claude-501/<project>/<session-uuid>/tasks/. Intermittently the harness reports that this location is full (0MB free) and discards command output, advising the user to set CLAUDE_CODE_TMPDIR. This is a false signal: df from inside the same harness shows /System/Volumes/Data with 38 GiB available, and the user's Finder shows 147.62 GB available. The error hits some commands (multi-pattern grep) while others in the same session (df, ls, mount, git) succeed, indicating a harness-side bug (e.g., a tiny/misconfigured tmpfs, a stale/locked .output file, or an inode/handle leak in the task-output writer) rather than a genuine disk condition.

What's Been Tried

1. df -h on the temp path → showed 38 GiB free on the real volume. Result: confirms not a real disk-full.
2. Inspected the tasks/ dir (ls -la) → contained a single 0-byte .output file (total 0). Result: directory is effectively empty; "full" claim is spurious.
3. Re-ran the failing grep and redirected output to files on the roomy volume → output still reported "lost"; redirect target came back empty. Result: failure is in the harness output-capture layer, not the command or target FS.

---

What Should Happen?

Not create false out-of-disk-space issues, nor waste customer tokens to infinitely look for a solution to false out-of-disk-space issues which will go in a blind loop.

Opus 4.8's own description:
Expected: Bash returns the command's stdout/stderr; absent a genuine disk-full, no ENOSPC.
Actual: Intermittent "the temp filesystem at …/tasks is full (0MB free) … set CLAUDE_CODE_TMPDIR"; output discarded though the command's side effects still apply.
Environment: macOS (Darwin 24.6.0), Claude Code, model claude-opus-4-8[1m]; volume /dev/disk1s1 1.5 TiB, 38 GiB free (Finder: 147.62 GB free); temp path /private/tmp/claude-501/-Users-username-code/<session-uuid>/tasks/. Frequency: intermittent, same session.

Error Messages/Logs

Steps to Reproduce

Reproduction Steps

1. Start a Claude Code (Opus 4.8) session on macOS with the project at /Users/<username>/code/.
2. Issue several Bash tool calls in succession, including a multi-pattern grep -n "a\|b\|c" <file>.
3. Observe that some calls return normally while others fail.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.12603.1 (3df4fd) 2026-06-11T16:57:36.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Customer Communication

• Last update to customer: 2026-06-16 — agent acknowledged the false error, apologized for token spend, and recorded a workaround in its memory.
• Customer expectation: The agent should ignore this phantom error and not spend tokens on it; the bug should be fixed upstream.
• Escalation risk: User already escalated twice (interrupted the agent, then filed this). Continued false errors / token waste risk further frustration.

What's Needed

• Investigate root cause of the false ENOSPC in the Bash-tool output-capture path on macOS (tmpfs sizing/inode handling, stale .output files, or error misclassification).
• Fix: stop surfacing a disk-full error when the target volume has space; fail open (return whatever output is available) and log the real errno.
• Interim agent behavior: treat this message as non-fatal, don't diagnose disk space, prefer file tools (Read/Edit/Write) over Bash for search/edit. (Already applied this session — saved to agent memory.)
• Deadline: Next Claude Code patch release; interim agent workaround effective immediately.

Supporting Context

• Exact error string: "Command output was lost: the temp filesystem at /private/tmp/claude-501/-Users-username-code/<session-uuid>/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."
• Evidence: in-harness df (38 GiB free) and Finder screenshot (147.62 GB available); ls -la of tasks/ showing one 0-byte file.
• Agent memory note: bash-false-enospc-harness-bug.md (this project's memory dir).