[Bug][Windows] 0.1.7-rc.2: 窗口关闭死锁 / ACL沙箱权限崩溃(Win32 5) / 子代理卡片失踪与硬锁8并发 / SSRF误杀TUN代理

[le2412644848]

运行环境

• 操作系统：Windows 10 / Windows 11
• 客户端版本：DeepSeek Harness Desktop 0.1.7-rc.2

在 Windows 桌面端使用过程中发现 4 个较为严重的官方实现缺陷，均已定位到底层代码与具体触发点，恳请官方团队排查修复：

---

问题 1：【严重】关闭窗口后后台进程幽灵死锁，无法再次启动（必须杀进程或重启）

• 现象：
  点击窗口右上角“X”关闭后，界面关闭，但后台残留 5~6 个 DeepSeek Harness.exe 进程。再次双击桌面快捷方式无任何反应，必须手动去任务管理器结束进程甚至重启电脑。
• 源码根因：
  1. lib/main.js 中主窗口 close 事件被 event.preventDefault() 拦截，默认执行 hideMainWindow(window) 试图隐藏至托盘；但 Windows 下 Chromium 常因 Unable to create status tray icon 导致托盘根本没有图标，用户无法点击唤回；
  2. 后台隐藏进程持续霸占 singleInstanceLock。用户二次启动时新进程被拦截直接退出；而发送给旧进程的 second-instance 唤醒事件又被 if (window === mainWindow && !enteredWorkspace) return; 判定阻断，导致二次启动被静默吞掉。
• 修复建议：
  • 托盘图标创建失败时直接 fallback 调用 app.quit()；
  • 增加“点击关闭直接退出”设置选项；
  • 移除 second-instance 中的 !enteredWorkspace 阻断，收到二次启动事件时强制执行 window.restore(); window.show(); window.focus();。

---

问题 2：【严重】Windows 沙箱 ACL 权限踩踏，终端命令执行必崩（Win32 Error 5）

• 现象：
  常规 Windows 用户权限（非管理员提权）下执行命令必报：
  Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)，导致命令及后续操作中断。
• 源码根因：
  0.1.7 针对 Windows 引入的沙箱机制（dsh-sandbox-windows-acl）在 workspace-write 模式下直接调用底层 Win32 API SetNamedSecurityInfoW 试图写入 Low-Integrity SACL 标签；普通用户进程默认无 SeSecurityPrivilege 特权，被 Windows 内核以 Win32 5 (ERROR_ACCESS_DENIED) 拒绝。
• 修复建议：
  • 捕获特权不足异常并优雅降级（fallback 到标准 DACL 或跳过 SACL 降权标签），禁止直接未捕获异常中断主流程。

---

问题 3：【高】子代理设置卡片前端失踪，后端默默硬编码卡死 8 并发

• 现象：
  旧版本在设置面板中可以调节子代理并发数；0.1.7-rc.2 中设置面板里的「子代理（Subagent）」卡片彻底失踪，用户无处调节。主 Agent 一旦并发调起超过 8 个子代理，后台直接报错：subagent limit reached (active child limit: 8)。
• 源码根因：
  1. @deepseek-ai/dsh-client-ui-settings-subagent（lib/client.js）的前端挂载条件被改为了：
     ctx.configForms.whileServed([SUBAGENT_NS, SUBAGENT_MODEL_SELECTION_NS], ...)；
  2. 桌面端 Profile 的启动配置（cordis.patch.yml）中漏掉了 subagent-model-selection-settings 服务的注册；
  3. 导致条件永远不满足，整个子代理设置卡片被前端完全隐藏；
  4. 而内核 @deepseek-ai/dsh-subagent（lib/index.js）在未接收到配置时硬编码 default(8)，导致用户在无感知情况下被强锁 8 并发。
• 修复建议：
  • 在桌面端 Profile 默认补齐 subagent-model-selection-settings 服务挂载；
  • 前端挂载条件解耦，即使缺少模型选择服务，也应允许渲染基础的「并发限制 / 递归深度」设置。

---

问题 4：【中】网络请求 SSRF 防御过于死板，误杀开发者本地代理与 TUN 模式

• 现象：
  电脑开启主流网络代理（如 TUN 模式）时，内置网页抓取与搜索直接报错：
  Error: URL hostname "..." resolves to a non-public IP address。
• 源码根因：
  网络请求层对所有非公网 IP 强制拦截，直接将 TUN 虚拟网卡分配的合法 Fake-IP（198.18.0.0/15）及本地回环（127.0.0.1）误判为“恶意私网攻击”。
• 修复建议：
  • 允许在配置中放行本地回环及常见 Fake-IP 网段；
  • 区分服务端 SSRF 校验与桌面客户端代理流量。

[Sabraker]

补充一份独立复现与证据（与「问题 2」同一故障，但根因指向不同，请维护者以证据为准）

运行环境

• Windows 11 25H2（注册表 ProductName 仍报 Windows 10 Home China），build 26200.7840，AMD64；工作区所在 D: 为 NTFS
• 桌面版 0.1.7-rc.2（安装包签名主体 Hangzhou DeepSeek Artificial Intelligence Co., Ltd.）
• 同一 $DSH_HOME 下的全局 CLI @deepseek-ai/dsh 0.1.5-rc.2 作对照
• Node v24.21.0 / npm 11.19.0；Windows PowerShell 5.1.26100.7705（未安装 pwsh 7）
• 账户非提升（BUILTIN\Administrators 为 deny-only），Medium 完整性，无 S-1-5-12

复现：workspace-write 下任意 pwsh 调用 100% 失败且命令不执行：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\dev\dsh-workspace)

把会话权限模式切到 danger-full-access 后，同一命令立即正常 ⇒ 失败点在 ACL 授予阶段，而非命令本身。

三条与「缺少 SeSecurityPrivilege / 写 SACL」不符的证据

1. 失败调用写的是 DACL，不是 SACL。 dsh-sandbox-windows-acl/lib/types-*.js：
   api.setNamedSecurityInfoW(path, /*ObjectType=*/1, /*SecurityInfo=*/4, null, null, newAcl, null)
   其中 1 = SE_FILE_OBJECT、4 = DACL_SECURITY_INFORMATION；SACL 需 0x10、LABEL 需 0x8，都没有传。
2. 期望的 ACE 已经存在，且与代码里的掩码逐位一致。 icacls 显示 S-1-4-441113627-748341310:(OI)(CI)(W,D,DC)，.NET FileSystemRights = 0x00110156；而代码里 const GRANT_MASK = 1114454（即 0x110156）⇒ 掩码完全相同，不是"试图新增一条 ACE 却加不上"。
3. 同用户、非提升进程手动把相同 DACL 原样回写是成功的（该进程父进程就是 DeepSeek Harness.exe）⇒ 这个令牌具备 WRITE_DAC。因此问题应落在桌面版 Host 侧执行 grantWrite 那次调用所处的令牌/进程上下文，而不是"普通用户改 ACL 权限不足"这一整类。

两条独立对照

4. 同一工作区、同一用户、同一 $DSH_HOME 下，web profile（CLI 0.1.5-rc.2，dsh web）从未出现该错误。
5. 从 resources/app.asar 抽出桌面版 0.1.7 的 dsh-sandbox-windows-acl 与 npm 全局 0.1.5 对比：lib/runner.js 两侧都是 manageDacls: false（ACE 由调用方先授），且 AclSandbox.init() 顺序一致 —— 先 grantWrite() 再 createRestrictedToken()（0.1.5 L988-1004 / 0.1.7 L999-1015）⇒ 不是顺序回归。

已在本机验证的规避方式

会话权限模式切到 danger-full-access 后一切正常（read-only / workspace-write 仍会在 ACL 步骤失败）。

给修复的建议

既然 ACE 数据、掩码与同类 DACL 写入都验证正常，建议优先排查桌面版 Host 内 grantWrite 调用所处的令牌/进程上下文（例如是否在受限令牌或 Electron 子进程上下文中执行），而不是把它当成 SACL 特权问题。