Correcting an agent while it's still working (queued messages only land after the turn)

[gentoosys]

What am I trying to do

Correct an agent while it's working. Long turns are where this matters: I watch it head down the wrong path, or I remember a constraint I should have stated, and I want that in front of it now rather than after it has spent five more minutes building on the wrong assumption.

In the CLI this is second nature — I type while it's running and the agent picks the message up during the turn, so my correction lands before the wasted work happens.

How I do it today

In Paseo I type the correction and it sits queued until the turn finishes. So either I wait, and the agent finishes work I already know is wrong, or I interrupt the turn manually, then retype or re-send the message myself. The second is what I actually do, and it costs me the partial work the turn had already done.

Where Paseo gets in the way

The queue is deliberately gated on the turn being over:

if (agent && agent.status !== "running") {
  getHostRuntimeStore().drainQueuedAgentMessage(serverId, agentId);
}

Queued text lives client-side and is only released once status leaves running. There's no way to say "deliver this one now" — the queue is a waiting room, not a channel to a running agent. I assume that's deliberate caution after #2568, where writing at the wrong moment destroyed the message outright, and I'm not asking for that to be undone.

Worth being precise about what's actually possible, because I looked into it before writing this up. True mid-turn injection — the agent noticing a new message at a tool boundary and carrying on with the same turn — is what the TUI does with in-process access, and as far as I can tell it is not available to SDK/stream-json consumers. The Agent SDK streaming input docs describe additional messages as queued and processed in order, and the documented way to redirect a running agent is interrupt() followed by the new message. There's an open Anthropic request for a stdin interrupt message for --input-format stream-json (anthropics/claude-code#41665), filed by someone building exactly this kind of multi-agent overlay, which suggests the gap is known upstream and not something Paseo can simply switch on.

What would the flow look like if it worked for me

A Send now action on a queued message: interrupt the current turn and deliver it immediately, as one action instead of the interrupt-then-retype dance I do by hand. Paseo already implements interrupt, and the queued text is already sitting there, so from the outside this looks like wiring two things it can both already do rather than new capability.

Semantics I'd expect: the turn stops where it is, whatever it produced stays in the timeline, and the queued message becomes the next turn — so it's clearly "stop and redo with this", not "the agent quietly absorbed my note". Keeping normal queueing as the default behaviour, with this as an explicit opt-in per message, would mean nothing changes for people who like the current safety.

If the upstream stdin-interrupt request ever lands, the same button could become genuinely mid-turn without the workflow changing.

For context on why this matters more to me than it might to others: my sessions are long-running infrastructure work rather than short code edits, so a turn can run for many minutes and a wrong assumption early on wastes all of it.

[gentoosys]

Following up on my own post, because I dug into this further and the picture is clearer than when I wrote it — and I think it changes what's worth doing here.

This is an upstream parity gap, not something Paseo is behind on. Anthropic's own desktop app drives Claude Code exactly the way Paseo does: it spawns the same local claude install as a subprocess in streaming-input mode with --input-format stream-json (accidentally documented in anthropics/claude-code#54462, where someone captured the spawn command, and noted again in anthropics/claude-code#71726). It reads the same ~/.claude/settings.json and writes the same ~/.claude/projects/<path>/<id>.jsonl.

And it has the identical limitation. There's an open request against it — anthropics/claude-code#71726, "Desktop app: inject queued messages mid-task between tool calls (CLI steering parity)" — describing the Code window holding messages until the turn completes while the TUI injects them at tool-call boundaries. Two further open requests ask for the same capability generally: #64624 (real-time steering) and #30492 (priority message channel).

So the split is by how the agent is driven, not by which client:

• TUI in a PTY → steers at tool-call boundaries. #49373 is effectively the complaint that it does this too eagerly.
• --print / stream-json front-ends → queue to end of turn. Paseo, and Anthropic's own desktop app, both land here.

What I think that means for this thread: true mid-turn injection isn't currently reachable from where Paseo sits, so it isn't worth attempting until the engine exposes it. If #71726 or #30492 ships, it becomes available to Paseo the same day it becomes available to the desktop app.

The smaller thing I asked for still stands on its own though: a Send now on a queued message that interrupts and delivers as the next turn. That's within reach today, needs nothing from upstream, and covers most of what I actually want — stop building on the wrong assumption now rather than in five minutes. It just shouldn't be mistaken for steering: it ends the current turn rather than folding into it.

Happy for this to sit until upstream moves. I mostly wanted the architectural constraint on record so nobody spends time trying to work around something that isn't Paseo's to fix.

[gentoosys]

Rewriting this comment — I've now tested both sides and my earlier suggestion (just forward the queued message while the turn runs) was wrong. It doesn't work, and the reason points at something more specific.

The engine does steer

Driving the CLI directly, no GUI in the middle, on claude-code 2.1.220:

claude --print --verbose --input-format stream-json --output-format stream-json \
       --allowed-tools "Bash(sleep:*)"

Turn 1 asked for five sequential sleep 8 calls. Fifteen seconds in, with the first tool call still running, a second user message went in on stdin. Four of the five sleeps never ran and it all came back as one result (num_turns: 2). Session transcript:

13:30:17  assistant        tool_use  Bash(sleep 8)
13:30:32  queue-operation  enqueue                      <- arrives mid-turn
13:30:32  attachment       {"type":"queued_command","parentUuid":"ef1df7a3-…"}
13:30:46  user             tool_result
13:30:46  queue-operation  remove                       <- released AT the tool boundary, 14s later
13:30:49  assistant        "BANANA"

This is the behaviour reported from engine 2.1.217 onward in anthropics/claude-code#71726. It's undocumented, and note the observable form is a queued_command attachment in the session JSONL — not a <system-reminder> in the stream-json output, which is what the issue thread describes and what I initially grepped for and wrongly concluded was absent.

Paseo cancels instead

Same thing through Paseo 0.2.5, sending while a turn was running. Same transcript format:

13:45:28  user             (turn 1 prompt)
13:45:29  user             "[Request interrupted by user]"    <- turn cancelled ~1s later
13:45:29  queue-operation  enqueue
13:45:29  queue-operation  dequeue                            <- same second, no boundary wait
13:45:29  user             (second message, as a new turn)

No queued_command attachment, no wait for a tool boundary, and the in-progress work is discarded. Paseo's own source says why:

// packages/app/src/composer/index.tsx
// Reuse the regular send path; server-side send atomically interrupts any active run.

So both modes miss the capability: sendBehavior: "queue" holds until the turn ends, and "interrupt" — or forwarding a queued message early, which is what I originally asked for — routes through a send that cancels first.

What would actually be needed

The send path unconditionally opens a new turn: it emits turn_started and registers a fresh cancelCurrentTurn before pushing to the SDK input. So skipping the interrupt on its own wouldn't produce steering, it would produce two concurrent foreground turns in a model that assumes one.

What steering needs is a delivery mode distinct from send: push the message into the existing session input without opening a turn — no turn_started, no cancel, response attributed to the turn already running — and let the engine place it at the next tool-call boundary. That's turn accounting rather than queue behaviour, which is why I don't think this is a small change, and why I'd rather flag it accurately than under-describe it.

Three things worth building in if it's ever picked up:

• Gate on engine version. The behaviour is absent below 2.1.217, so on older engines the current handling should stay.
• This is not the bug: idle-GC'd Claude agent silently destroys the next user message instead of respawning #2568 hazard. That was writing to a collected/dead transport, which destroyed the message. This is a live transport with the engine's own enqueue/remove accounting for exactly this case.
• Delivery timing is bounded by tool calls. A message lands at the next tool-call boundary, so a turn that's only generating text has no injection point until it ends. Any UI would need to show "waiting to deliver" honestly rather than implying instant arrival — and Queue messages to send at true end-of-turn, not next LLM pause anthropics/claude-code#49373 is the mirror-image complaint from CLI users that boundary delivery can be too eager, so per-message opt-in still seems right.