[Bug] Queued steering message is parked forever after Escape interrupts the turn

[ruttybob]

Affected area: TUI / Agent core

What happened?

When a steering message is queued during an agent turn and the user then presses Escape, the session appears to hang: the turn is interrupted, but the queued message is never delivered and nothing further happens automatically.

Looking at the code, this is a parked queue with no affordance:

• Submitting mid-turn queues the message server-side (next_turn_boundary lane, AgentSession.steer()), and the TUI shows the queued preview while streaming.
• Escape interrupts via requestAbort(), which suspends the session input pump. The queue is preserved, but the only things that resume it are submitting a new message (Enter) or editing the queue (the queued-message browser, which calls resumeQueuedWork()).
• Pressing Enter on an empty editor is a no-op, so from the user's perspective the steering message silently vanished and the session is stuck.

Upstream pi handles this deliberately: its Escape handler (interactive-mode.ts, onEscape → restoreQueuedMessagesToEditor) clears both queues, puts the queued texts back into the editor joined with blank lines, and only then aborts. So in pi, Escape means "stop and give me my draft back".

Steps to reproduce

1. Start an interactive session and trigger a long agent turn (e.g. a task with several tool calls).
2. While the turn is streaming, type a message and press Enter — it is queued as steering.
3. Press Escape to interrupt the turn.
4. Observe: the turn stops, the queued steering message is never delivered, and pressing Enter with an empty editor does nothing. The session looks frozen until you type and submit a new message.

Expected behavior

Unclear — that is the point of this discussion. The candidates I see:

• A. Auto-deliver after interrupt. After an Escape-driven abort, the queue resumes automatically, so a steering message effectively becomes "stop this turn and act on my message next". Risk: an explicit "stop" immediately launching a new turn is surprising, and it collides with the double-Escape tree/clear affordance.
• B. Return queued text to the editor (pi parity). Escape clears the queue and restores the drafted text(s) for manual re-send. Simple and predictable, but loses server-side durability and image attachments, and merging multiple queued messages into one editor buffer is lossy.
• C. Keep the queue, add an affordance. The current parking behavior stays (durable queue, survives restarts), but the idle state clearly shows it — e.g. a line above the editor like 1 queued (steering) · Enter to send · <key> to edit — and Enter on an empty editor sends the parked queue instead of being a no-op.

C feels closest to Prime Agent's design (durable, inspectable queue), B is closest to upstream pi, and A matches what programmatic aborts already do (queues drain on continue). Curious which direction maintainers prefer; happy to prototype any of them.

Prime Agent version: 0.7.2 (source, dev build)

Environment: macOS 15, zsh + tmux

Additional context

• The queue browser (edit/delete/reorder queued messages) already exists and resumes the queue after edits, so the gap is specifically: no visible affordance in idle state, and no one-key "send the parked queue" action.
• pi reference: packages/coding-agent/src/modes/interactive/interactive-mode.ts onEscape → restoreQueuedMessagesToEditor({ abort: true }) (queue cleared before abort, so no auto-continue).