[Bug] Session corruption under memory pressure: lost conversation + 400 tool_call response error on resume

What version of Kimi Code CLI is running?

kimi, version 1.43.0

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

kimi-for-coding

What platform is your computer?

Linux 6.8.0-111-generic x86_64 x86_64

What issue are you seeing?

When the server is under high memory pressure, the Kimi CLI exhibits UI glitches (input lag, chat content rendering into the input line). If the user exits the session and restarts the CLI, the conversation disappears from the session list. Attempting to resume the conversation from history then triggers a persistent 400 Invalid request error:

LLM provider error: Error code: 400 - {'error': {'message': "an assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: Shell:206", 'type': 'invalid_request_error'}}

What steps can reproduce the bug?

1. Start a kimi session and engage in a multi-turn conversation involving tool use (e.g., shell commands).
2. Trigger high memory pressure on the server (or let it occur naturally under load).
3. Observe CLI UI degradation: input becomes laggy, and assistant output streams into the user's input line instead of the chat pane.
4. Exit the current Kimi session (e.g., Ctrl+C or closing the terminal pane).
5. Restart kimi — notice that the previous conversation is missing from the active session list.
6. Navigate to conversation history and select the lost conversation.
7. Type any new message and submit.
8. Result: The CLI immediately crashes with the 400 error about missing tool response for Shell:206.

What is the expected behavior?

• The CLI should gracefully handle memory pressure without corrupting the local message log.
• If a tool response is lost due to resource constraints, the client should discard the incomplete turn or repair the sequence rather than sending an invalid message history to the API.
• Exiting and reopening the CLI should either recover the intact session or cleanly discard the corrupted one.

Additional information

The issue appears to be a client-side state consistency bug triggered by resource exhaustion: the conversation history was saved, but the final tool response in the message array was not, leaving an assistant tool_calls message without its required follow-up. This makes the conversation permanently unresumable from history.

Start by tracing the CLI's local session-history persistence and resume flow, focusing on how tool-call messages and their responses are saved and restored. Reproduce the documented multi-turn tool-use scenario under memory pressure, then verify that reopening history either preserves a valid sequence or safely discards an incomplete turn without sending it to the API.