Bash tool silently returns empty output when `/tmp/claude-$UID/` exceeds tmpfs quota

Summary

Claude Code accumulates task outputs and tool results under /tmp/claude-$UID/ (e.g. /tmp/claude-1000/) without any cleanup/rotation. When this directory's size causes the user to hit their tmpfs quota, the Bash tool silently starts returning empty output with no error surfaced to the user or the model. Every bash invocation appears to 'succeed' with zero stdout and zero stderr, making this bug extremely hard to diagnose.

Environment

• Claude Code version: 2.1.104 and 2.1.117 (both affected)
• OS: Fedora 43
• Kernel: 6.18.16-200.fc43.x86_64
• Shell: bash
• Node.js: v22.22.0
• Install method: native
• /tmp: tmpfs, 12G total
• User tmpfs quota: 9472M

Reproduction

1. Use Claude Code over a long period so /tmp/claude-$UID/ accumulates data (mine grew to 6.3G)
2. Once user's tmpfs quota is reached, the Bash tool stops working across all running sessions simultaneously
3. Every bash command — including trivial ones like echo hello, ls, pwd, true — returns empty stdout, empty stderr, and a non-zero exit code (varies: 1, 2, 128)
4. The !<cmd> inline shell runner in Claude Code also produces empty output
5. The regular terminal (outside Claude Code) continues to work fine

Symptoms

• Bash tool returns empty output with no error
• Affects all running sessions at once (all write to shared /tmp)
• Affects both sandboxed and dangerouslyDisableSandbox: true invocations
• Affects background-mode bash commands
• Affects subagents
• Regular bash/bwrap outside Claude Code works fine
• Fresh sessions started after the quota is hit are also broken

Debug log evidence

From ~/.claude/debug/<session>.txt during a bash call:

[DEBUG] Creating shell snapshot for bash (/bin/bash)
[DEBUG] Looking for shell config file: /home/m/.bashrc
[DEBUG] Snapshots directory: /home/m/.claude/shell-snapshots
[DEBUG] Creating snapshot at: /home/m/.claude/shell-snapshots/snapshot-bash-<ts>.sh
[DEBUG] Execution timeout: 10000ms
[DEBUG] Shell snapshot created successfully (79833 bytes)
[DEBUG] No session environment scripts found
[DEBUG] Spawning shell without login (-l flag skipped)
[DEBUG] FileHistory: Added snapshot for <uuid>, tracking 0 files

No error logged after the shell spawn — CC silently proceeds to the next invocation. When running with strace, the log fills with strace: /tmp/cc-trace.log: Disk quota exceeded confirming writes to /tmp are being blocked by EDQUOT, which is the actual root cause.

Root cause

• /tmp/claude-$UID/ grew unbounded (6.3G in my case) with no rotation
• Once user's tmpfs quota is saturated, writes silently EDQUOT into the void
• Bash tool implementation captures stdout/stderr via a temp file in /tmp/; the temp file write fails and CC reads back an empty result as if the command had no output
• The EDQUOT error is never surfaced to the tool result or to the model

Fix suggestions

1. Rotate/cleanup /tmp/claude-$UID/ — evict entries older than N hours, cap total size, or clean on session exit.
2. Surface write errors from the tool output capture path — if the temp file write fails, the Bash tool should report the underlying error (EDQUOT, ENOSPC, etc.) rather than returning empty output with a confusing exit code.
3. Fail loudly at startup if /tmp/claude-$UID/ is already at or near the user's tmpfs quota.

Workaround

rm -rf /tmp/claude-$UID/

Bash tool immediately starts working again after this, no restart required.

Notes

This took hours to diagnose because:

• The bash tool reports a non-zero exit code with zero output, which looks identical to many other failure modes
• No error is logged anywhere by Claude Code
• The debug log shows Shell snapshot created successfully and Spawning shell without login and then just moves on as if everything was fine
• The regular terminal works fine, so the user assumes their shell environment is healthy
• autoUpdates: false does not actually prevent native installs from updating (see autoUpdatesProtectedForNative), which added version confusion during diagnosis