fix(tui): restore queued messages when a session is interrupted

[chaitanyarahalkar]

Issue for this PR

Closes #33812

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

If you type a follow-up while the agent is streaming and then press ESC twice to interrupt, the message you typed is lost. It is still persisted server-side, but no turn ever runs for it and the QUEUED badge disappears, so you have to retype it.

The cause is that the interrupt handler aborts without checking whether a user message arrived after the running assistant turn started. runLoop only picks up a queued message when the current assistant message completes, so interrupting before that point leaves the message with nothing to consume it.

Before aborting, the handler now collects user messages newer than the running turn and puts their text and file parts back into the prompt box via PromptRef.set — the same call session.undo already uses to return a reverted message's text to the input. It only restores when the prompt is empty, so it will not overwrite a draft you have already started typing.

I used the client-side restore rather than re-arming the runner after cancel. Re-arming would make double-ESC sometimes stop the session and sometimes immediately start another turn, and when you interrupt you usually want to edit the message before resending it anyway.

One thing this does not fix: the orphaned user message still sits in the transcript. Removing it needs a session.revert call, which seemed like a separate change.

How did you verify your code works?

bun test test/prompt/queued.test.ts in packages/tui — 4 new tests covering the queuedMessages selector: one queued message, several stacked up, an idle session, and an abandoned turn that a later turn already completed.

Full packages/tui suite: 195 pass, 1 skip, 0 fail. Baseline on dev is 191 pass, so that is the 4 added here and no regressions.

To reproduce by hand: start a turn, type a second message while it is streaming, then press ESC twice. Before this change the input box is empty and the text is gone; after it, the text is back in the box.

Screenshots / recordings

No visual change — the diff is behavioural. The observable difference is that the prompt box contains your text after an interrupt instead of being empty.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found several related PRs that may be of interest, though none appear to be direct duplicates of PR #39189:

Related PRs:

1. fix(opencode): CLI queued prompt drain after Esc interrupt #35008 - fix(opencode): CLI queued prompt drain after Esc interrupt - Directly related; addresses a similar issue with queued prompts after interrupt, but for the CLI
2. fix(tui): queue busy prompts after interrupt #34530 - fix(tui): queue busy prompts after interrupt - Related to queued prompt handling during interrupts
3. feat(tui): clear prompt input on double escape #35036 - feat(tui): clear prompt input on double escape - Related to the double-ESC interrupt behavior
4. feat(opencode): interrupt a running subagent — steer / cancel / abort #32425 - feat(opencode): interrupt a running subagent — steer / cancel / abort - Related to interrupt handling infrastructure

These PRs suggest there's been ongoing work in this area (interrupt handling and queued messages), but PR #39189 appears to be unique in addressing the specific issue of restoring the lost queued message text to the input box after an interrupt.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍