`bsk doctor` hangs indefinitely when no browser extension is connected (Windows, agent context)

Start with AGENT_INSTALL.md and trace the bsk doctor path that auto-starts services before waiting for the browser extension. Reproduce on Windows with no extension connected, then verify that the command exits within a bounded window with the existing FAIL row and hint, while the BSK_AUTO_START=0 behavior remains prompt.

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

1. Install CLI 0.2.1 on Windows before the browser extension is installed (so no browser is connected).
2. Run bsk doctor, without BSK_AUTO_START=0.
3. 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.