[bug] Native folder dialog truncates paths at characters whose UTF-16 low byte is 0x00 ("05agent开发" → "05agent")

[chouyi-tech]

Status: 用户报告；已静态定位根因并本地修复验证（实机复验待确认）

现象

在 Windows 的 dsh Web GUI 中切换 / 创建 workspace，点击原生文件夹选择对话框（Select Workspace Directory）选中目录后，路径中的部分汉字被截断，导致 workspace 创建失败：

workspace create failed: workspace-invalid-path: cannot create a workspace at
"F:\01_workplace\05agent": ENOENT: no such file or directory, realpath 'F:\01_workplace\05agent'

• 用户实际选择的目录是 F:\01_workplace\05agent开发，报错路径中**「开发」被整体截断**——从「开」（U+5F00）开始及其后的所有字符丢失。
• 用户经验观察：纯英文 + 数字、以及部分纯中文目录名不受影响；仅"中英混排"目录名出问题。
• 该行为与目录名中具体包含哪些字符有关，并非"混排"本身（见根因分析：触发条件是字符码位的低字节为 0）。

环境

• 仓库：deepseek-ai/deepseek-harness
• HEAD：47f943859bef60e4160492346772ded9b24f765a（Merge pull request #2519 from deepseek-harness/feat/npm-public）
• 平台：Windows 10 Pro 10.0.19045；Node.js v24.16.0；pnpm 11.21.0
• 运行方式：源码检出 + pnpm dsh web（tsx 源码模式；目录选择 worker 同样走源码分支 import.meta.url.endsWith('.ts')，见 win32-dialog-host.ts:27-30）
• 复现路径：Web GUI → 切换 workspace → 原生目录选择器 → 选择含"低字节为 0"字符的路径 → 报 workspace-invalid-path 错误

代码路径

客户端包装：packages/client/runtime/src/client/workspaces/service.ts:212

throw new Error(`directory picker failed: ${response.result.error.message}`)

路径字符串读取：packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-44，调用点在 :159（IShellItem::GetDisplayName(SIGDN_FILESYSPATH) 的返回值）：

function readUtf16(koffi: Koffi, address: unknown): string {
  const bytes = Buffer.from(koffi.view(address, 32768))
  let end = 0
  while (end + 1 < bytes.length && bytes[end] !== 0) end += 2
  return bytes.toString('utf16le', 0, end)
}

根因分析

readUtf16 用单字节判 NUL 来定位 UTF-16LE 字符串的结束位置，这对 ASCII 成立，但对任意"码位低字节为 0"的字符会提前截断：

• Windows 路径是 UTF-16LE 编码。ASCII 字符（如 a，U+0061）的低字节非 0（61 00），只有真正的字符串终止符 00 00 会命中偶数字节偏移处的 0x00，因此单字节检查在纯 ASCII 下是正确的。
• 但码位形如 U+XX00 的字符，其 UTF-16LE 字节序为 00 XX——偶数字节偏移处恰好是 0x00，被误判为字符串结束。
• 例：「开」= U+5F00 → 字节 00 5F。路径 F:\01_workplace\05agent开发 中，「开」从第 14 字节开始，扫描在 bytes[14] === 0 处停止，结果 toString('utf16le', 0, 14) = "F:\01_workplace\05agent"——与用户报错完全一致。

字节级复现（node 模拟，路径 F:\01_workplace\05agent开发）：

const path = "F:\\01_workplace\\05agent开发";
const bytes = Buffer.from(path, "utf16le");

// 旧逻辑（单字节判 NUL）
let end = 0;
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;
console.log(bytes.toString("utf16le", 0, end)); // "F:\\01_workplace\\05agent"  ← 截断

// 正确逻辑（UTF-16 单元双字节全 0 才算终止）
end = 0;
while (end + 1 < bytes.length && !(bytes[end] === 0 && bytes[end + 1] === 0)) end += 2;
console.log(bytes.toString("utf16le", 0, end)); // "F:\\01_workplace\\05agent开发"  ← 完整

受影响字符范围：所有低字节为 0 的码位，包含大量常用 CJK 汉字（如「一」U+4E00、「开」U+5F00）、部分谚文音节等。因此：

• 用户"纯中文目录没事"的经验是巧合——其目录名（如「资料」「疲劳问卷」）恰好不含此类字符；任何包含「一」「开」等字的纯中文目录同样会截断。
• 正确表述：目录名（或路径任意段）包含低字节为 0 的字符即触发。

影响面：全仓库 grep 确认仅此一处存在该扫描模式（bytes[end] !== 0 循环仅出现于 win32-dialog-bindings.ts:40）；koffi 自身的 str16 处理不受影响。修复隔离、风险低。

安全 / 正确性影响（目录混淆）：若截断后的前缀路径存在，realpath 校验会通过，workspace 将被创建在用户未选中的目录上，agent 随后在错误目录中读写、执行——属于路径混淆（path confusion）。两种场景对比：

• 前缀不存在（本报告实测场景）：F:\01_workplace\05agent 不存在 → 创建失败，表现为功能缺陷（拒绝服务级）；
• 前缀存在（推演场景）：用户选择 F:\docs\开单系统，截断为 F:\docs（存在）→ realpath 通过，workspace 静默创建在 F:\docs，agent 在错误的目录上工作，危害更大且无任何告警。

期望行为

• 目录选择器返回的路径必须原样完整保留（如 F:\01_workplace\05agent开发），不能丢失任何字符。
• workspace 创建目录必须与用户在对话框中选中的目录严格一致，不允许任何静默的路径改写（截断 / 规范化），杜绝"选中 A、实际在 B 建 workspace"的目录混淆。
• 终止符判定应基于完整的 16 位 NUL 单元（00 00），而非单个字节。

建议

1. 修复 readUtf16 的终止符检查（已验证可修复截断）：

   function readUtf16(koffi: Koffi, address: unknown): string {
     const bytes = Buffer.from(koffi.view(address, 32768))
     let end = 0
     // The terminator is a full 16-bit NUL unit, not a zero low byte: a code
     // point like U+5F00 (开) has a zero low byte, and a single-byte check
     // truncates the string at the first such character.
     while (end + 1 < bytes.length && !(bytes[end] === 0 && bytes[end + 1] === 0)) end += 2
     return bytes.toString('utf16le', 0, end)
   }

2. 补充单元测试：覆盖含低字节 0 字符的路径（05agent开发、「一」开头、纯 CJK、谚文等），以及纯 ASCII、纯 CJK（无 00 低字节）、空串、超长路径（32768 字节 koffi.view 上限边界）等用例；建议同时覆盖源码分支与 built worker.cjs 分支。

3. 后续可考虑抽查仓库其它手工读取 Win32 字符串的路径（本次 grep 未发现同类模式），防同类问题扩散。

未确认项

• 本机已应用上述本地补丁（win32-dialog-bindings.ts），但用户实机复验结果待确认（本报告撰写时尚未收到复验反馈）。
• 报告基于源码静态分析 + 字节级模拟复现；未运行仓库测试套件（vitest）验证补丁对既有用例的影响（改动仅限终止符判定，语义上只放宽了扫描，不改变纯 ASCII 行为）。
• built（CJS worker.cjs）产物由同一源码编译，推断同样受影响；未对 built 产物实测。
• 非 CJK 场景（U+XX00 类字符在韩文/日文中的出现）未逐一实测。
• 「目录混淆」场景（截断后前缀路径存在、realpath 通过、workspace 建在错误目录）为静态推演，未实机验证。