[Bug] APIConnectionError becomes permanent until process restart — HTTP client wedges, no sockets opened during retries (0.27.0)

What version of Kimi Code is running?

0.27.0 (also reproduced on 0.26.0)

Which open platform/subscription were you using?

Kimi Code (OAuth, managed:kimi-code)

Which model were you using?

k3

What platform is your computer?

Darwin 25.5.0 arm64 (macOS, Apple Silicon), Node v26.3.0, npm-global install, iTerm

What issue are you seeing?

Several times per day, mid-session, every LLM request starts failing with
Error: [provider.connection_error] Connection error. Once this starts, it
never recovers within the process: all retry attempts fail (~1.4 s each), every
subsequent turn fails the same way, and only restarting the TUI fixes it.
Resuming the session after restart works fine.

I captured one occurrence with external instrumentation running in parallel,
which shows the failure is inside the kimi-code process, not the network:

1. Network was healthy the whole time. A probe loop on the same machine
   hit the LAN gateway, a neutral internet target, and
   https://api.kimi.com/coding/v1/models every 20 seconds throughout the
   failure window. Every probe succeeded (the API answered 401 in ~0.6 s, as
   expected without a token). node -e 'fetch("https://api.kimi.com/...")'
   with the same Node binary also succeeded while the TUI was failing.

2. OAuth token was valid. The credentials file showed a token minted
   minutes before the failure with plenty of validity left (900 s TTL), so
   this is not token expiry. (An earlier occurrence on 0.26.0 also predated
   PR #1808, so the bare message gave no transport cause.)

3. The failing process opens no sockets during retries. lsof -nP -i -a -p <pid>
   sampled every 0.4 s during three full retry attempts recorded zero new
   sockets and zero state changes on existing ones. The process held a few
   long-lived ESTABLISHED connections (Cloudflare edge for api.kimi.com,
   CDN77, and a Moonshot host) that never transitioned. Each attempt failed
   in ~1.4 s without any observable network I/O — the APIConnectionError is
   generated in-process.

This looks like the provider's HTTP client / connection pool entering a
permanently broken state after some initial connection-level event (possibly a
dropped keep-alive connection or server-side close during a slow streamed
response), after which every request fails fast against the dead in-memory
state instead of establishing a fresh connection.

Retry log excerpt (attempts 7–9 fell inside the socket-watch window)

11:26:30 INFO  llm request  turnStep=8.1
11:26:33 INFO  llm request  turnStep=8.1 attempt=2/10
...
11:27:14 INFO  llm request  turnStep=8.1 attempt=7/10
11:27:52 INFO  llm request  turnStep=8.1 attempt=8/10
11:28:33 INFO  llm request  turnStep=8.1 attempt=9/10
11:28:5x WARN  llm request failed  attempt=10/10 model=k3 errorName=APIConnectionError errorMessage="Connection error."
ERROR turn failed
  APIConnectionError: Connection error.
    at convertOpenAIError$1 (.../dist/main.mjs:53355:52)
    at KimiChatProvider$1.generate (.../dist/main.mjs:53916:11)

What steps can reproduce the bug?

No deterministic repro; occurs a few times per day during long, heavy agent
sessions (it also hit a session with two parallel subagents — all agents in
the process fail simultaneously, consistent with shared client state). The
provider was very slow that day (12–24 s TTFT on every request), which may
increase the chance of the triggering connection event.

What is the expected behavior?

After a connection-level error, the provider client should discard broken
pooled connections (or be recreated) so retries establish fresh connections.
A process restart should never be required to recover from a transient
connection error.

Additional information

Session debug export from an earlier occurrence of the same failure is
available (session_29a29b56-29eb-424b-8963-276d6433b02b) — happy to attach it
or run further diagnostics on request.

Start at KimiChatProvider$1.generate and convertOpenAIError$1 in dist/main.mjs, using the retry log and socket observations to trace the in-process connection failure. No deterministic reproduction or test is named, so first identify the relevant client and retry path. Done means a connection-level failure can recover through retries without restarting the process.