zcode reverse proxy: a DSH plugin for DeepSeek Harness

A zcode reverse proxy is not system-wide network proxying: it uses a DSH plugin (dsh-zcode-cli-proxy) to hand DeepSeek Harness model requests to the agent built into your local ZCode client — it changes where the model comes from, not how the network flows.

DSH plugin reverse proxy overview

This guide answers three things about the zcode reverse proxy: what it actually solves, how to install and wire it up in DeepSeek Harness, and where it sits relative to a system network proxy and the built-in model providers. Conclusion first: it is a forwarding plugin at the model-request layer, not a proxy server, and it needs no API key in DeepSeek Harness. For general outbound network proxying (the HTTPS_PROXY family) go to How to configure a network proxy in DeepSeek Harness; this piece covers the zcode-specific reverse proxy only. The three directions at a glance:

What the zcode reverse proxy solves: turning the local ZCode client into a DeepSeek Harness model source

The zcode reverse proxy targets this situation: you already have the ZCode client installed locally with Start Plan quota on the account, but there is no usable API key in DeepSeek Harness and you don't want to build your own gateway. dsh-zcode-cli-proxy hands DeepSeek Harness model requests to the agent built into the local ZCode client, spending your ZCode account's Start Plan / Coding Plan quota directly (source). Specifically, it does these things for you:

1. Raises a resident app-server channel — it starts the ZCode app-server process the way the ZCode GUI does, and multi-turn sessions reuse it by DeepSeek Harness's sessionId, so there's no handshake every turn.
2. Injects the account and returns authentication — it injects the Start Plan account and returns the shared credential's auth info to the agent before each request, letting the agent sign the request itself.
3. Keeps true streaming and multimodality — text / reasoning deltas are forwarded directly, tool calls work as usual, and images are attached as local files for the agent to read.
4. Self-heals unstable turns — hitting "a turn is already running" makes it re-send a stop, wait and retry; a reclaimed session means a new session that replays history; an app-server subprocess exit invalidates the session mapping.

In one line: it swaps where the model comes from — from an API key or a self-built gateway to the ZCode client already signed in on your machine. The fit is when you hold ZCode quota, have the client on the machine and just want that model to appear in DeepSeek Harness's model list; the misfit is when the client isn't installed or the account has no usable quota, in which case the reverse proxy has nothing to work with. One more thing: because the request is ultimately sent by the local client, whether the model endpoint is reachable depends on the client's network environment, not DeepSeek Harness's outbound settings.

How to configure it: install dsh-zcode-cli-proxy and pick a provider and model

Configuration has two halves: install this DSH plugin into a profile from the command line, then in DeepSeek Harness settings switch the provider to "ZCode Start Plan (client reverse proxy)" and choose a model (source). Go in order:

1. Confirm the prerequisites — the local machine has the ZCode client installed, signed in to an account with Start Plan quota. Expected: the client opens normally and quota is available; the plugin auto-detects the client's bundled script path, and you can specify it manually later if it can't.
2. Install the plugin — it has no npm package name and installs directly from GitHub, so run dsh plugin --profile web add github:kyle123740/dsh-zcode-cli-proxy. Expected: pnpm prints an added line and the dependency is written to the web profile. If you'd rather not type commands, paste the GitHub address through "Custom install" in the DSH Plugin Hub market.
3. Restart the host — restart dsh web so the plugin tree reloads. Expected: the provider shows up on the Models page, meaning the plugin has mounted.
4. Pick a provider and model — open the Models page in DeepSeek Harness settings, set the provider to "ZCode Start Plan (client reverse proxy)" and choose the matching model (for example GLM-5.3-Flash (ZCode CLI)). Expected: from then on DeepSeek Harness model requests are executed by the resident ZCode app-server.
5. Send a task to verify — ask a simple question in a session. Expected: the answer streams token by token and consumes your ZCode account quota rather than any API key.
6. Fine-tune fields if needed — go to Settings → Plugins and adjust the items below as required. Expected: behavior fits your machine environment and turn length.

# install the plugin (GitHub-direct, no npm package name)
dsh plugin --profile web add github:kyle123740/dsh-zcode-cli-proxy
# confirm the dependency really landed
dsh plugin --profile web why dsh-zcode-cli-proxy
# takes effect after restarting the host
dsh web

Adjustable fields (Settings → Plugins):

This DeepSeek plugin's master switch lives on the same page: to temporarily fall back to an ordinary model provider, just turn the master switch off — no uninstall required.

Boundaries: zcode reverse proxy vs network proxy vs built-in model providers

Three things are easily confused: the zcode reverse proxy is a source switch at the model-request layer, a network proxy is the network egress, and a built-in model provider is DeepSeek Harness's own model wiring — they can coexist but never replace one another. Compare them:

A few boundaries to remember:

1. A dead reverse proxy ≠ dead network — requests are sent by the local ZCode agent and the network proxy is another layer; a misconfigured HTTPS_PROXY can look like the reverse proxy doing nothing at all, so confirm the egress first at How to configure a network proxy in DeepSeek Harness.
2. The reverse proxy isn't an API-key substitute — what it bypasses is the credential, not turning ZCode into a general gateway; to fill in an API key or build a gateway, go to How to configure DeepSeek Harness model providers.
3. Get the quota accounting right — auxiliary calls like session titles are generated locally and burn no quota, while what really consumes quota is the model request itself; don't confuse the two or you'll misjudge "installed but not working".

Notes and limits for the zcode DSH plugin

1. It depends heavily on the local environment — with no ZCode client, or a client not signed in to an account with quota, the reverse proxy has no executor to use.
2. The usual GitHub-direct pitfall — if the repo is a git dependency with build scripts, pnpm 10 and later can block the first add with allowBuilds; copy the key into the profile's pnpm-workspace.yaml and rerun.
3. Turn locks and timeouts leave errors — after a single turn is aborted or times out, a turn lock may remain and surface as this run failed · PROVIDER; the channel layer re-sends a stop and retries, and for long turns you can raise zcodeCliTimeoutMs.
4. Session reclaim keeps history — on a session-not-found message the plugin discards the cache, creates a new session and replays the whole conversation under first-turn semantics, preserving history intact.
5. If quota doesn't move, check two places — the revision identifier used for injection must match the config source character for character (a mismatch is silently skipped), and the auth token must come from shared credentials and not be expired.
6. Community plugin, not official — maintained by the author kyle123740 under AGPL-3.0 and unaffiliated with DeepSeek AI; read the source repo before installing.
7. Preview changes things — DeepSeek Harness is in developer preview, so treat the fields and commands as version-specific.

Rather than trial-and-error in the config and mixing the zcode reverse proxy with a general network proxy, install the proxy from the market of DSH Plugin Hub and set provider and model once in the settings page.

Source: kyle123740/dsh-zcode-cli-proxy, dsh-zcode-cli-proxy (DSH Plugin Hub entry), DeepSeek Harness docs - network proxy