[Windows] Any non-daemon bsk command hangs forever when no daemon is running -- automatic daemon startup never returns, while bsk daemon start alone takes ~190 ms

[xiajiajun516]

Environment

item	value
bsk CLI	0.3.0 (bsk --version), ~/.local/bin/bsk.exe, installed with the official install.ps1
bsk daemon / protocol	0.3.0 / 1.3
extension / browser	0.3.0 / Microsoft Edge 153.0.0.0 — connected (bsk browsers lists it, session_count: 0)
OS	Windows 11 Pro, build 26200, x64
callers used to reproduce	Windows PowerShell 5.1.26100.7705, Node.js v24.13.0 (child_process.spawn), WMI Win32_Process.Create + cmd.exe
bsk update --check	up_to_date (0.3.0 is the current release)

Summary

With no daemon running, every bsk command that is not a daemon subcommand hangs forever and prints nothing — browsers, status, session start, all of them. The daemon is started in the background (.bsk/daemon.json is written, the daemon log shows daemon ready and then browser connected), and a command issued later from another shell returns in ~100 ms — but the first process never returns and can only be killed.

• bsk daemon start invoked directly returns in 191 ms, exit 0, and leaves a healthy daemon.
• With BSK_AUTO_START=0 the same cold command returns in 86 ms, exit 2, with the proper actionable error:
  error: ensure daemon is running: automatic daemon startup is disabled (BSK_AUTO_START=0); run 'bsk daemon start' in the owning host environment with the same BSK_HOME, then retry

So the hang lives exactly in the automatic daemon startup path (ensure daemon is running) — the code that starts the daemon on demand and then waits for it.

Steps to reproduce

bsk daemon stop        # make sure no daemon is running
bsk browsers           # <-- hangs forever, no output

1. bsk daemon stop — afterwards Get-Process bsk is empty.
2. Run any non-daemon command (bsk browsers, bsk status, bsk session start --no-focus). It blocks with zero stdout and zero stderr; -vv also produces nothing, so it blocks before anything is logged to the caller.
3. In another shell, bsk status returns immediately and reports a healthy daemon with the browser connected — the daemon was started successfully, only the waiting client is stuck.
4. The first process stays stuck indefinitely (observed 60 s+, see the table); killing the daemon is the only thing that releases it.

Evidence (all observed on the machine above)

cold-daemon invocation	caller stdio	result
bsk browsers from PowerShell 5.1 (& bsk ... 2>&1 | Out-String)	pipe	hang, 0 output, > 60 s
bsk -vv browsers from PowerShell	pipe	hang, 0 bytes on stderr
bsk browsers from Node spawn (stdio default pipe, and ['ignore','pipe','pipe'])	pipes	hang, 0 output, > 20 s
bsk browsers from a WMI-created cmd.exe with > out.txt 2> err.txt (outside any job object)	file redirection	hang, both files 0 bytes, > 19 s
bsk browsers via Start-Process -WindowStyle Hidden (own console)	real console	hang, > 20 s
bsk browsers from Node with a minimal clean environment (only PATH/SystemRoot/TEMP/USERPROFILE/...)	pipe	hang, > 20 s
bsk browsers with BSK_AUTO_START=0	pipe	86 ms, exit 2, clear error
bsk daemon start directly	pipe	191 ms, exit 0, daemon healthy afterwards
bsk browsers with a warm daemon	pipe	108-180 ms, exit 0

Daemon log of one cold hang (these lines and then nothing more):

INFO daemon lock acquired                                      (t0 + 0 ms)
INFO ws server listening  127.0.0.1:52800
INFO daemon ready         pid=... ws_port=52800
INFO ipc named-pipe server listening  \.\pipe\bsk-daemon-<hash>
INFO browser connected    id=<browser-id> name=edge generation=1   (t0 + ~4 s)

Even after the extension is connected and the daemon is fully ready, the waiting client never proceeds.

Impact — it also freezes the caller

The auto-started daemon appears to inherit the caller stdio handles and keeps them open. For any consumer that spawns bsk <cmd> with piped stdio and waits for the stream (Node close event, child_process.execFileSync, Python subprocess.communicate()), the pipe never reaches EOF — so even after the consumer own timeout kills the CLI, the consumer stays blocked forever, an uncancellable hanging tool call.

Real incident in a downstream agent harness (DeepSeek Harness plugin @wxg-prc-cpg/browser-skill-dsh-plugin, which runs bsk <cmd> --json with piped stdio):

time	event
T+0 s	harness spawns bsk session start --json; no daemon running
T+0 s	daemon starts (log lines above); extension connects at T+4 s
T+120 s	harness command timeout fires and cancels the CLI (the CLI process is gone afterwards), but the pipe stays open, so the harness keeps waiting
T+1168 s	an operator kills the daemon; the pipes close and the harness unblocks in the same second

This is the classic Windows wait-for-EOF-instead-of-exit trap: a descendant holds the write end of the pipe. The same pattern is documented for another daemon CLI in open-gsd/gsd-browser#62 (daemon start leaves the caller inherited stdio handles open, hanging any consumer that uses a pipe).

Hypothesized cause (outside-in — I have not read the sources)

The automatic-start path seems to wait on the spawned daemon child stdio rather than on its exit or on a readiness handshake — e.g. a Rust wait_with_output() / Command::output() on the bsk daemon start child. That returns on pipe EOF, not on process exit; the daemon keeps the inherited write handle, so EOF never happens. Using bsk daemon start directly does not take that path, which is why it returns in ~190 ms.

Suggested directions:

1. Keep the daemon child off the caller stdio (Stdio::null()) and/or use a readiness handshake over the existing IPC named pipe; wait on that or on process exit — never on pipe EOF.
2. Bound the auto-start wait with a timeout and reuse the error text that the BSK_AUTO_START=0 path already produces.
3. Because of the inherited handles this also leaks into the caller, so keeping every descendant off the caller stdio would stop consumers from hanging even before the wait itself is fixed.

Workarounds

• Consumer side: make sure a daemon is running before the first real command — bsk daemon start returns in ~200 ms and leaves a detached daemon, so pre-warm once per session (this is what I have patched into the DSH plugin).
• Or set BSK_AUTO_START=0 and manage the daemon yourself: you get a bounded, actionable error instead of a hang.
• Consumers should settle on process exit rather than pipe EOF; to unblock a caller that is already stuck, kill the daemon.

Related reports

• bsk doctor hangs indefinitely when no browser extension is connected (Windows, agent context) #265 — bsk doctor hangs indefinitely when no browser extension is connected (Windows). Its workaround is BSK_AUTO_START=0 plus a warm daemon, which matches the hang living in the auto-start path.
• Windows: bsk daemon start auto-detached process exits immediately, extension cannot connect #218 — Windows: bsk daemon start auto-detached process exits immediately, extension cannot connect.
• bsk 在 Windows 上的两个会话可靠性问题：命令刚返回就报 unfinished command，以及 session stop 无法强制终止卡死命令、只能重启 daemon #185 — Windows session reliability: stuck commands and session stop cannot force-terminate.

中文摘要

Windows 11（build 26200）+ bsk/扩展 0.3.0：没有 daemon 在跑时，任何非 daemon 子命令（browsers / status / session start）都会永久挂起且零输出——daemon 其实已经在后台起来了（日志有 daemon ready / browser connected），另一个 shell 的 bsk status 能秒回，但第一个进程永不返回。直接跑 bsk daemon start 191 ms 返回并留下健康 daemon；BSK_AUTO_START=0 时同一条命令 86 ms 返回 exit 2 且错误信息清晰。所以卡死点就在「自动拉起 daemon」这条路径的等待逻辑里。已排除：stdio 类型（管道 / 文件重定向 / 真控制台都复现）、环境变量（最小干净环境同样复现）、job object（WMI 外挂 cmd 同样复现）。

更严重的是它会连带冻住调用方：自动拉起的 daemon 继承了调用方的 stdio 句柄，调用方即使超时杀掉 CLI，管道也到不了 EOF（典型的 Windows「等 EOF 而不是等进程退出」陷阱，参见 open-gsd/gsd-browser#62）。实测事故：调用方 120 s 超时杀掉 CLI 后又被额外阻塞 19 分 28 秒，直到有人手动杀掉 daemon 才在同一秒解冻。建议：让 daemon 子进程完全不碰调用方 stdio（Stdio::null()）并改为等待进程退出 / IPC 就绪握手，同时给自动拉起路径加超时，并复用 BSK_AUTO_START=0 那句错误提示。

[Sthreal]

I would like to work on this issue. I plan to reproduce the Windows auto-start hang, trace the spawn/resume/readiness path, keep the daemon detached from the caller stdio, enforce one deadline across the full auto-start flow, and add a Windows regression test using piped stdio. Could a maintainer confirm whether this approach is acceptable or assign the issue to me?

[iuyo5678]

Thanks a lot for the exceptionally detailed report — your outside-in diagnosis was spot on. In 0.3.0, automatic startup launched an intermediate bsk daemon start with a piped stderr and waited on output(); on Windows the detached daemon inherited that pipe (and the caller's pipes), so EOF never arrived.

This was fixed in #282 (merged 2026-09-20) and shipped in bsk CLI 0.3.1 (released 2026-09-23, one day after this report):

• automatic startup now spawns the daemon directly, with no intermediate launcher and no captured pipe, and waits on IPC readiness with a single bounded deadline;
• on Windows the daemon's stdio points to NUL, and PROC_THREAD_ATTRIBUTE_HANDLE_LIST restricts inheritance to those handles only, so the caller's pipes are never held by the daemon;
• a Windows regression test cold-starts bsk status --json with piped stdio and asserts both process exit and stdout/stderr EOF.

The DSH plugin 0.3.1 also settles on process exit instead of waiting indefinitely for pipe close.

Please upgrade with bsk update (and update the extension/plugin to 0.3.1), then verify with:

bsk daemon stop; Measure-Command { bsk browsers --json }; bsk --version

I'm closing this as fixed. If it still reproduces on 0.3.1, please reopen with bsk --version and the daemon log. Thanks again!

该问题已在 #282 修复，并随 bsk CLI 0.3.1（2026-09-23）发布。升级后如仍能复现，请附 bsk --version 和 daemon 日志重新打开。