Ctrl+C silently destroys unsent multi-line drafts with no recovery path

Ctrl+C silently destroys unsent multi-line drafts with no recovery path

Environment

• kimi-code CLI 0.42.0 (npm install), Windows 11, Windows Terminal
• This has happened to me multiple times across recent versions; today it destroyed a two-hour feature plan

What happened

A long multi-line draft was in the input box. Ctrl+C was pressed — a reflex, it is the most common key combination there is. The input box cleared instantly, before the text was ever sent. The draft was unrecoverable.

Why there is no recovery (all verified on disk)

• The undo selector (Esc Esc) only lists sent prompts — it is conversation undo, not input undo
• Input history (up/down) only recalls sent messages; a Ctrl+C-cleared draft never enters it
• Nothing is persisted for unsent input: user-history/*.jsonl, session state.json, and the CLI logs contain only sent content and metadata
• Since the draft was never submitted, it never reached the API or any cache

The docs describe the shortcut as "clear the input box" — the behavior matches the docs, but the outcome is destructive data loss from a single common keystroke, with no confirmation and no undo.

Suggestions (any one of these would prevent the damage)

1. Persist drafts (e.g., into the session directory) and restore them on resume
2. Push the cleared input into the input history so it can be recalled with the up arrow
3. Require a second Ctrl+C confirmation when the input box is non-empty — the same double-press pattern already used for exiting

Option 3 is the smallest change and mirrors existing behavior.

Start with the CLI input handling for Ctrl+C and the existing double-press exit behavior described in the issue. Trace how non-empty drafts are cleared, then verify the chosen recovery or confirmation behavior with an appropriate CLI test; done means a Ctrl+C cannot silently destroy an unsent multi-line draft.