[0.2.1-rc.3] MCP tools silently disappear after upgrade: transitive profile deps stuck on old rc vs exact-peer compatibility gate

[lybym]

Issues are disabled on this repo, so posting here (following the practice of #6544).

Environment

• DeepSeek Harness desktop 0.2.1-rc.3 (in-app upgrade from 0.2.1-rc.2 on 2026-10-25)
• Windows 11, Chrome 156
• Profile desktop, MCP plugins registered via cordis.patch.yml (@deepseek-ai/dsh-mcp-client, stdio transport; one Playwright MCP entry + one Telegram MCP entry)

TL;DR

After the in-app upgrade to 0.2.1-rc.3, all mcp__<server>__* tools silently disappear. The upgrade reinstalls the profile dependency tree but leaves the transitive plugin package @deepseek-ai/dsh-mcp-client at 0.2.1-rc.2 (lockfile/range resolution — it is not a direct dependency of the profile). Because the plugin has no engines.dsh and instead pins every @deepseek-ai/dsh-* peer to the exact version 0.2.1-rc.2, the boot-time compatibility gate (dsh-app-boot → evaluatePluginCompatibility) finds unmet requirements and rejects the plugin before the stdio child is ever spawned. Nothing is logged anywhere user-discoverable, and failOnStartupError never comes into play because no connection attempt happens.

Fix: pnpm add --save-exact @deepseek-ai/dsh-mcp-client@0.2.1-rc.3 inside the profile → restart → harness spawns the MCP child again (verified via process command line) → all 23 mcp__playwright-mcp__* tools return in new sessions.

Evidence chain

1. Working state on rc.2: the MCP server wrote page snapshots on Oct 24 (profiles/<name>/.playwright-mcp/).
2. Upgrade on Oct 25 01:10: app → rc.3; profile tree reinstalled. profiles/<name>/package.json direct deps pinned to exact rc.3 (e.g. @deepseek-ai/dsh-subagent-codex: 0.2.1-rc.3), but node_modules/@deepseek-ai/dsh-mcp-client = 0.2.1-rc.2 (pnpm-lock resolves it as rc.2; transitive only).
3. Spawn probe: swapped the patch entry's command for cmd.exe unconditionally appending to a log file, then launching the original command via a Node wrapper that logs require() errors. After boot the log file did not exist → the plugin command was never spawned.
4. Gate located in source (dsh-app-boot): no engines.dsh → unmetRequirements() requires every @deepseek-ai/dsh-* peer to satisfy the runtime version. The rc.2 manifest pins peers to exact 0.2.1-rc.2 → unmet → rejected pre-spawn.
5. Fix verified: exact-pin to 0.2.1-rc.3 → restart → child spawned by the harness (observed command line = the original registration command) → all tools back.

Ruled out during diagnosis (for triage hygiene)

• Not the Windows agent sandbox: the MCP stdio child is spawned by the harness itself outside the agent sandbox (per apps/cli/reference/README.md). Launching Chrome from inside the agent sandbox does fail (0xFFFF7001 — see [Bug/建议] Windows 沙箱内无法启动 Chromium 系浏览器（0x80000003）—— 根因定位与修复建议 #6544), but that pre-existing limitation is unrelated to this path.
• Not Chrome 156 / Playwright-version incompatibility: the original registration command works end-to-end outside the harness (stdio JSON-RPC probe: initialize → 24 tools → navigate OK).
• Not config loss: the cordis.patch.yml entry and all referenced paths were intact the whole time.
• Diagnostic red herring worth documenting: 0xFFFF7001 is Crashpad's no-dump exit path, not a specific "sandbox denied" code.

Asks for maintainers

1. Upgrade flow: when reinstalling profile dependency trees, align transitive @deepseek-ai/* packages with the new runtime rc (or warn when a profile-resolved plugin version ≠ runtime rc), so exact-peer gates don't start failing after an in-app upgrade. (Possibly related: minimumReleaseAge / minimumReleaseAgeExclude interaction with range resolution during upgrade — unconfirmed.)
2. Observability: write a discoverable log entry (logs.db / GUI banner) when evaluatePluginCompatibility rejects a plugin at boot. Currently the rejection is completely silent (logs.db has zero rows; failOnStartupError is unrelated because no connection is ever attempted).
3. Docs: clarify that failOnStartupError only governs post-connection activation behavior, and document the profile-vs-runtime module resolution precedence for patch entries (name: resolution order; whether/when the runtime mapping shadows stale profile-local copies).

Notes

• A profile-local compatibility.json exact-version exemption ("@deepseek-ai/dsh-mcp-client@0.2.1-rc.2": ["0.2.1-rc.3"]) would also have unblocked boot, but updating the package is the correct remedy.
• Happy to provide the full diagnostic timeline (spawn-probe/CDP-proxy/stdio-probe scripts) if useful.

[kinght1510]

Independent confirmation — but the drifted packages here are the profile's direct dependencies, not only transitive ones.

Environment: DSH desktop 0.2.1-rc.3 (in-app upgrade from 0.2.1-rc.2; the updater had already placed pending\deepseek-harness-0.2.1-rc.3-win-x64.exe, upgraded 2026-10-26), Windows 11, profile desktop.

What differs from the report's trigger

• profiles/desktop/package.json still pins seven @deepseek-ai/dsh-* packages at 0.2.1-rc.2. They are direct dependencies of the profile, not transitive resolution leftovers — the in-app upgrade did not rewrite any of them.
• Each of those packages pins its runtime peers to the exact 0.2.1-rc.2 (@deepseek-ai/dsh-brand, @deepseek-ai/dsh-tools, …), so the same gate rejects all of them at boot.
• Four rows are denied: browser-use, computer-use, browser-playwright-mcp, computer-cua-native. Both tool namespaces disappear (mcp__playwright-mcp__*, cua_driver_native__*); a session that should expose them reports 36 tools, 0 of them mcp__*.
• The plugin panel shows those four rows as disabled, and nothing states which requirement failed.

So there is a second path to the same silent loss: any profile package the upgrade does not own stays pinned, and every runtime bump disables it. User-added provider plugins (browser-use / computer-use / playwright-mcp / cua-driver) are exactly that class, so for those users the failure repeats on every upgrade, not just one regressed transitive dep.

Reproduction check (read-only)

(Get-Item "<install root>\DeepSeek Harness.exe").VersionInfo.FileVersion          # 0.2.1-rc.3
Get-Content "$env:USERPROFILE\.dsh\profiles\desktop\package.json"                 # "@deepseek-ai/dsh-browser-use": "0.2.1-rc.2", ...
(Get-Content "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\@deepseek-ai\dsh-browser-use\package.json" -Raw |
  ConvertFrom-Json).peerDependencies.'@deepseek-ai/dsh-brand'                     # 0.2.1-rc.2

After pnpm add --save-exact for the seven packages at 0.2.1-rc.3 (bundled pnpm, profile directory) and one app restart, the gate passes and the rows re-enable.

Fix proposals, tied to the sources at tag dsh-v0.2.1-rc.3

1. Carry the denial into something queryable. The reporter is a stderr line — packages/boot/app-boot/src/compatibility-preflight.ts:74-84; preflight() already returns { rows, blocked } (:168), but the per-row (row, reason) pair is dropped after printing. Exposing it on the loader row (the disabledReason idea from Upgrading DSH silently disables version-mismatched profile plugins; the reason lives only on stderr #11080) or writing a profile diagnostics record that the desktop shell renders as a startup banner would make this self-diagnosing.

2. Align before the restart instead of after. The updater downloads the installer while the old runtime is still running (pending\update-info.json names deepseek-harness-<version>-win-x64.exe), so the next runtime version is known in advance. Re-pinning the profile's @deepseek-ai/dsh-* dependencies to that version before quit/install makes the upgrade seamless; that is the only window where a repair lands before the new runtime takes its boot-time snapshot. A local guard that does exactly this (read pending version → pnpm add --save-exact in the profile → restart) is what we run here.

3. Prefer a runtime range over exact peers for first-party plugins. The gate short-circuits on engines.dsh (packages/boot/app-boot/src/plugin-compatibility.ts:55-62), so a plugin declaring engines.dsh: ">=0.2.1-rc.3 <0.3.0" survives rc bumps. First-party provider plugins currently pin exact @deepseek-ai/dsh-* peers, which turns every app upgrade into a guaranteed break for anyone who installed them from the registry.

Related: #11080 reports the same silent-disable symptom one day later and proposes surfacing it in the loader listing.

[lybym]

Original reporter here (OP of this discussion) — thank you for the independent confirmation. Two additions that may help triage and other users:

1. Two distinct residue paths converging on the same gate.
In our profile the updater did rewrite direct dependencies to exact 0.2.1-rc.3 (e.g. @deepseek-ai/dsh-subagent-codex was bumped), but the transitive @deepseek-ai/dsh-mcp-client stayed at 0.2.1-rc.2 via lockfile/range resolution — the exact mirror image of your case, where direct deps were never rewritten at all. Both paths end identically: any profile-resolved @deepseek-ai/dsh-* plugin ≠ runtime rc → exact-peer gate rejects pre-spawn → silent tool loss. Your proposal 2 (re-pin before quit/install using the known pending version) would cover both paths; proposal 3 (engines.dsh ranges instead of exact peers for first-party plugins) would end the class permanently.

2. Spawn probe — proving “never spawned” without stderr access.
Since the rejection currently leaves nothing queryable, we swapped the patch entry's command for an unconditional probe:

cmd.exe /d /c "(echo SPAWN %DATE% %TIME% >> probe.log) && (<node.exe> <wrapper.js> --cdp-endpoint http://127.0.0.1:9333)"

where wrapper.js logs argv/cwd and any require() error stack to a file, then loads the original cli.js. After boot: absence of the SPAWN line = definitive pre-spawn rejection; presence plus a stack = the child's actual failure reason. No timing race, immune to the failOnStartupError silence. If the per-row denial surfacing (#11080 / your point 1) takes a while to land, this trick may deserve a spot in the troubleshooting docs.

Two small confirmations: (a) the profile-local compatibility.json exact-version exemption does unblock boot (tested), though re-pinning the package is the correct remedy; (b) failOnStartupError indeed never fired here — it only governs post-connection activation behavior, consistent with your reading. logs.db had zero rows throughout.

[lybym]

Update — recurrence on 0.2.1-rc.5 (2026-10-30), confirming the "repeats on every upgrade" prediction.

The in-app upgrade to 0.2.1-rc.5 reproduced the exact same silent loss:

• Runtime: 0.2.1-rc.5 (read from the installed asar's dsh/package.json).
• Profile desktop: the two @deepseek-ai/* deps we had exact-pinned to 0.2.1-rc.3 after the rc.3 incident (@deepseek-ai/dsh-mcp-client, @deepseek-ai/dsh-subagent-codex) were left at rc.3 by the upgrade — the updater did not align them with the new runtime rc.
• Same signature as before: compatibility gate rejects pre-spawn (spawn probe shows the patch command is never created), no tools, nothing in logs.db, failOnStartupError unrelated.
• Remedy applied again: pnpm add --save-exact @deepseek-ai/dsh-mcp-client@0.2.1-rc.5 @deepseek-ai/dsh-subagent-codex@0.2.1-rc.5 → restart.

This tightens the pattern: it is not a one-off transitive-resolution miss (the rc.3 incident) — the updater simply does not touch any profile @deepseek-ai/* dependency, whether transitive (first report) or user-pinned to the previous rc (this report). Every runtime rc bump will disable every profile plugin until manual re-pinning. A small local helper now automates this on our side (read the runtime version from the installed asar → re-pin all profile @deepseek-ai/* deps → restart); sharing it in case it helps others until ask 1 lands:

re-pin-after-upgrade.ps1 (run after every in-app upgrade, then restart the harness)

$ErrorActionPreference = "Stop"
$asar = "C:\Users\<you>\AppData\Local\Programs\DeepSeek Harness\resources\app.asar"
$prof = "$env:USERPROFILE\.dsh\profiles\desktop"
$node = "$env:USERPROFILE\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe"
$pnpm = "$env:USERPROFILE\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\pnpm\bin\pnpm.mjs"

$ver = & $node -e "const fs=require('fs');const fd=fs.openSync(process.argv[1],'r');const h=Buffer.alloc(16);fs.readSync(fd,h,0,16,0);const hs=h.readUInt32LE(4);const jl=h.readUInt32LE(12);const b=Buffer.alloc(jl);fs.readSync(fd,b,0,jl,16);const idx=JSON.parse(b.toString('utf8'));const e=idx.files.dsh.files['package.json'];const db=Buffer.alloc(e.size);fs.readSync(fd,db,0,e.size,8+hs+parseInt(e.offset,10));console.log(JSON.parse(db.toString('utf8')).version)" $asar
Write-Output "runtime: $ver"

$pkg = Get-Content "$prof\package.json" -Raw | ConvertFrom-Json
$specs = @($pkg.dependencies.PSObject.Properties |
    Where-Object { $_.Name -like '@deepseek-ai/*' } |
    ForEach-Object { "$($_.Name)@$ver" })
$env:PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD = "1"
Push-Location $prof
& $node $pnpm add --save-exact @specs
if ($LASTEXITCODE -ne 0) { throw "pnpm add failed" }
Pop-Location

foreach ($s in $specs) {
    $n = $s.Substring(0, $s.LastIndexOf('@'))
    $v = (Get-Content "$prof\node_modules\$n\package.json" -Raw | ConvertFrom-Json).version
    Write-Output ("{0}: {1} [{2}]" -f $n, $v, $(if ($v -eq $ver) { "OK" } else { "MISMATCH" }))
}
Write-Output "done - restart DeepSeek Harness"

Will follow up once the restart verification confirms tools are back on rc.5.