@crckss/dsh-remote-trust

Open DSH's privileged /api methods to remote trusted hosts, so a browser visiting the Web UI through a reverse proxy (or from another machine on your network) can configure the harness — Settings → Models, provider and credential management — instead of getting 403 forbidden.

# ~/.dsh/profiles/web/cordis.patch.yml
- insert:
    - id: remote-trust
      name: "@crckss/dsh-remote-trust"
      config:
        hosts:
          - dsh.example.com

Why this exists

DeepSeek Harness binds its Web server to loopback for safety (--host 0.0.0.0 is refused outright) and its /api browser-trust fence has two layers:

1. A general fence — the request's Host must be loopback or a --trusted-host authority, with Origin and sec-fetch-site checks.
2. A privileged-method pin — settings.*, credentials.*, agentPreset.*, and llm.discoverModels are additionally FORCED to loopback with an empty trust list, even when --trusted-host names your domain.

That pin is hardcoded in @deepseek-ai/dsh-client-connection, so a deployment behind Traefik/Caddy/nginx can browse sessions but can never open the settings plane. This plugin removes the pin for endpoints you declare, without touching node_modules.

How it works

The webserver's route table is checked exact-first, then longest-prefix. The built-in /api route is a prefix route, so this plugin registers exact routes for each privileged endpoint (/api/settings.describe, …). Those exact routes win, run the same browser-trust fence (Host + Origin + sec-fetch-site) against loopback plus your configured hosts, and then forward the request to apiProxy exactly like the built-in bridge would.

The two host-native methods (host.pickDirectory, host.openPath) are not opened by default because they drive native dialogs on the server machine.

Install

Manually (local profile)

# from your DSH profile directory
cd "${DSH_HOME:-~/.dsh}/profiles/web"   # or profiles/tui, …

# pnpm must be on PATH (dsh plugin forwards to pnpm)
dsh plugin --profile web add @crckss/dsh-remote-trust
# or, from a local checkout:
dsh plugin --profile web add /path/to/dsh-remote-trust

From npm

dsh plugin --profile web add @crckss/dsh-remote-trust

Configuration

- insert:
    - id: remote-trust
      name: "@crckss/dsh-remote-trust"
      config:
        # Authorities allowed to call privileged methods.
        # Port-less host matches any port; host:port matches exactly.
        hosts:
          - dsh.example.com
          - 100.34.48.118
        # Optional: open privileged methods beyond the defaults
        # (these are host-native actions, opt-in).
        extraEndpoints:
          - host.pickDirectory
        # Optional: request body ceiling for the forwarded bridge.
        maxRequestBodyBytes: 4194304

Trusted authorities are merged from two places:

• config.hosts — explicit entries in the patch layer;
• ctx.webStartup.trustedHosts — whatever the invocation declared with --trusted-host, plus LAN IP literals derived from the bind (when bound to all interfaces).

So the plugin follows the deployment's existing trust declaration: if you already run dsh web --trusted-host dsh.example.com, the plugin picks that up even with an empty hosts list.

Opened by default

agentPreset.read          agentPreset.copy
agentPreset.openDocument  agentPreset.remove
settings.describe         settings.openDocument
settings.update           settings.replace
settings.mutate
credentials.describe      credentials.set
credentials.unset
llm.discoverModels

host.pickDirectory and host.openPath stay loopback-only unless listed in extraEndpoints.

Security model

The plugin reuses the harness's own browser-trust logic — it does not add a looser check:

• Host must be loopback or a configured authority (DNS-rebinding gate);
• Origin, when a browser sends one, must match the Host;
• sec-fetch-site: cross-site is always refused.

Nothing becomes unauthenticated: the fence is not authentication, and it never was. What changes is that the config plane stops being loopback-only and becomes reachable from the authorities you already trust with --trusted-host.

Do not expose the DSH port (3080) or the whole machine through a public proxy unless you add your own authentication. The fence protects against rebinding and cross-site requests, not against a stranger who can reach the port.

Verify

BODY='{"type":"client-request","rpcId":"v","method":"settings.describe","payload":{}}'
# remote host -> should be 200 (was 403 without the plugin)
curl -i -H 'Host: dsh.example.com' -H 'Content-Type: application/json' \
  -d "$BODY" http://127.0.0.1:3080/api/settings.describe
# cross-site / attacker host -> must stay 403
curl -i -H 'Host: dsh.example.com' -H 'Origin: https://evil.example' \
  -H 'sec-fetch-site: cross-site' -H 'Content-Type: application/json' \
  -d "$BODY" http://127.0.0.1:3080/api/settings.describe
curl -i -H 'Host: evil.example' -H 'Content-Type: application/json' \
  -d "$BODY" http://127.0.0.1:3080/api/settings.describe

Known limitations

• Tracks the harness release. The pin lives in @deepseek-ai/dsh-client-connection; this plugin pins @deepseek-ai/dsh-host-apiproxy to a matching version so the forwarded bridge stays compatible. After upgrading dsh, bump that dependency.
• It opens, it does not delete. Deleting a privileged method still needs a cordis.yml composition change; the settings seam's merge semantics apply.
• No auth added. Add your own if the endpoint can be reached by people you do not trust.

License

MIT