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

[youngting520]

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.

[QuFeiFan]

Still reproducible on 0.29.1 (Windows 10, session started via kimi web).

• The main agent launched two explore subagents in parallel via the Agent tool (foreground). Both ran to completion in the same turn and their results were delivered and used.
• In the web UI, both subagent entries kept showing as running.
• From the agent side, TaskList (with active_only=false) returned 0 tasks — the tasks genuinely finished; only the web client state was stale.

Notably, none of the triggers in the report applied here: no 429, no interruption/resume, no page refresh or WebSocket reconnect that we noticed, and no sleep/display-off. The session ran uninterrupted, and the rows still failed to converge to a terminal state.

One more data point: manually refreshing the web page cleared the stale "running" rows — after reload the UI showed the correct finished state. So a full client reload does reconcile state from the server; the live session just never does it on its own.

Environment:

• kimi-code version: 0.29.1
• OS: Windows 10 (19045)
• Mode: web UI session (started via kimi web)