readUtf16 在 Windows 原生文件夹对话框中会把含低字节为 0x00 的汉字（如 开 U+5F00）的路径截断，导致"添加工作区"报误导性的 ENOENT

[victorwwd]

环境

• 系统：Windows 10/11
• 包：@deepseek-ai/dsh 0.1.0-rc.7（npm 最新版，全局安装），通过 dsh web 启动
• 组件：@deepseek-ai/dsh-host-directory-picker-native（Windows 原生文件夹对话框）

现象

在 Web 界面点击"添加工作区"会弹出 Windows 原生文件夹对话框。用鼠标逐级点选（非手动输入）一个路径中含有"低字节为 0x00 的汉字（U+XX00）"的目录后，创建工作区失败：

workspace create failed: workspace-invalid-path: cannot create a workspace at "D:\PythonProjects\Python\CAN盒子二次": ENOENT: no such file or directory, realpath 'D:\PythonProjects\Python\CAN盒子二次'

期望路径是 D:\PythonProjects\Python\CAN盒子二次开发\can_auto_test，实际在 开（U+5F00）处被静默截断。截断后的路径在磁盘上不存在，服务端 fs.realpath 拒绝是正确行为——但路径在到达服务端之前就已经损坏了。

根因

packages/host/directory-picker-native/src/win32-dialog-bindings.ts 中的 readUtf16：

while (end + 1 < bytes.length && bytes[end] !== 0) end += 2

它按 UTF-16LE 逐字符扫描，把任意偶数偏移处的 0 字节当作字符串终止符。UTF-16LE 中，码位 U+XX00（如 一 U+4E00、刀 U+5200、开 U+5F00、退 U+9000）的存储为 00 XX，循环会在字符串中间停下。UTF-16LE 真正的终止符是连续两个 0 字节，判断必须同时检查两个字节：

while (end + 1 < bytes.length && (bytes[end] !== 0 || bytes[end + 1] !== 0)) end += 2

影响

• 仅 Windows、仅原生文件夹对话框路径。
• 只有路径含此类字符时才触发；纯 ASCII 路径永远不会命中坏字节模式，所以现有测试（大概率用 ASCII 夹具路径）测不出来。
• 报错有误导性：ENOENT 看起来像"用户路径写错"，而不是产品 Bug，遇到的人一般不会上报。

复现步骤

1. Windows 下运行 dsh web。
2. 点击"添加工作区"（弹出原生文件夹对话框）。
3. 用鼠标进入任意路径中含 U+XX00 汉字的目录，例如 D:\PythonProjects\Python\CAN盒子二次开发\can_auto_test。
4. 路径在 开 处被截断，创建工作区失败，报错如上。

修复建议

按上文在 readUtf16 中改一行（终止符判断改为同时检查两个字节）。

[argszero]

Confirmed at source + empirically reproduced — your diagnosis is exactly right, and it resolves discussion #3188 (the CJK directory-name truncation report) whose root cause was misattributed on my part. This is the host-side bug I wrongly ruled out.

1. Verification (rc.7, 99f6f02)

packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-42:

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   // ← low byte only
  return bytes.toString('utf16le', 0, end)
}

The loop treats any even-offset 0 byte as the terminator. For 开 (U+5F00), UTF-16LE stores 00 5F — the scan stops at the low byte, truncating the string mid-path.

Empirical reproduction with the exact characters from #3188 (开发设置 / 插件开发):

current loop: "C:\Codex\开发设置" → "C:\Codex\"           (matches #3188 symptom 1)
current loop: "C:\Codex\插件开发" → "C:\Codex\插件"        (matches #3188 symptom 2: 找不到路径)
fixed loop:   full path both times

Your one-line fix (check both bytes for the true UTF-16LE NUL: bytes[end] !== 0 || bytes[end+1] !== 0) is correct — verified it restores the full path.

2. Self-correction (my #3188 reply was wrong)

In discussion #3188 I source-verified the whole host chain and stated the native Win32 readUtf16 decode was "clean for CJK / no surrogate-pair issue" — that conclusion was wrong. I checked for BMP/surrogate/byte-length issues but not the low-byte-zero pattern (U+XX00), which is exactly what 开发设置's leading 开 (U+5F00) hits. The #3188 symptoms map 1:1 onto this bug, so the earlier "host side is clean → client-side UI" conclusion should be retracted: the truncation is in the native dialog child, before the path ever reaches the wire. My apologies to the #3188 reporter for the misdirection — and thanks to victorwwd (#3291) and dandaogc (#3279, duplicate report) for pinning it precisely.

3. Why this is a nastier bug than it looks

• Silent corruption before the boundary: the path is damaged inside the native dialog child; the host, RPC wire, and workspace validation all behave correctly on a path that was already truncated. No layer downstream can detect it.
• Misleading ENOENT: workspace create failed: … ENOENT: no such file or directory, realpath 'D:\…\CAN盒子二次' looks like a user typo, so affected users (Chinese/Japanese/Korean path environments — many common Han characters are U+XX00) rarely file it. The two independent reports here (plus 【bug report】打开工作区选择目录的时候，目录名字里【开发】之后的字符串会被截断 #3188) are the visible tip.
• The test gap is structural: existing tests use ASCII fixture paths, which can never hit the 00 XX byte pattern. A regression test needs a non-ASCII fixture containing a U+XX00 code point (e.g. 开 or 中 U+4E2D) asserted to round-trip through readUtf16-equivalent decoding — without it, the fix silently regresses.

4. Suggested shape (one PR, ~3 lines + 1 test)

• readUtf16: two-byte NUL check (the fix above).
• Add a unit test with a U+XX00-containing fixture (the bindings are injectable/fakeable per win32-dialog-logic.ts's design — the decode is a pure function of the buffer).
• Optionally: a defensive note in the function doc that UTF-16LE NUL is two zero bytes, not one.

This is the cleanest small-fix candidate I've seen this week: root cause pinned to one byte comparison, one-line repair, deterministic regression test, and it closes three threads (#3188 / #3279 / #3291). When the PR channel reopens, this should be near the front of the queue.

[denial123789]

补充一个面向使用者的判别与验收方法。这个问题和 #30 的 worker crash 外观不同：

• readUtf16 在 Windows 原生文件夹对话框中会把含低字节为 0x00 的汉字（如 开 U+5F00）的路径截断，导致"添加工作区"报误导性的 ENOENT #3291 这条分支：worker 可以正常返回 IPC，但 readUtf16() 把 UTF-16LE 中单个低位 00 当成终止符，随后 fs.realpath() 对已经截短的路径报出误导性的 ENOENT。
• 真正的终止条件应是连续两个字节 00 00。例如 开（U+5F00）编码为 00 5F，不是 NUL。
• 回归测试必须使用实际包含 U+XX00 字符的目录，例如 D:\测试\开源项目；泛泛的“中文路径”样例未必能命中这个字节模式。
• 在官方修复进入发行版前，不建议直接修改全局安装目录里的编译产物。可临时改用随包提供的 browse backend，并用相同 row ID 替换 native provider，避免两个 picker 并存。

验收时至少确认：Open、Navigate、包含 U+XX00 的 Unicode 路径、Create folder、Restart 后仍可用。

我们根据 rc.7 源码把 crash 与 silent truncation 分成四条排查分支，并画出了 00 5F ≠ 00 00 的边界：
https://sandbaseai.github.io/deepseek-harness-handbook/windows-folder-picker-crash.html

说明：这是独立社区 runbook，不代表官方修复状态。