Bug: settings UI unavailable on --trusted-host deployments (web behind tunnel/reverse proxy)

[U3RhcnQ]

Summary

dsh web served through Cloudflare Tunnel (or any reverse proxy + Access) loses the
entire settings UI: Settings → Models fails with

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

even though the page authority is declared via --trusted-host and every API and
websocket RPC works. The agent itself is unaffected (models come from the
environment). This looks like a bug rather than a policy: the /api trust fence and
the settings mirror are fed by the same trustedHosts declaration, but they make
opposite decisions.

Reproduction

1. dsh web --host 127.0.0.1 --no-open --trusted-host example.com
2. Reach the page via a tunnel/reverse proxy at https://example.com/?token=...
3. Settings → Models → Loading the provider directory failed: settings are unavailable in this browser
4. Loading the same server through a loopback origin (e.g. SSH port-forward) makes
   the settings UI work.

Current behavior

packages/client/ui-settings/src/client/index.ts (verified at dsh-v0.1.6-alpha.2;
same line exists in dsh-v0.1.5-rc.2):

const persistence = ctx.remote.$host.isLoopback ? 'host' : 'memory'

On any non-loopback page the settings mirror is 'memory'. settings-mirror.ts
documents 'unavailable' as "the terminal non-loopback state" and ensure()
short-circuits in memory mode, so the Models store's describeFace.getSnapshot().view
stays undefined and it renders that fallback string
(packages/client/ui-settings-models/src/client/store.ts).

This contradicts the deployment's own trust declaration: --trusted-host <authority...> (packages/bundle/web-app/src/startup.ts) declares authorities to the
/api trust fence, and the connection row wires it through
(trustedHosts: !!js ctx.webRuntime.trustedHosts in web-app/cordis.patch.yml).
The fence accepts the page; the settings mirror does not — the same authority list
produces two different trust decisions.

Not a broken deployment: dsh web --dump-config shows settings → @deepseek-ai/dsh-settings-file mounted, Settings → General renders (so the provider
works), and the Models page's llm/listProviders / llm/listConfigurableProviders
RPCs return ok:true with the full directory — only the describe-mirror path fails.

Expected behavior

A page loaded from a declared --trusted-host authority should get 'host'
persistence, same as the /api fence grants. Undeclared non-loopback authorities
can stay 'memory'/unavailable. (Or, if remote settings are intentionally out of
scope, an explicit opt-in flag such as --allow-remote-settings — but the current
silent split between the fence and the mirror reads as an oversight.)

Environment

• dsh 0.1.6-alpha.2 (also present in 0.1.5-rc.2), Linux arm64, Node 22.23.2
• dsh web --host 127.0.0.1 --no-open --trusted-host dsh.petr.ie behind a
  Cloudflare Tunnel with Access in front
• Settings document absent ($DSH_HOME/settings.yaml never created)

Workaround

SSH port-forward to the loopback page, or edit $DSH_HOME/settings.yaml directly
(hot-reloaded). Both work today; the UI is simply unreachable for remote deployments.

PRs are disabled on this repository, so no code is attached — the fix is a one-line
change to the persistence selection (honor the page authority's presence in the
declared trustedHosts), happy to provide a fork commit if you'd like one.

[Exagone313]

I have created a plugin to work around this issue. It simply needs to be installed.

https://www.npmjs.com/package/@exagone313/dsh-trusted-host-is-loopback

Note: It was published using NPM provenance from GitHub Actions on my repository, for increased transparency and security.