claude-code - 💡(How to fix) Fix Bash/Read tool results intermittently return empty (then flush late, redundantly) on Linux — NOT length/concurrency-correlated; same symptom as stale-closed #36038

Summary

In a long, highly-concurrent session, Bash and Read tool calls intermittently return empty content to the model even though the command succeeded (exit 0) and the file/stdout is correct (side effects like file writes happen). This is the same symptom as #36038 ("Bash tool output silently empty … in long sessions"), which was reported on Windows/Git Bash and stale-closed (not_planned) without a fix — but it reproduces here on Linux, so the underlying cause does not appear to be Windows-specific.

A distinctive extra detail: the missing outputs are not dropped — they flush late, arriving as a batch in a later turn, after the calls had already been retried successfully.

Environment

• Claude Code 2.1.156 (native installer, claude-native-aarch64). Latest at time of report: 2.1.157; stable tag: 2.1.148.
• Platform: Linux (kernel 6.8.x), shell: zsh.
• Usage pattern: long session with heavy concurrency — many background subagents / Workflow runs and parallel Bash batches.

Steps / observations

1. Run a Bash command that reads or writes a file (cat, wc -l, git log, od -c, etc.). The tool result comes back blank.
2. The data was never missing: od -c <file> (or a re-read) in a following call shows the full bytes; the command had completed and its side effects (file writes) were present.
3. The backed-up outputs later arrive as a batch of ~10–15 previously-blank results at once in a single assistant turn — typically one to a few tool-call rounds later, and after I had already re-run those calls and received successful results. So it is redundant / duplicate late delivery (the originals eventually flush on top of the successful retries), not merely slow original delivery.
4. Onset and persistence match a buffer filling up: it starts after the session has run long / pushed a lot of output, and once it starts, blanks recur in clusters.
5. Affected both the main loop and background subagents, intermittently (the same session also had subagent calls that returned output fine — e.g. a freshly-spawned verification subagent worked).
6. Edit/Write success confirmations still arrived during stretches where Bash/Read result bodies were blank.

Expected

Each tool result is delivered to the model in the turn the tool completes.

Actual

The result body is intermittently empty for that turn; the content arrives batched in a later turn, redundantly, after retries have already returned.

Relationship to existing issues

• #36038 ("Bash tool output silently empty on Windows (Git Bash) in long sessions"; CLOSED not_planned — auto-closed as stale for inactivity; no maintainer response, no fix): the closest prior art and almost certainly the same bug. Its body describes this symptom near-verbatim — empty output even for echo, worsening as the session gets longer, "once it starts, ALL subsequent Bash calls return empty," commands still execute (file writes happen) but stdout/stderr isn't captured, delegating to an Agent/subagent works fine, and restarting fixes it temporarily. A commenter hypothesized pipe-buffer exhaustion (the pipe fills over a long session, after which reads return empty). It was reported on Windows 11/Git Bash and carries platform:windows, but nothing in it establishes the cause as Windows-specific — and this report shows the same behavior on Linux at 2.1.156. Likely a never-fixed, cross-platform buffering bug that was simply stale-closed; worth reopening or superseding.
• #54847 (tool dispatch stalls silently, 2.1.121–2.1.123, no disk side-effects): different — here commands do have side effects, and the version is past that regression window.
• #53862 (interactive Bash hangs after success; tool_result not written): related, but tagged platform:macos / area:providers and described as a hang, whereas this is a later redundant flush on Linux with no proxy.
• #39830 (parallel Agent calls lose tool_result; closed): surfaced as a [Tool result missing] placeholder; here results are blank then flushed late, no placeholder.

Hypothesis

A result-delivery buffering / back-pressure problem rather than a dispatch failure: commands run and their side effects land, but stdout/stderr isn't captured for that turn. This matches #36038's pipe-buffer-exhaustion hypothesis (a long, high-throughput session fills a buffer; once full, reads come back empty), and is consistent with what's seen here: onset after a long, concurrency-heavy session (many parallel Bash batches + background subagents), then a late batched flush once the buffer drains. The separate "Bash output lost when running multiple Claude Code sessions in the same project directory" changelog fix feels adjacent.

Two wrinkles worth noting:

• The late flush is redundant with successful retries (duplicate late delivery), which argues against "just latency."
• At least once a result came back not merely empty but containing fabricated text that was never in the underlying file (caught by re-reading the file a different way) — so the failure mode isn't always a clean blank.

Impact

In a long multi-agent session this is corrosive: a blank result is easily misread as "the command failed / the file is empty / something is broken," prompting a wrong (sometimes destructive) corrective action when the operation actually succeeded.

Workarounds observed (from #36038, and consistent here)

run_in_background + reading the output file; delegating to a fresh subagent; periodic /compact; restarting the session.