dsh web — arbitrary --host (non-invasive bundle)

dsh web originally restricts the bind host:

1. dsh-web-app/lib/startup.js — rejects --host 0.0.0.0 outright (usage error).
2. dsh-host-webserver/lib/index.js — the webServer config schema only accepts the literals 127.0.0.1 or 0.0.0.0, so no other host (e.g. a concrete LAN IP) can be configured.
3. dsh-web-app/lib/index.js (resolveLanTrust) — the /api browser-trust fence auto-derives trusted authorities only for the 0.0.0.0 bind.

This bundle removes those restrictions: any --host value is accepted verbatim and handed to node:http server.listen, and the app refuses to load from a non-secure browser origin instead of booting half-broken.

How it is wired (zero modification of shipped files)

The global dsh installation is untouched (wherever it lives — the installer locates it dynamically, see below). Instead, a single bundle package plugin/ is registered as an extra bundle layer of the web profile through the official mechanism:

dsh plugin --profile web add ./plugin

That runs pnpm add in the profile and reconcilePlugins appends dsh-arbitrary-host to dsh.profile.bundles (now [@deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app, dsh-arbitrary-host]). During local development the dependency is a pnpm link: — the plugin dir stays the single source of truth, so edits are live (no reinstall for code changes).

The bundle's cordis.patch.yml uses the include patch dialect: the shipped web-startup / webserver / web-runtime / connection rows are disabled and replacement rows are inserted under new ids. (The dialect cannot change a row's name — "name mismatch, skipping" — so disable

• insert is the only non-invasive way to swap an implementation.)

The connection replacement row is named with the bare package name (name: 'dsh-arbitrary-host', like dsh-webui-auth): its main export is the connection implementation and its ./client export is the restamped client bundle — so a single package carries both the server and browser halves.

Update behavior

• Global dsh updates never touch the profile, and nothing in the bundle edits a shipped file, so an update cannot "lose" these changes.
• The replacements import the current shipped packages: webserver.js subclasses the shipped WebServer (only the host schema is widened), frontend-static.js reuses the shipped serveStatic, and glue.js reuses the shipped webAppInternals.resolveDistIndex. When the global packages update, the new code flows into the bundle automatically.
• What can need attention after an update: if a shipped row id or service contract changes, the disabled ids / glue may need small adjustments (visible immediately in dsh web --dump-config). The plugin's node_modules symlink (below) must point at the current global install.

The changes

• plugin/lib/startup.js — shipped startup minus the --host 0.0.0.0 rejection (only the non-numeric --port check remains).
• plugin/lib/webserver.js — WebServer subclass with host: z.string().required() (any host string reaches server.listen).
• plugin/lib/glue.js — web-runtime glue mounting the gated frontend-static, with resolveLanTrust also deriving a concrete non-loopback IP-literal bind host as a trusted /api authority. Hostname binds stay caller-declared (--trusted-host); the fence's loopback and cross-site checks are untouched.
• plugin/lib/frontend-static.js — secure-context gate: the Web shell depends on crypto.randomUUID, which browsers expose only in secure contexts (HTTPS, or localhost). Over plain HTTP on a LAN IP or hostname the app would boot half-broken (lists fail, "add workspace" throws crypto.randomUUID is not a function), so the fallback returns a self-contained 403 guidance page (Chinese/English) instead, pointing to: loopback on the host, an HTTPS reverse proxy (X-Forwarded-Proto: https passes the gate), or a browser "insecure origins treated as secure" flag. /api and /plugins routes are untouched, so scripts/curl keep working.
• plugin/lib/connection.js — connection row replacement (row name dsh-arbitrary-host)
  • The shipped @deepseek-ai/dsh-client-connection pins a set of methods (settings.*, credentials.*, agentPreset.*, host.pickDirectory, host.openPath, llm.discoverModels) to loopback only by design. Over a reverse-proxy domain these returned transport failure for /api/settings.describe: HTTP 403.
  • The replacement is the shipped transport verbatim (reuses the shipped HostConnectionService, toFetchHandler, fence, bridge, and WebSocket downlinks; the browser client bundle is a copy of the shipped one with only the registration id restamped, re-synced by the installer), with the loopback-only gate driven by a new row config privilegedMethods (default [] = none privileged).
  • With privilegedMethods: [] every method still passes the outer DNS-rebinding fence (trustedHosts), so only loopback or a declared --trusted-host authority reaches the configuration plane; un-declared hosts stay 403 (verified). Relaxing the plane is the deployment's deliberate choice — trustedHosts is explicitly not authentication. Re-lock specific methods by listing them in privilegedMethods in cordis.patch.yml.

Files

plugin/                  the single bundle package (pnpm link: dep of the web profile)
  package.json           name, exports map, dsh.bundle.patch + dsh.client manifest
  cordis.patch.yml       disable shipped rows + insert replacements
  lib/startup.js         web-startup replacement
  lib/webserver.js       WebServer subclass (relaxed host schema)
  lib/frontend-static.js gated SPA server (reuses shipped serveStatic)
  lib/glue.js            web-runtime replacement (LAN trust + gate mount)
  lib/connection.js      connection row replacement (row name = the package name)
  lib/client.js          restamped client bundle — GENERATED by install.mjs
                         (see below; deliberately not committed)
  node_modules -> global install   (lets the plugin's own imports resolve;
                                    local link: development only)
install.mjs              installer — registers the package via `dsh plugin` (idempotent, Node.js only)
uninstall.mjs            uninstaller — removes the package again (idempotent, Node.js only)

Why lib/client.js is generated, not committed

The connection row replaces the shipped @deepseek-ai/dsh-client-connection row, so its browser-half bundle must carry a different registration id. The bundle is a copy of the shipped client with only that id rewritten — ~10k lines of vendored shipped code. Committing it would make the repo carry a stale-by-construction copy (it must track every global dsh update), so the installer regenerates it from the CURRENT global install on every run. Consequence: a fully remote one-liner (dsh plugin add github:...) is not possible for the connection row — clone the repo and run node install.mjs instead (it performs the official dsh plugin add under the hood).

Setup

The installer is idempotent (Node.js only, no shell script — and no pnpm requirement):

node install.mjs      # Node.js only — no shell script, pnpm optional
dsh web --dump-config | grep arbitrary-host   # confirm the rows

Registration prefers the official dsh plugin mechanism when pnpm is on PATH (it also maintains the profile's pnpm-lock.yaml); when pnpm is absent the installer falls back to an equivalent pure-Node registration (profile manifest dependency + bundle layer + node_modules link — the same state dsh plugin add produces; the next dsh plugin/pnpm run in the profile reconciles the lockfile from the manifest). uninstall.mjs mirrors this. The loader and the boot never read the pnpm lockfile, so both paths produce a profile that boots identically (verified).

Both honor DSH_PROFILE (default web) and DSH_GLOBAL_NODE_MODULES (override for the global node_modules). No machine-specific path is hardcoded anywhere.

How the global dsh install is located

The installer needs the global node_modules that holds the shipped @deepseek-ai packages (to sync the client bundle and to let the plugins' imports resolve). It is found regardless of how dsh was installed, using only Node built-ins (no sh, no npm/pnpm CLI probes — cross-platform):

1. DSH_GLOBAL_NODE_MODULES, if set;
2. the deployment the dsh binary on PATH resolves to — realpath the binary, then walk up probing both each directory and its node_modules (the second probe finds package-own dependency trees, e.g. the .../@deepseek-ai/dsh/node_modules layout mise/pnpm produce);
3. the global root of the node running the installer (dirname(process.execPath)/../lib/node_modules and friends), which covers mise / nvm / npm layouts even when dsh is not on PATH;
4. standard layouts: $BUN_INSTALL/install/global/node_modules, then npm-style prefix roots (best effort).

Only roots that actually hold the shipped @deepseek-ai/dsh-client-connection/lib/client.js are accepted, and the chosen root is probe-checked for compatibility: if its own @deepseek-ai/dsh-host-apiproxy calls z.looseObject, its zod must export it, or the installer aborts with a clear message. (This is the failure the probe exists for: a wrong root — e.g. an unrelated tool's global install carrying @deepseek-ai packages as transitive dependencies with a different zod — makes the very first boot die with z$1.looseObject is not a function when the connection row is imported.)

If none matches, it prints where it looked and how to set the override.

Manual install (no scripts at all)

The dsh plugin command is the entire official mechanism; the only extra step is the client-bundle sync, which needs the global path from which dsh:

# .../node_modules/@deepseek-ai/dsh/lib/bin.js -> up four levels to node_modules
GLOBAL="$(dirname "$(dirname "$(dirname "$(dirname "$(readlink -f "$(command -v dsh)")")")")")"
dsh plugin --profile web add ./plugin
cp "$GLOBAL/@deepseek-ai/dsh-client-connection/lib/client.js" plugin/lib/client.js
sed -i 's|id: "@deepseek-ai/dsh-client-connection"|id: "dsh-arbitrary-host"|' plugin/lib/client.js

($GLOBAL resolves to .../node_modules for bun/npm symlinked bins; for other layouts set it to the root that contains @deepseek-ai.)

Uninstall

node uninstall.mjs    # idempotent; restores the shipped rows automatically

uninstall.mjs removes the package from the profile's dependencies (dsh plugin ... remove reconciles dsh.profile.bundles), so the shipped web-startup / webserver / web-runtime / connection rows come back on the next boot, and clean the node_modules symlinks / sync marker that the installer created inside the plugin dir. Your source files are never touched.

Usage

dsh web --host 0.0.0.0            # all interfaces
dsh web --host 192.168.1.5        # one LAN address (auto-trusted for /api)
dsh web --host myhost.local --trusted-host myhost.local   # name bind: declare it
dsh web --port 0                  # OS-assigned port (unchanged)

Reverse proxy: forward the original Host (bare hostname) and set X-Forwarded-Proto: https, and start dsh with --trusted-host <public-hostname> — otherwise the /api browser-trust fence rejects the proxied hostname (transport failure ... HTTP 403). The dsh-arbitrary-host-connection row also relaxes the loopback-only configuration plane (settings.*, credentials.*, agentPreset.*, ...) to declared trusted authorities; un-declared hosts remain 403.

LAN access caveat: the plain-HTTP LAN origin shows the 403 guidance page by design (see frontend-static.js).

License

MIT — see LICENSE in this directory.