[BUG] `Messages sent during a Bash tool call are silently destroyed when the call returns is_error: true`

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?

Distinct from #20431: that issue reports intermittent loss of queued input with no identified mechanism, and is closed and locked. This report identifies a deterministic trigger — the message is dropped exactly when the in-flight tool call returns is_error:
true — with a two-command reproduction. Not #82772, which is a dequeue-and-hang failure.

When I send a message while a Bash tool call is running, Claude Code normally delivers it by appending a {"type":"text"} block to that call's tool_result envelope. If the call returns is_error: true, that block is never added: the message never reaches the
model, and it is never written to the session transcript, so it cannot be recovered afterwards.

Neither side gets any indication. I watch my message vanish; the model sees nothing and carries on as though I had said nothing — which is how I found it, after a correction I typed was lost and the model then stated the opposite of what I had told it.

Reproduced on 2.1.247 (Linux, bash): run sleep 15; exit 1 and type a message while it runs — destroyed. Run sleep 15; exit 0 and type a message while it runs — delivered. Four arms across two command families, all consistent.

What Should Happen?

A message typed while a tool call is in flight should be delivered regardless of that call's outcome — the same way it is delivered when the call succeeds. The call's exit status and error flag are unrelated to whether the user's input is worth keeping.

Failing that, the loss should at least be visible and recoverable: warn me that my message was not delivered, and write it to the session transcript either way.

Error Messages/Logs

Steps to Reproduce

Two runs, ~15 seconds each. No repo, no config, no special permissions needed.

Arm A — failing call (the bug):

1. Have Claude Code run this Bash command: sleep 15; exit 1
2. While it is running, type any marker — e.g. TESTC — and send it.
3. Wait for the turn to finish, then ask the model what you just said.

Result: the model has no record of the message. The tool_result envelope in ~/.claude/projects/<slug>/<session>.jsonl shows Exit code 1 with no attached {"type":"text"} block, and the marker appears nowhere in the transcript.

Arm B — control, identical except the exit status:

1. Have Claude Code run: sleep 15; exit 0
2. While it is running, type a different marker — e.g. TESTD — and send it.
3. Wait for the turn to finish.

Result: the model receives the marker and can echo it back. The envelope carries a second content block: {"type":"text","text":"TESTD"}.

Only the exit status differs between the two arms. Reproduced on 2.1.247; also reproduced independently with a git command pair (exit 0 vs exit 128), so it is not specific to sleep.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.247 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

``Ubuntu 24.04.4 LTS, Linux 7.0.0-30-generic #30~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 7 13:27:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux, GNOME Terminal (VTE 0.76), bash, claude-opus-5[1m]``