Remote web UI: ask_user_question card vanishes after mux reconnect (SSH / reverse-proxy)

[clarkzhao]

Symptom

When DeepSeek Harness web is reached over a remote hop (SSH local-forward, Tailscale Serve, or any reverse proxy that is not loopback), ask_user_question can leave the turn blocked on the host while the browser composer never shows the question card.

Locally (http://127.0.0.1:3080) the same session usually works. Remotely the session still looks “running”, tool-call / assistant events keep arriving, but the input bar is never replaced by the question UI. The only recovery is to cancel the turn. After cancel, the tool result is:

Error: ask_user_question was aborted before the user answered

This is not “the tool is missing from the preset”. The model-facing tool ran. The human never got a card to answer.

Environment that reproduces it

• DSH web (npx @deepseek-ai/dsh web) listening on 127.0.0.1:3080
• Browser not on the same machine; access via:
  • ssh -L 3080:127.0.0.1:3080 …, or
  • Tailscale Serve (https://<magicdns> → 127.0.0.1:3080)
• --trusted-host is set so /api is not 403 (page loads, history loads, live events flow)
• A preset that actually composes @deepseek-ai/dsh-tool-ask-user (official Standard / creative-style presets do)
• Trigger: any turn that calls ask_user_question and then sits waiting for a human

Idle time on the hop (tens of seconds is enough on some SSH / Serve paths) makes it much more likely.

Expected

1. Model calls ask_user_question.
2. Host registers a pending wait and pushes question/requested on the mux downlink.
3. The web composer chain elects the question plugin and renders the card (options / custom / skip).
4. Answering posts /api/respond with the same rpcId; host settles the tool call; the loop continues.

A later mux reconnect while the question is still pending should re-show the same card, because the wait is still live on the host.

Actual (remote)

Steps 1–2 happen. Step 3 often does not. The host stays in userQuestions.ask() until the user cancels. Refreshing the page does not recover the card if the client later wipes the wait (see below). Cancelling the turn is the only way out.

Why this is a remote-only footgun

ask_user_question is not a session-log event. It is a generation-scoped mux frame:

• Host (dsh-host-apiproxy) registerProvider.ask() mints an rpcId, stores the wait in an in-memory table, and pushes { type: "question/requested", sessionId, questions } to every connected mux consumer.
• On mux subscribe, still-pending waits are replayed into the new stream (same rpcId).
• question/resolved is also mux-only.
• None of this is written to session.jsonl. History backfill cannot restore a card.

So the card’s entire lifetime is: mux frame → client Session.pending → conversation.composer chain.

The browser downlink is a WebSocket (GET /api/events.mux upgrade), not SSE. Unary RPCs stay on HTTP. A hop that drops idle WebSockets (SSH -L, Tailscale Serve, many reverse proxies) will tear the mux even while HTTP history/prompt still work. That is why the chat can look healthy and the card still disappears.

Race (this is the bug)

Official client reconnect order:

1. Mux socket opens. Host immediately replays every still-pending question/requested / approval/requested.
2. Readiness handshake (host.describe + both streams open) succeeds → onConnected.
3. Session.resync() rebuilds the history window.

In current dsh-client-runtime, resync() does:

this.pending.clear()
then re-open history

History does not contain the question. The frames from step 1 were already applied to pending. Step 3 deletes them. The composer’s selectQuestion then sees an empty interactions list and keeps the normal input bar.

The comments around disconnect already know the right model:

• On disconnect, drop generation-scoped waits (they may have been answered while the socket was dead; there is no frame for that).
• On mux-open, replay re-adds every still-pending host request with its live rpcId.

Clearing pending in resync() (which runs after that replay) inverts the contract. On a stable loopback socket you rarely reconnect mid-wait, so the bug stays hidden. On SSH / Serve you reconnect often, so the card is gone and the tool is still blocked.

There is a second aggravating factor: the host WebSocket downlink does not ping. An idle remote hop can close the socket, which forces the reconnect path above while a question is outstanding.

Suggested direction (not a patch request, just the invariant)

Two independent, demoable slices:

1. Pending-wait lifetime vs reconnect
   Treat question/requested / approval/requested as mux-generation state:

   • Clear them on disconnect (old generation is dead).
   • Do not clear them in resync() / onConnected (replay already ran).
   • After reconnect, a still-pending host wait must produce a visible composer card without the user cancelling.

2. Keep the downlink alive on a hop
   Server-side WebSocket ping (e.g. every 15s) on /api/events.mux and /api/events.host, so an idle SSH / Serve path does not force a reconnect in the first place.

Slice 1 is sufficient to make a pending question survive reconnect. Slice 2 reduces how often you hit the path.

Acceptance

• Call ask_user_question from a session opened through SSH -L or Tailscale Serve; the question card appears in the composer without cancelling the turn.
• While the card is up, drop and restore the mux (disable the hop for a few seconds, or wait for an idle timeout). After the client reconnects, the same pending question is visible again (same rpcId / same options).
• Answering the restored card settles the host wait and the agent continues.
• Loopback http://127.0.0.1:3080 behaviour is unchanged.
• A cancelled / already-answered wait does not resurrect a stale card after reconnect.

Notes

• Preset composition is fine: @deepseek-ai/dsh-tool-ask-user is per-agent; @deepseek-ai/dsh-client-ui-user-questions is the host UI and is already in the web-app overlay. This is not “the tool was not unlocked”.
• --trusted-host 403s are a different class of failure (nothing in /api works). Here unary /api works; only the wait UI is missing.
• Issues are disabled on this repo, so this is filed as a Discussion.

[PerryLink]

The mechanism you diagnosed is real, but it belongs to the pre-dsh-v0.1.2-alpha.1 client stack: packages/client/runtime and the question/requested mux frame were removed on 2026-08-23 (be531688f3, "refactor(client): migrate consumers and remove Runtime"), which first shipped in dsh-v0.1.2-alpha.1. On dsh-v0.1.6-alpha.2 (ddefc45fbc) there is no dsh-client-runtime, no question/requested / question/resolved mux frame, and no resync() that clears a session-scoped pending map. resync() still exists (packages/api/session-controller/src/client/sessions/session.ts:454-469) but it now only rebuilds the history window; pending interactions are not stored there.

What replaced it, and it answers both slices you proposed:

1. A question is a pending scoped waterfall, not a session-scoped client table

• Host side: packages/api/remotes/src/index.ts:48-81 forwards the allowlisted waterfall events; a still-pending invocation is retained with its event id (forwardWaterfall, :134-158).
• The replay contract is explicit: packages/api/gateway/README.md:78 — connection generations reopen the internal $events stream, "one-way notifications are not replayed, while pending scoped waterfalls retain their event id across replay". Same statement in packages/api/remotes/README.md:75: "Only scoped waterfalls that are still pending are replayed after reconnection".
• It is covered by a test: packages/api/gateway/tests/gateway-stream.host.spec.ts:759-785 — a replacement client generation receives the same eventId, and answering it settles the original host-side promise.
• Client side: the listener is registered once on the plugin fiber — packages/client/ui-user-questions/src/client/index.ts:105-107 ctx.remote.$on('user-questions/request', …) — while the delivery pump is reopened per connection generation (packages/api/gateway/src/client/remote-events.ts:79 and :108-114). Nothing session-scoped is cleared on reconnect, so a replayed invocation re-enters answerQuestion (:54-61) and re-registers the pending question with the composer carrier (:65-68).

2. Slice 2 (server-side ping) is implemented

packages/api/gateway/src/stream-server.ts:22,75-94: the mux pings every heartbeatIntervalMs and terminates a socket after MAX_MISSED_HEARTBEATS = 2 unanswered pings, so an idle SSH / Serve path is no longer silently torn down. The default is 2000 ms, configurable as websocketHeartbeatIntervalMs (packages/api/gateway/src/index.ts:116-121,171-174).

Both changes are contained in dsh-v0.1.2-alpha.1 and every release since — including 0.1.5-rc.2 (current latest) and 0.1.6-alpha.2 (alpha).

3. If you still see it on a current version, here is what decides it

We cannot reproduce your hop (no SSH/Tailscale path to this host), so the following is what separates the remaining candidates rather than a verdict:

• Did the replay arrive? In DevTools → Network → WS, select the mux socket and look for an invocation frame carrying user-questions/request after the socket reopens. (a) Replay arrives, no card → the break is client-side after delivery: the composer chain selector (packages/client/ui-user-questions/src/client/index.ts:94-104) or a stale Session-scoped question-draft store (packages/client/ui-user-questions/src/client/draft-store.ts, whose lifetime is documented at packages/client/ui-user-questions/README.md:40). (b) No invocation after reopen → the break is in the host-side replay/pending path, and the gateway-stream.host.spec.ts:759-785 invariant is what to compare against.
• Is the socket actually dying? On the same socket, Ping/Pong control frames should appear roughly every 2 s. Their absence means your build predates af562d3649 ("fix(api-gateway): keep idle websocket alive") or the interval was raised; their presence means teardown is not the trigger and (a)/(b) above decides it.
• Does answering do anything? A restored card posts its result for that eventId — REMOTE_EVENT_RESULT_ENDPOINT is defined at packages/api/gateway/src/stream-protocol.ts:12 as '$events/result', assembled with eventId: frame.eventId at packages/api/gateway/src/client/remote-events.ts:214 and POSTed at :221. If the card renders but answering is a no-op, that POST is the thing to capture.
• Preset is still not the variable — agreed with your original note: the model-facing tool ran, so composition is fine. --trusted-host 403s also remain a different class: unary /api works in your report.

4. Two honest caveats

• There is still no reconnect coverage for the composer: apps/web/tests/question-composer.e2e.ts exercises the question flow but nothing there drops and restores the mux, so your third acceptance criterion ("the same pending question is visible again after the client reconnects") is not pinned by a test. A reconnect case in that e2e is the cheapest way to prove or falsify it.
• We did not reproduce your remote hop, so everything above is code and contract on dsh-v0.1.6-alpha.2, not an observed recovery.

If this gets you to the failing link, marking it as the answer will help the next person who loses a card on a proxied connection start from the replay contract instead of the composer.