[Feature]: Return the prompt to the composer when aborting before the model replies

[kele98]

Product or interface

CLI - interactive TUI

Use case and problem

When I submit a prompt and immediately realize it has a typo, targets the wrong file, or asks the wrong question, the only escape is Esc — which stops the turn and leaves the prompt stuck inside a cancelled turn in the transcript. I have to retype it or recall it with Up and edit from history, losing the "fix one word and resend" flow.

Today the queue flow already returns queued messages to the composer (Alt+Up), and crash recovery already restores interrupted submissions on relaunch — but the most common case, "I just sent it and regret it", has no path.

Desired behavior

State-gated restore, keyed on what the aborted turn actually produced — not a timer:

When the user aborts a running turn AND that turn has produced no user-visible output (no assistant text, no tool call, no steer message), the prompt text returns to the composer for editing. Thinking does not disqualify: it is internal model process and the most common regret moment. Turns with output keep today's stop-only behavior, so intentional stops are never second-guessed.

Interaction example:

type a prompt, press Enter
Esc                                        (before any reply/tool output)
  -> "Stopped · message restored to the Composer."
  -> the prompt is back in the composer, editable
  -> the aborted turn's transcript row is removed
type the correction (merges below the restored text), Enter to resend

Esc after the model started replying
  -> turn stops as today; composer stays empty; transcript kept

Acceptance criteria:

• The trigger is the confirmed stop of the aborted turn on the existing abort funnel — delegated-only stops (root still running) never fire it; a stop the runtime does not confirm never fires it.
• Restore merges with text typed during the stop (never overwrites in-progress typing); restores drop the matching pending retry so a relaunch cannot duplicate the text; side conversations are skipped.
• Exiting the app after an abort still persists the restored draft (existing draft-recovery path), so the text survives to the next launch.
• A restore failure reports a warning without breaking Esc handling.

Why state-gated instead of a time window: a timer races the model's first token and behaves non-deterministically; gating on "no output yet" captures exactly the regret window with zero timing sensitivity. Why not unconditional: interrupting a turn that is already replying usually means "stop", not "give my words back" — unconditional restore would fight that intent.

Platform

Multiple platforms

Alternatives and additional context

What I tried / considered:

• Up input-history recall — works, but loses cursor position and attachments and requires knowing the shortcut.
• /history Edit on the committed message — a runtime-level rewind; far heavier than the regret-window case needs.
• Doing nothing — the cancelled turn keeps the text, but editing it means retyping.

I implemented this on my fork (per the collaborators-only PR policy, not opening a PR; feel free to review the fork commit and port it as a maintainer PR — partial adoption welcome):

• Branch feat/abort-prompt-restore, single commit 2dfc60b on top of current main: kele98@2dfc60b
• TUI-only: 6 files (packages/tui abort funnel + app wiring + a small draft-lifecycle helper + tests + the Esc shortcut row in README/README_ZH updated in both languages). No runtime, persistence, or protocol changes.
• Validation: tui-app.test.ts 270/281 — the 11 failures are the pre-existing zh-CN locale baseline on this machine, reproduced identically with the patch stashed; new/adjusted cases cover no-output restore, thinking-only restore, after-output no-restore, unconfirmed-stop no-restore, delegated-only-stop no-restore, merge-with-typed-text, and a two-instance relaunch non-duplication test through real draft persistence. pnpm verify passes all gates up to test:capabilities (stops on the same 23 environment-baseline failures: 11 locale assertions + 12 Windows symlink EPERM); remaining gates pass individually (status-contract 9/9, smoke 16 pass/1 skip, byok 11/11); typecheck and build clean. Interactive smoke via a real pty against a local fixture provider (stream holds open until abort) verified both timings end-to-end. Not claimed: macOS/Linux manual acceptance, live-model runs, Desktop app.

Key semantics (trigger scope, thinking exemption, transcript-row removal) are all open to adjustment if maintainers prefer a different shape.

[hetaoBackend]

Thanks for the detailed proposal and the implementation link. The product behavior is valuable, and the state-gated trigger is much better than a timer: a confirmed root stop with no assistant text, tool call, or steer output is a reasonable definition of the regret window.

I reviewed the patch against the current TUI runtime. Before this is adopted, I see two correctness boundaries that need to be addressed:

1. Settled stop, not merely accepted stop. runCoordinator.abort() can return after the cancellation-settlement timeout while the run is still in a retiring state. Restoring the composer from the abort() boolean alone can race a late stream/result-delivery event. The restore should fire only after the root turn is confirmed settled, or be attached to the existing retirement/settlement event.

2. TUI transcript removal does not necessarily retract Runtime history. The TUI clears user:${turnId} locally, but opening or refreshing a session can hydrate the same user message again from Runtime history. If the desired behavior includes removing the transcript row without a duplicate on relaunch, we need either a Runtime-level withdrawal/retraction operation for an unoutput turn, or an MVP that restores the composer while retaining a clearly marked cancelled user row.

Also, the restore should preserve the complete original submission where possible; the current path reconstructs only file-backed attachments and does not cover every transport-only/asset-backed attachment. The pending-retry discard should also be verified against the persisted recovery file, not only the in-memory map.

I agree with the proposed no-output, thinking-only, delegated-only, side-conversation, and failure semantics. The fork is a good starting point, but I would make the settled-stop and Runtime-history semantics explicit before merging.

[kele98]

Follow-up commit on feat/abort-prompt-restore (base 2dfc60b): kele98/minimax-code@191ebe9

1. Settled stop — after a confirmed root-turn stop, the restore waits for whenIdle() (the existing settlement chain) bounded by the shared 1s settlement constant (now exported so the windows can't drift); on timeout it skips silently — an unbounded wait would hang the funnel, since nothing resolves idle waiters in that state. Dedicated test (parked whenIdle → no restore, no hang).

2. Marked row (your option A) — the user row stays, explicitly upserted to cancelled (markTurn skips succeeded cells) and rendered with a muted × Cancelled marker. Re-hydration can no longer duplicate. Runtime withdrawal noted as a possible follow-up (the rewind primitive exists; this row is its fallback).

3. Attachments (partial, disclosed) — assetId entries ride transportAttachments on resubmit; no composer chip for asset-only; transportContent/intents/paste structure not reconstructed (/edit remains full-fidelity). This passthrough has no automated test yet.

4. Discard vs persisted file — discardPendingRetries() write-through flushes (mirrors settleSubmission), so the retry is off disk at Esc time; relaunch test verifies the end state, the hard-crash window isn't directly exercised.

Validation — typecheck clean; tui-app.test.ts 270/282 (11 pre-existing zh-CN locale + 1 real-bash timing case that passes in isolation both with and without the branch stashed); all 7 restore tests pass; other gates ran during development, the delta since 2dfc60b is six TUI files (incl. the one-line constant export); full verify on CI.

Known boundaries — restore scope unchanged (no output/tool/steer; thinking allowed; side skipped; delegated-only never fires); the 1s constant is reused (same drain, one honest constant — worst-case Esc ~2s on a no-output abort, intentional stops unaffected); cross-attempt dedupe is code-verified without a dedicated test (happy to add); the marker is session-ephemeral and can rarely appear without a restore (cosmetic).

[hetaoBackend]

Thanks for the follow-up. I reviewed 191ebe93c541b8d6526c997acb52b03284595586 and ran focused local checks. The bounded settlement wait, retained cancelled row, and recovery-file flush address important parts of the earlier feedback.

There is still an attachment-loss bug in the restore/resubmit path:

• Start with a user row containing one file-backed attachment (local.png) and one asset-only attachment (asset.png).
• Abort before output, let the prompt restore, then resubmit.
• The composer retains the local attachment, but the outgoing request contains only asset.png.

I reproduced this with a temporary TUI app test using a synthetic transcript attachment fixture and a mocked runtime. The assertion expected both attachment names; the actual second sendMessage request contained only asset.png.

The restore callback builds draftAttachments from file paths and transportAttachments from asset IDs. When any transport-only attachment is present, the recovery path preserves that transport list, and submission selects submission.transportAttachments ?? submission.attachments. The partial transport list therefore replaces the file-backed list instead of including it.

Please preserve the complete attachment set through restore and resubmit, and add a regression covering mixed file-backed and asset-only attachments. Preferably, retain the original submission snapshot keyed to the turn rather than reconstructing it from the display cell; that also provides a route to preserving transport content, client intent, and editor metadata. If this remains a narrower MVP, its supported submission types should be explicit and unsupported submissions should not silently lose content.

Validation here: six selected existing abort/restore tests passed; the added mixed-attachment regression failed as described. I did not run full pnpm verify, live-model acceptance, or cross-platform validation. This is close, but I would fix the attachment-loss path before adoption.