6mt/dsh-plugin-loopback-trust ↗★ 0
dsh-plugin-loopback-trust
反代部署下恢复设置页的Host持久化配置 适合通过反向代理(如Nginx)访问DSH Web端且需要保存设置的用户。
安装
npx -p @deepseek-ai/dsh dsh plugin --profile web add github:6mt/dsh-plugin-loopback-trust说明文档
阅读完整 README ↗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 adjustclient.jsaccordingly.
Uninstall
dsh plugin --profile web remove dsh-plugin-loopback-trust