[BUG] No non-destructive way to steer an in-flight task: correction sits unread for minutes, and interrupt terminates running bash processes and subagents

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?

There is no way to add a correction or missing context to a task that is
already running without either waiting a long time or destroying the
task.

Sending the message works eventually, but it can sit for minutes and
many tool calls before the model sees it, while the model continues
executing against instructions I have already corrected. It does get
delivered mid-turn, so this isn't a case of waiting for end of turn. It
waits for some later point whose criteria I can't determine from the
outside.

Interrupting delivers the message immediately, but it terminates
in-flight bash processes and any running subagents, discarding work that
was already complete and correct.

So the only fast path is also the destructive one.

To be clear about what this is not: this is not a request for messages
to be held longer. Follow-up tasks already work well. Saying "do this
after the current task" reliably gets acknowledged and handled
afterward, without needing any queue mechanism. The gap is specifically
mid-task steering, which is a different behavior from deferred
follow-ups and is not served by the same mechanism.

Noting the surface explicitly because several CLI reports have been
consolidated into #30677, which is labeled platform:vscode and
describes the opposite behavior (messages interrupting immediately).
This is a CLI report.

What Should Happen?

A message sent during a running task should be delivered on the very
next tool result.

Every tool call already round-trips through a user-role message: the
assistant emits a tool_use block, and the harness sends back a
tool_result block inside a user message. Adding my text is just a
second content block on a message that is already being constructed:

{
"role": "user",
"content": [
{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." },
{ "type": "text", "text": "wait, use the other config file" }
]
}

That is valid on the first tool result after I hit enter. Nothing has to
be interrupted, nothing has to be torn down, and no process has to be
killed, because a user message is already being sent at that exact
point.

What happens instead is that my text sits through many more of these
round trips before it appears. It does land mid-turn, so this isn't a
case of waiting for end of turn. It waits for some later point whose
criteria I can't determine from the outside, and in the meantime the
model keeps executing against instructions I have already corrected.

Failing that, interrupting to deliver a steer should at minimum not
terminate in-flight bash processes and subagents. Their completed work
is usually still valid, and only the direction of the task needs to
change.

Error Messages/Logs

None. No errors are produced; the failure is behavioral.

Steps to Reproduce

1. In one turn, launch a batch of parallel background agents (six, in my

case).

1. While the first is still spawning, send three separate corrections as

normal messages, e.g. "use a different agent for X," then two more
adjusting other agents in the batch.

1. Without interrupting, watch them sit. In my experience they go unread

for minutes while the batch keeps launching against the original
instructions. Count how many agents spawn before anything is picked
up.

1. Repeat, but interrupt instead. Observe that only the first pending

message is read; the remaining two stay pending, so the model acts on
partial context. Each additional correction required its own
interrupt.

1. Observe the interrupt also lands mid-spawn, killing or preventing

whichever agents hadn't launched yet. In my case one had launched and
five had not. Recovery meant confirming the first survived and
relaunching the rest. Roughly 5-10 minutes plus re-spawn overhead.

Note that this appears intermittent and timing-dependent. Same session,
same morning, a different mid-turn message ("I already downloaded that
file, have an agent file it instead") arrived alongside a tool result,
was read without any interrupt, and was folded into the plan with zero
disruption. That is the behavior I'd expect every time.

The difference between those two cases is what I can't account for from
the outside, and it's why I don't think this is a fixed delay so much as
an unclear gating condition.

Claude Model

Multiple models, Worse on Fable 5.1

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.263

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Model: Claude Fable 5.1 (not available in the model dropdown above, so
noting it here).

Claude Code runs inside WSL2 on this machine, but this is not
WSL-specific: I see the same behavior on native Ubuntu.

Notably, corrections land far more promptly on Claude Cowork, which runs
the same model. That suggests the gating is in the local CLI's message
handling rather than in the model or the API.

WSL2 (where Claude Code runs):
Claude Code: 2.1.263
Node: v22.22.0
npm: 10.9.4
OS: Ubuntu 22.04.5 LTS
Kernel: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
Shell: /bin/bash
TERM: xterm-256color

Windows host:
Claude Code: 2.1.263
Node: v24.13.0
npm: 11.6.2
OS: Microsoft Windows 11 Pro 10.0.26100
Arch: AMD64
PowerShell: 5.1.26100.7920
Terminal: Windows Terminal