dsh-web-lan-access
DeepSeek Harness Web UI 的局域网 / 远程访问支持：自包含的 0.0.0.0 绑定、远程 Host 设置、自动扩大 /api 信任边界，以及不安全来源的 randomUUID polyfill。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-web-lan-access@1.3.2Web Lan Access 以 dsh-web-lan-access 发布，当前版本为 1.3.2。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
English | 简体中文
LAN / remote access support for the DeepSeek Harness Web UI.
The Web UI calls crypto.randomUUID() in boot-critical paths (RPC id minting, message ids, draft attachments). That Web API exists only in secure contexts (HTTPS, or http://localhost / http://127.0.0.1). When the UI is served over plain HTTP from a non-loopback address — a LAN IP, a Tailscale IP, or a hostname — crypto.randomUUID is undefined, every RPC throws, and sessions and models never render.
Current DSH clients also select Host-backed settings from the browser hostname: a non-loopback page is assigned memory-only settings even after browser authentication succeeds. The Models and plugin settings pages therefore remain unavailable on an otherwise working trusted-host deployment.
A host-side plugin that uses the webserver's official index-tap extension point (webServer.tapIndex) to inject a small bootstrap as the first script in <head>, before the boot manifest and shell entry. The bootstrap:
ownsHost deployment signal, enabling authenticated Host settings from the trusted remote page;crypto.randomUUID with an RFC 4122 v4 implementation built on crypto.getRandomValues, which is available on insecure origins.The bootstrap leaves a transport supplied by another shell untouched, and the UUID polyfill is a no-op on secure origins.
Send this repo URL directly to your DSH chat with the instruction:
"Install this plugin for me: https://github.com/AcidGr/dsh-web-lan-access"
Your DSH Agent will automatically install the package and configure it in the background.
Installed from npm:
dsh plugin --profile web add dsh-web-lan-access
(No npm / local development — point pnpm at the repo instead:
dsh plugin --profile web add github:AcidGr/dsh-web-lan-access
)
Restart dsh web, then hard-refresh the browser.
PROFILE="$DSH_HOME/profiles/web" # adjust DSH_HOME and profile name
mkdir -p "$PROFILE/plugins" "$PROFILE/node_modules/@dsh-profile"
cp -r dsh-web-lan-access "$PROFILE/plugins/lan-access"
ln -sfn ../../plugins/lan-access "$PROFILE/node_modules/@dsh-profile/lan-access"
# append to $PROFILE/cordis.patch.yml:
# - insert:
# - id: lan-access
# name: '@dsh-profile/lan-access'
The plugin is self-contained: its bundle patch sets the webserver bind host to 0.0.0.0 directly (the CLI flag --host 0.0.0.0 is hard-rejected for safety on newer harness versions, but the webserver config still accepts it — so no source changes and no --host flag are needed; the CLI --port flag still works). It also widens the /api trust fence automatically.
Install the plugin, then start normally — without --host:
dsh --profile web --port 3080
The bundle patch re-derives the /api trust fence from every non-internal IPv4 the host currently has — LAN (192.168.x), Tailscale (100.x), and VPN interfaces — and merges in whatever resolveLanTrust already computed. So as long as the remote interface is up when dsh web starts (Tailscale usually autostarts first), LAN and Tailscale IP access need zero extra config: open http://<server-ip>:3080 or http://<tailscale-ip>:3080 and sessions/models load.
If you prefer NOT to let the plugin take over the bind host (e.g. you want loopback + a port forward), keep the
webserverrow override out of your tree and instead forward a port (socat / rinetd / Tailscale serve) from127.0.0.1:3080, adding the forwarded address totrustedHostsmanually.
MagicDNS hostnames (e.g. xxx.tailXXXX.ts.net) — the fence can't discover hostnames, only IP literals, so add your own names if you want to browse by name instead of IP. Patch the web-runtime row, whose trustedHosts feed into the fence computation (resolveLanTrust merges them), so your entries stack on top of the auto-discovered IPs:
- id: web-runtime
config:
trustedHosts:
- <short-name> # e.g. myhost — MUST be listed separately!
- <name>.tailXXXX.ts.net # full domain
Or skip file editing entirely with the repeatable CLI flag (same injection path): dsh --profile web --trusted-host myhost --trusted-host myhost.tailXXXX.ts.net. Use one mechanism or the other — a static list replaces the row's default expression, so it will not merge with --trusted-host.
⚠️ The fence compares the Host header literally: a MagicDNS short name (http://myhost:3080) is not the full domain — list the short name on its own line, or every /api call returns 403 (page shell loads, sessions/models absent). Tailscale / LAN IP literals need no entry here — they stay covered automatically.
⚠️ Do not retarget this block at the
connectionrow: patch layers compose by whole-key replacement in application order (bundle layers first, then your profile's ), so a plain literal array on would silently replace the bundle's dynamic fence expression — names would work, but the auto-derived LAN/Tailscale IP trust would vanish. If you truly need , copy the full concatenation expression from the plugin's bundle patch and append your literals; never write a plain list there.
The transport signal enables every client surface DSH currently associates with owning the Host, not only Models. That includes Host-backed settings and native Host actions such as opening a produced file. Use this plugin only when the authenticated remote browser is meant to operate the agent machine. DSH's Host/Origin fence and browser authentication remain in force; this signal changes the client's capability projection, not request authentication.
Older harness builds that pin privileged methods to loopback on the server will continue returning 403 for those methods. This client bootstrap does not weaken that server-side fence.
curl http://127.0.0.1:3080/ | grep lan-access-polyfill # must match
Then open http://<server-ip>:3080 from another device — sessions and models must load.
Binding 0.0.0.0 exposes the DSH authentication surface to every reachable interface. trustedHosts is an Origin/Host fence, not identity; current DSH builds separately authenticate the browser. Use only on trusted networks, restrict with a firewall (e.g. ufw allow from 192.168.0.0/16), or expose through Tailscale or an authenticated reverse proxy. A TLS reverse proxy removes the need for the UUID polyfill but not the remote Host-settings bootstrap.
dsh plugin --profile web remove dsh-web-lan-accesslan-access insert block from cordis.patch.yml; optionally start without --host 0.0.0.0MIT
cordis.patch.ymlconnection.config.trustedHostsconnection