Windows11系统Pswh工具调用失败导致后续聊天无法进行

[88514205-oss]

IN{
"command": "pwd; Get-Location",
"description": "查看当前工作目录"
}
OUT
Interrupted: interrupted
后续报错为：
本轮运行失败Cannot read properties of undefined (reading 'prepare')
UNKNOWN

[denial123789]

这里其实有两个需要分开的故障：

1. OUT Interrupted: interrupted 表示这次工具调用被 Harness 的取消/中断路径终止；它本身不能证明 PowerShell 命令语法失败。pwd; Get-Location 在 PowerShell 中是可执行的（pwd 是 Get-Location 的别名）。
2. 后面的 Cannot read properties of undefined (reading 'prepare') 是宿主/会话继续处理时出现的 JavaScript 空引用。它不像 PowerShell stderr，也不应该通过扩大沙箱权限解决。

建议用这个最小矩阵定位：

A. 判断是否只损坏了当前 Session

• 保留当前 Session，不再继续发送会产生副作用的命令。
• 新建一个全新会话，在同一 workspace 运行：

Get-Location
$PSVersionTable.PSVersion
$ExecutionContext.SessionState.LanguageMode

如果新会话正常而旧会话每次都报 prepare，请导出旧 Session，并在报告里标明错误发生在“中断后继续同一会话”。

B. 判断是否是 Host 运行时状态

完全退出并重新启动 dsh web，再用一个新的会话执行同样三个只读表达式。如果重启恢复，记录终端中 prepare 错误前后的完整 stack；仅有 UI 的 UNKNOWN 不足以定位具体 service。

C. 判断是否是 profile/plugin 组合

dsh --profile web --dump-config
$env:DSH_HOME = Join-Path $env:TEMP "dsh-clean-profile"
npx @deepseek-ai/dsh web

在临时 clean profile 里只配置模型，选择一个小型临时 workspace 后复现。测试完执行：

Remove-Item Env:DSH_HOME

如果 clean profile 正常，逐个恢复第三方插件；优先检查接管 Session persistence/query、工具事件或 PowerShell tool 的插件。

报告时请补充 Node、DSH、PowerShell 版本，启动终端里的完整 prepare 堆栈、是否手动点击 Stop/Interrupt、当前 Session 导出，以及新会话/重启/clean profile 三组结果。不要上传 API key 或未脱敏的完整配置。

可直接对照这份独立的 Windows 支持边界和故障矩阵：DeepSeek Harness on Windows。其中也说明了 pwsh 每次调用是新进程、如何检查 active platform rows，以及为什么工具参数校验、PowerShell 执行和 Windows sandbox 必须分层判断。

[argszero]

这个报错字符串是我们一个已知家族的第三次现场报告——前两次：#1337（taonokenshin，Windows 11）、#1633（NuanFeng801，Windows 10）。Cannot read properties of undefined (reading 'prepare') 不是 PowerShell 命令的问题，也不是沙箱权限问题，而是 profile 里出现了 @deepseek-ai/dsh-tools / @deepseek-ai/cordis 的重复物理拷贝。

机制（当前 master 47f9438 已复核）

• TOOL_RUNTIME_SCHEDULER 是 unique symbol（packages/core/tools/src/index.ts:466）——每份物理拷贝在磁盘上求值都得到不同的 Symbol 实例。
• 崩溃点 packages/core/agent-loop/src/tool-calls.ts:169：ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)——ctx.tools 落到外来拷贝的实例上 → undefined.prepare → 本轮失败（UNKNOWN）。
• 设计上本应防住这个洞：packages/boot/app-boot/src/profile.ts:133-137 的 hoisted + 缺失 peer 回落 profiles/node_modules 安装闭包回退（:204-208 符号链接），让所有外部插件共享安装的单一 cordis/dsh-tools 实例。顶层 dependencies 被塞进副本后，pnpm 平铺出第二份 → 回退被绕过。

你观察里的两个故障是独立的

1. OUT Interrupted: interrupted —— 工具调用的取消/中断路径（client 端渲染见 client/ui-conversation/src/client/conversation-nodes/tool.ts:204），与 PowerShell 语法无关（pwd 就是 Get-Location 的别名）。
2. 之后的 prepare 崩溃 —— 家族签名。它发生在取消之后的下一次工具调用上（或会话恢复路径上），是重复拷贝的 Symbol 错配。

"后续聊天无法进行" 的机制：会话毒化放大器

崩溃前 appendToolCall 已把 tool_calls 事件提交进会话（tool-calls.ts:168，dispatch 之前）→ 崩溃后该会话残留孤儿 tool call id → 恢复时 llm-deepseek/src/serialize.ts:105-140 原样重放这个悬挂 id（无配对校验）→ DeepSeek 持续 400 INVALID_REQUEST → 这个会话永久卡死（纯文字没问题，因为不走工具重放路径）。这正是 #1593 家族（序列化毒化）与 #1337/#1633 家族（调度器崩溃）的交汇点。

直接回答 denial123789 的定位矩阵

• 若新会话的工具调用也报 prepare 崩溃 → 这是全局问题（profile 级重复拷贝），不是会话级损坏。修复：在 profile 目录（~/.dsh/profiles/web 或 profiles/<name>）执行 pnpm why @deepseek-ai/dsh-tools 找出谁带进来的，移除顶层重复依赖 + pnpm dedupe（或 pnpm.overrides 固定单一版本）。
• 若新会话工具调用正常、只有旧会话卡死 → 旧会话已被毒化，导出会话数据后重建即可（会话本身无法自动修复，见 Add a session doctor and versioned migrations #1518/[BUG] 会话日志中一条 tool/result 引用了不存在的 call id，导致该会话所有请求被供应商 400 拒绝，永久不可用 #1593 讨论中的修复工具提案）。

长期修复方向（与 #1337/#1633 帖一致）：① apps/cli/src/plugin.ts 的 reconcilePlugins 增加核心包名单检查臂（顶层 dependencies 命中 dsh-tools/cordis → 明确报错）；② tool-calls.ts:169 加防御检查，调度器缺失时用干净的合成 tool result 收尾而非崩溃——这样一次崩溃不会变成"会话永久毒化"。这两处社区已有完整蓝图，等上游 PR 通道重新开放即可落地。

[sjh9714]

Minimal 在 Windows 起不来是官方已知缺口（运行时缺 win32 进程探测器）。写了个插件补上了，装完之后选 minimal-windows 预设就是持久 Git Bash 版的极简模式。https://github.com/sjh9714/dsh-win32