[Bug] Agent 重启 DSH 时会杀死自身宿主，导致会话永久停留在“运行中”

[Hu9956]

问题概述

运行在 dsh web 内部的 Agent 可能会为了让配置生效，决定重启当前 DSH Web 服务，并通过 Bash 工具执行 kill <dsh-web-pid>。

但被终止的进程同时也是执行当前 Agent 和工具调用的宿主。进程被杀死后：

• 当前工具调用无法返回结果；
• Agent 计划中的后续启动命令无法执行；
• 浏览器仍错误地显示会话正在运行；
• DSH 后端实际上已经停止。

环境

• DSH：0.1.0-rc.6
• 操作系统：macOS 27.0，arm64
• Node.js：v22.22.2
• 启动模式：dsh web
• Agent 预设：标准模式
• 模型：DeepSeek-V4-Flash，High 推理等级
• 访问模式：Full access

复现步骤

1. 启动 DSH：

dsh web

2. 创建一个需要修改 Web profile，并且必须重启服务才能让配置生效的 Agent 目标。

3. Agent 检测到 HMR 不可用，因此决定重启当前 DSH 服务。

4. Agent 在当前会话内部执行类似下面的工具调用：

kill <dsh-web-pid>
sleep 3
# 检查原进程是否已经停止

5. DSH 后端立即退出。这个工具调用没有返回结果，Agent 也无法继续执行原计划中的服务启动命令。

实际结果

• 3080 端口不再有进程监听。
• 持久化会话日志的最后一条记录是包含 kill <dsh-web-pid> 的 tool/call。
• 日志中没有与其对应的 tool/result、step/end 或完整的 Assistant 回复。
• 浏览器仍显示会话“进行中”，并保留“停止生成”按钮。
• 点击 Session log 会显示 Failed to fetch。
• 无论等待多久，会话都不会自行恢复。
• 必须从 DSH 外部手动重新启动服务。

页面中显示的另一个后台命令其实已经正常完成，结果为：

CODEX_OK
exit=0

因此，表面上的“命令一直运行”并不是该后台命令卡住，而是 Agent 终止了自己的宿主进程。

预期结果

DSH 应当阻止运行于宿主内部的 Agent 直接终止负责执行当前工具调用的宿主进程。

如果 Agent 请求重启服务，应该交给独立于当前宿主进程的外部监督器或专用重启机制处理，并保证：

1. 在停止服务前，先持久化当前会话，并将其标记为“已中断”或“可恢复”。
2. 当前工具调用得到确认后，再停止 Web 宿主。
3. 由宿主进程之外的机制启动新进程。
4. 浏览器能够自动重连，或者明确提示后端正在重启。

即使宿主意外退出，浏览器和持久化会话也不应永久停留在错误的“运行中”状态。

建议的防护措施

• 检测并阻止 kill、pkill、killall 等命令终止 DSH 宿主进程或其必要的父进程。
• 提供受监督的专用重启操作，不允许 Agent 通过普通 Shell 工具重启自身宿主。
• DSH 启动时，检查以未完成工具调用结尾的会话，并将其标记为“已中断”或“可恢复”。
• Web 前端检测后端连接中断后，应将过期的“运行中”状态替换为明确的“连接已断开”或“执行已中断”。

恢复验证

从 DSH 外部手动重新执行 dsh web 后：

• 127.0.0.1:3080 恢复正常监听；
• 首页返回 HTTP 200。

复现和说明该问题不需要提供任何凭证、认证 Token 或用户专属路径。

[Mooling0602]

Agent 工具通病吧，其实加个提示词让模型不要做做这种危险操作就好

[DRAG0NM]

已定位根因：workspace-write 沙箱只限制文件写、不限制进程操作，沙箱内 taskkill 可杀死宿主；宿主在 turn 中途死亡后，会话日志干净地停在未闭合的 turn/step/tool 上。持久化层只修"撕裂尾部"、不对干净 EOF 的悬空 turn 做闭合；客户端从日志投影状态（settled===undefined → running）→ 永久"运行中"转圈；服务端活跃度又来自活体 agent 注册表（冷启动无 agent），两处矛盾且无冷启动协调。修复方案（推荐：加载时补写中断 closeout 事件）见 #466 。