What can you still install on your version
Version chains, known breaking changes, and pre/post upgrade checklists.
This page is a public-source compilation, not our own testing. Every row links to its source; “incident” rows are single-sided community reports we haven’t reproduced. Whether a plugin runs on a given version is decided by the compatibility page’s verified results.
Version chain & known changes
| Version | Date | Type | Note | Source |
|---|---|---|---|---|
| 0.1.7-rc.2 | 2026-09 | Public compilation | npm's latest tag stayed on this version for a long time while next pointed to a newer rc; the default install target and the preview channel were not the same version. | Community version-check article |
| 0.2.0-rc.1 | 2026-09-28 | Breaking change | Removed runtime invariant plugins; extensions and custom profiles relying on those diagnostic entry points break outright. composer statistics was split into activity / usage, so plugins using the old key names need to follow suit. | Community version ledger / release notes summary |
| 0.2.0-rc.1 | 2026-09-28 | Public compilation | Automation tasks moved from a built-in feature to an optional plugin package; after upgrading you must install it separately to restore the entry point. | Community version analysis |
| 0.2.1-alpha / rc | 2026-10 | Public compilation | Community plugins began declaring engines.dsh host ranges; hosts that don't satisfy them are rejected by the version gate: the plugin stays in the installed list but does not run, and saved configuration is retained. | Community plugin CHANGELOG (Chinese) |
| 0.2.2-alpha.3 | 2026-11-03 | Public compilation | Added plugin-install-failure diagnostics and a Host log entry point, distinguishing 'installation failed' from 'enable-after-install failed'. | Community ecosystem report |
| 0.2.2-rc.1 | 2026-11-04 | Upgrade incident | A Windows user reported that after upgrading from 0.2.1-rc.5, plugin entries in the config file dropped from 34 to 2, and an incompatible localization plugin caused the first launch to fail; at the time the client had no pre-upgrade automatic backup or version rollback, and manual recovery took about 5 hours. | Community incident report (not reproduced by this site) |
Pre-upgrade checklist
Do this once; it saves more time than digging through logs after something breaks.
- Write down the current host version, profile name, and list of installed plugins
- Back up the config and profile directories under $DSH_HOME and make sure the backup files open
- Commit or separately save uncommitted workspace changes first; don't rely on rollback alone
- Record, one by one, the model routes, MCP config, Agent presets, and local dependency paths you want to keep
- After upgrading, check the plugin entry count first, then enable them one at a time; don't turn them all on at once
- If startup fails, restore the config from the backup first, then isolate the single incompatible plugin
How to roll back when it breaks
First restore your profile config and plugin list from the pre-upgrade backup, then enable plugins one by one. In community reports the slow part was never the fix itself but the lack of a backup, forcing a manual rebuild of model routing and MCP config. The client offers no version rollback, so what you roll back is the config, not the version.
Claim a compatibility re-test Look up by error, not by chapter