CLI hangs silently forever after "llm request" log line — no output, no error, no timeout

What version of Kimi Code is running?

kimi-code 0.34.0 (linux/x64, node v24.15.0)

Which open platform/subscription were you using?

https://platform.kimi.ai

Which model were you using?

kimi k3

What platform is your computer?

Linux 7.0.0-28-generic x86_64 x86_64

What issue are you seeing?

Every prompt — interactive TUI and non-interactive -p mode alike — hangs indefinitely with zero output. The session log records llm request and then nothing else ever follows: no llm response, no error, no retry. The process sits idle (main thread parked in ep_poll, all workers parked in futex_do_wait) until killed. This is 100% reproducible, not intermittent.

What steps can reproduce the bug?

1. Valid api_key configured for moonshot-ai provider in config.toml.
2. Run kimi -p "reply with just the word: pong" in any directory.
3. Process hangs past 30s+ with no output; killing after 5 minutes still shows nothing was ever printed.

What is the expected behavior?

No response

Additional information

What I ruled out (each independently verified):

• Not the API key or account — calling https://api.moonshot.ai/v1/chat/completions directly with the same key (plain, streaming, and streaming+tools) succeeds in 3–8s e
  very time.
• Not network/DNS/TLS — direct curl to api.moonshot.ai over both IPv4 and IPv6 connects and completes in <100ms.
• Not the working directory/repo — reproduces identically in a trivial single-file, non-git scratch directory, and in a 4,000+ file real project. systemPromptChars stay
  s constant (~60581) regardless of directory content, ruling out repo-size-dependent context building.
• Not model-specific — reproduces with both kimi-k3 and kimi-k2.6.
• Not the local search-index — reproduces identically with a freshly deleted/rebuilt ~/.kimi-code/search-index.
• Not kimi doctor-detectable — config.toml and tui.toml both pass validation.

Where I couldn't get further:
I attempted to trace the actual HTTP exchange on the api.moonshot.ai socket using NODE_DEBUG, and on one occasion observed a 429 rate_limit_reached_error (max organization concurrency: 3) come back on that connection — but I can't confirm this is the general cause, since that trace followed a burst of my own concurrent test requests and a cleaner rerun didn't reproduce it clearly (instrumentation issue on my end, not a confirmed negative). Worth checking on your end whether kimi-code fires more than one concurrent request to api.moonshot.ai per turn (it does contact code.kimi.com, cdn.kimi.com, and telemetry-logs.kimi.com in the same turn, in addition to the actual chat completion) — and, separately, whether the client silently swallows non-2xx responses instead of surfacing them, since either way "receive an error, print nothing, hang forever"

Reproduce with kimi -p "reply with just the word: pong" using the stated Moonshot configuration, and inspect the request path after the llm request log line. Trace the api.moonshot.ai exchange, including non-2xx handling, concurrent requests, response completion, and timeout behavior; done means failures surface as errors and successful requests produce output instead of hanging.