Windows: recurring hard crash - V8 fatal 'Check failed: has_exception()' during long TUI sessions

Bug description

The CLI process hard-crashes (V8 fatal error) during long interactive TUI sessions. It has happened 7–8 times over the past days. The process dies instantly and drops back to the shell, leaving garbled terminal escape sequences behind (e.g. [O[I[O[I).

Console output at crash:

#auto  K3 thinking: max  C:\Users\funst
# Fatal error in , line 0
# Check failed: has_exception().
#
#FailureMessage Object: 00000024837FD630
----- Native stack trace -----
 1: 00007FF6F94D6F4D node::MultiIsolatePlatform::DisposeIsolate+5341
 2: 00007FF6FA93E05F V8_Fatal+287
 3: 00007FF6FA0630F7 SSL_CTX_set_default_read_buffer_len+11799
 4: 00007FF6F9BC55C0 v8::String::Utf8Value::~Utf8Value+139072
 5: 000001C7F2937582

Notes:

• Nothing is written to ~/.kimi-code/logs/kimi-code.log at the moment of the crash — the fatal error only reaches stderr, so the diagnostic log has no trace of it.
• Sessions involved are long-running, with heavy tool use (Todo list active, sub-agents, large context). The session data itself survives and can be resumed with kimi --session.
• Network on this machine goes through a local proxy/VPN (the SSL_CTX_set_default_read_buffer_len frame in the stack may or may not be related).

Environment

• Kimi Code CLI: 0.34.0
• OS: Windows 11 (x64), running in Windows Terminal / PowerShell
• Node.js: v24.15.0

Steps to reproduce

No deterministic repro — it occurs spontaneously mid-session (observed during/after agent turns with active todo tracking), roughly every few hours of use.

Attachments

I have a debug ZIP produced by kimi export (session + global diagnostic log, ~2.3 MB). Since it may contain sensitive session content I have not attached it publicly — happy to email it to code@moonshot.ai referencing this issue.

Start with the Windows 11, Node.js v24.15.0 environment and the stderr V8 fatal output from long TUI sessions; the issue names no source file or test. Try to reproduce the crash during extended sessions with heavy tool use and inspect the session and diagnostic-log behavior. Done means identifying the crash path and preventing the hard crash or capturing actionable diagnostics.