dsh-remote-signin
让远程浏览器完成 DeepSeek 账户登录：接管平台要求的回环重定向，然后通过注入 DSH 页面中的粘贴面板带回授权码。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:2220545672/dsh-remote-signin#1fed99ac0e9c70d5e4516b60bbf55c806b3c23e2Remote Signin 以 dsh-remote-signin 发布，当前版本为 0.2.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →English · 中文
A DeepSeek Harness (DSH) plugin that lets a DeepSeek account sign-in finish in the browser in front of you — over the LAN, a reverse-proxied domain, or Tailscale. All it adds is one paste, into a box that appears in the page by itself.
You open DSH on a machine that is not the one running it — http://192.168.0.20:8080,
https://dsh.example.com, http://100.x.y.z:8080 — and then:
ssh -L and open http://127.0.0.1:…;So the workarounds have always been: use an API key, or open a tunnel every time you sign in. This plugin exists for that one step.
With it installed, a remote browser finishes an account sign-in as normal:
1. browser (https://dsh.example.com) you press "Sign in with a DeepSeek account"
2. DSH host + this plugin registers a 127.0.0.1 address instead of yours
3. platform.deepseek.com accepts it, returns the login page
4. browser the login page opens (this is where it used to
fail), you sign in there
5. browser the platform sends you to 127.0.0.1:47821 — a page
that cannot load, but the address bar holds the
authorization code (`code` and `state`)
6. DSH page a paste box has appeared by itself, bottom right:
paste that address into it
7. DSH host completes the sign-in — the validation and the token
exchange are DSH's own → the dialog turns green
Why step 6 cannot be automatic: the code has to be delivered to that 127.0.0.1
address by your browser, and your browser is precisely the thing that cannot reach it.
(If it could, you would be on the machine already and would not need this plugin.) What
can be removed has been: no address to remember, no second page to open, no hosts file to
edit — the box shows up when it is needed.
DSH hands the platform the address you are browsing from and asks it to deliver the
login there; the platform only accepts a local address (127.0.0.1 and friends). So the
request is refused before a login page is ever opened — nothing to do with your network,
firewall or reverse proxy; it is an upstream restriction.
Measured 2026-10-16 against the real platform (POST /auth-api/v0/dsh/auth_init):
| callback address given to the platform | platform answer |
|---|---|
http://127.0.0.1:47821/oauth/callback | {"code":0, … "authorize_url": …}, expires_in: 600 |
https://dsh.example.com/oauth/callback | {"code":50005,"msg":"PAYLOAD_SCHEMA_MISMATCH"} |
What the plugin splits is those two halves: the platform only validates a string, and
the only thing that has to reach the address in it is the browser. The plugin supplies
the string (a port on 127.0.0.1, where nothing listens); you hand the code back.
Unraid / the dsh-unraid image — nothing to do; the image installs this plugin and
loads it through REMOTE_SIGNIN (default on; set off for upstream's behaviour).
Any DSH profile — install it into the profile, which picks up cordis.patch.yml
through the package's dsh.bundle declaration:
dsh plugin --profile web add github:2220545672/dsh-remote-signin
Or load it as a patch overlay (no profile change):
dsh --profile web --patch "$(node -p "require.resolve('dsh-remote-signin/cordis.patch.yml')")"
One setting: which 127.0.0.1 address to register. The default works; you rarely need to
touch it.
| Source | Meaning |
|---|---|
config.claimOrigin in the patch entry | Highest priority. |
REMOTE_SIGNIN_ORIGIN | Environment fallback. Must be http:// + 127.0.0.1 / localhost / [::1] + an explicit port. |
| default | http://127.0.0.1:47821 |
The port is deliberately an odd one: if something of yours did listen there, it would be handed the authorization code — so do not point it at a port you use.
state check and the PKCE verifier it keeps in memory;
this plugin only chooses which loopback string is registered.127.0.0.1 (ssh -L, the desktop
app): those origins pass through untouched, exactly as upstream behaves.--dsw-*: surface, radius, elevation, label and state colours, primary button fill),
so it follows the app's theme — including a user-chosen dark mode — and any future
restyle. A test fails if a hard-coded colour creeps back in.code and state are re-encoded and sent to this origin's own /oauth/callback —
nowhere else, so the panel cannot be used as a redirector.| Symptom | What it means |
|---|---|
| Still "Could not complete the operation. Try again." | The plugin is not active: docker logs <container> | grep remote-signin says why (off, a missing package, INACTIVE). |
The login page opens, but afterwards the dead 127.0.0.1 page has no paste box | The panel was not injected — same log line. The panel is the only way back; without it the sign-in cannot be finished. |
The panel says no sign-in is waiting (404) | The attempt expired (~10 minutes), or it belonged to a different DSH instance — recreating the container throws it away, and a tab left open from the previous instance still looks like it is waiting. Press Sign in again in the tab you are actually using. |
The panel says the state does not match (400) | The address came from a different attempt, or the code was already consumed. |
| You want upstream behaviour back | Remove the plugin (or set REMOTE_SIGNIN=off on the dsh-unraid image), and go back to an API key or a tunnel. |
node --test # 16 tests, no dependencies, no browser
| File | Purpose |
|---|---|
src/index.js | Server plugin: wraps deepseekAccount.startSignIn (a non-loopback browser origin becomes the registered loopback origin), serves the panel script, injects it into the DSH document. |
src/claim.js | Pure functions: how an address is parsed and validated — testable without booting DSH. |
assets/inpage.js | The panel. It appears only while a sign-in waits, which it learns from the status of GET /oauth/callback (400 = waiting, 404 = idle) — no new endpoint. |
test/, test-support/ | The node --test suites and the small DOM stub they share (probe cadence, dismissal, address extraction and every status are covered). |
A patch entry's name is resolved from two anchors: the packages carried by the
@deepseek-ai/dsh installation (its dependency closure), and the profile
directory ($DSH_HOME/profiles/<name>/node_modules). A package installed anywhere else —
a dependency of your own runtime manifest, or a copy in an image — is in neither, and
name: dsh-remote-signin then fails with ERR_MODULE_NOT_FOUND. Two ways out:
install into the profile (dsh plugin … add …, above), where the name resolves; or
point the entry at the file, as the dsh-unraid image does:
- insert:
- id: remote-signin
name: file:///app/node_modules/dsh-remote-signin/src/index.js
Upstream is in developer preview. The plugin depends on two contracts only —
deepseekAccount.startSignIn and the web server's route/index APIs — and degrades rather
than breaks when either changes.
MIT licensed. See CHANGELOG.md.