# Remote Vision Router settings

Vision Router uses a dedicated DSH Connection RPC channel at `/vision-router-settings/*` because the global DSH settings/credentials plane is intentionally loopback-only.

Remote editing is off by default. When a Vision Router settings page is opened through a DSH trusted host while the permission is still disabled, the page shows an explicit risk confirmation. Cancelling leaves remote editing disabled and writes nothing. Confirming enables only `allowRemoteSettings`, then reloads the scoped Vision Router settings immediately. The same permission can still be enabled or revoked from the loopback settings page.

DSH `trustedHosts` protects the browser carrier against Host/Origin/DNS-rebinding attacks; it is **not user authentication**. Enable remote editing only when you trust the clients that can reach the DSH instance. Ordinary remote mutations remain restricted to the explicit Vision Router allow-list. Credential-bearing HTTP providers, local Ollama/LM Studio configuration, artifact paths and every other field not present in that allow-list stay unavailable remotely. `allowRemoteSettings` itself is not added to the ordinary mutation allow-list: it can be enabled only through the explicit risk-confirmation flow (or from the loopback settings page).

The transport contract differs across supported DSH generations without changing that security model. On the rc.8 Connection contract, Vision Router registers the dedicated channel with the required per-channel `{ authority: 'trusted-host' }` option. Newer Connection contracts expose the carrier-level `requestRejection()` / BrowserAuth fence and `rpc.handle()` no longer accepts a channel authority option; Vision Router feature-detects that carrier and registers with the modern two-argument form. The remote field allow-list and `allowRemoteSettings` gate remain authoritative in both cases.

If DSH is behind Nginx, Caddy or another reverse proxy, forward `/vision-router-settings/*` to the same DSH origin in addition to the normal DSH routes. The UI detects a 404 on this channel and shows this requirement directly.

**Reverse-proxy security:** Follow the [upstream DSH public deployment contract](https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/docs/user/guide/public-deployments.md): preserve the **browser-facing `Host`** on proxy requests; do **not** rewrite it to `localhost` or `127.0.0.1` when forwarding remote traffic to a loopback DSH listener. DSH Host/Origin checks and its signed browser session authenticate accepted requests, but do **not** attest that a user is physically local. Vision Router grants local-only diagnostics, permission changes and self-update tokens only to requests classified as local. It conservatively treats loopback TCP requests carrying `Forwarded`, `X-Forwarded-*`, `X-Real-IP`, `Via` or common client-IP proxy headers as **remote for local-only actions**, regardless of an apparent localhost `Host`.

**Limit:** Forwarding headers can be absent, stripped or forged; they are only negative evidence, **never positive proof of physical-local origin**. An untrusted proxy that rewrites the browser `Host` to localhost and strips all forwarding evidence is indistinguishable from a genuine local browser using the current DSH Host request contract. Do not expose such a topology. Restrict upstream listener access, preserve external `Host`, configure DSH `trustedHosts` explicitly, and keep local-only actions on a direct trusted loopback UI. The broader local-presence attestation gap remains tracked in [Issue #680](https://github.com/ysr666/dsh-vision-router/issues/680).