Web UI keeps showing finished subagents as running after reconnect or interruption

Summary

In a session started via the kimi web command, a finished subagent can remain visible as running with an ever-increasing elapsed timer when the Web client misses its terminal lifecycle event. This has been observed both after a 429 interruption and resume, and after the computer sleeps or the display-off period disconnects the WebSocket before the client resumes.

In both cases, the subagent has already finished and no corresponding task remains active, but the stale UI row does not converge to a terminal state.

Environment

• kimi-code version: 0.26.0
• OS: macOS
• Mode: web UI session (started via kimi web)

Steps to reproduce

Scenario A: 429 interruption and resume

1. Launch two subagents via the Agent tool (in this case two explore subagents in parallel).
2. One subagent run is interrupted mid-flight by an API error: 429 The engine is currently overloaded, please try again later (the subagent reports that it stopped before finishing).
3. Resume the same subagent with its resume id. The resumed instance runs to completion and returns its result.
4. Both subagent results are delivered and used by the main agent.

Scenario B: sleep, display-off, and reconnect

1. Start one or more subagents from a Kimi Web session.
2. Put the computer to sleep, or leave the display off long enough for the Web client to lose its WebSocket connection while subagent work is in flight.
3. Wake the computer and return to the Web client after the subagent has finished.
4. Observe the restored session after the client reconnects.

Expected behavior

Subagent entries should transition to their completed or failed terminal state. If the client was disconnected when the terminal event was emitted, it should reconcile the current state from the server after reconnecting.

Actual behavior

After either scenario, finished subagent entries can remain running for hours with growing timers, for example:

Resume audit subagent
运行中 · 190:06
Audit callers subagent
运行中 · 328:18

The entries represent work that has already finished, but their UI state remains live.

Evidence that nothing is actually running

• TaskList with active_only=false returns background_tasks: 0 / No background tasks found.
• TaskOutput for both agent ids returns Task not found: agent-0 / Task not found: agent-1.
• Both subagent results were fully received and consumed by the main agent; subsequent work in the session proceeded normally.

Impact

This is a UI-state issue, but it is confusing because the user cannot tell whether background work is still consuming resources, and the stale entries cannot be cleared without restarting the session.

The common failure mode is that the client misses or does not receive a terminal subagent lifecycle event and cannot authoritatively reconcile the stale local row afterward. The 429 interruption and resume path is one reproducer; sleep/wake and other WebSocket disconnects can expose the same reconciliation gap.

Start with the kimi web WebSocket reconnect flow and the client handling for subagent lifecycle events described in the report. Reproduce the 429/resume or sleep/wake scenario, then verify that a restored session reconciles entries with server state and displays completed or failed rather than running; use TaskList and TaskOutput as checks that no task remains active.