bsk 在 Windows 上的两个会话可靠性问题：命令刚返回就报 unfinished command，以及 session stop 无法强制终止卡死命令、只能重启 daemon

[lbdmxhs]

归属说明

通过 DeepSeek Harness 插件 @wxg-prc-cpg/browser-skill-dsh-plugin@0.2.0 触发，但问题疑似位于
crates/bsk-cli / bsk daemon 的会话命令调度（单命令轨道竞态 + stop 不能强制中断 + 无命令超时），
并非插件层（插件仅透传 bsk <cmd> --json）。请转交 bsk CLI/daemon 负责人。

运行环境

• 操作系统：Windows 11 家庭中文版（build 10.0.26200），x64
• 浏览器：Google Chrome 152.0.0.0（Chromium）
• BrowserSkill 扩展：0.2.0
• bsk CLI / daemon：0.2.0（协议 1.1）
• 使用方式：DeepSeek Harness 插件 @wxg-prc-cpg/browser-skill-dsh-plugin@0.2.0

问题概述

围绕「每个会话同一时间只允许一条未完成命令」这一规则，出现两个可靠性问题：

1）命令刚返回成功就偶发「未完成命令」（时序竞态）
即使严格串行、一次只发一条、每次都等上一条返回，紧跟在一个【已成功返回】的命令之后的下一条
命令，仍会被拒绝：
Error: bsk <command> failed: session already has an unfinished command
对同一条命令原样重试 1~2 次即可成功。已在 fill、screenshot、session stop 上复现。

2）死锁：一条永不结束的命令会令 stop 完全失效
登录进一个登录后仍在持续后台请求的 SPA（图表/通知/轮询）后，会话会一直挂着一条未完成命令。
此后所有后续命令——包括 session stop——均被拒绝：
Error: bsk session stop failed: session already has an unfinished command
提示“请等待当前命令完成、用 Ctrl+C 取消、或停止/重启会话”。唯一逃逸方式是 bsk daemon restart，
它会把 daemon 连同其会话一起杀掉。

复现步骤

1. bsk session start（或插件的 browser_session start）。
2. navigate 到一个加载完成后仍在轮询的 Vue SPA，使用 waitUntil: domcontentloaded。
3. 在上一步【成功返回】后紧跟一条新命令 → 间歇性出现 session already has an unfinished command。
4. 页面后台请求较忙时执行 session stop → 被拒 previous session command is still running；
   反复重试无效 → 只能 daemon restart。

期望行为

• 命令返回成功后应立即释放会话命令槽，下一条命令应能立即执行，而不应被拒绝。
• 卡住 / 长时间运行的命令应可被中断（包括通过 session stop）。

建议

• 命令一旦返回，立即将会话命令槽标记为“完成”，修复此竞态。
• 为单条命令增加超时（如默认 30s），避免挂死命令永久阻塞会话。
• 让 session stop 能强制终止当前正在执行的命令，而不是在命令运行期间自身也被拒绝。
• 或在 CLI 中显式提供 cancel / interrupt 命令。

诊断数据

bsk status

bsk-daemon.log.2026-09-05.txt

[iuyo5678]

感谢反馈。我核对了当前 main（498f8fb）及 cli-v0.2.0：

1. 命令执行完成后，daemon 会先释放会话 busy 状态，再返回结果。因此，现在还没法确认“成功返回后未及时释放命令槽”这一原因，需要进一步复现。
2. session stop 在会话有运行中命令时确实会返回 busy，当前 main 仍保留这一行为。错误提示同时建议停止会话，确实存在引导不一致（这个我会提一个小的pr修复掉）。
3. 当前已有默认 30 秒工具 RPC 超时，也支持命令指定超时。不过，这不能排除某个异常路径未正确结束或清理。

为方便我继续定位问题，麻烦方便补充：

• 可复现的最小命令序列，以及各条命令的完整输出和开始、结束时间；
• 卡住的具体命令、传入的超时值，以及超过该时间后是否仍持续 busy；
• 绕过 Harness 插件、直接串行运行 bsk CLI 是否也会出现；
• 发生问题时的 bsk status 输出。分享前请移除敏感信息。

[lbdmxhs]

感谢核对，按你的建议我又复现了一轮，补充如下（均已脱敏）：

① 关于「命令成功返回后未及时释放命令槽」
这边能稳定复现：严格串行、每次等上一条成功返回，紧跟的下一条仍偶发被拒，原样重试即成功。
最小序列：

fill 密码 …                              成功
click 登录 → Error: bsk click failed: session already has an unfinished command
click 登录（原样重试）→                   成功

同样出现在 observe、press 之后。命令返回后紧接着连发同一条指令，甚至能连续 3 次被拒：

observe → Error: bsk observe failed: session already has an unfinished command
observe → Error: bsk observe failed: session already has an unfinished command
observe → Error: bsk observe failed: session already has an unfinished command

所以看起来确实存在「命令已返回、但命令行槽还未释放」的窗口，和你的判断一致。

② 关于 session stop 的保留行为
忙会话时 session stop 确实会返回 busy：

session stop → Error: bsk session stop failed: session already has an unfinished command

但有个额外发现：紧接着原样重试一次就成功了，全程没遇到「只能 daemon restart」的永久死锁。
也就是说 busy 状态在命令返回后会被短暂释放，更像瞬时竞态，而不是某条命令永不结束导致卡死。
提示文案「请等待当前命令完成…或停止/重启会话」确实跟 stop 自身也被拒的表现矛盾，同意你提的小 PR。

③ 关于 30s 默认超时
进入较重的业务页时命令会卡满 30s：

navigate → Error: bsk navigate failed: tool RPC timed out after 30s

默认没显式传超时（走默认 30s）。超过超时后，我用重试的 session stop 正常恢复了，没持续强 busy。
不过这个页面前端其实还在初始化（大量懒加载 + 列表轮询），30s 偏紧，容易被误判成卡死，
建议超时前先确认浏览器是否仍在响应。

暂时没补上的

• bsk status / bsk logs：插件侧没有直连，我这边在装有 bsk CLI 的机器上跑一份再发你（会脱敏）。
• 绕过插件直接串行跑 bsk CLI 是否同样复现：这点还没验证，需要的话我补测。

暂未验证/需补充

• bsk status / bsk logs：插件侧无直连入口，需在装有 bsk CLI 的机器上执行后脱敏补充。
• 绕过 Harness 插件、直接串行运行 bsk CLI 是否同样复现：本次未验证。

证据附录（原始输出摘录，已脱敏）

E1. 症状① 竞态 —— 命令成功返回后下一条被拒

命令序列：fill（成功返回）→ click（被拒）→ 原样重试 click（成功）

> fill  密码(654321) ……                …… 成功
> click @登录                           [ERROR]
Error: bsk click failed: session already has an unfinished command
(hint: wait for the current command to finish, cancel it with Ctrl-C, or stop/restart the session)
> click @登录   (原样重试 1 次)          …… 成功
[session bgpa] clicked at (972, 571.5) on tab 89491997

> fill  菜单搜索框「问题对策」           …… 成功
> observe                               [ERROR]
Error: bsk observe failed: session already has an unfinished command
(hint: wait for the current command to finish, cancel it with Ctrl-C, or stop/restart the session)
> observe   (原样重试 1 次)             …… 成功

> press  Enter                          …… 成功
> observe                               [ERROR]
Error: bsk observe failed: session already has an unfinished command
(hint: wait for the current command to finish, cancel it with Ctrl-C, or stop/restart the session)
> observe   (原样重试 1 次)             …… 成功

连续被拒放大（一次命令返回后在窗口期连发同一条指令，连续 3 次均被拒）：

> observe                               [ERROR]
Error: bsk observe failed: session already has an unfinished command
> observe   (重试)                      [ERROR]
Error: bsk observe failed: session already has an unfinished command
> observe   (重试)                      [ERROR]
Error: bsk observe failed: session already has an unfinished command

E2. 症状② 忙会话挂起 —— navigate 默认 30s RPC 超时

> navigate http://<host>/#/…/issueCountermeasure
Error: bsk navigate failed: tool RPC timed out after 30s
(hint: retry the command; if timeouts persist, check `bsk logs` and confirm the browser is still responding)
> navigate (同一命令重试)
Error: bsk navigate failed: tool RPC timed out after 30s
(hint: retry the command; if timeouts persist, check `bsk logs` and confirm the browser is still responding)
# 此后页面仍停留在原页（未跳转），随后 observe 回显 RootWebArea "<原页面> | IFactory"

E3. 症状② session stop 被拒（忙会话期间）

> browser_session stop
Error: bsk session stop failed: session already has an unfinished command
(hint: wait for the current command to finish, cancel it with Ctrl-C, or stop/restart the session)
> browser_session stop  (原样重试 1 次)
stopped browser session bgpa

E4. busv SPI —— 持续后台轮询的实际网络请求（脱敏 host）

POST http://<host>/api-sips-server/basic/aitoTodoTask/default/pageFilter?apply_id=ppm&timestamp=…&nonce=…
→ 200 OK   （待办列表轮询；登录后页面持续发起该接口及大量模块懒加载请求）

E5. 会话可恢复性

• session stop 被拒后紧接着原样重试即成功（见 E3），全程未出现必须 bsk daemon restart 才能逃逸的永久死锁。
• 说明忙会话的 busy 状态在命令返回后会被短暂释放，竞态为瞬时/偶发。

[DrakeFlorence]

以下全文内容由“deepseek-v4.1-flash-expires-on-0910”测试复现并整理记录

补充复现：根因在 Harness 插件的「后台缩略图截图」占用会话命令槽

感谢排查。我在 DeepSeek Harness 插件侧做了代码与实验分析，补一条可能尚未覆盖的路径：开启观察浮层（observationEnabled: true，默认值）时，daemon 视角下从来不是「严格串行」——插件会在后台周期性发出 bsk screenshot --session <id>，它和 Agent 的工具调用共用同一个 per-session 命令槽。

环境（脱敏）

• OS：Windows 11 x64
• 浏览器：Microsoft Edge 152.0.0.0（Chromium）
• 扩展 / bsk CLI / daemon：均 0.2.0（协议 1.1）
• Harness：DSH Desktop 2.0.5 + 插件 @wxg-prc-cpg/browser-skill-dsh-plugin@0.2.0，默认配置（observationEnabled: true、thumbnailIntervalMs: 1500、idleIntervalMs: 8000、lazyTools: true）

插件侧证据（node_modules/@wxg-prc-cpg/browser-skill-dsh-plugin/lib/index.mjs，0.2.0 发布产物）

• ObservationService.endAction()：每次工具调用结束后立即 scheduleCapture(sessionId, 0)（延迟 0ms）→ 发起一次隐藏的 bsk screenshot；addSession() 与 acquireForeground() 释放时同样传 0。
• capture()：走 queue.run(sessionId, …)，即与工具调用同一条 per-session FIFO，命令为 bsk screenshot --session <id> --out <tmp>，timeoutMs: 15000。
• acquireForeground()：工具调用开始时只 killFor('observation:<session>') 杀掉插件自己 spawn 的 bsk 子进程；daemon 侧那条 screenshot 在扩展返回前仍占用会话槽。
• runWithSessionBusyRetry()：原先只重试 1 次、间隔 SESSION_BUSY_RETRY_DELAY_MS = 100。竞态窗口一旦超过约 100ms，工具调用就直接报 session already has an unfinished command。

一次完整时间线（插件层观察）

1. browser_session start（带 url）成功，随后第一条 observe 成功。
2. 紧接着 navigate → session already has an unfinished command；原样重试 → 同样报错。
3. 此时 browser_session stop → 同样报 busy（与楼上 E3 的现象一致）。
4. 该状态持续约 5 分钟后，把 Agent Window 切到前台，会话立刻恢复可接受命令。
5. 另一轮里，「上一条成功返回后紧跟下一条」的模式在 navigate / observe 上重复被拒。

两个实验（用于区分「daemon 竞态」与「插件后台命令」）

• 实验 1：把插件的 busy 重试预算从 100ms × 1 改为 400ms × 8（约 3.2s），并把动作后截图的延迟从 0 改为 2500ms。
  → 连发 6 条命令（observe / observe / navigate / observe / navigate / observe）全部成功；打补丁前完全相同的序列里有 2 条被拒。
• 实验 2：用外部进程在同一会话上循环执行 25 次 bsk screenshot（约 8s 持续占槽，模拟「后台截图一直在飞」的极端情况）。
  → 4 条命令里仍有 2 条被拒。
  → 说明失败概率与「后台命令占槽时长」成正比，而不是一个固定的 100ms 窗口；也说明只要观察浮层开着，daemon 的命令槽就会被插件的截图持续打扰。

复现建议（比纯 CLI 串行更容易命中）

1. 通过插件跑（observationEnabled: true，默认），不要绕过插件直接串行跑 bsk CLI——后者看不到后台截图，这可能是当前难以复现的原因。
2. 想稳定复现，把 thumbnailIntervalMs 调到 200 左右放大占槽频率，然后在同一会话里连发两条工具调用。
3. 同时观察 bsk status 的 sessions 与扩展连接状态，并留意插件进程是否还有存活的 bsk 子进程。

建议

• 插件侧：观察通道不要在工具调用待执行时启动截图（或在 endAction 之后至少延迟 2s），并显著加大 busy 重试预算；更理想的是给观察通道单独的优先级/让路机制。
• daemon 侧：客户端断连（SIGINT）时应确定性释放会话命令槽；session stop 应能强制中断正在运行的命令。
• 文档：在 observationEnabled 的说明里明确「开启后 daemon 会持续看到后台 screenshot 命令」。