Bug report: ask_user_question card never appears in the browser; turn hangs indefinitely

[Q1hangL]

Bug report: ask_user_question card never appears in browser, turn hangs indefinitely

Ready to paste into DeepSeek Harness GitHub Discussions (Bug Reports).
Prepared: 2026-08-14. Diagnosis artifacts listed at the end.

Environment

• @deepseek-ai/dsh v0.1.0-rc.6 (installed via npx)
• dsh web profile, Windows 10, Chrome-class browser
• Single user, localhost, no proxy-specific config in the harness itself

Summary

When the model calls ask_user_question, the browser sometimes never shows the
question card. The chat shows the tool call stuck in its pending state, and the
turn hangs with no timeout — observed for 22.6 minutes and 6.1 hours in two
incidents. The only way out is pressing Stop, which aborts the turn and returns
Error: ask_user_question was aborted before the user answered (ASK_ABORTED).

Reproduction

1. Start dsh web, open a session, ask the agent something that triggers
   ask_user_question.
2. Walk away from the computer, or let the laptop sleep / the browser tab get
   backgrounded or frozen (Chrome Memory Saver, Windows Modern Standby).
3. On return, the question card is not visible, only the pending tool call.
   The turn has been hanging the whole time.
4. Press Stop: the turn aborts with ASK_ABORTED (turn/end reason
   {kind:"aborted", reason:{kind:"user"}}).
5. With the user present and the page in the foreground, the same flow works
   perfectly (card renders, answering resolves the call).

Root cause analysis

Two stacked issues:

1. Single-push delivery over a connection with no heartbeat.

dsh-host-apiproxy registers the web user-questions provider and pushes one
question/requested frame to every mux queue
(packages/host/apiproxy/src/index.ts, the ctx.userQuestions.registerProvider
block). Pending questions are replayed to a client only when it (re)subscribes
(the events.mux baseline loop). The mux WebSocket transport has no
application-level heartbeat on either side: the client
(packages/client/connection/src/* readWebSocket) relies solely on the
WebSocket close event, and the host WS server sends no ping/pong. When the
connection dies half-open (OS sleep, backgrounded/frozen tab, NAT/proxy idle
timeout — no FIN), the pushed frame is lost, the client never sees close, so
it never reconnects, and the replay path is never reached. The page keeps
displaying stale local state and looks healthy.

2. ask_user_question declares no timeout budget.

The tool's README states it declares no timeout-policy budget, and
dsh-tool-call-timeout-policy only enforces budgets declared by tool plugins.
So a lost question blocks the turn forever. (A budget would turn the hang into
a clean TOOL_TIMEOUT result after N minutes.)

Evidence: the durable session log shows zero events between tool/call and the
abort in both incidents; an independent WebSocket client connected to
/api/events.mux during a healthy third run received
question/requested / question/resolved answered within 4 seconds, proving
the host broadcast and replay mechanisms themselves are correct.

Suggested fixes

1. Heartbeat on the mux WS (highest value): host-side ws.ping() with
   terminate-on-no-pong (browsers auto-answer protocol pings) or app-level
   ping/pong frames, plus a client-side watchdog. A detected half-open
   connection then reconnects, and the existing replay-on-subscribe delivers
   pending questions automatically.
2. Timeout for ask_user_question: declare a timeoutMs (e.g. 5–10 min)
   on the tool definition; the existing dsh-tool-call-timeout-policy
   mechanism turns a lost question into a structured TOOL_TIMEOUT instead of
   an infinite hang.
3. Client-side affordance: while a question is pending past a threshold,
   show a hint ("no response — press F5 to re-sync or Stop") since a page
   refresh triggers the replay path.

Workaround for users

• Keep the page in the foreground when expecting a question.
• If stuck at the pending tool call with no card: press F5 — reconnect
  replays the pending question and the card appears; or press Stop and answer
  in chat.

[oliblue-evan]

Nice repro write-up. We hit the same symptom family on a self-hosted instance (master build behind a reverse proxy), and the missing piece turned out to be the real-time event channel, not the card itself — worth checking before digging into card rendering:

1. The question card is delivered over the events.mux WebSocket stream. In the browser console, look for [web-runtime] connection lost, retry #N or WebSocket connection to '…/api/events.mux' failed around the time the card stops appearing.
2. When the tab is backgrounded or frozen (Chrome Memory Saver, Windows Modern Standby), the WS either dies silently or the browser stops delivering frames; on resume the client reconnects, but the pending ask_user_question state is not re-subscribed — so the turn hangs even though the server emitted the event correctly.
3. Server-side triage: check whether the question event was actually emitted (the pending tool/call exists in the session log). If the event is there but the browser never renders the card, it is a client delivery / re-subscription gap, not a server-side one.

In our case the root cause was the proxy stripping the WebSocket upgrade (Host header rewritten → 403 on the events endpoints, and an authenticating tunnel returning 200 HTML instead of 101). Fixing the proxy made cards appear reliably. On localhost that particular cause should not apply, but the backgrounded-tab WS death + no re-subscribe path is plausibly the same root family. Useful checks:

• Console around the hang: any WS close / reconnect lines?
• Does the card appear if the tab stays focused the whole time?
• After a reconnect, does a fresh ask_user_question from a new turn render (i.e. is only the pre-hang pending card lost)?

If it turns out to be the re-subscribe gap, a minimal client-side fix would be re-emitting / re-querying pending ask_user_question state on reconnect. Happy to help dig further if you share the console output from a hang.

[Q1hangL]

Thanks — this is a great cross-check, and your proxy finding is a valuable data point for self-hosted users (WS upgrade stripped → 403/200-HTML instead of 101): same symptom family, different trigger.

On our side we already ran the triage you list, with two results worth sharing:

1. Server-side check: the durable session log shows the pending tool/call with zero events between call and abort (22.6 min and 6.1 h in the two captures). Since question/requested is live-only, "emitted vs delivered" had to be proven separately — we connected an independent WebSocket client to /api/events.mux during a healthy run and received question/requested → question/resolved answered within 4 s. Host broadcast works on rc.6.

2. Re-subscribe: on rc.6 the host does replay pending questions when a client (re)subscribes (the events.mux baseline loop in dsh-host-apiproxy), so a reconnect should re-deliver the pending card — which matches your "fresh ask after reconnect renders" prediction. The remaining gap in our case is that the reconnect never happens: the mux WS has no heartbeat on either side (client readWebSocket relies solely on close; host sends no ping/pong), so a half-open connection (tab frozen / sleep / no-FIN proxy drop) never fires close and the replay path is never reached. That lines up with your "WS dies silently" observation.

Practical consequences: F5 forces the reconnect+replay and recovers the pending card (we documented it in the workaround); and we shipped the ask-timeout side as a community plugin since the harness currently accepts no external PRs: https://github.com/Q1hangL/dsh-ask-guard (a tools/execute deadline wrapper that resolves a lost question as a structured ASK_TIMEOUT instead of hanging forever).

Happy to capture and share console output from the next real reproduction — the [web-runtime] connection lost lines would confirm the heartbeat gap directly.

[oliblue-evan]

Your half-open-connection analysis checks out against master too — I verified it in the source:

• Client side: packages/client/connection/src/client/web-api-client.ts registers only open / message / close listeners; there is no heartbeat and no frame-interval watchdog. On a half-open socket (no FIN), handleClose never fires and the reader blocks on an empty inbox forever — the reconnect/replay path is unreachable by design.
• Host side: the mux endpoints send no ping frames either, so nothing can surface a dead peer.

Two distinct silent-failure paths converge on the same missing liveness signal:

1. Your case: half-open connection (frozen tab / sleep / proxy drop without FIN) — no close, no reconnect, pending card never replayed.
2. Our self-hosted case: the proxy terminates the WS upgrade (403 / 200-HTML instead of 101) — the client does get an error/close, so reconnect fires, but it fails immediately and loops ([web-runtime] connection lost, retry #N).

Both disappear with a liveness mechanism. The minimal fix that needs no protocol change: a client-side frame watchdog — if no frame (any frame) arrives within N seconds, call socket.close() to force the existing reconnect+replay path. Browsers answer server pings automatically, so a host-side ping (protocol-level, no client code) also works if you'd rather fix it server-side.

Your dsh-ask-guard timeout wrapper is a good belt-and-suspenders layer regardless — the watchdog fixes delivery, the timeout fixes the "model waiting forever" worst case. Happy to test a watchdog patch against our master instance if you open one.

[Q1hangL]

Patch is up, exactly the client-side frame-watchdog shape you described — branch fix/mux-frame-watchdog on my fork, commit f4831a7:

https://github.com/Q1hangL/deepseek-harness/tree/fix/mux-frame-watchdog

What it does: ConnectionController arms a per-stream frame watchdog (ConnectionConfig.frameWatchdogMs, default 300000 ms — follows the existing tunables pattern in src/client/connection.ts). Each pump records its last frame timestamp; a timer re-checks at most every 30 s and aborts the generation once that stream has been silent past the limit. The abort rides the existing teardown, so the reconnect path re-subscribes and the host's baseline replay re-delivers the pending question card. Per-stream rather than per-generation deliberately: host-stream traffic must not mask a silently dead mux stream (mux is the question channel).

Evidence so far:

• Targeted suite: pnpm exec vitest run packages/client/connection/tests/connection.client.spec.ts → 17/17 (3 new cases: both streams silent → reconnect at the watchdog limit; host fed + mux silent → reconnect (per-stream isolation); both fed every 30 ms → no reconnect across 2× the window).
• Repo's own pre-push gate ran the narrow typecheck on this diff: green.
• Included per repo conventions: bilingual Agent Note pair (2026-08-14-mux-frame-watchdog) and README updates for both languages; the *.i18n.yaml hashes were computed with git hash-object, but re-run pnpm run verify-translation-pairing --write … if you edit either side after cherry-pick.

On your master instance: cherry-pick f4831a7, drop frameWatchdogMs to e.g. 60_000 for a quick loop, then freeze the tab / kill the socket without a FIN — you should see [web-runtime] connection lost, retry #1 within the window and the pending card re-render after reconnect. The tunable stays programmatic on ConnectionConfig until the client half grows plugin-level Config — happy to wire that through a cordis.yml row if you'd prefer it user-tunable before landing.