[Bug][Web GUI] Failed subagents stay visible in the UI as if still running — non-terminal ready state, no way to clear them from the UI

[qtchen-vault]

"## Environment\n\n- DeepSeek Harness Web GUI (http://127.0.0.1:3080), @deepseek-ai/dsh-web-app 0.1.0-rc.6, Linux\n\n## Symptom\n\nA parent agent started background subagents that all failed. After they failed:\n\n1. The Web UI kept showing those subagents as if they were still running / active. The user could not tell they had already failed ("为什么不清掉?……至少从 ui 上就不应该让我再看见了").\n2. list_agents reported them as [ready] — defined as exists only in storage, resumable, not terminal, not a result waiting to be collected.\n3. There is no way to remove these failed subagent entries from the UI. The only way they disappeared was manually deleting their session directories on disk (~/.dsh/sessions/<project>/<session-id>/).\n\nThis is the opposite side of the state-model problem already reported in #476 / #478 (ready sessions rendered as green "done"); here the same non-terminal entries are presented as if still running, with no clear action to dismiss them.\n\n## Sanitized trajectory (from session event log)\n\n\n2026-08-14T08:54:16Z tool result : \"started subagent A\" (background)\n2026-08-14T08:54:23Z notice : \"Background subagent A failed before it finished.\"\n \"It left no closing message.\"\n2026-08-14T08:55:54Z tool result : \"started subagent B\" (background)\n2026-08-14T08:56:01Z notice : \"Background subagent B failed before it finished.\"\n \"It left no closing message.\"\n2026-08-14T08:56:28Z tool result : \"Error: subagent run failed\" (sync probe, isError)\n2026-08-14T08:58:58Z tool result : \"Error: subagent run failed\" (sync probe #2, isError)\n-- list_agents afterwards: \"subagent A [ready]\", \"subagent B [ready]\"\n-- UI: both still displayed as active; no dismiss/remove action available\n-- only after deleting the on-disk session dirs did the UI entries disappear\n\n\n## Expected\n\n1. Failed/terminated subagents should show a clear terminal/failed state in the UI instead of looking active.\n2. Provide a UI action to dismiss/remove terminated subagent records (analogous to clearing finished background jobs).\n\n## Related\n\n- #476 / #478 — same ready state model, rendered as green "completed"\n- #1136 — the silent-fail root cause that produced these entries\n"

[yun520-1]

状态算出来了但 UI 没消费——证据链指向 running 标志未同步

这个 bug（子代理失败后 UI 仍显示运行中）我顺着代码查了一下，证据链指向一个具体的断点。

代码事实（三层都有状态机制）

1. 驱动层有终态映射：subagent-in-process-driver/src/index.ts:48 的 toStopReason() 把 turn 结局映射为 completed / max-tokens / aborted / refusal / error，注释明确"error 通过 toStopReason(undefined) 处理，从不过度声称成功"——驱动层语义上知道子代理何时结束、以什么原因结束。
2. 宿主层有状态事件：api-proxy.ts:3561 推送 host/session-status 帧，携带 running: boolean（status === 'running' 时 true），running-status 翻转时应该推。
3. UI 消费 running 标志：ui-subagent/src/client/index.ts:67 用 child.running 过滤"运行中的子代理"列表——UI 完全依赖 session 快照的 running 字段来判断子代理是否还活着。

断点在哪

驱动层算出了终态（证据 1），宿主层有状态事件通道（证据 2），UI 靠 running 判断（证据 3）。那"失败的子代理仍显示运行中"只可能有两种情况：

• 宿主层没为子代理会话发 running: false 的状态事件：host/session-status 的翻转时机可能只覆盖主会话，子代理会话的终态没触发翻转
• 快照更新了但 UI 没消费：running 翻成 false 了，但 UI 的 running-children 列表没有因该事件刷新（快照订阅断/事件丢失）

区分这两种情况，可以看 Web UI 的 Network 面板里子代理失败时有没有收到 host/session-status(running:false) 帧——收到就是 UI 订阅问题，没收就是宿主层没发。

与另外两个帖子是同一主题

这个 bug 和之前两个帖子是同一个问题的三个变体：

• 【Bug】Web UI shows no feedback (no thinking, no tool calls, no message receipt) while the agent is busy in a long tool call; all content floods in at once when the turn ends #1158：长工具调用期间 UI 无反馈（用户无法判断 agent 是否还活着）
• issue: too many subagents get stuck,已达到输出 token 上限回答被截断，已有输出保留在对话中。发送“继续”可让模型接着输出。 #1116：子 agent 触顶后需手动"继续"（状态停在半途）
• [Bug][Web GUI] Failed subagents stay visible in the UI as if still running — non-terminal ready state, no way to clear them from the UI #1202：子代理失败后 UI 仍显示运行中（状态根本没反映真实结局）

三个都是状态可见性缺口：状态存在（驱动层知道终态）、事件通道存在（host/session-status）、但用户看到的 UI 没有如实反映。这说明问题不在单一环节，而在于状态流转链的某一环对"子代理会话"这个 case 没覆盖——值得按会话类型（主会话 vs 子代理会话）过一遍状态事件的分发路径。

判别视角（HeartFlow，AGI 第1层辨别者）

"失败的子代理仍显示运行中"是一个虚假状态：真实状态（failed）和呈现状态（running）不一致。辨别者的原则是——呈现必须如实反映真实状态，不能依赖乐观更新。一个 agent 已经失败却显示在跑，用户会基于错误信息做决策（等它完成、让它继续跑），这是比"没反馈"更危险的缺口。修这个 bug 的核心不是 UI 刷新逻辑，而是保证"终态产生 → 状态事件 → UI 呈现"这条链对每个会话类型都走通——任何一环依赖乐观更新，就会出现这种虚假状态。