Windows: pwsh 窗口反复显示并抢占前台焦点

[jian45154]

问题描述

在 Windows 上使用 DSH Desktop 时，Harness 执行 PowerShell 命令会反复打开用户可见的 pwsh 窗口，并将该窗口切换为前台活动窗口。

这会中断用户在其他应用中的键盘输入和鼠标操作；当 Agent 连续执行多个 PowerShell 命令时，焦点会被重复抢占，严重影响正常使用电脑。

复现步骤

1. 在 Windows 11 上从当前 main 启动 DSH Desktop（npm run dev）。
2. 打开任意工作区并创建会话。
3. 让 Agent 执行会调用 pwsh 的工具操作。
4. 观察每次调用时出现的 PowerShell 窗口。

实际行为

• pwsh 窗口对用户可见。
• 窗口会被切换为前台活动窗口。
• 连续工具调用会反复打断用户当前正在操作的应用。

预期行为

DSH Desktop 启动的 Harness、PowerShell 和其他后台工具子进程应保持隐藏，不创建用户可见的控制台窗口，也不应改变 Windows 当前的前台活动窗口。

环境

• OS: Microsoft Windows 11 Pro for Workstations 10.0.26200
• Architecture: Windows x64
• DSH Desktop: current main, commit d8fa20fb9b8aa71fdebbeae9a452e095620818b8
• Node.js: v24.14.1
• npm: 11.16.0
• Electron: 43.4.0
• DSH: 0.1.0-rc.6

初步代码调查

桌面层启动 Harness 时已经设置了 windowsHide: true：

• src/main/runtime/harness-runtime.ts

但 Harness 内部的本地 subprocess 创建路径没有传入 windowsHide：

• deepseek-harness: subprocess-local/src/spawn.ts

Windows ACL sandbox 路径还明确说明，为避免 restricted token 下的 STATUS_DLL_INIT_FAILED，当前有意不使用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE，子进程共享宿主控制台：

• deepseek-harness: sandbox-windows-acl/src/spawn.ts

因此问题看起来发生在 Harness 内部的 PowerShell/subprocess 路径，而不是 DSH Desktop 最外层 Harness 启动过程。以上只是初步判断，仍需要在打包版本和 sandbox/non-sandbox 两条路径分别验证。

建议验证方向

• 分别验证 danger-full-access 与 Windows ACL sandbox 模式是否都会复现。
• 非 sandbox 路径可检查 Windows 下使用 windowsHide: true 是否足够。
• ACL restricted-token 路径不应直接采用已知不兼容的 CREATE_NO_WINDOW；可评估 STARTF_USESHOWWINDOW | SW_HIDE 是否能隐藏窗口，同时保留当前 console/stdio 语义。
• 增加 Windows 回归测试，并在真实 Windows runner 上确认执行 pwsh 不改变前台窗口。

重复问题检查

已搜索本仓库及 deepseek-ai/deepseek-harness 的公开 Issues/PR，暂未找到描述“PowerShell 窗口反复显示并抢占焦点”的现有报告。

[jian45154]

补充调查结果：

问题基本可以定位到 Harness 内部的子进程启动路径，而不是 DSH Desktop 最外层启动 Harness 的代码。

调用链大致为：

DSH Desktop -> @deepseek-ai/dsh -> @deepseek-ai/dsh-subprocess-local -> spawn() -> pwsh

本项目 src/main/runtime/harness-runtime.ts 启动 Harness 时已经设置了 windowsHide: true，因此外层 Harness 进程本身具备隐藏窗口配置。但当前锁定的 @deepseek-ai/dsh@0.1.0-rc.6 依赖中，@deepseek-ai/dsh-subprocess-local 的 Windows spawn() 路径没有传入 windowsHide: true，这可以解释为什么执行 PowerShell 时仍会出现可见窗口并抢占前台焦点。

另外，Windows ACL sandbox 路径的实现明确没有使用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE，原因是受限 token 下可能触发 STATUS_DLL_INIT_FAILED。因此该路径不能直接套用普通 Node.js 子进程的隐藏参数，需要单独评估 STARTF_USESHOWWINDOW + SW_HIDE 等方案，并确认不会破坏 restricted-token 启动和 stdio 行为。

建议：

1. 在 Harness 的 subprocess-local 非 sandbox Windows 路径增加隐藏窗口配置。
2. 对 Windows ACL sandbox 路径设计兼容的隐藏方案，不直接启用已知不兼容的 console flags。
3. 增加真实 Windows runner 回归测试，分别覆盖 danger-full-access 和 ACL sandbox，验证执行 pwsh 时窗口不可见且不会改变当前前台窗口。

本地 DSH Desktop 当前只固定依赖 @deepseek-ai/dsh@0.1.0-rc.6，暂未发现本仓库中可以彻底修复内部 PowerShell 子进程窗口问题的独立改动点。