Bug: browser crypto.randomUUID fails on HTTP non-loopback origins (Settings + Agent presets stuck on LAN)

[skyle97]

Summary

crypto.randomUUID() is called from two browser-bundled code paths. The Web Crypto API requires a secure context (HTTPS or loopback) and is undefined on a plain HTTP origin. A deployment that binds the Web UI to a non-loopback address (e.g. via the documented 0.0.0.0 patch overlay) therefore fails every browser RPC with crypto.randomUUID is not a function, leaving the Settings page stuck on the retry toast and the Agent-presets page empty.

The repository already ships a randomUuid() helper at packages/client/connection/src/client/random-uuid.ts built on crypto.getRandomValues() (which is exposed on every origin), and the same helper is used by rpc.ts and fixture.ts inside that package. The two remaining browser-bundled call sites still reach for crypto.randomUUID() directly.

Reproduction (rc.7, current behavior)

1. Bind the Web UI to 0.0.0.0 via a cordis.patch.yml overlay on the webserver row (the documented way to expose the LAN UI; the CLI intentionally does not support --host 0.0.0.0).
2. Run dsh web and open http://<lan-ip>:3080/ in any modern browser.
3. Click Settings → Models, or Settings → Agent presets.

Expected: the provider directory and the four built-in presets load. Actual: every RPC fails with crypto.randomUUID is not a function. The Agent-presets page shows "Could not load agent presets. crypto.randomUUID is not a function"; the Settings → Models page shows a permanent "Loading the provider directory failed" toast.

Note on settings.describe: Settings → Models is also gated by the PRIVILEGED_METHODS list in packages/host/connection/src/index.ts, which keeps that endpoint loopback-only by design (settings + credentials mutate the user's secret store and trustedHosts is documented as a DNS-rebinding fence, not authentication). That is a separate, intentional design decision; the present report is only about the randomUUID failure that precedes it.

Verified impact

Origin	crypto.randomUUID	isSecureContext	Bug
http://127.0.0.1:3080	function	true	no
http://<lan-ip>:3080	undefined	false	yes

Affected call sites

grep -rn 'crypto\.randomUUID' packages/ --include='*.ts' | grep -v '\.d\.ts' yields three non-comment hits; one is host-only (server-side message.ts:183), two are browser-bundled:

• packages/host/apiproxy/src/fetch/client.ts:300 — AbstractApiClient.mintRpcId()
• packages/client/ui-conversation/src/client/service.ts:65 — browserDraftAttachment()

Suggested fix

Replace both call sites with the existing browser-safe randomUuid() helper, inlined per file to keep the patch self-contained (an extra util package would be cleaner and I'm happy to refactor in a follow-up if maintainers prefer). The helper is ~10 lines and produces an RFC 4122 v4 UUID via globalThis.crypto.getRandomValues, which is exposed on every origin (HTTPS, HTTP, file://).

Reference

• Full patch as a gist: https://gist.github.com/skyle97/b85fdc8fcf0dc6c3330722df4760039c

• Branch on a fork (offered as a cherry-pick reference, not a PR per CONTRIBUTING.md): https://github.com/skyle97/deepseek-harness/tree/fix/browser-secure-context-randomuuid (commit 267de88)

• Diff stat:

   .../client/ui-conversation/src/client/service.ts   | 15 +++++++++++-
   packages/host/apiproxy/src/fetch/client.ts         | 28 ++++++++++++++++++++--
   2 files changed, 40 insertions(+), 3 deletions(-)
  

Environment

• @deepseek-ai/dsh@0.1.0-rc.7 (commit 99f6f02)
• Node.js 22.22.2
• Chromium 147 (Linux), Firefox/Safari share the same secure-context rule
• Bind: 0.0.0.0:3080 via cordis.patch.yml overlay on webserver.host
• Workaround used in the meantime: a pnpm postinstall script that patches the compiled bundles on disk (same patch shape, applied to lib/client.js rather than the source).

Thanks for the open-source release and the explicit "Identify and report issues" invitation in CONTRIBUTING.md — happy to follow up if anything in the repro or the proposed fix needs to be sharpened.

[hungnnvidia]

Proposed fix (fork PR): hungnnvidia#4 — replace remaining browser crypto.randomUUID call sites with a getRandomValues-based helper.

[hungnnvidia]

Proposed fix (fork PR): hungnnvidia#4 — remaining browser crypto.randomUUID call sites now use getRandomValues.

[mattheliu]

I reproduced this issue and verified a local workaround.

Environment:

• Linux x86_64
• Node.js 24.x
• @deepseek-ai/dsh 0.1.1-rc.2 installed from npm
• DSH listening on http://127.0.0.1:<dsh-port>
• Browser access through http://<private-lan-ip>:<proxy-port>

I observed three separate layers:

1. The first RPC failed with crypto.randomUUID is not a function.
2. After adding a UUID v4 fallback based on crypto.getRandomValues(), /api/llm.providers returned HTTP 403 because the browser-facing Host and Origin were non-loopback.
3. After proxying API/WebSocket traffic through loopback, the frontend still selected its remote/memory settings mode from location.hostname, producing settings are unavailable in this browser.

For local testing, I used a compatibility reverse proxy that:

• injects a crypto.randomUUID fallback based on crypto.getRandomValues();
• proxies HTTP and WebSocket traffic to the loopback DSH listener;
• normalizes upstream Host and Origin to the loopback authority; and
• makes the connection client use loopback settings mode.

After that, I verified successful responses from llm.providers, settings.describe, and settings.mutate.

Security warning: normalizing remote requests as loopback bypasses DSH's intentional loopback-only protection for settings and credential-related APIs. I tested this only on a restricted private network. This should not be exposed publicly or treated as a production solution without HTTPS and authentication.

A source-level fix for the direct crypto.randomUUID() calls is still useful, but it only fixes the browser compatibility/RPC layer. It does not make the Settings UI remotely available by itself. It would be helpful to document this distinction and clarify whether an authenticated remote-settings mode is planned.