Bash tool stdout duplicated N times in tool results (N grows per call); command runs once — capture/render bug, not the shell

Summary

Bash tool results are duplicated many times over. Each line of a command's stdout is repeated dozens-to-hundreds of times in what the tool returns, and the multiplier grows as the session goes on (started ~16x, later 100x+). The command itself runs exactly once — verified with a side-effect counter — so this is a capture/render-layer duplication, not repeated execution. It appears to start right after a single very large command output.

Environment

• Claude Code: 2.0.72
• Node: v20.19.4
• OS: Ubuntu 24.04.5 LTS — Linux 6.17.0-1019-aws x86_64
• Shell: bash 5.2.21, non-interactive ($- = hB)
• TERM: xterm-256color, no tmux/screen
• Model: Opus 4.8 (1M context)

What I see

Every Bash tool result shows the command's stdout repeated many times:

• printf 'PROBE_OK\n' -> PROBE_OK repeated ~hundreds of times
• echo RESET -> dozens of RESET
• wc -l < file (real answer 1) -> 1 printed dozens of times

The duplication factor is not constant — it increases over the life of the session.

The command runs once; only the display is duplicated (verified)

Reproduced with a side-effect counter so execution count is observable independently of display:

1. : > counter.txt # reset
2. echo tick >> counter.txt # append exactly one line; stdout showed APPENDED_ONCE ~40x
3. wc -l < counter.txt # -> 1

The file has exactly 1 line despite the ~40x display. So the command executed once; its stdout was duplicated only in the tool result returned to the model.

Ruled out — not the user's shell or hooks

• Shell is non-interactive; PROMPT_COMMAND, PS0, PS1, BASH_ENV, ENV all empty; trap -p empty.
• stdout redirected to a file is a single clean copy — so the stream leaving bash is single. The duplication is on the Claude Code capture/render side.
• No hooks in ~/.claude/settings.json or settings.local.json; no ~/.claude/hooks/.
• Process chain: bash is a direct child of claude.

Additional symptom (same session, later)

As the session went on it degraded further: the session scratchpad dir appeared to roll back to an earlier snapshot (recently-written files vanished), and some tool calls returned empty ("no output"). Attempts to file THIS bug report via gh from inside the affected session could not be confirmed because the confirmation output was itself eaten/duplicated. Consistent with corrupted client-side session/output state.

Suspected trigger (hypothesis, not proven)

The amplification began immediately after a command that scanned a ~13 MB .jsonl file and printed a large amount of raw content — potentially containing NUL / control characters — to stdout. Hypothesis: a single oversized/binary-ish stdout corrupts the client's output-stream buffering, after which each subsequent tool result replays an accumulating buffer.

Impact

Not harmful to state (commands run once), but floods tool results, inflates output token usage (each result N× larger), and forces a redirect-to-file workaround.

Workaround

Redirect command stdout to a file and read it back. Restarting the session is expected to clear the corrupted buffer.

Minimal repro (best-effort)

1. In a long-running session, run a command that dumps a large amount of raw/binary-ish content to stdout (e.g. cat a multi-MB JSONL with embedded control characters).
2. Then run any trivial command, e.g. echo hi.
3. Observe the output duplicated N times, with N growing on subsequent calls.