[Bug] dsh-browser: browser_open/browser_act crashes the dsh web process (CDP WebSocket has no error fallback); session resumes with "tool outcome unknown"

[zhangtingaxiao666]

Package: @deepseek-ai/dsh-browser@0.1.0-rc.1 (lib/index.js)
Environment: dsh web profile, Node v24.16.0, Windows (Edge/Chrome)

Symptom

• Calling browser_open / browser_act (autonomous-browser tools) crashes the whole dsh web process: the cmd window returns to the prompt (process exits).
• On the next launch, the resumed session shows:

  "The tool call was interrupted after it was recorded, but no result was durably recorded. Its outcome is unknown."

• Sometimes, instead of crashing, the turn hangs forever at "Deep diving..." and the Stop button does nothing (the tool call stays "running").

Root cause (in connectCdp)

1. ws.onmessage calls JSON.parse(ev.data) with no try/catch — a malformed/no-JSON CDP frame throws an uncaught exception and kills the process.
2. After the socket is open there is no onclose/onerror handler, so when Chrome dies or the connection drops, every pending send() promise never settles (infinite hang).
3. send() has no timeout, so even a live-but-unresponsive Chrome hangs the command forever.
4. spawn(chromePath, ...) has no error listener, so a spawn failure emits an unhandled error event that crashes the process.

Expected behavior
The CDP client should reject pending commands (surfacing a normal tool error to the model) on socket close/error, parse frames defensively, and time out stalled commands — instead of crashing the process or hanging the turn. A tool error should be recorded as tool/result (isError) so the conversation continues.

Suggested fix (I patched this locally and it works)

• Wrap JSON.parse in try/catch.
• Add onclose/onerror → reject all pending sends.
• Add a timeout to send().
• Add an error listener on the spawned Chrome process.

[Mide69]

Checked before answering, and this looks like it's not actually about a package in this repo.

@deepseek-ai/dsh-browser does not exist. It's not published under the @deepseek-ai scope on npm (npm view returns a plain 404), and there is no package anywhere in packages/ with browser_open or browser_act as tool names, no connectCdp function, nothing CDP-related outside packages/experimental/inspector (which is a debugger, unrelated to browser automation). So this can't be verified against this repo's source, because the thing it's describing isn't in it.

Searching npm for dsh-browser turns up a real package with that exact name, but it's unscoped (published by a community author, not @deepseek-ai) and its own description says it's Playwright-based (open/click/type/screenshot/eval), which doesn't match a hand-rolled raw CDP WebSocket client with connectCdp, ws.onmessage, and spawn(chromePath, ...). So even that isn't a clean match for what you're describing. There are also a dozen or so other community browser-automation plugins on npm with similar names (dsh-browser-firefox, dsh-agent-browser, various scoped @user/dsh-browser-* packages), any of which could be the real source.

Worth checking your own node_modules or lockfile for the exact resolved package name and its actual npm scope/author, since "dsh-browser" alone isn't unique in this ecosystem. If the bug is real (and the diagnosis reads like it probably is, a raw CDP client with no error/close handling and no send timeout is a believable way to crash a Node process), it needs to go to that specific plugin's own repo, not here, since this Discussions space is for the official deepseek-ai/deepseek-harness project per CONTRIBUTING.md and third-party plugins aren't part of this codebase.