[BUG]: Host-backed settings (Settings > Models/General) are impossible behind any reverse proxy — isLoopback gate tests the hostname string only, with no deployment override

[emircanerkul]

Summary

DSH gates host-backed settings (Settings > Models, Settings > General — i.e. everything that persists to $DSH_HOME/settings.yaml / .credentials.yaml) on the browser page's origin being loopback. The check is a pure string test on location.hostname, so any deployment that serves the web UI through a reverse proxy — even one that terminates on the same machine and resolves to 127.0.0.1 — permanently loses the ability to edit providers/keys from the browser. There is no server-side or config-file override to restore it.

This makes the gate effectively "loopback-origin-only", which excludes a common, legitimate class of deployments: containerized setups (Docker/DDEV/Dev Containers), SSH-tunnel setups where the printed loopback URL belongs to the remote host, and LAN deployments that already pass the server-side Host/Origin trust fence via --trusted-host.

Environment

• dsh: 0.1.5-rc.1 (installed globally, web mode: dsh web --port 3080 --no-open --trusted-host …)
• OS (host): macOS 26.6.2 arm64; OS (container): Ubuntu 24.04 aarch64 (Docker/podman via DDEV)
• Node: v22.23.2
• Deployment: dsh web inside a container, bound to 127.0.0.1:3080, relayed to 0.0.0.0:3081 (socat), published to the host, and reverse-proxied by the DDEV router at https://<project>.ddev.site:8144 with a trusted TLS cert. The proxy forwards Host unchanged; the server-side Host/Origin fence accepts it via --trusted-host.

Reproduction

1. Serve dsh web behind any proxy with a non-loopback hostname that the server trust fence accepts (here: https://xxxx.ddev.site:8144, which resolves to 127.0.0.1).
2. Open the UI in a browser, authenticate with the token.
3. Open Settings → Models.

Actual: "Loading the provider directory failed: settings are unavailable in this browser". Every settings scope is silently in memory mode; writes are refused.

Expected: host-backed settings work — the deployment already authorized this authority on the server side via --trusted-host, and the page is the operator's own browser on the same machine.

Opening the same server directly at http://127.0.0.1:<port> in the same browser works, which isolates the cause to the origin check alone.

Root cause (from the installed source)

The decision is made client-side in @deepseek-ai/dsh-client-ui-settings:

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

isLoopback comes from @deepseek-ai/dsh-client-connection:

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

function isLoopbackHostname(hostname) {
    if (hostname === "localhost" || hostname === "[::1]") return true;
    const parts = hostname.split(".");
    return parts.length === 4 && parts[0] === "127" && parts.every(
        (part) => /^\d{1,3}$/.test(part) && Number(part) <= 255);
}

Consumers of the same flag (all degrade on non-loopback origins):

• dsh-client-ui-settings — describe mirror + all scope persistence (memory = read/write refused)
• dsh-client-ui-settings-general — SettingsDocumentStore is only constructed when isLoopback
• dsh-client-ui-settings-models — Models page fails with the error above

Notes:

• I understand why the check is a string test: a browser page cannot verify where a name resolves, and "hostname literally reads loopback" is a cheap proxy for "the operator's own browser" that DNS rebinding cannot forge. That rationale is sound for the default.
• The only escape hatch, __DSH_TRANSPORT__.ownsHost, is reserved for shells that assemble their own transport (the worker preview); a served page behind a proxy cannot use it, and per the type docs "served pages never carry the global at all".
• The server-side fence (isTrustedApiRequest) already has the right concept — explicit, deployment-declared trusted authorities (--trusted-host, exact host:port or port-less) — but the settings gate never consults it.

Impact

• In container/proxy deployments, provider and key management is only possible by editing $DSH_HOME/settings.yaml / .credentials.yaml by hand (or docker cp), losing the Models UI workflow the docs recommend.
• The failure mode is silent and confusing: the UI shows a generic "settings are unavailable in this browser" with no hint that the origin is the reason.

Feature request

Provide a deployment-level way to mark a non-loopback authority as "operator-equivalent" for the settings gate. Options, in order of preference:

1. Derive the gate from the existing trust fence: if the page's origin matches a --trusted-host authority, treat isLoopback as true for settings persistence. This reuses an existing, explicit, admin-controlled concept — no new surface.
2. A dedicated web-app config field (e.g. trustedSettingsHosts: ["myhost.example:8144"]) consumed the same way.
3. At minimum, a UX fix: make the "settings are unavailable in this browser" message state the cause ("host-backed settings require a loopback origin (localhost / 127.x.x.x); open the UI via http://localhost:") so users can self-recover.

Security considerations: option 1/2 still requires the server-side Host/Origin fence and token auth on every request (unchanged), and the authority must be explicitly declared by the deployment — the same trust decision the fence already makes for reachability. If the concern is a proxy that terminates TLS elsewhere, that's already out of trust scope today (the fence accepts declared authorities).

Workarounds tried

• --trusted-host <host>:8144 — accepted by the /api fence, but does not affect the settings gate (it's client-side).
• Opening https://…ddev.site:8144 from a host where it resolves to 127.0.0.1 — no effect; the check is on the hostname string.
• Routing http://localhost:<router-port> through the proxy — fails earlier (no Host-based route match for localhost).

---

Two notes before you post it:

• Repo/labels: I don't know dsh's actual issue templates or whether the repo is public — paste the body as-is and adapt the title to their template (this one fits "Bug / Feature request" hybrid; if forced to pick one, feature request is the more accurate frame, since the behavior is documented-by-design and the ask is an override).
• I kept it to one issue. If you'd rather split it, the UX message fix (option 3) stands alone nicely as a tiny second issue — the "unavailable in this browser" message genuinely never tells the user the loopback requirement, which is half the pain you experienced.

[PerryLink]

Your analysis is confirmed end to end at HEAD (ddefc45fbc, v0.1.6-alpha.2), including the parts you flagged as inferences.

The gate is exactly the one line you found, packages/client/ui-settings/src/client/index.ts:58:

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

and isLoopback is the pure hostname-string test at packages/client/connection/src/client/index.ts:248:

isLoopback: transport?.ownsHost === true || pageLocation === undefined || isLoopbackHostname(pageLocation.hostname),

with isLoopbackHostname at packages/client/connection/src/loopback-hostname.ts:12-17 accepting only localhost, [::1], and 127/8 IPv4. Your read of the ownsHost escape hatch is also exactly right: packages/client/connection/src/client/index.ts:96-104 documents that "Only a shell that assembles its own transport can set this; served pages never carry the global at all."

I grepped the whole tree for any override (trustedSettingsHosts, settingsHosts, trustedSettings) — zero matches, and the settings gate never consults the server-side trust list that --trusted-host feeds (packages/client/connection/src/api-request-trust.ts:103 is the fence; the settings packages don't import it). In memory mode writes silently no-op (packages/client/ui-settings/src/client/settings-scope.ts:166: if (this.persistence === 'memory' || this.disposed) return Promise.resolve()), and ui-settings-general/src/client/index.ts:86-88 only constructs the document store when isLoopback — so every consequence you listed is source-verified.

Workaround that works today (source-grounded): only the hostname string the browser sees matters. An SSH port-forward makes the page origin literally loopback: ssh -L 3080:127.0.0.1:3080 <host>, then open http://127.0.0.1:3080 (or localhost / [::1]). The server fence accepts loopback Host headers without any --trusted-host (api-request-trust.ts:103). Risk: the tunnel must land directly on the dsh port — a Host-name-routing proxy in between (your DDEV router) still can't route localhost, which is the failure you hit. Where tunneling isn't possible, hand-editing settings.yaml/.credentials.yaml stays the only route.

The feature-request part (deriving the gate from --trusted-host, a dedicated trustedSettingsHosts, or at least a message stating the loopback requirement) is maintainer territory — nothing at HEAD supports it. Your option-3 UX fix stands alone nicely; the "unavailable in this browser" text really never tells users the loopback requirement.

If you want, I can dump the exact settings-scope snapshot fields a proxied origin produces, to attach to any follow-up report.

[emircanerkul]

@PerryLink not sure if its solved in new version, but not having issues tab in github is weird so we could had better visibility and tracking over that

[emircanerkul]

thankx Add --public-url for the Web address shown to users, opened in the browser, and supplied to the model, including reverse-proxy URLs with a path prefix. by @oraluben

[oraluben]

We've updated that a little bit more to make reverse proxy more useable, enjoy!

[emircanerkul]

https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.1-alpha.1#en-v0.2.1-alpha.1-community