[Bug]: dsh plugin add 在 Windows 上挂起不退出，profile bundles 永不 reconcile（插件"装上了但不加载"）

[ccc0zl]

[Bug]: dsh plugin add 在 Windows 上挂起不退出，profile bundles 永不 reconcile（插件"装上了但不加载"）

提交目标：https://github.com/deepseek-ai/deepseek-harness/issues/new
提交前建议先检索 open/closed Issue 确认无重复；可补一张终端截图（挂起进程树 / 时间戳证据）。

摘要

在 Windows 上执行 dsh plugin --profile <X> add <Pkg> 时，pnpm 已完成安装（dependencies 与 pnpm-lock.yaml 均写入）并打印 Done in ... using pnpm v11.7.0 之后进程不退出（实测挂起 11+ 分钟，CPU 完全静止、无子进程、无网络连接、目录无写入）。由于 dsh CLI 的 reconcile 阶段只在 pnpm 正常退出后才执行，bundles 永不 reconcile → 插件被装进 dependencies 但永远不进 dsh.profile.bundles，GUI 不加载。dsh-hot-installer 插件因此"装上了但不加载"。

预期结果

dsh plugin add 应当像正常 pnpm 一样在打印 Done 后退出，随后平台 reconcile 把包追加进 dsh.profile.bundles，插件被 GUI 加载。即使 build 脚本异常，CLI 也应有超时保护而不是无限挂起。

详情 / 复现步骤

1. 环境：Windows（DeepSeek Harness GUI，desktop profile）。
2. 执行 dsh plugin --profile desktop add dsh-hot-installer（dsh = DSH 内置 CLI：DeepSeek Harness.exe --expose-internals ...\cli.js plugin ...，内部 pnpm = 11.7.0，ELECTRON_RUN_AS_NODE=1 下运行）。
3. 观察：pnpm 阶段输出 Done in 4.7s using pnpm v11.7.0 后零输出挂起；dependencies 已写入（+ dsh-hot-installer ^0.5.4）、pnpm-lock.yaml 已写完（时间戳确认），但 dsh.profile.bundles 未追加该包；.plugin-manager\run.json 残留 {"pid":6940,"grouped":false}（finally 未执行）。
4. 挂起期间进程树：pwsh → cmd (dsh.cmd) → Harness (cli.js plugin add, CPU 0.6) → Harness (pnpm.mjs add, CPU 5.42 两次采样完全一致、线程 13、句柄 230、**无任何子进程**、无 TCP 连接)。
5. 反复出现（两次独立执行均复现，分别为 18:05 与 18:30）。
6. 影响：任何通过 dsh plugin add 安装的带 dsh.bundle.patch 的插件都不会被加载；dsh-hot-installer 插件本身的热生效机制也无从触发。

环境信息

• DSH：DeepSeek Harness（resources\app.asar，内置 pnpm 11.7.0，内置 node v24.18.1）
• 操作系统：Windows 10/11 x64（企业网络，nodejs.org / GitHub Releases 被代理限速）
• 插件：dsh-hot-installer v0.5.4（desktop profile）
• CLI：dsh（DSH 内置，dsh-desktop-host\lib\cli.js → asar 内嵌 @deepseek-ai\dsh）

Bug 截图

说明：当前无可直接粘贴的 GUI 截图（问题发生在 CLI/进程层面）。以下为进程证据文本，如需可补充终端截图。

# 18:30 挂起时的进程树（第二次复现）
22644 pwsh            (job 主进程)
 └─ 24036 cmd          dsh.cmd
     └─ 17840 Harness  DeepSeek Harness.exe --expose-internals ...\cli.js plugin --profile desktop add dsh-hot-installer   (CPU 0.6)
         └─ 18380 Harness  DeepSeek Harness.exe --expose-internals ...\pnpm.mjs add dsh-hot-installer
                          (无子进程 / CPU 两次采样 5.421875 完全一致 / 线程 13 / 句柄 230 / 无 TCP 连接)

# 关键文件时间戳（时间线闭合）
package.json    18:13:20  手动写入 bundles 的时刻（GUI 18:13 热加载成功）
pnpm-lock.yaml  18:30:06  第二次 add 已写完 lockfile 后才卡住（Done 打印后、进程退出前）
%TEMP%\dsh-hot-desktop-add.log  最后一行 = "Done in 4.7s using pnpm v11.7.0"（之后零输出）

冒烟测试

• 环境：同一 DSH / desktop profile。
• 执行与观察：
  1. dsh plugin --profile desktop add dsh-hot-installer → 挂起 >11 分钟（两次复现，18:05 / 18:30）；
  2. 手动把该包追加进 dsh.profile.bundles → GUI 10 秒内热加载成功，插件日志 active（证明 reconcile 是唯一缺口）；
  3. 用 --ignore-scripts 重建 node_modules 后再次完整 add → 2.1s 正常完成、exit 0（node_modules 一致状态下 pnpm 正常退出，佐证挂起与损坏/不一致 node_modules 下的 build 脚本链路相关）；
  4. 对照：全局独立 pnpm 12.10.1（非 DSH 内置）执行同类操作无挂起。
• 结论：挂起发生在 DSH 内置 pnpm（Electron + ELECTRON_RUN_AS_NODE=1 模式）打印 Done 后、进程退出前，非网络、非死循环、非 postinstall 子进程。

引用代码

问题根因位于 DSH 平台内置 CLI（app.asar 内），非本仓库代码：

• dsh/node_modules/@deepseek-ai/dsh-plugin-manager/lib/types/operations.js：
  • L503-504：else if (options.activateNewBundles !== false) { await reconcile(before, dir, context.installAnchor, options); } ← reconcile 仅在 pnpm exitCode===0 且正常退出后执行（L443 if (exitCode === 0 && !control.stalled)）；
  • L345：armIdle 仅在 idleTimeoutMs 定义时生效——cli 模式 options 未传 idleTimeoutMs → 永不超时；
  • L389 recordRun 写 run.json；L508-514 finally 清理（挂起时未执行 → run.json 残留）。
• dsh/node_modules/@deepseek-ai/dsh/lib/plugin-*.js（runPlugin）：options 仅含 {...packageManager, execution:"cli", outputBytes:16384, lockWaitMs:12e4, lookupTimeoutMs:12e4, onOutput}，无 idleTimeoutMs、无 activateNewBundles。
• dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js L882-888 / L901-907：packageDirFromAnchor / resolveBundleDir（reconcile 依赖的 bundle 解析，纯同步、非卡点）。
• 插件侧：dsh-hot-installer v0.5.4 index.mjs（声明平台自身 reconcile bundles，插件不补写）。

补充信息

• 完整根因链：DSH 内置 pnpm 11.7.0 在 ELECTRON_RUN_AS_NODE=1 下运行 build 脚本后丢失子进程 exit/close 事件（Windows）→ 打印 Done 后不退出 → CLI 无 idleTimeoutMs 无限期等待 → reconcile 永不执行 → bundles 永不写入。
• 建议修复（平台侧）：
  1. cli 模式为 pnpm 传入 idleTimeoutMs（如 60s）并在超时后强制 terminate + 继续 reconcile（reconcile 是纯同步本地操作，与 pnpm 退出无关，可在超时路径安全执行）；
  2. 升级内置 pnpm（11.7.0 → 最新，修复 Electron 子进程 close 事件问题）；
  3. reconcile 与 pnpm 解耦：pnpm 阶段完成后（lockfile 已写）立即执行 reconcile，不依赖进程 exit 事件。
• 本机 workaround 已落地：dsh-plugin-add-fix.ps1（超时检测 + 精准 kill add 进程链 + 手动 reconcile 追加 bundles，热生效）。

[ccc0zl]

<#
dsh-plugin-add-fix.ps1 - workaround for the "dsh plugin add" hang defect

Background: the DSH built-in pnpm 11.7.0 (running under
ELECTRON_RUN_AS_NODE=1) loses the child-process 'close' event for build
scripts on Windows. dsh plugin --profile X add Pkg completes the
install phase (dependencies + lockfile are written), then pnpm prints
"Done in ..." and never exits -> the dsh CLI (which has no
idleTimeoutMs) waits forever -> the platform reconcile never runs ->
the package's dsh.bundle is never appended to dsh.profile.bundles, so
the plugin "installs" but never loads.

What this script does:
1. Runs dsh plugin add in the background with a timeout (default 90s)
2. On hang: kills the stuck pnpm / dsh CLI process chain (only the
one-shot add processes; it never touches the running DSH GUI)
3. Regardless of hang or not, performs a manual reconcile (equivalent
to operations.js reconcile): if the package is in dependencies and
node_modules has dsh.bundle.patch -> append it to
dsh.profile.bundles (DSH's dsh-hmr hot-applies it, no GUI restart)

Usage:
powershell -ExecutionPolicy Bypass -File dsh-plugin-add-fix.ps1 -Profile desktop -Package dsh-hot-installer
powershell -ExecutionPolicy Bypass -File dsh-plugin-add-fix.ps1 -Package @linxin666/dsh-web-all -TimeoutSec 120

After add, the plugin should appear in the GUI plugin panel within
15-30s; if not, check ~/.dsh/logs/dsh-hot-installer/dsh-hot-installer.log
#>
param(
[string]$Profile = "desktop",
[Parameter(Mandatory = $true)][string]$Package,
[int]$TimeoutSec = 90
)

$ErrorActionPreference = "Stop"
$profileDir = Join-Path $env:USERPROFILE ".dsh\profiles$Profile"
$manifestPath = Join-Path $profileDir "package.json"

if (-not (Test-Path $profileDir)) { throw "profile not found: $profileDir" }
if (-not (Test-Path $manifestPath)) { throw "profile manifest not found: $manifestPath" }

Write-Host "==> dsh plugin --profile $Profile add $Package (timeout ${TimeoutSec}s)"

--- record pre-add state ---

$before = Get-Content $manifestPath -Raw | ConvertFrom-Json
$hadDep = $null -ne $before.dependencies.$Package
$hadBundle = @($before.dsh.profile.bundles) -contains $Package

--- run add in background with timeout polling ---

$log = Join-Path $env:TEMP ("dsh-add-" + ($Package -replace "/", "_") + ".log")
$job = Start-Job -ScriptBlock {
param($p, $pk, $l)
dsh plugin --profile $p add $pk *>&1 | Tee-Object -FilePath $l
$LASTEXITCODE
} -ArgumentList $Profile, $Package, $log

$deadline = (Get-Date).AddSeconds($TimeoutSec)
$stuck = $false
while ((Get-Date) -lt $deadline) {
if ($job.State -ne "Running") { break }
Start-Sleep -Seconds 3
}
if ($job.State -eq "Running") {
$stuck = $true
Write-Warning "!!! add did not finish within ${TimeoutSec}s - known defect hit (pnpm build child close-event loss)"
Write-Warning " cleaning up the stuck pnpm / dsh CLI process chain (running GUI is untouched)..."

# kill the add-related chain: pnpm.mjs add, cli.js plugin add, dsh.cmd
$victims = Get-CimInstance Win32_Process | Where-Object {
    $_.CommandLine -and (
        ($_.CommandLine -match "pnpm\.mjs" -and $_.CommandLine -match "add\s+$([regex]::Escape($Package))") -or
        ($_.CommandLine -match "cli\.js" -and $_.CommandLine -match "plugin" -and $_.CommandLine -match "add\s+$([regex]::Escape($Package))") -or
        ($_.Name -eq "cmd.exe" -and $_.CommandLine -match "dsh\.cmd.*add\s+$([regex]::Escape($Package))")
    )
}
foreach ($v in $victims) {
    try { Stop-Process -Id $v.ProcessId -Force -ErrorAction SilentlyContinue; Write-Host ("  killed pid " + $v.ProcessId + " (" + $v.Name + ")") } catch { }
}
Stop-Job $job -ErrorAction SilentlyContinue
Remove-Job $job -Force -ErrorAction SilentlyContinue

} else {
$jobOutput = Receive-Job $job -ErrorAction SilentlyContinue
Remove-Job $job -Force -ErrorAction SilentlyContinue
$code = @($jobOutput)[-1] # last line = $LASTEXITCODE
if ($code -ne 0) { Write-Host "add exit code: $code (see log $log)" }
}

--- manual reconcile (equivalent to operations.js reconcile L44-72) ---

Start-Sleep -Milliseconds 500
$after = Get-Content $manifestPath -Raw | ConvertFrom-Json
$nowDep = $null -ne $after.dependencies.$Package
$nowBundle = @($after.dsh.profile.bundles) -contains $Package

if ($nowDep -and -not $nowBundle) {
$pkgJson = Join-Path $profileDir "node_modules$Package\package.json"
if (Test-Path $pkgJson) {
$m = Get-Content $pkgJson -Raw | ConvertFrom-Json
if ($m.dsh.bundle.patch) {
$after.dsh.profile.bundles = @($after.dsh.profile.bundles) + $Package
$json = $after | ConvertTo-Json -Depth 20
[System.IO.File]::WriteAllText($manifestPath, $json, (New-Object System.Text.UTF8Encoding($false)))
Write-Host "OK: manual reconcile done - $Package appended to dsh.profile.bundles (total $(@($after.dsh.profile.bundles).Count) bundles)"
Write-Host " dsh-hmr will hot-load the plugin; if it does not appear within 30s check ~/.dsh/logs/dsh-hot-installer/dsh-hot-installer.log"
} else {
Write-Warning " $Package has no dsh.bundle.patch - it is a plain dependency, not a profile layer; not added to bundles"
}
} else {
Write-Warning " $Package not found in node_modules - add did not complete, dependency may not be installed"
}
} elseif ($nowBundle) {
Write-Host "OK: nothing to fix - $Package is already in dsh.profile.bundles"
} else {
Write-Warning " $Package is neither in dependencies nor bundles - add did not take effect, see $log"
}

--- summary ---

Write-Host ""
Write-Host "==> Summary"
Write-Host (" add hang handled: " + $(if ($stuck) { "yes (stuck processes cleaned)" } else { "no (add completed normally)" }))
Write-Host (" dependency written: " + $(if ($nowDep) { "yes" } else { "no" }))
Write-Host (" bundle registered: " + $(if ($nowBundle) { "yes" } else { "no" }))
Write-Host " manifest: $manifestPath"

[antst]

The same symptom on macOS with the plain Node CLI, and a pnpm fix that may be relevant here

We have seen this three times on GitHub-hosted macOS arm64 runners, outside Windows and Electron: Node 22.23.2, dsh 0.2.1-alpha.2 installed globally with pnpm, and pnpm 11.18.0 on PATH.

dsh plugin --profile dashi add @deepseek-ai/dsh-llm-replay@0.2.1-alpha.2

Each time pnpm printed its summary (Done in 1.2s, 1.9s and 2.3s, using pnpm v11.18.0) and the command was still running when our test stopped it after 180 seconds (1, 2, 3). In the second and third, the command's process group was listed just before that. The third:

PID   PPID  PGID  state  process
2435  1592  2435  S<s    node .../@deepseek-ai/dsh/lib/bin.js plugin --profile dashi add ...
2478  2435  2435  S<     node .../tools/bin/pnpm add @deepseek-ai/dsh-llm-replay@0.2.1-alpha.2

pnpm itself had not exited, and the CLI was still its parent. In both, the profile's three .plugin-manager/logs/operation-*/pnpm.log files were empty. The profile was fresh and already held one bundle added from a local tarball, with two of that bundle's dependencies overridden to local tarballs. On these versions the same test job completed in 29 other macOS runs and 39 Ubuntu runs, issuing this add three times in each. We have no reliable reproduction: a loop of 200 such adds did not hang, but it used the registry build of the bundle, no overrides and Node's --report-on-signal options, and after its first iteration nothing was downloaded, whereas the three hanging adds downloaded 8, 8 and 7 packages.

pnpm. pnpm/pnpm#12297 and pnpm/pnpm#13617 describe pnpm not exiting after Done in: a fetch that completes after cleanup re-creates the worker pool, which keeps the event loop alive. pnpm/pnpm#13226 fixed it, first released in 11.23.0. In the published bundles, finishWorkers drops the pool reference in 11.7.0, 11.18.0, 11.21.0 and 11.22.0 and keeps it in 11.23.0 and 11.28.5. pnpm/pnpm#13617 also includes a reproduction that hangs on 11.7.0 every time. The pnpm versions in this report (11.7.0) and in #8922 (11.21.0) predate that fix. apps/desktop/package.json pins pnpm 11.7.0 at dsh-v0.2.1-alpha.1 and 11.28.5 at dsh-v0.2.1-alpha.2. We did not capture pnpm's handles, so this fits what we saw but is not shown to be the cause, in our runs or in the reports here. Our job has since passed five times on macOS with pnpm 11.28.5, which is too few runs to conclude anything.

DSH. On 0.2.1-alpha.2 the wait is as the report above describes. With execution: 'cli' (apps/cli/src/plugin.ts:84-91) pnpm inherits stdio (packages/boot/plugin-manager/src/operations.ts:357-364), so the silence bound is never armed (:376-384, :412-414), the wait for pnpm's exit has no limit (:421-422), and the bundle selection is reconciled only after a zero exit (:465, :522). The README states this as intended: the CLI run "stays unbounded for its operator to interrupt" (packages/boot/plugin-manager/README.md:102).

Two questions. When pnpm has printed its summary but does not exit, is interrupting and re-running the supported recovery, and does the re-run reconcile what the first run never reached? And for callers with no operator (CI, scripts), would an opt-in limit on dsh plugin be acceptable? We have not tested interrupt-and-rerun or the manual reconcile posted above.

[argszero]

Reading the wait path: this one isn't dsh's hang, and the timeout you're asking for is two edits away

@antst's cross-platform reproduction is what made me go read the code, because it removes the two explanations I would otherwise have reached for (Electron and Windows). I read the CLI's package path on a 0.2.x tree (5badb15009) and the wait is not where the hang is.

dsh already awaits the process's own exit, not a piped stdio

packages/boot/plugin-manager/src/operations.ts:418-422:

// execa resolves its promise only once the piped stdio has ended, so the
// process's own exit — the run's completion — is read from the raw child. A
// spawn failure settles without one.
const settled = Promise.allSettled([child])
await Promise.race([exited, settled])

and exited is once(child.nodeChildProcess, 'exit') (:366) — the raw exit event, deliberately not execa's promise, precisely so a descendant holding the pipes open cannot stall the run. So if pnpm reached exit, the CLI would proceed to the reconcile stage. Your own process tree shows the opposite: the pnpm process (18380) is still alive, CPU plateaus across samples, no children, no sockets. The wait is not stuck on dsh — the child never finishes exiting. That is consistent with @antst's runs too (Done in 1.2s … still running at 180s, process group listed).

So the question worth chasing is what keeps pnpm's event loop alive after it has printed its summary, not dsh's wait.

"The CLI should have a timeout" — true, but it is not one edit

The bound exists and its default is generous:

• packages/boot/plugin-manager/src/index.ts:184 — idleTimeoutMs defaults to 600000, and :690 passes it into the run.
• apps/cli/src/plugin.ts:84-91 — the CLI's option block sets execution: 'cli' and omits idleTimeoutMs, so on this path operations.ts:377 returns immediately (options.idleTimeoutMs === undefined).

But supplying it would still not arm anything, because arming is gated on captured output:

// operations.ts:412-414
// Inherited descriptors hand pnpm the terminal, so there is no captured output
// for a silence bound to observe: it would fire on a healthy run.
if (collectors.length > 0) armIdle()

With execution: 'cli', all three descriptors are 'inherit' (:359-362), so child.stdout/child.stderr are null, collectors is empty (:405-408), and the bound is structurally unreachable — the option's own doc comment already says so (:46-52): "A run with inherited descriptors captures nothing and is never bound." A CLI-visible silence bound needs both: the option passed in apps/cli/src/plugin.ts, and an idle arm that does not depend on piped stdio — plus a decision about what "silence" even means when output goes to the user's terminal rather than through onOutput. That is why the GUI path is bounded and this one is not: index.ts:688 uses execution: 'service', which pipes.

I'd suggest the issue's expected-result bullet name both edits. A fix that only threads idleTimeoutMs through the CLI would look right in review and still hang.

The plugin boundary, since this thread's label invites it

This one is not available to a plugin, and I want to be explicit rather than hint: the failure is a child process of the CLI, which runs outside any dsh session — there is no ctx, no hook, and nothing a mounted plugin could veto or wrap. The only plugin-adjacent half is the residue, "installed but never bundled": nothing today compares a profile's dependencies against its dsh.profile.bundles, so a package that declares dsh.bundle and never lands in the bundles list leaves no runtime trace at all. That comparison is readable from the profile directory and is worth its own check — I've noted it as a candidate rather than claiming an existing asset covers it, because the ones I ship look at bundles that were skipped, and a package that never entered the list produces no such entry.

[argszero]

A follow-up on the state this leaves behind, since the diagnosis here was already narrowed: dsh plugin add installs through the package manager and reconciles afterwards, so when the CLI never returns the package stays in dependencies and pnpm-lock.yaml while dsh.profile.bundles is never written. The plugin is installed and never selected — and that is the one shape nothing in the running application can report, because the only artifact of the loss is a list the package is missing from.

@argszero/dsh-activation-doctor@0.3.0 now reports it (npm: @argszero/dsh-activation-doctor, source: https://github.com/argszero/dsh-activation-doctor). It is a doctor, not a fix — the upstream ordering is still yours to change — but the state is no longer silent:

dsh: activation-doctor: 1 package installed but never selected (report: $DSH_HOME/logs/activation-…log)
  unselected @acme/dsh-hot-installer: installed 0.5.4 — declares dsh.bundle.patch ./cordis.patch.yml — absent from dsh.profile.bundles (resolved from the profile)

The report carries the two lists and the path to follow: add the name to dsh.profile.bundles, or re-run the install so reconcile runs.

Two things about the implementation that were not obvious, in case they matter to a first-class check upstream:

• The qualifier is what keeps it from being noise. A profile's dependencies and its dsh.profile.bundles are different lists on purpose, so "a dependency that is not in the bundle list" would report every ordinary dependency. The bundle claim is read from each package's own manifest, the way bundleManifest reads it — dsh.bundle.patch defined — and a dependency that declares none is inspected and passed over. A dsh.bundle.patch that exists but is neither a path nor a list of paths is reported too, since app-boot throws while loading it and the profile loses the package either way.
• Resolution mirrors resolveBundleDir: the installation anchor is searched before the profile, so an in-box package is never mistaken for the profile-local copy. Only package.json files are read; nothing is imported. Dependencies the audit cannot resolve, or whose manifest it cannot read, are listed as coverage (coverage: 2 of 11 dependencies could not be inspected) rather than as findings — an incomplete audit must not read as a broken installation.

One defect was worth reporting on its own, because it was mine and it was invisible to every fixture that omits the key: dependencies in a profile package.json is an npm map ({"@acme/plugin": "^0.5.4"}), not the array dsh.profile.bundles is. The first cut read it with the list reader, so the parse failed on any real profile-manifest and took the pre-existing composition diff down with it — a regression that only an end-to-end arm built from a manifest npm would have written could catch. Fixed in 0.3.0; plugin-manager reads the field the same way (Object.keys(manifest.dependencies ?? {}), packages/boot/plugin-manager/src/operations.ts).

Verified on the published lines 0.1.7-rc.2, 0.2.0-rc.2 and 0.2.1-alpha.2; the arm is on by default and can be switched off with installed: false.

[aavainer]

Reproduced on 0.2.0-rc.2 (Windows 11): dsh plugin add @argszero/dsh-skill-residency fails with os error 5 — «Failed to save the manifest file: access denied» — and the profile bundles never reconcile. This is exactly the «installed but not loaded» symptom.

Workaround that worked for us: manually edit profiles/web/package.json (add the package to both dependencies and dsh.profile.bundles), run pnpm install, then restart DSH. The plugin then loads and injects correctly.

So on Windows the plugin-manager's pnpm add step cannot write the manifest (handle/permission issue), while a plain pnpm install and a manual manifest edit both succeed. Looks like a Windows-specific manifest-write bug in the plugin manager, not a package problem.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.