Environment
- bsk CLI: 0.2.1 (installed via
install.ps1 from main)
- OS: Windows 11 x64
- Shell: Git Bash (MSYS) and Windows PS 5.1
- Daemon protocol: 1.1
- Agent harness: WorkBuddy (
~/.workbuddy/skills)
Steps to reproduce
- Install CLI 0.2.1 on Windows before the browser extension is installed (so no browser is connected).
- Run
bsk doctor, without BSK_AUTO_START=0.
- It prints
waiting for browser extension to connect... and then never returns.
Actual behavior
The command blocks with no further output and no exit. Two separate runs went for 4m09s and 3m54s before I killed the shell both times.
timeout 90 bsk doctor does not help on Windows: the timeout signal does not terminate bsk.exe, so the process keeps running and the shell call never comes back.
Expected behavior
doctor should be bounded. If no browser extension connects within a reasonable window (say 30s), it should print the extension connected row as FAIL with the existing hint and exit, or expose an explicit --timeout <duration> / --no-wait flag so the caller can bound it.
The existing hint (Chrome Web Store / Edge Add-ons links) is genuinely good - in this state it just never gets a chance to print.
Why this hurts agents specifically
doctor is the first command an agent runs, and AGENT_INSTALL.md tells agents to run it during setup. Agents invoke shell tools with a fixed per-call timeout and usually capture stdout, so an unbounded wait means:
- the whole agent turn is consumed with no output to reason about;
- common wrappers cannot reclaim it on Windows (
timeout does not work here, and backgrounding plus polling still leaves the process alive);
- the operator has to kill the shell by hand.
Additional data point
With BSK_AUTO_START=0 and the daemon already running, the same command returns immediately with the expected FAIL row and hint. So the hang looks like it lives in the "start services, then wait for the extension" path rather than in the check itself.
Workaround
BSK_AUTO_START=0 bsk doctor returns promptly once the daemon is up.
Suggestion
Bound the extension wait by default (or add a flag), and mention BSK_AUTO_START=0 in AGENT_INSTALL.md as the way to get a non-blocking run for agents.
Positive note
Once the extension was installed everything was green, and a full session lifecycle (session start -> navigate -> observe -> screenshot -> session stop) worked on the first try. Thanks for building this.
Environment
install.ps1from main)~/.workbuddy/skills)Steps to reproduce
bsk doctor, withoutBSK_AUTO_START=0.waiting for browser extension to connect...and then never returns.Actual behavior
The command blocks with no further output and no exit. Two separate runs went for 4m09s and 3m54s before I killed the shell both times.
timeout 90 bsk doctordoes not help on Windows: thetimeoutsignal does not terminatebsk.exe, so the process keeps running and the shell call never comes back.Expected behavior
doctorshould be bounded. If no browser extension connects within a reasonable window (say 30s), it should print theextension connectedrow as FAIL with the existing hint and exit, or expose an explicit--timeout <duration>/--no-waitflag so the caller can bound it.The existing hint (Chrome Web Store / Edge Add-ons links) is genuinely good - in this state it just never gets a chance to print.
Why this hurts agents specifically
doctoris the first command an agent runs, andAGENT_INSTALL.mdtells agents to run it during setup. Agents invoke shell tools with a fixed per-call timeout and usually capture stdout, so an unbounded wait means:timeoutdoes not work here, and backgrounding plus polling still leaves the process alive);Additional data point
With
BSK_AUTO_START=0and the daemon already running, the same command returns immediately with the expected FAIL row and hint. So the hang looks like it lives in the "start services, then wait for the extension" path rather than in the check itself.Workaround
BSK_AUTO_START=0 bsk doctorreturns promptly once the daemon is up.Suggestion
Bound the extension wait by default (or add a flag), and mention
BSK_AUTO_START=0inAGENT_INSTALL.mdas the way to get a non-blocking run for agents.Positive note
Once the extension was installed everything was green, and a full session lifecycle (
session start->navigate->observe->screenshot->session stop) worked on the first try. Thanks for building this.