You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Desktop 0.2.2-rc.3] Experimental bundles resolve npm latest (alphas older than the runtime), disabling storage and hiding workspaces/sessions
#13236
Installing four experimental bundles from the plugin manager picks the npm latest dist-tag. For all four of them, latest currently points to a
pre-release older than the running runtime (0.2.1-alpha.2 / 0.2.2-alpha.2 instead of 0.2.2-rc.3, which is on the next tag).
bundle
latest (installed)
next (runtime)
@deepseek-ai/dsh-cua-bundle
0.2.2-alpha.2
0.2.2-rc.3
@deepseek-ai/dsh-experimental-forge-bundle
0.2.2-alpha.2
0.2.2-rc.3
@deepseek-ai/dsh-experimental-session-search
0.2.1-alpha.2
0.2.2-rc.3
@deepseek-ai/dsh-experimental-terminal-bundle
0.2.1-alpha.2
0.2.2-rc.3
The alphas pull alpha copies of core modules into the profile. On restart, DSH
0.2.2-rc.3 marks them incompatible and disables them — including @deepseek-ai/dsh-storage-domain. The desktop UI then starts with no workspace
and no session, and refuses to add a workspace. No user data is lost: sessions
and workspace.json are intact, and everything comes back once the four bundles
are pinned to 0.2.2-rc.3.
Expected vs observed
Expected: install a bundle version compatible with the running runtime, or
refuse with an explicit message.
Observed:
no version compatibility check when resolving the bundle;
the wrong version is written to ~/.dsh/profiles/desktop/package.json, so
every later start reinstalls it (the breakage is persistent);
incompatible modules are disabled silently, and the cascade reaches storage:
the user sees an empty app rather than a plugin error;
a compatibility gate does exist but does not fire here. Installing @deepseek-ai/dsh-experimental-tool-worktree@0.2.1-alpha.2 in the same
session was correctly rejected with installation rejected: Plugin … is incompatible with dsh 0.2.2-rc.3: requirements {...}.
The four bundles above declare no requirements — only dsh.bundle.patch / dsh.bundle.platforms — so there is nothing for the
gate to check.
Reproduction
Fresh desktop profile on 0.2.2-rc.3.
Install @deepseek-ai/dsh-experimental-terminal-bundle from the plugin
manager without specifying a version (so it follows latest).
~/.dsh/profiles/desktop/package.json now has "@deepseek-ai/dsh-experimental-terminal-bundle": "0.2.1-alpha.2".
Repeat for session-search, cua, forge.
Quit and relaunch the app.
Workspace list and sessions are gone; adding a folder fails; the alpha
modules are disabled at load.
Step 3 is deterministic as long as latest keeps pointing at a pre-release.
The plugin manager's own logs (~/.dsh/profiles/desktop/.plugin-manager/logs/operation-*/pnpm.log)
show the alphas were really installed, not just mis-recorded:
Measured impact at load: 27 modules replaced by their alpha counterparts, 9
services disabled including storage, workspaces and sessions invisible, adding a
workspace refused. No data loss.
Also worth noting: dsh plugin … refuses to operate on this profile with error: profile "desktop" is managed exclusively by the Electron application,
so there is no official repair path — the only workaround is editing package.json by hand and running pnpm install in the profile directory.
Root cause
Version resolution ignores the runtime and ignores that the tag points at
a pre-release.latest is not a compatibility criterion; here it selects
alphas older than the installed next/rc.
The compatibility gate only covers plugins that declare requirements.
Bundles that do not declare any pass unchecked, even though their
dependencies pull in core modules.
Disabling is silent and not contained. Neutralising dsh-storage-domain
takes workspace and session services down with it, and the user gets an empty
UI instead of an error.
The manifest keeps the bad version, so the failure replays on every
start until manually fixed.
Suggested fixes
Resolve a bundle version compatible with the runtime (engine/peer range;
otherwise refuse explicitly), and never follow a latest that resolves to a
pre-release without saying so.
Extend the compatibility check to bundles' transitive dependencies, not only
to plugins that declare requirements.
Contain the disablement to the offending module and surface a blocking
error ("incompatible modules: …") with a repair action, instead of starting
without storage.
Provide an official repair path for profiles "managed exclusively by the
Electron application" (CLI refuses today).
Workaround for other users
After installing or updating any experimental plugin:
Any version containing alpha will break the next start. Pin the four bundles
to the runtime version (0.2.2-rc.3 here) and run pnpm install in the profile
directory, app closed. Verify on a copy of the profile first if possible.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Summary
Installing four experimental bundles from the plugin manager picks the npm
latestdist-tag. For all four of them,latestcurrently points to apre-release older than the running runtime (
0.2.1-alpha.2/0.2.2-alpha.2instead of0.2.2-rc.3, which is on thenexttag).latest(installed)next(runtime)@deepseek-ai/dsh-cua-bundle0.2.2-alpha.20.2.2-rc.3@deepseek-ai/dsh-experimental-forge-bundle0.2.2-alpha.20.2.2-rc.3@deepseek-ai/dsh-experimental-session-search0.2.1-alpha.20.2.2-rc.3@deepseek-ai/dsh-experimental-terminal-bundle0.2.1-alpha.20.2.2-rc.3The alphas pull alpha copies of core modules into the profile. On restart, DSH
0.2.2-rc.3 marks them incompatible and disables them — including
@deepseek-ai/dsh-storage-domain. The desktop UI then starts with no workspaceand no session, and refuses to add a workspace. No user data is lost: sessions
and
workspace.jsonare intact, and everything comes back once the four bundlesare pinned to
0.2.2-rc.3.Expected vs observed
Expected: install a bundle version compatible with the running runtime, or
refuse with an explicit message.
Observed:
~/.dsh/profiles/desktop/package.json, soevery later start reinstalls it (the breakage is persistent);
the user sees an empty app rather than a plugin error;
@deepseek-ai/dsh-experimental-tool-worktree@0.2.1-alpha.2in the samesession was correctly rejected with
installation rejected: Plugin … is incompatible with dsh 0.2.2-rc.3: requirements {...}.The four bundles above declare no
requirements— onlydsh.bundle.patch/dsh.bundle.platforms— so there is nothing for thegate to check.
Reproduction
desktopprofile on 0.2.2-rc.3.@deepseek-ai/dsh-experimental-terminal-bundlefrom the pluginmanager without specifying a version (so it follows
latest).~/.dsh/profiles/desktop/package.jsonnow has"@deepseek-ai/dsh-experimental-terminal-bundle": "0.2.1-alpha.2".session-search,cua,forge.modules are disabled at load.
Step 3 is deterministic as long as
latestkeeps pointing at a pre-release.Evidence
npm dist-tags at the time of the report:
The plugin manager's own logs (
~/.dsh/profiles/desktop/.plugin-manager/logs/operation-*/pnpm.log)show the alphas were really installed, not just mis-recorded:
Manifest state before the repair (extract):
Measured impact at load: 27 modules replaced by their alpha counterparts, 9
services disabled including storage, workspaces and sessions invisible, adding a
workspace refused. No data loss.
Also worth noting:
dsh plugin …refuses to operate on this profile witherror: profile "desktop" is managed exclusively by the Electron application,so there is no official repair path — the only workaround is editing
package.jsonby hand and runningpnpm installin the profile directory.Root cause
a pre-release.
latestis not a compatibility criterion; here it selectsalphas older than the installed
next/rc.requirements.Bundles that do not declare any pass unchecked, even though their
dependencies pull in core modules.
dsh-storage-domaintakes workspace and session services down with it, and the user gets an empty
UI instead of an error.
start until manually fixed.
Suggested fixes
otherwise refuse explicitly), and never follow a
latestthat resolves to apre-release without saying so.
to plugins that declare
requirements.error ("incompatible modules: …") with a repair action, instead of starting
without storage.
Electron application" (CLI refuses today).
Workaround for other users
After installing or updating any experimental plugin:
$ grep -i alpha ~/.dsh/profiles/desktop/package.jsonAny version containing
alphawill break the next start. Pin the four bundlesto the runtime version (
0.2.2-rc.3here) and runpnpm installin the profiledirectory, app closed. Verify on a copy of the profile first if possible.
Environment
~/.dsh/profiles/desktopdsh-base,dsh-web-app,dsh-subagent-claude-code,dsh-subagent-codex,dsh-experimental-terminal-bundle,dsh-experimental-session-search,dsh-cua-bundle,dsh-experimental-forge-bundle,dsh-experimental-plugin-market-bundle,dsh-experimental-auto-reviewAll reactions