Best possible solution:

Land a canonical TUI pending-submit fix that preserves current main's stale-busy clearing, guards draft restoration against editor races, and then closes or supersedes overlapping pending-message PRs.

Do we have a high-confidence way to reproduce the issue?

Yes for the patch defect by source inspection: Esc starts abortActive asynchronously, abortActive returns restoredDraftText only after awaiting abortChat, and the later editor.setText can overwrite text typed during that gap. I did not run an interactive PTY repro in this read-only review.

Is this the best way to solve the issue?

No, not yet. Restoring a still-unregistered aborted draft is a reasonable fix direction, but the best version must make the restore conditional on the editor not having changed and should include focused regression coverage for that ordering case.

Full review comments:

• [P2] Avoid overwriting editor input after async abort — src/tui/tui.ts:1410
  When Esc aborts a pending draft, abortActive() waits for client.abortChat() before resolving restoredDraftText. During that await the editor is still active, so if the user starts typing a replacement prompt, this setText() overwrites it with the aborted draft. Capture the editor text/state at Esc time and only restore when it is still safe, with coverage for typing before the abort resolves.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 892602eaba07.

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

• P2: This is a normal-priority TUI state-machine bugfix with limited blast radius but real user-visible editor/message impact.
• merge-risk: 🚨 compatibility: The PR changes existing Esc abort behavior by restoring aborted prompt text into the editor, which can affect current TUI workflows.
• merge-risk: 🚨 message-delivery: The patch can overwrite newly typed replacement text after abort, causing user input to be lost or sent differently than intended.
• merge-risk: 🚨 session-state: The diff changes pending run, optimistic message, pending draft, and history reconciliation state across TUI abort and reload paths.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external contributor proof gate is not applied because this PR is maintainer-authored/labeled; the PR body supplies focused unit/typecheck proof but no live interactive TUI proof.

PR surface:

Source +94, Tests +47. Total +141 across 8 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs src/tui/tui-command-handlers.test.ts src/tui/tui-session-actions.test.ts src/tui/tui-event-handlers.test.ts src/tui/components/chat-log.test.ts src/tui/tui.test.ts.
• [P1] node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.test.ui.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/test-ui.tsbuildinfo.
• [P1] git diff --check.

What I checked:

• Repository policy read: Root AGENTS.md and scoped src/tui/AGENTS.md were read; the TUI guide says fake-backend PTY tests do not prove Gateway transport, embedded runtime, providers, session persistence, or live streaming. (AGENTS.md:1, 892602eaba07)
• Patch restores draft after async abort: The PR head wires Esc to wait for abortActive() and then unconditionally writes restoredDraftText into the editor, which creates a race with user input typed while abortChat is still pending. (src/tui/tui.ts:1410, c1793c64ebb7)
• Abort result is delayed by backend RPC: abortActive awaits client.abortChat before returning restoredDraftText, so the editor remains usable during the interval that the later setText can overwrite. (src/tui/tui-session-actions.ts:647, c1793c64ebb7)
• Current main already clears stale busy state on abort and session switch: Current main clears pendingOptimisticUserMessage in abortActive and session-switch paths, so the PR's remaining value is broader pending-draft restoration and history reconciliation rather than only the original stale-busy flag clear. (src/tui/tui-session-actions.ts:529, 892602eaba07)
• Latest release partially covers the stale busy fix: v2026.5.28 already clears pendingOptimisticUserMessage after aborting a pending run, but its setSession path did not clear that flag; current main is ahead of the release on the session-switch portion. (src/tui/tui-session-actions.ts:378, e93216080aa1)
• Whitespace check: The PR diff has no whitespace errors under git diff --check. (c1793c64ebb7)

Likely related people:

• vincentkoc: Recent current-main blame and history show Vincent Koc touching TUI pending-send, busy-state visibility, and pending-history reconciliation around the affected files. (role: recent area contributor; confidence: high; commits: eddf1c776dd2, 51d6d7013f07, f0a44232716d; files: src/tui/tui-session-actions.ts, src/tui/tui-command-handlers.ts, src/tui/tui.ts)
• vignesh07: History shows Vignesh Natarajan introduced and maintained TUI optimistic user-message and active-run behavior adjacent to this pending-submit state machine. (role: feature-history owner; confidence: medium; commits: 61a0b0293104, 68cb4fc8a163, b4cdffc7a429; files: src/tui/tui.ts, src/tui/tui-event-handlers.ts, src/tui/tui-command-handlers.ts)
• steipete: History shows Peter Steinberger as a frequent TUI refactor/fix contributor, including the handler split and deferred history sync paths that frame this owner boundary. (role: adjacent owner; confidence: medium; commits: 32cfc4900273, ff2e9a52ff10, 38752338dcbc; files: src/tui/tui.ts, src/tui/tui-session-actions.ts, src/tui/tui-event-handlers.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.