Going from alpha to rc sounds like a milestone. I unpacked both versions and compared them. Conclusion: not a single byte changed.

The short version first

0.2.2-rc.1 was published at 17:20 Beijing time on November 4, 2026 (2026-11-04T09:20:32Z).

I ran a per-file md5 comparison against 0.2.2-alpha.3, which shipped on November 3, 2026. The scope was the top-level package, the six core sub-packages, and the underlying framework cordis. 290 files, all lined up and hashed.

Result: in every package, the only file that differs is package.json.

dist, src, locale, README, all identical. This is not “a small change”. This is zero change.

How I compared them

Three steps on the command line, no special tooling.

npm pack @deepseek-ai/dsh@0.2.2-alpha.3 and @0.2.2-rc.1 to pull one tarball each, unpack them into two directories, then hash every file by relative path.

The top-level package has 20 files, the six sub-packages have 30 to 60 each, cordis has 32. Every file with a matching name on both sides got hashed, and I only kept the ones whose hashes disagreed.

No additions, no deletions. Eight packages, eight changes, all of them in the version number and dependency range lines.

The only thing that actually changed

The code did not change. But every dependency version moved, and that is the only substantive act in this release:

In one sentence: strip the alpha suffix off the entire cordis family and promote it to release version numbers.

But there is a detail here worth spelling out. I also unpacked cordis 4.0.6-alpha.2 and 4.1.0 and compared those two. Of its 32 files, again only package.json differs. Which means even the framework layer was carried over as-is, with nothing but the house number changed. That is more interesting than the table above.

The “version number goes from alpha to stable” event had a change count of zero.

So what was the point of this release

A tag.

Before this release, latest pointed at 0.2.1-rc.5 and next pointed at 0.2.2-alpha.3. If you wanted the newest one, you had to type the full version number by hand.

After it, both latest and next point at 0.2.2-rc.1. That means npm i -g @deepseek-ai/dsh with no version number installs this one by default.

For a project this size that is not a small thing. The alpha line is the “we are willing to use it ourselves” marker. rc is the “you try it too, the interfaces are frozen” marker. Changing features is development. Changing the marker is a promise. This release did the latter.

The upgrade took under a minute

One command for the global install, npm i -g @deepseek-ai/dsh@0.2.2-rc.1, and once it finishes dsh --version says 0.2.2-rc.1.

The second command is not an upgrade, it is a profile fix. A lot of people skip this one. I skipped it last time:

dsh plugin --profile web add @deepseek-ai/dsh-cua-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-plugin-market-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-client-ui-agent-team@0.2.2-rc.1

pnpm came back with: resolved 62 packages, reused 41, downloaded 21, added 22, in 939 milliseconds.

After the install I ran a headless smoke test first, telling it to “answer with two words only: received”. It answered “received”, which means the profile boots, model routing works, and no plugin is stuck in a disabled state. That step is faster than looking at the UI.

Why run it again? Because a dsh profile is plugin layers stacked on plugin layers. Once you upgrade dsh globally, the plugins in the profile that are still pinned to alpha.3 no longer match the host program’s version, and the version check disables them at startup.

Last time, when I went to alpha.3, I only upgraded globally. Six plugin rows got shut off, storage-domain among them. Once that one died, the workspace, the session list, and the scheduled tasks all froze with it, the web app was effectively dead, and this command is what brought it back.

So my order is fixed now: global first, then profile, then verify. Skip a step and you are making trouble for yourself.

The one that never came back last time is back

The only leftover damage from the previous upgrade was ui-agent-team. Its version line is unusual, there was no package on npm that lined up with alpha.3, so it stayed disabled the whole time.

This time it has a matching version. In the plugin list that profile_ping reports after the install, all three of these are present:

@deepseek-ai/dsh-experimental-agent-team

@deepseek-ai/dsh-experimental-client-ui-agent-team

@deepseek-ai/dsh-experimental-tool-agent-team

dsh-storage-domain, the one that got disabled last round, is in the list too. On the plugins page the “Agent teams” toggle is on, and a new session’s title bar now carries an extra Agent team badge.

The installer printed one line that I think is worth recording verbatim: @deepseek-ai/dsh-experimental-client-ui-agent-team does not declare dsh.bundle, so it was installed as an ordinary dependency, not as a profile layer.

In other words it works, but its position in the system is not the same as those bundles. Vendors do not put this in the release notes. It flashes by once, in the install output.

Not everything in a profile is an official package

I took a look at the profile’s dependency list while I was there. Six entries.

Three bundles are on rc.1 now. agent-team-web-profile is still stuck on 0.1.6-alpha.2. The last two I installed myself, one from a local tgz, one straight from a GitHub repo.

Which tells you that a dsh profile is not a closed official bundle, it is a combination you assemble yourself. The upside is you can add whatever you want. The cost is that on upgrade you have to watch it yourself: which ones are official, which are pinned to a specific version, which are not on the official version line at all.

agent-team-web-profile is the example. It is the UI layer for agent-team, its version line is completely independent of the host program, and the host is on rc.1 while it sits on alpha.2. A package like that will not follow your upgrade. It goes its own way.

A quick sanity check

After the upgrade I opened a new session in the web app and sent one line: call profile_ping and paste the returned JSON back as-is.

Ten seconds and it was done. The response started with "profile": "web", "dshVersion": "0.2.2-rc.1", "plugins": [ followed by 212 plugin names.

Those 212 lines are what my profile actually contains right now, from cordis-plugin-timer all the way to dsh-plugin-profile-ping, which I wrote myself. If you want to confirm the upgrade really took effect, that one number is more reliable than any UI.

Incidentally the query itself cost 56.3K tokens, with an 86% cache hit and 3% of context used. The cost is the long plugin list, not the reasoning.

One lesson about checking versions

If you want to track dsh versions too, there is a trap to avoid: the latest tag on sub-packages lags.

Take dsh-experimental-client-ui-agent-team. Its latest is stuck at 0.1.5-alpha.2, alpha is stuck at 0.2.2-alpha.3, and the actual new version lives under next.

npm view <package> dist-tags and read all three tags together, not just latest. The main package’s latest is correct right now. The sub-packages’ are not.

My call

Is a release like this worth following? My answer is yes, but there is no rush.

Zero code change means risk close to zero. Upgrading or not upgrading will not break your environment. The real payoff is not in dsh itself but in the plugins that got promoted along with it: a package like ui-agent-team that spans version lines only gets released when the whole line moves to rc together.

On the flip side, if you have an alpha.3 that runs fine and no plugin is disabled, you do not need to touch anything this time. Wait for the 0.2.2 stable release and catch up in one go. There are no new features coming your way in the meantime.

When you upgrade, do you read the release notes first, or just unpack the tarballs and diff them yourself?

I run dsh daily, on 0.2.2-alpha.2 released October 28. My first instinct was not to paraphrase it. It was to try it.

So I opened a Creator mode session in my own web profile with a one-line request: write the smallest possible plugin, register a tool called profile_ping, and have it return the current profile name, the dsh version, and which plugins are installed in that profile.

Nine minutes later the tool was sitting in the plugin manager. I opened a new session, called it, and had the answer in ten seconds.

dsh has four modes

Open the web UI and there is a mode selector above the input box. It expands to four:

• Standard: writes code, looks things up, runs commands, good for most tasks
• PTC: everything Standard does, plus batches of tool calls you then filter, dedupe, count, or summarize
• Minimal: terminal and image reading only, for testing baseline capability
• Creator: in the official wording, customize dsh through conversation, letting the agent write plugins that add features or UI, or combine tools and prompts into a mode of your own

I picked the fourth.

It did not start by writing code

That was the most surprising part.

After receiving the request it loaded a skill package called cordis-plugin-development, then started inspecting the runtime.

The Trajectory panel on the right shows the sequence. It ran inspect providers to see what services exist, then query runtime to ask for the exact method signatures on Service.listService, and worked through the contracts for pluginManager, profileContext, and defineTool.

It even went and read the source of @deepseek-ai/dsh-app-boot to decide whether a plugin could import that package. It needed the dsh version, and the version only exists in the install directory’s package.json.

That reasoning step is worth more than the result. It first established that a profile-installed plugin cannot resolve packages from the install directory, then switched to the profileContext the runtime already exposes, reading the version itself from the installAnchor path.

What it produced

The output is a standard bundle package in the session workspace: manifest, patch, entry point, two locale files, an icon, and a README.

The line in package.json, "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }, is how it introduces itself to dsh. The patch file is three lines, inserting a row with the id profile-ping.

index.js is 6.9 KB: it registers the tool, defines the parameter and output schemas, and writes a render function. The Chinese display name, “Profile 探针” (profile probe), it picked on its own.

I rejected it once

The install step calls plugin_manager with install_bundle, which raises an approval dialog stating that this writes changes into the profile and that installed Host code runs outside the sandbox.

I clicked Allow once.

Later it wanted to copy the packed tgz out of /tmp into Documents for safekeeping, and asked for approval again. I clicked Reject, because this was a temporary artifact I planned to clean up.

Its reaction is worth recording: it stopped, and said explicitly that the user declined the escalation, so it should not work around it and would just explain.

That rule is written in its skill package, not improvised by the model. The text: do not hand-write the profile’s package.json, do not run pnpm in the profile directory, install_bundle does those things.

It works

In a new session I said: call profile_ping directly and paste the raw output.

Ten seconds later it came back with Profile: web, dsh version: 0.2.2-alpha.2, Plugins (209):, followed by 209 package names. The one at the end of that list is the tool it just wrote.

The plugin manager’s installed list also gained a row: Profile ping, with icon, description, and its toggle switched on.

The rules are written into the skill package

I only read the skill document it loaded after the run, and then I understood why it moved the way it did. The document writes that the workflow has five steps, and the first is “deliver a working version first.”

The opening of the doc says: ship something that runs, then talk about how it looks. If a visual request names no destination, the default is the current web UI. Do not build a preview page, do not make several design variants, do not write screenshot scripts.

Then three prohibitions: do not hand-write the profile’s package.json, do not run pnpm in the profile directory, do not create packages under $DSH_HOME. Those all go through install_bundle, and a hand write costs an approval each time.

There is also a verification rule: after install, read application and warnings from the returned result, not logs, not the process list, not whether the page came up.

I did not interfere with a single technical decision. The only thing I did was two approval clicks, one yes and one no. It walked the whole thing inside that rulebook.

Three rough edges I have to mention

First, the workspace directory it created has a literal backslash in its name. On macOS dsh built the path as deepseek-harness\creator-lab, and that backslash is a real character, not an escape. ESM cannot load such a path, so the plugin simply could not be imported. It found this itself and worked around it by packing a tgz and installing from that.

Second, in the same turn the tool could not be called. The tool list is fixed when a turn begins, so a freshly registered tool only appears next turn. It spun in the Trajectory several times, writing in its own reasoning that it could probably only emit tools from the static list. I had to open a new session to verify it.

Third, the install record says file:/tmp/dsh-plugin-build/xxx.tgz. Clear the temp directory and this plugin never installs again. That is the problem it wanted to fix, and that is the request I rejected. For anything long-lived, the package belongs in a workspace and should be installed by pointing install_bundle at the directory.

What it can build, and what it cannot

It can build tool plugins, which add a capability to the agent’s toolbox, like my profile_ping; configuration plugins, which change the behavior of some host service; and UI plugins, which mount into a slot in the web UI. The skill package ships templates and reference docs for all three.

It cannot build plugins that need a new host service. Its own documentation says this plugin is not a kernel: no new services, no new session event types, no new sandbox backends. Cross-profile changes are also out, one profile at a time.

The more practical limit is tokens. Nine minutes of work burned 8.9 million tokens, and a 99% cache hit rate is what kept the cost bearable. If you want it doing serious work, decide first whether it is worth that.

My take

“Build plugins by chatting” makes it sound like a generator: you describe, it emits code.

It is not that. It behaves like an engineer who knows this framework: inspect what the runtime offers, read source to confirm the constraints, follow the skill package’s procedure, request approval to install, and verify the result itself.

What is actually scarce here is the procedure. The skill package writes down “deliver something runnable before anything pretty,” “an unspecified visual request lands in the current UI,” and “read application, not logs.” Models change. This rulebook does not.

One boundary worth stating: 8.9 million tokens for nine minutes, 99% cache hit. This is not free magic, it is real construction work.

What tool of yours do you have to dig through config every time just to learn its state? That one is worth having a plugin written for it.