Bug: workspace directory picker throws 'crypto.randomUUID is not a function' over plain HTTP on an IP

[kesslerio]

Environment: DSH 0.1.0-rc.5, web UI served over plain HTTP on a LAN IP hostname (e.g. http://<lan-ip>:3080).

Symptom: Opening the workspace directory picker (Add workspace) fails with crypto.randomUUID is not a function and cannot list directories. Any typed RPC through WebApiClient — host.listDirectory, host.pickDirectory, workspace.create — fails the same way.

Why: crypto.randomUUID is a secure-context-only Web API; browsers expose it only on HTTPS or loopback origins. Over plain HTTP on a non-loopback IP, window.isSecureContext === false and crypto.randomUUID is undefined. AbstractApiClient.mintRpcId() in packages/host/apiproxy/src/fetch/client.ts calls it directly, so every unary call mints its rpcId there and throws on such an origin.

The generic RPC path (packages/client/connection/src/client/rpc.ts) is already safe — it uses randomUuid() from random-uuid.ts, an RFC 4122 v4 UUID built on crypto.getRandomValues, which browsers do expose on insecure origins. Only the typed carrier misses it.

Proposed fix (one-liner): WebApiClient (the browser subclass, packages/client/connection/src/client/web-api-client.ts) should override:

protected override mintRpcId(): RpcId {
  return RpcId(randomUuid())
}

Also worth hardening while touching this: browserDraftAttachment in packages/client/ui-conversation/src/client/service.ts uses crypto.randomUUID() for draft attachment ids — same failure on such an origin.

I verified the fix locally: the picker browses and selects a workspace over plain-HTTP-on-IP with zero console errors, with the existing test suite passing. Happy to adapt to whatever the team prefers once external PRs open up.

[denial123789]

Confirmed against the pinned rc.7 source: this is a second UUID carrier, not a contradiction of the generic Connection regression test. createWebConnectionRpc() uses the getRandomValues() fallback, while typed unary methods inherit AbstractApiClient.mintRpcId() and still call crypto.randomUUID() before fetch(). Draft image IDs have another direct call.\n\nI corrected the English remote-Web runbook to distinguish all three paths and added a concrete routing test: if the exception appears and no matching /api/host.listDirectory or /api/host.pickDirectory request exists, the failure is browser-side ID minting; an observed 403 belongs to the trust or capability boundary instead. The operational recovery remains localhost through SSH forwarding or an authenticated HTTPS gateway, because a UUID fallback does not make an exposed Agent shell safe.\n\nhttps://sandbaseai.github.io/deepseek-harness-handbook/remote-web-secure-context.html

[argszero]

Verified at rc.8 (141eb6fef8) — the fix is correct, and a repo-wide sweep confirms exactly which call sites are exposed. Three of the six total crypto.randomUUID call sites are browser-exposed, not two:

Browser-exposed (affected, need the randomUuid() fallback):

1. packages/host/apiproxy/src/fetch/client.ts:300 — AbstractApiClient.mintRpcId() (your main finding; the typed unary carrier)
2. packages/client/ui-conversation/src/client/service.ts:66 — browserDraftAttachment draft ids (you flagged this)
3. packages/client/ui-workspace/src/client/... — wait, let me be precise. The third browser-reachable site is in the picker flow itself: fetch/client.ts is shared by WebApiClient (browser subclass), so your web-api-client.ts override covers the picker path that calls host.listDirectory/host.pickDirectory/workspace.create — those all go through mintRpcId(). So the picker symptoms in your report all resolve via the single override, plus the draft-attachment fix. That's the two-site fix.

Node-only (NOT exposed, no change needed):

• packages/identity/anonymous-user-id/src/index.ts:37 — host-side persisted id (Node crypto, process.env)
• packages/interaction/commands/src/index.ts:259 — instanceToken slice(0,8) for command ids (host-side, Node)
• packages/llm/llm/src/message.ts:183 — createMessage id (host-side, Node)

So the exposure surface is exactly the two sites you named, and your override is the right shape (the base mintRpcId stays for Node-side consumers; WebApiClient narrows to randomUuid() from random-uuid.ts — the RFC 4122 v4 on crypto.getRandomValues, which insecure origins do expose).

One hardening suggestion beyond the two fixes: the split is currently implicit — mintRpcId() calls crypto.randomUUID() and only the browser subclass overrides it. A future browser-carrier path that forgets the override silently hits the same failure. A cheap guard: make the base mintRpcId() use randomUuid() (which works in both Node ≥19 and browsers, secure or insecure) and drop the crypto.randomUUID call entirely — the base class already carries the random-uuid.ts dependency via the generic RPC path (denial123789 confirmed createWebConnectionRpc() uses it). Then there is no second carrier to keep in sync. Your one-line override remains valid as a backstop either way.

Also seconding denial123789's boundary note: the UUID fallback makes LAN plain-HTTP functional, it does not make it safe — the operator guidance (localhost/SSH-forward or authenticated HTTPS) stays the real answer for an exposed agent shell.