[BunsDev]

Summary

Sends a real flood of text deltas through the real client and query loop, and fixes the two problems it found in Next. Classic's behaviour is unchanged.

Problem	Before	After
Quitting during a running turn	Nothing from that turn was saved. In a new conversation that meant no session file at all, so the prompt and the partial answer were both gone.	The turn is stopped, then the prompt and what it delivered so far are saved.
Deltas still queued when a turn is cancelled	Each one restarted the turn on screen, so further Ctrl+C presses cancelled again and never reached the exit sequence.	They no longer touch the screen. Ctrl+C reaches the exit sequence straight away.

The second fix also makes a cancelled flood much cheaper (release build, Next, one host, 120x40, 1,000,000 deltas, 2 runs each):

	main b3c952f	This branch
Settled after Escape	16.5-17.4 s	7.2 s
RSS after settling	about 1.7 GB	330-363 MB
Typed key painted during the burst	29-33 ms	30-31 ms
Escape acknowledged	30-36 ms	39-44 ms

Two runs are too few to read anything into the Escape difference, and these rates are far beyond any real provider.

Context

• Related: [TUI v2][P0] T1: extract a typed presentation seam and support Classic/Next without runtime divergence #408. Stacked on test(tui-tests): run approval edges through real engine-local tools #449 because it uses the same fake Messages API; retarget to main when that lands.
• Both fixes are gated to Next, so Classic keeps its existing cancel and exit. deltas_still_queued_when_a_turn_is_cancelled_cannot_restart_it pins Classic's late-delta handling, and a probe confirmed that quitting Classic mid-turn still saves nothing.
• Finished turns were already saved. Only a turn still running at quit was lost.

Behaviour to check

• Quitting can now take up to 2 seconds longer. The terminal is handed back first, then the process waits up to 2 s for the turn to stop. A cancelled flood stops at once. A running sleep did not react to cancellation: exit took about 2.3 s against 0.3 s on main, and only the prompt was saved because the tool had produced no result yet. The tool did not finish after quit, on either build.
• Ctrl+C and Ctrl+D do nothing while an approval panel is open. Both were tried: the process stays open and the tool does not run. Answer the panel first. This PR doesn't change that, but it means the exit path isn't reached with a panel open through those keys.

Docs

docs/keybindings.md said one Ctrl+D exits and that it signals EOF when the prompt has content. It takes two presses within 2 seconds, and it does nothing while the prompt has content. docs/commands.md said unsaved state is flushed on exit, which wasn't true of a running turn. It now says what each renderer does.

Validation

• Failing first: deltas_still_queued_when_a_turn_is_cancelled_cannot_restart_it, and the two "keeps the prompt" and "keeps the partial answer" checks, failed before their fixes.
• Control: with the delta guard disabled on a debug build, exactly the three "Ctrl+C twice more" checks fail and the other 16 pass.
• scripts/tui-tests/run.sh event_flood: 19 passed, 0 failed.
• cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings.
• cargo test --workspace --locked: 2916 passed, 0 failed.
• Full tmux suite: 145 passed, 0 failed. The flood case also passed on its own under bash and zsh.
• Test scripts' unit tests pass, and git diff --check is clean.

Not tested: Windows, Linux, or a real provider. On a fast release build a 300,000-delta burst can settle before the later Ctrl+C presses, so that part of the case only has teeth on a debug build, which is what tui-tests.yml runs. The unit test covers the same logic on any build.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Nov 4, 2026 4:25pm UTC