Web UI behind a reverse proxy: the Models settings page can never load ("settings are unavailable in this browser")

[zerodegress]

Summary

dsh --profile web published behind a reverse proxy is documented as a supported deployment (docs/user/guide/public-deployments.md, via --public-url + --trusted-host). But when the browser origin is the public authority rather than loopback, every settings surface that reads the host settings document is permanently unavailable.

The clear user-visible case is Account → Bot settings → Harness settings → Models:

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

Retry can never succeed, so provider and model management is impossible from a proxied deployment, even though the /api fence already trusts that authority for every other request.

Reproduction

Serve the web profile on loopback and publish it under a non-loopback authority: dsh --profile web --public-url https://app.example/ --trusted-host app.example
Open the printed URL in a browser and authenticate, so the page origin is app.example.
Open Account → Bot settings → Harness settings → Models.

Control: the same process, same session cookie, same click path, with the browser origin at 127.0.0.1: — the provider directory loads normally and edits persist to the host.

Current behavior

• @deepseek-ai/dsh-client-ui-settings chooses its persistence from the page origin (lib/client.js:1509): const persistence = ctx.remote.$host.isLoopback ? "host" : "memory";
• ctx.remote.$host.isLoopback comes from @deepseek-ai/dsh-client-connection (lib/client.js:1404, isLoopbackHostname at :1333): isLoopback: transport?.ownsHost === true || pageLocation === void 0 || isLoopbackHostname(pageLocation.hostname) — only localhost, [::1], 127.0.0.0/8. An authority named by --trusted-host / trustedHosts is not considered, even though the Host/Origin fence admits it for every /api request.
• With persistence === "memory", SettingsDescribeMirror never reads the host — load() and ensure() return early, and the snapshot stays at { status: "unavailable", view: undefined, error: null }.
• @deepseek-ai/dsh-client-ui-settings-models then renders mirrored.error ?? "settings are unavailable in this browser". Since error is null, the user gets the generic fallback and Retry re-runs the same dead path.
• The same origin silently makes every settings edit memory-only: a change appears to apply but is never written back, with no warning.
• Present identically in 0.2.1-alpha.1 and 0.2.1-alpha.2.

Expected behavior (either resolves it)

1. Trust the declared authority. Treat an authority admitted by trustedHosts / --trusted-host as an owner browser for settings persistence too — it is already trusted for every other /api call.
2. Or make the restriction explicit, if deliberate. Say so on the settings surface instead of a Retry that cannot succeed, and document it in public-deployments.md, which currently reads as though a proxied deployment is fully featured.

Environment

dsh 0.2.1-alpha.1 (npm, @deepseek-ai/dsh-web-app), --profile web behind a reverse proxy, browser origin = a --trusted-host authority, plain-HTTP loopback listener, Chromium.

[IlyaKhalafi]

The localhost-only settings gate has been removed in the published 0.2.1-rc.2 client. The current implementation creates the Host settings mirror for every authenticated browser, without selecting a memory-only mode from isLoopback.

I checked the published 0.2.1-alpha.2 and 0.2.1-rc.2 code with a non-loopback client context and a simulated settings RPC. The old code made zero settings.describe calls and stayed unavailable. The newer code made one settings.describe call and reached ready. This was an isolated client check, not a full reverse-proxy test.

Try 0.2.1-rc.2 using the same profile and proxy configuration. For the standard npm Web launch, use npx @deepseek-ai/dsh@0.2.1-rc.2 web with your existing --public-url, --trusted-host and other listener flags. If your profile pins older DSH web or client packages, align those versions too. Restart the server and reload the proxied page so it fetches the new client bundle.

Keep the existing browser authentication. Settings now use the shared Host document, with access still governed by authentication and the writable flag the Host reports.