User-cancel context handling: prompt persists when cancelled before any output; discuss undo for landed side-effects

[MicroGery]

What feature would you like to see?

Background

This issue covers two distinct kinds of user-cancel:

• Case A (primary): cancelling before the model produces any meaningful output. The prompt should be withdrawn so the next message runs in a clean context. like [Feature Request] Add checkpoint / rewind support (restore conversation + file state to previous turn) #151
• Case B (extended discussion): cancelling after side-effects have already landed (files written, commands executed). Rolling these back needs undo / checkpoint support, discussed at the end. like /rewind 功能相关 #108

Case A — Prompt persists after cancel (primary issue)

Problem

When I submit a prompt and cancel (Esc / Ctrl-C) before the model has produced any text or tool call, the prompt stays in context.history. The next message I send is therefore processed together with the abandoned one.

Steps to reproduce (kimi-code 0.10.1):

1. Send prompt A.
2. Cancel before the model produces any text or tool call.
3. Send prompt B.
4. The model responds to both A and B.

Current behavior (0.10.1)

onEscape / Ctrl-C only calls cancelCurrentStream() → session.cancel(), which aborts the current turn but does not remove the user message already pushed into context.history. When the model has not produced any meaningful output yet, there is no logic that withdraws the prompt.

For comparison: cancelling mid-tool-call, or cancelling at the permission-approval prompt, is already handled correctly — kimi-code injects context via abortedToolOutput and formatApprovalRejectionMessage respectively, so the model knows what happened. The gap is specifically the case where cancel happens before any meaningful output.

Expected behavior

When a turn is cancelled and no meaningful content has been produced yet (no assistant text, no tool call), the prompt should be automatically withdrawn from history, so the next prompt runs in a clean context.

A guard detail worth aligning on: at cancel time, runToolCallBatch synthesizes an abortedToolOutput tool_result for any in-flight tool_use. This synthesized result must be treated as non-meaningful, otherwise the guard would never trigger in practice.

Optional enhancement: repopulate the editor with the withdrawn prompt text, so it can be edited and resent.

Case B — Cancel after side-effects have landed

Tool operations such as file writes and command execution land instantly; there is no time window where they are cancelled "halfway through". So when this kind of cancel happens, the side-effects are already complete.

Rolling back such side-effects requires undo / checkpoint support — i.e. saving a file snapshot before each tool execution, so the state can be restored after a cancel. This is a separate, larger problem, distinct from Case A's "withdraw the prompt" mechanism.

kimi-code 0.10.1 currently only supports the command-style /undo [count]. kimi-cli 1.45.0's /undo already supports viewing history turns in a list and choosing a rollback point, but it likewise cannot roll back file modifications.

Additional information

Willingness to contribute

I'm a regular kimi-code user and would like to contribute. If the team agrees on the direction, I'd be glad to work on both:

• Case A: the cancel-time guard logic and auto-withdraw (plus the optional editor repopulation).
• Case B: the design and implementation of file checkpoint support.

Before opening a PR I'd like maintainer input on the approach — in particular, how "meaningful content" should be defined in kimi-code's context model for Case A, and whether the Case B checkpoint work is on the roadmap. Looking forward to your feedback.