协同 Worker 调用内置浏览器 status 后无返回，界面仍显示 running，中断无法消费

**提交人**: zym
**客户端版本**: 0.1.73

---

## 场景

协同模式（Lead + 多个 Worker）下，几个 Claude Code Worker 被要求用 Cindy 内置浏览器读取需要 JS 渲染的公开网页。

## 卡在哪一步

不是打开网页，也不是点击页面。Worker 先 `list_tools` 拿到浏览器工具（这一步有结果），接着发出**第一次真正的浏览器调用**：

`browser`，`action: "status"`（只探测浏览器是否可用）

对话停在这条 tool_use 上，**始终没有 tool_result**。

多个 Worker 几乎同时打了这次 `status`。

## 出了什么 error

工具没有返回 `ok: false`，也没有 errorCode、超时文案或堆栈。过了很长时间（约两小时量级），运行探针才把这些会话标成：

- `phase: error`
- 摘要：「上次运行未正常结束」
- 最后活动时间停在该 turn 开头

协同栏和 Worker 列表却一直显示 **running**。

## 中断也救不回来

Lead 对这些 Worker 做 interrupt（替换当前任务）：

- 返回 waiting-for-safe-point（系统认为还有工具在跑）
- 替换消息进入队列，一直 `consuming=false`，不会被执行

有一个 Worker 的 interrupt 确实生效了，后来改用非浏览器方式把活干完并写了结果，但该 turn 仍被标成「上次运行未正常结束」，界面还是 running。

同期未走内置浏览器的 Worker 可以正常交差。

## 期望

- `browser status` 这类探测调用应在合理时间内返回成功或失败，不要无限挂起且不给错误体
- 进程实际已经 error 时，界面不应继续显示 running
- 对已死 / 工具永不返回的 turn 做中断时，下一条任务应能被消费，而不是永远等一个不会到来的安全点

## 如何复现

1. 打开协同模式，创建多个 Claude Code Worker
2. 让它们用内置浏览器打开并读取一个需要真实页面渲染的公开网页
3. 观察它们在 `browser` / `action: status` 之后长时间无 tool_result
4. 此时列表仍为 running，运行探针已是 error，活动时间不再更新
5. 对卡住的 Worker 发 interrupt，队列里的新消息不会被消费
---
## 提交时的任务环境

仅代表提交时快照,不一定是故障环境。OS 来自提交客户端本机,不含 SSH 远端主机;Harness / 模型来自当前任务。与运行环境无关的反馈可忽略本段。
**版本区域**: CN
**OS**: darwin arm64 (25.5.0)
**Harness**: Pi
**Model ID**: ` x-ai-grok/grok-4.6 `
**界面语言**: zh-CN

Start by tracing the browser tool's status call and why it produces no tool_result. Follow the same worker turn through run-probe error reporting, UI running state, and interrupt queue handling. Reproduce with concurrent workers and verify that status returns or fails within a reasonable time, errors stop the running state, and queued work is consumed after interruption.

Written by the indexing model from the issue text.