Blog · Pulse

DSH 0.2 rumors this week: what to pin before Monday

September 28, 2026 · dshbase · X pulse

This is a field note, not a release note. Over the last day, posts on X have started to cluster around a DeepSeek Harness 0.2 window — Monday, or maybe Tuesday — and a few of them fold in a second hope: that a V4.1 Pro built for DSH shows up on the same clock. None of that is an announcement from the project. Treat the dates as rumor. Treat the model pairing as a separate rumor stacked on the first one. What you can do before the week opens is narrower and more useful: freeze the install you already trust.

Separate what is confirmed from what is wished

Confirmed, from this desk: we have not seen an official 0.2 changelog, an official ship date, or a model card that says “V4.1 Pro for DSH.” We are not going to invent an npm dist-tag, a star count, or a calendar entry to fill that gap. If your timeline is quoting a version string, copy it from your own machine, not from this page.

Also confirmed, from the public record we have already written up: Harness has been moving fast enough that upgrade is its own failure mode. The first-month note tracked a prerelease train that outran the product. Community Pulse #4 watched a later rc land and take session lists with it. Plugin authors already live in that weather. A rumor of 0.2 does not create a new risk class. It raises the odds that people will type @latest on a Monday morning because a screenshot said the window was open.

The wish, labeled as such: @teortaxesTex is hoping for Monday, and hoping the drop lines up with a V4.1 Pro aimed at DSH. @som_dutt_ puts v0.2.0 on Monday or Tuesday and tells plugin authors to check compatibility. Chinese-language echoes from @Zekunnnnn and @VTNuE0tKLGS0N5g repeat the same cluster. Echoes are how a rumor gets a shape. They are not a second source of truth. “Hoping,” “window,” and “check compat” are the vocabulary of people bracing, not of a tag that has been cut.

Two clocks, not one

Even if both halves of the rumor were real, they would not be the same event. A harness version changes plugins, config shape, tool schemas, and session files. A model id changes weights, price, and how those tools get called. Shipping them together would be a coordination story. It is not something you can pin by bumping one package.

We have already watched a V4.1 Flash checkpoint move on its own clock. The limited-beta note was about an intermediate id with an expiry baked into the name, community measurements, and two friction points inside DSH. That post does not authorize anyone to treat “V4.1 Pro for DSH” as a product you can select today. If a new model id appears, read its own card. If a new harness tag appears, read its own changelog. Do not let a single X post weld them into one upgrade command.

Plugin authors are the people the Monday/Tuesday line is actually aimed at. A compat check is reasonable precisely because DSH’s extension surface is the product: tools, presets, and config layers move together. See the patch-stack field notes if you need a reminder that “my config” is several files, not one. A breaking API in that stack does not announce itself as a crash on first boot. It announces itself as a plugin that loads and then never shows up in the tree, or a session that opens and then cannot list itself.

The pin checklist

Do this on the profile you would be afraid to lose. Do it before you read any more timeline posts. The point is a snapshot you can return to, not a prediction about what 0.2 will contain.

Pin the build you already run. Record the exact package version your profile resolved — from dsh --version, from npm ls in the environment that actually starts the UI, or from the lockfile of a project install. Write that string into a note next to the machine name. Do not “pin” by leaving the range at latest. Do not copy a version number out of a rumor thread; if this page does not print one, that is intentional.
Dump config, both layers. dsh --profile web --dump-default-config and dsh --profile web --dump-config show defaults versus what you actually booted. Save both outputs somewhere that is not the agent’s workspace. The installer field notes treat this as the first move for a reason: arguments about plugins are faster when you can diff a file.
List the plugins that are really loaded. The dump is the list. If you also keep a directory of GitHub-sourced plugins, write down which ones are npm, which are git URLs, and which ones you have locally patched. A compat pass that only names the official bundle will miss the thing that breaks.
Tag the snapshot. Commit your config overlays, your notes, and a one-line “known good” description. If the config lives outside git, copy the directory and name the copy with the date and the version string from step 1. A tag you cannot check out is a feeling.
Wait 48 hours before a production upgrade. When a tag does appear — if it appears — let other people meet the breaking APIs first. Two days is enough for plugin authors to file the obvious mismatches and not enough for you to forget where the rollback tag is. Preview profiles can move sooner. Production profiles should not.
Read the changelog for breaking APIs before you move. Look for session format, tool-argument binding, config keys, plugin inject signatures, and anything that says migration. Pulse #4 is the cautionary shape: an upgrade that “worked” and then hid sessions. If the notes are empty or the tag is only a social post, you are not upgrading. You are hoping.

What usually breaks, without pretending we have a 0.2 diff

We are not publishing a fictional migration guide. The breaks that have already shown up on this site are the ones worth rehearsing, because a 0.2 rumor does not repeal them.

Session identity. Forked or seeded sessions have already gone dark across a rc bump when the snapshot check rejected the history. If your work lives in long sessions, export or copy them before you change the package.
Tool schemas. Zero-argument tools have failed at argument binding. Any plugin you wrote against “the model will just call it” needs a schema test, not a vibe check.
Config layering. Home patch, profile, and --patch can hide a key you thought you set. Dump after the upgrade, and diff against the dump from step 2. If the trees differ in places you did not edit, stop.
Model ids are not harness versions. Pointing a new profile at a new model while also bumping the runtime makes the failure unreadable. Change one. The model setup guide is the place to record which endpoint you meant.

What not to do on Monday

Do not run a production profile on npx with an unpinned @latest because the timeline got loud. npx @deepseek-ai/dsh web is still the right way to start a local UI — see the desktop note that goes with this pulse — and a bad way to absorb a surprise major on a machine that has customer data in the workspace.

Do not install a binary someone attached because “0.2 leaked.” That failure mode gets its own post. A version rumor and an installer rumor travel together, and only one of them is fixable with a changelog.

Do not tell a team the model got smarter because a harness tag might exist. If you need a cost and cache plan for whatever model you already have, that is the token-efficiency note in this same set. If you need to know whether a shared board will multiply a bad upgrade, read the task-board note before you add more agents to a moving runtime.

How we will update this

If an official tag and changelog show up, the pin checklist still holds: the snapshot is what makes the upgrade reversible. If the week passes with no tag, the rumor expired and your pin did not cost you anything. Either outcome is a better Monday than discovering, at noon, that the plugin tree no longer matches the note you meant to write down.

X sources

Posts below are community signals. They are not DeepSeek release notes.

@teortaxesTex — hoping for a Monday 0.2, and hoping it lines up with a V4.1 Pro for DSH.
@som_dutt_ — v0.2.0 framed as Monday or Tuesday; plugin authors told to check compatibility.
@Zekunnnnn and @VTNuE0tKLGS0N5g — Chinese-language echoes of the same cluster. Counted as echoes, not as confirmation.

All articles →