crypto.randomUUID is unavailable on non-secure contexts, breaking the Web UI over plain-HTTP LAN/Tailscale access

[hyq58]

问题摘要

When the dsh Web UI is served over plain HTTP from a non-loopback address (LAN IP, Tailscale IP, or a hostname), the frontend crashes on every RPC, because crypto.randomUUID only exists in secure contexts (HTTPS, http://localhost, http://127.0.0.1). Symptom: the page shell loads, but workspaces/sessions/models never render — the workspace selector spins forever ("正在加载工作区"), and the console reports:

crypto.randomUUID is not a function. (In 'crypto.randomUUID()', 'crypto.randomUUID' is undefined)

Root cause

Several boot-critical paths call crypto.randomUUID() with no fallback:

• mintRpcId() in the connection client (packages/client/connection): return RpcId(crypto.randomUUID()) — every unary /api call mints an rpc id, so on insecure origins every request throws before it is sent.
• createMessage(...) / message ids: MessageId(crypto.randomUUID()).
• browserDraftAttachment(...) in dsh-client-ui-conversation (image drafts).

Note that crypto.getRandomValues is available on insecure origins — only randomUUID is gated to secure contexts — so an RFC 4122 v4 fallback built on getRandomValues is trivial.

Repro

1. Serve the Web UI on a LAN interface (the CLI intentionally rejects --host 0.0.0.0, but the webserver row's config schema accepts it; a port forward / reverse proxy from loopback reproduces it too).
2. From another machine (or the same machine using the LAN IP instead of 127.0.0.1), open http://<ip>:3080.
3. DevTools console shows the error above; session/workspace list never loads.

Loopback access (http://127.0.0.1:3080) is unaffected because loopback is a secure context.

Suggested fix

• Install a tiny crypto.randomUUID polyfill (UUID v4 via crypto.getRandomValues) early in the client bundle when the API is missing, and/or
• give mintRpcId and message-id creation a fallback that does not depend on crypto.randomUUID (e.g. getRandomValues-based v4).

A reference for the same class of fix: openai/openai-agents-js PR #510 ("add fallback when crypto.randomUUID is unavailable").

Context / impact

This looks like the same root cause the community has already been working around this week — e.g. AcidGr/dsh-web-lan-access injects a polyfill via the official webServer.tapIndex extension point, and @visol-456/dsh-web-compat does it from a client bundle. Given that the CLI says 0.0.0.0 binding is "intentionally not supported yet", plain-HTTP LAN/Tailscale serving is clearly a direction the product wants to support — fixing the fallback upstream would make it work out of the box and let those workarounds go away.

Environment

• dsh @deepseek-ai/dsh@0.1.0-rc.6
• Node v22, macOS; reproduced in desktop Chrome and mobile Safari (iOS).