Web UI on a trusted remote host: model settings are loopback-only - please expose a documented deployment trust flag

[claytontavaresdan]

Context

Running the Web UI on a remote host: dsh web --host 127.0.0.1 --no-open --trusted-host <vpn-host>, reached from another machine through a VPN overlay with an HTTPS front end. The page origin is therefore not loopback.

What works

• The page loads and authenticated sessions work: the server-side /api host fence accepts the declared authority from --trusted-host.
• Sessions, tools, workspaces and persistence all behave normally.

What does not work

Settings → Models on that remote origin:

Loading the provider directory failed: settings are unavailable in this browser

So a user working in the browser from another machine cannot add a provider API key, select a model, or change model settings. Model configuration is effectively loopback-only, and the message does not say what to do instead.

Why (from the shipped 0.2.0-rc.2 bundles)

• @deepseek-ai/dsh-client-ui-settings-models: the settings surface derives its persistence from the connection seat (isLoopback ? 'host' : 'memory'); with memory the provider directory is never fetched and the message above is displayed.
• @deepseek-ai/dsh-client-connection:

  isLoopback: transport?.ownsHost === true || pageLocation === void 0 || isLoopbackHostname(pageLocation.hostname)

• The desktop shell already obtains such a seat on any origin: dsh-web-frontend reads globalThis.dshDesktopBoot and then installs globalThis.__DSH_TRANSPORT__ = { ownsHost: true, streamBaseUrl }.

The client-side capability exists. What is missing is a first-party, documented way to declare a remote deployment trusted.

Idea

Make the trust decision explicit, operator-controlled and documented, for example:

1. extend --trusted-host (or add a dedicated flag / profile setting) so a trusted non-loopback authority is also treated as host-owned for settings persistence; or
2. add a deployment trust field that the Web UI reads from the server at boot, instead of deriving trust from the page URL.

Notes

• location.hostname is immutable from the page, so a reverse proxy that only rewrites Host/Origin does not fix this: it satisfies the server fence, not the client seat. Community relays work around it by rewriting the client bundle in flight - exactly the patching a first-party flag would remove.
• The security trade-off is clear: settings/credentials would become writable from that origin. Gating it behind an explicit operator flag (documented next to the host fence, fail-closed by default) keeps the current safe default while making remote/VPN deployments usable.
• If the intended answer is "always use a loopback tunnel for settings", documenting that in the Web UI guide would help just as much - the current message leaves the user with no next step.

Environment

• dsh 0.2.0-rc.2 from npm, Node 24.21.0, Debian 13, Chromium 154
• dsh web --no-open --host 127.0.0.1 --port 3080 --trusted-host <vpn-host>, HTTPS provided by the VPN's own certificate
• Reproduced on the same version with a local (loopback) page as control: there the provider directory loads normally.

[LUgABeEEE]

Adding evidence from the plugin side, since the same gate is being re-implemented by every plugin author and failing in different shapes.

Under a --trusted-host deployment (web bound to loopback, reached through a LAN/tunnel front end that does not rewrite Host), four unrelated plugins failed at once:

• plugin server route: 403 "this endpoint is local-only"
• another plugin server route: 403 "forbidden: loopback-only"
• a third: bare 400 with no body (its guard dereferenced a service it never registered, and the host webserver converted the throw into a 400 — very misleading to debug)
• client side: provider settings degrade to "settings are unavailable in this browser" because persistence falls back to memory and never issues describe

All four share one root: hand-rolled isLoopback*() hostname string checks that ignore the declared trust set.

What already exists internally: dsh-web-app's resolveLanTrust() publishes webRuntime { lanAddresses, trustedHosts }, and dsh-client-connection's isTrustedApiRequest() consumes it. But there is no documented helper for plugin server routes, so each author copies a loopback check and gets it wrong. We patched the plugins locally with exactly one shape: resolve the trust set lazily (hostCtx.get('webRuntime')?.trustedHosts) and use one shared helper for both Host and Origin, falling back to loopback-only when no trust set is present.

One more data point: 0.2.1-alpha.2 removed the public webRuntime service (#9598) and third-party plugins broke silently — they had reached for that internal precisely because no documented trust API existed. A tiny exported helper would end both failure modes.

Proposal: export and document something like isTrustedRequest(req) / getTrustedHosts(ctx):

• one implementation shared by the Host and Origin checks
• consults the declared trust set (--trusted-host / config), not just hostname strings
• falls back to loopback-only when no trust set is configured (secure default)
• outsiders stay rejected: authorities not in the trust set still get 403 (we verified attacker-controlled Host values remain rejected after the fix)

Related threads: #7382, #9541, #7206, #7032 (client-side settings gate), #9598 (webRuntime removal).

[LUgABeEEE]

0.2.1-rc.2 data point: the webRuntime removal also broke plugin-side LAN fences that reused webRuntime.trustedHosts — dsh-memory API, @linxin666/dsh-ssh, and dsh-client-ui-git-graph now return 403 loopback-only on a trusted LAN origin. A documented, profile-independent deployment trust source would cover both the settings page and these plugin fences. Details and a proposed DSH_TRUSTED_HOSTS / compat-alias shape are in #9598.