ilimei/dsh-zenmux-oauth

ZenMux OAuth 2.0 PKCE plugin for DeepSeek Harness

dsh-zenmux-oauth adds OAuth 2.0 Authorization Code login with PKCE S256 for interactive DeepSeek Harness deployments fronted by ZenMux. The plugin registers /zenmux [login|status|logout]: login opens a single-use 127.0.0.1 loopback listener that receives the authorization response, persists the versioned access/refresh token set through ctx.credentials, and refreshes before expiry; status reports connection and expiry without returning tokens; logout attempts remote refresh-token revocation, clears the stored set, and removes the mirrored access token only while it still matches the OAuth-owned value. The listener rejects other paths, mismatched state, duplicate callbacks and late callbacks, binds only to loopback, and closes after one accepted response or timeout. Model routing stays separate — point a pi-ai custom provider at ZenMux with apiKeyEnv set to the configured accessTokenRef; never disable TLS verification (NODE_TLS_REJECT_UNAUTHORIZED=0 would expose authorization codes and refresh tokens).

Other ★ 0 updated 2026-08-14 ⚠️ needs adapt
View on GitHub ↗

Install

dsh plugin --profile web add github:ilimei/dsh-zenmux-oauth

GitHub install per README (EN primary with 中文 edition): dsh plugin --profile web add github:ilimei/dsh-zenmux-oauth, then dsh web. README notes the shorter npm spec will work 'after the package is published to npm' — at verify time 2026-09-03 it is GitHub-only. The bundle declares dsh.bundle.patch which mounts an idle controller and sets proxyUrl to socks5h://127.0.0.1:1080 without modifying the built-in base bundle.

Compatibility

Interactive Harness deployments behind ZenMux; OAuth 2.0 Authorization Code + PKCE S256; credentials persisted via ctx.credentials; proxyUrl socks5h://127.0.0.1:1080 (the h form keeps DNS on the proxy side).

Details

Recent updates

No changelog section; npm publish pending per README.

FAQ

What does /zenmux login do?
Starts an OAuth Authorization Code + PKCE S256 flow: you open the ZenMux URL on a loopback callback, approve, and the token set is persisted through ctx.credentials with refresh-before-expiry.
Is the callback listener safe?
It binds only to 127.0.0.1, accepts one response, and rejects other paths, mismatched state, duplicate callbacks and callbacks after loginTimeoutMs.
Does logout revoke remotely?
It attempts remote refresh-token revocation, clears the stored OAuth set, and removes the mirrored access token only when it still matches the OAuth-owned value.

Alternatives

ai-eks/dsh-auth-tunnel · revive/dsh-git-credentials

More plugins in Other

Browse more in Other

Guides for Other plugins