dsh-plugin-loopback-trust

English | 中文

Restore Host-persisted settings in DeepSeek Harness (dsh) web when it is reached through a reverse proxy.

The problem

dsh 0.1.7 deliberately gates the Settings pages (especially the Models page) on a loopback check: settings persistence is only offered to pages opened on 127.0.0.1 / localhost / ::1.

// dsh-client-ui-settings
const persistence = ctx.remote.$host.isLoopback ? "host" : "memory";

isLoopback is derived from the browser hostname. When dsh listens on 127.0.0.1:3080 behind nginx (or any reverse proxy) and you open the UI through a domain name, the page is classified as non-privileged: settings silently degrade to in-memory mode and the Models page reports "settings are unavailable in this browser".

What this plugin does

It marks the page's connection as host-owning — the same fact the official desktop shell asserts — so the settings pages keep Host persistence on non-loopback origins. Chat and everything else were never affected and stay byte-identical: the plugin changes exactly one boolean in the client's connection state.

Sits in the boot prefetch tier and runs before any client plugin applies
Never clobbers a real (desktop) transport; does nothing on loopback pages
Zero dependencies, no host-side code, ~60 lines of client JavaScript
Requires dsh 0.1.7 (engines.dsh: ">=0.1.7 =0.1.7 <0.2" so incompatible hosts refuse to install rather than break silently. On breakage the symptom is loud (the settings page returns to its unavailable state) — check dsh-client-connection in your installed version and adjust client.js accordingly.

Uninstall

dsh plugin --profile web remove dsh-plugin-loopback-trust

License

MIT

dsh-plugin-loopback-trust

インストール

ドキュメント