web settings: Host persistence is loopback-only — remote browsers get "settings are unavailable in this browser"

[erkkimon]

In 0.1.2-rc.1, @deepseek-ai/dsh-client-ui-settings selects
persistence with:

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

and "memory" short-circuits the settings mirror (load() returns
without a wire read), so the mirror never delivers a view. On any
browser that is not on the same machine as the dsh process this
surfaces as:

• Settings → Models: "Loading the provider directory failed: settings
  are unavailable in this browser" (the provider directory reads fine —
  credentials/describe and llm/listProviders both answer — only the
  describe-mirror is dead), and
• every settings-driven plugin feature silently disappears for remote
  browsers, because their scopes derive from the same mirror.

Reverse-proxied deployments (TLS name on a trusted LAN, authorities
declared via --trusted-host) therefore lose the whole Settings
surface even though the same browsers may drive sessions, tools and
credentials writes over /api.

Could host persistence be allowed for browsers that pass the
--trusted-host fence (or gated by an explicit config field on the
settings plugin)? Happy to send a PR for either shape. We currently
patch the ternary to "host" and reapply on every upgrade.

[argszero]

Source-verified against current master (d347e70390) — your description is exact, including the failure mechanics, and the recommended shape is your config-field option rather than the fence-based one.

What the code does. packages/client/ui-settings/src/client/index.ts:58 resolves persistence once, from the only host fact the browser is given:

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

$host.isLoopback is computed in packages/client/connection/src/client/index.ts:224 (transport?.ownsHost || pageLocation === undefined || isLoopbackHostname(pageLocation.hostname)) — loopback-ness is the only browser-visible host property. In 'memory' mode SettingsDescribeMirror never performs the wire read (load() early-returns at settings-mirror.ts:115/:133, status set to 'unavailable' at :89), so the mirror stays empty and every scope derived from it reports the "settings are unavailable in this browser" surface you see. That part is exactly as you diagnosed.

Why the fence-based shape won't compose. "Passes the --trusted-host fence" is not a fact a browser can observe. trustedHosts is a server-side list (client/connection/src/index.ts:88) asserted per API request from the request's Host header (api-request-trust.ts:91 → rpc-host.ts:98); nothing in the handshake tells the page "you arrived through a declared authority". So keying persistence on the fence would first require a server→client trust signal — the missing read-side leg of the trust fence this codebase has been building since #3210. That signal is worth having (it would also serve the #5828 index-auth discussion), but even with it, fence-passing ≠ user-authenticated: your TLS proxy authenticates the host, not the user, and host persistence hands the browser the full settings document (the mirror is the one settings reader; the document spans every namespace). A trustedHosts-passing page from an unauthenticated LAN user would then read — and through the binder, write — host settings. That is the same boundary as the loopback gate in the first place.

The clean shape is your explicit-config option. A persistence (or hostPersistence: true) field on the settings client plugin config — default false/loopback-only — that selects 'host' for deployments whose proxy (or network isolation) does the real authentication. The mirror plumbing already exists; the change is the config surface plus the one-line selection at index.ts:58, with the trust tradeoff documented next to the field. That formalizes the patch you currently reapply, keeps the secure default, and gives managed fleets the escape hatch with their eyes open.

One asymmetry worth noting while you're there: fence-passing browsers already drive sessions, tools, and credential writes over /api (those RPCs sit behind isTrustedApiRequest), yet the settings view is the surface that stays loopback-only — so the loopback gate is doing settings-specific authorization, not general API authorization. A config field makes that policy explicit instead of implicit in a ternary.