Pressing ESC mid-stream permanently wedges the session: next request fails with 400 Invalid assistant message: content or tool_calls must be set

[xiahuaaaa]

What version of Kimi Code is running?

0.32.0 (also reproduced after background update to 0.33.0)

Which open platform/subscription were you using?

Third-party OpenAI-compatible provider (custom [model] config pointing at a DeepSeek-compatible endpoint), not the Moonshot login.

Which model were you using?

deepseek/deepseek-v4-flash (OpenAI-compatible protocol), thinking enabled (thinkingEffort=max).

What platform is your computer?

macOS, Darwin arm64 (Apple Silicon), Node v24.15.0.

What issue are you seeing?

Pressing ESC to interrupt an ongoing response permanently wedges the session. The next prompt (and every subsequent retry) fails with:

[provider.api_error] 400 Invalid assistant message: content or tool_calls must be set

The error repeats on every request because the broken message stays in the conversation history — the session cannot recover except by starting a new one (or manually cleaning the session records).

What steps can reproduce the bug?

1. Start a conversation with a thinking-enabled model (e.g. deepseek/deepseek-v4-flash with thinkingEffort=max).
2. Send a prompt and wait for the model to start streaming. Models emit their thinking first, so the stream begins with a think part.
3. Press ESC to interrupt while the model is still thinking — i.e. before any visible text/tool-call chunk has streamed.
4. Type and send the next message (e.g. "continue").
5. The request fails with 400 Invalid assistant message: content or tool_calls must be set; every retry fails the same way.

Root cause (verified from the session wire records): the cancelled step leaves a partial assistant message that holds only an unencrypted thinking fragment (no text, no tool calls). It gets sealed into the conversation history, and when the next request is built, the OpenAI-compatible base converts think parts out of content (into reasoning_content), so the message serializes with neither content nor tool_calls — which the provider rejects. Interrupting after the first text/tool chunk does not trigger this, because the sealed message then still carries content or tool calls.

What is the expected behavior?

Interrupting a response with ESC should be a no-op for the conversation history: the next prompt should work normally without the partial, reasoning-only message being resent.

Additional information

Fix submitted in PR: #2689 — the projector now treats unencrypted-thinking-only messages as non-sendable and drops them from outgoing requests (context history still keeps the reasoning). Both agent-core (v1) and agent-core-v2 engines are affected and fixed.