One thing has to be said up front. This version is not the latest one on npm yet. A plain install still gives you 0.2.1-rc.2, so you have to pin the version number by hand.

npm install -g @deepseek-ai/dsh@0.2.2-alpha.2

Skip that version number and nothing I describe below will be visible to you.

Then I started it, and there was the problem. Three consecutive disabling profile plugin row lines in the log. Three of the things I had installed were taken away.

npm had also flagged something during the install: install scripts for five packages were blocked, including two native modules, node-pty and koffi. I stared at it for a while and started the app anyway. The web UI opened, the model list loaded, nothing seemed broken. I filed that away to look at later if something misbehaved.

Three lines hit me the moment it booted

Here is the log, verbatim.

dsh: disabling profile plugin row "plugin-market":
  Plugin @deepseek-ai/dsh-plugin-market@0.2.1-rc.2
  is incompatible with dsh 0.2.2-alpha.2:
  requirements {"@deepseek-ai/dsh-plugin-manager":"0.2.1-rc.2",
                "@deepseek-ai/dsh-settings":"0.2.1-rc.2",
                "@deepseek-ai/dsh-tools":"0.2.1-rc.2",
                "@deepseek-ai/dsh-typert-protocol":"0.2.1-rc.2"}

The three that got disabled were ui-agent-team, plugin-market, and tool-plugin-market. The last two are actually the same package, referenced by two different config rows.

The requirements block is the whole story. It reads "0.2.1-rc.2". No caret, no tilde, four exact version numbers. And the four internal packages at runtime had already moved to 0.2.2-alpha.2.

Exact match fails, plugin gets rejected. DeepSeek Harness handles it cleanly: it does not load the plugin, it does not throw, it prints one warning line and keeps going.

That design is actually right. Letting a plugin that declared “I was only tested against these versions” run on a newer runtime makes the eventual crash far harder to diagnose. Rejection beats loading something broken.

The cost lands on the user though. You bump a version, things you installed disappear, and because it is a warning rather than an error, it is very easy to miss.

The fallout spreads to the plugin market

I had a custom plugin index configured. It lives at line 12 of ~/.dsh/profiles/web/cordis.patch.yml and points at a local static server.

After the upgrade I opened Plugins → Discover and got one line in red:

Could not read the index sources.

There was a Retry button next to it. Clicking it returned the same line.

My first instinct was the static server. lsof -iTCP:3489 came back empty, so the service had died at some point. I assumed that was the whole story, brought it back up, and curl returned 200 with a 3,764-byte index.json sitting there.

Back to the browser, clicked Retry. Same red line.

Same red line on the second try, and only then did it click: reading the index is itself an action performed by plugin-market. The index source was fine. The thing that reads it was gone. An empty page either way.

So there are two layers stacked here. On the surface the index source was down. Underneath, the plugin that reads it had been disabled.

I also tripped over a hole of my own making, worth noting. The serve.py I use for reproduction hardcodes its access log at /tmp/market/access.log, and I had cleaned that directory out. Every incoming request threw before it could respond, so curl returned exit 52 with an empty body. Creating the directory fixed the requests.

There is an official switch, buried in the warning text

The tail of those three warnings does give you a way out. It mentions dsh plugin allow-version, or the plugin manager, to grant an exemption for an exact version.

I read the help first. The plugin subcommand documentation for DeepSeek Harness does not mention this at all. It only says the remaining arguments are forwarded to pnpm.

So I just ran it, and the usage fell out on its own:

dsh: Error: usage: dsh plugin allow-version <package@version>
                   --dsh-version <exact> --accept-risk

Filling that in, one exemption per plugin:

$ dsh plugin --profile web allow-version \
    "@deepseek-ai/dsh-plugin-market@0.2.1-rc.2" \
    --dsh-version 0.2.2-alpha.2 --accept-risk
dsh: allowed @deepseek-ai/dsh-plugin-market@0.2.1-rc.2 for DSH 0.2.2-alpha.2

The exemption is scoped to one package at one version. A different version and you have to grant it again. After restarting DeepSeek Harness, the three warning lines were gone from the log, Discover read the index immediately, both plugins listed properly, and category and tag filters were back.

One note: --accept-risk means what it says. I got lucky here and the plugin ran without incident. That is not a guarantee.

What the new interface looks like

The plugins page now has two tabs, Installed and Discover. Installed splits into two sections.

The top section is Built-in plugin settings, four entries. Subagent governs recursion depth, count, and model. Web search configures the DeepSeek search source. Agent loop controls how the agent dispatches tool calls. Shell limits how long a single command may run and how much output it may produce.

The bottom section is Experimental plugins, five entries, each with a toggle:

Agent teams lets the agent split work across named teammates that share a task board and report results back.

Voice input transcribes locally with SenseVoice; the first use requires installing dependencies.

Custom plugin indexes is what adds the Discover tab to Plugins, letting you browse and install from index sources you add.

Auto authorization review is a new review mode: before each tool call the model checks it against your original request and batch-approves the ones that comply.

Change requests & worktrees tracks each session’s change requests along with their check and review results, and can start new sessions directly inside a Git worktree.

Of the five, the first two are on by default and the last three are off.

Two things that actually changed on the plugins page

After all that, it is worth looking back at what this upgrade actually delivered.

The plugin detail page now renders the package’s own README. Click into an experimental plugin and you get the full documentation, with an English and Chinese toggle, a summary, a table of contents, and a section called Use this package further down.

More interesting is that the same page breaks the bundle into its 5 components, listed one per row, each with an icon, a one-line description, a short name, the full package name, and its own toggle on the right.

Take the Change requests & worktrees package. Expanded, it is five parts.

Change requests, GitHub change requests, Session change requests, Worktree service, Change request panel. The top of the page reads Components 5 total · 5 off.

The bottom also shows provenance: Code source is Built in, current version 0.2.2-alpha.2.

This is far clearer than the old “one plugin, one switch” model. You can inspect each part of a bundle and flip them independently, and you no longer have to open a config file to find out what is installed.

Where I land on this

The interesting part of this whole episode is not the trap I fell into. It is the design tradeoff the trap exposes.

An exact-version lock keeps the plugin ecosystem safe, and the price is that any runtime upgrade can invalidate a batch of plugins at once. It is especially visible between alpha and rc: bump a few internal packages and every plugin declaring a dependency on them drops offline.

DeepSeek Harness provides an exemption switch, but the default path is rejection. The bet it is making is “better to load less than to run something broken.”

For people building plugins, this means reissuing a version declaration every time you follow a runtime release. For people using plugins, it means knowing what you installed before you upgrade, because afterwards you may not even be able to tell what went missing.

DeepSeek’s official release notes for 0.2.2-alpha.2 also mention that a failed hot plugin update will attempt to restore the previous version. That mechanism protects updates already in flight. It cannot save the version check that runs before startup. The two pieces of logic do not touch each other.

This release also lists a few things I did not verify: subagent_oar can hand standalone tasks to a local Codex or Claude CLI, and the developer tools stats plugin can show context, cache, model, and tool timing by turn. The first one sounds the most interesting, but I could not find an entry point in the UI, so it likely needs a separate install and I left it alone. Same for the hot-update rollback: official wording, and I did not construct a failure to test it.

Do you check which plugins you have installed before upgrading your toolchain? Or are you like me, finding out only after things are gone.

References

• DeepSeek Harness v0.2.2-alpha.2 release notes: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.2-alpha.2
• Test environment: macOS arm64, DeepSeek Harness upgraded directly from 0.2.1-rc.2 to 0.2.2-alpha.2, npm global install