[BUG]遇到个bug，它自己改了，有效果并生成了一个报告

[SuiYuanMingMing]

[BUG] Adding a workspace whose path contains a U+XX00 char (e.g. 开 U+5F00) fails: Win32 picker truncates the UTF-16 path at a single 0x00 byte

可直接粘贴至 https://github.com/deepseek-ai/deepseek-harness/issues
隐私说明：<ProjectRoot> 为占位符，代表复现机器上的真实本地根路径（可能含非 ASCII 目录名），已脱敏。

Summary

On Windows, "Add workspace" opens the native IFileOpenDialog (spawned child process + koffi COM).
The selected folder path is read back as a UTF-16LE LPWSTR. readUtf16() in
packages/host/directory-picker-native/src/win32-dialog-bindings.ts treats any single 0x00 byte at an
even offset as the string terminator, but a UTF-16 terminator is a full 0x0000 code unit (two zero
bytes). Any path containing a CJK character whose low byte is 0x00 (e.g. 开 = U+5F00, 一 = U+4E00) at an
even code-unit position is silently truncated at that character. The GUI then calls workspace.create
with the truncated path, the server's fs.realpath throws ENOENT, and the user sees:

workspace create failed: workspace-invalid-path: cannot create a workspace at "<ProjectRoot>\01": ENOENT: no such file or directory, realpath '<ProjectRoot>\01'

Environment

• Windows (native directory-picker capability; host serves native)
• @deepseek-ai/dsh-host-directory-picker-native 0.1.0-rc.6 (installed), also current on master (checked 2026-08-14)
• DSH web GUI (local deployment)

Repro

1. Create a folder whose name has an ASCII prefix followed by a character in the U+XX00 block.
   For example, under a Chinese-named parent: <ProjectRoot>\01开发域
   (the offending character 开 = U+5F00, low byte 0x00, sits at an even code-unit offset after 01).
2. Add it as a workspace via the GUI 添加工作区 -> native folder dialog -> select the folder. (Typing the
   path into the dialog produces the same result.)
3. Error: workspace create failed: workspace-invalid-path: ... realpath '<ProjectRoot>\01'
   — the 开发域 suffix vanished because the path was cut right before 开.

Note the Chinese-named parent segment survives because none of its code units has a 0x00 low byte
(which is a fingerprint of this exact bug, not a sign that CJK paths "mostly work").

Root cause

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

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   // <-- treats any even 0x00 byte as terminator
  return bytes.toString('utf16le', 0, end)
}

开 = U+5F00 encodes little-endian as 00 5F, so the loop stops right at the first byte of 开.

Reproduction of the loop semantics on the path (Node):

original: "<ProjectRoot>\01开发域"
buggy   : "<ProjectRoot>\01"      (matches the error exactly)
fixed   : "<ProjectRoot>\01开发域"

Secondary issue (same function, lower severity): koffi.view(address, 32768) reads up to 32 KiB past the
CoTaskMemAlloc'd string — a latent out-of-bounds read hazard that should be bounded differently.

Suggested fix (one line)

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

A terminator is only a complete 0x0000 code unit. Optionally also guard the read window with a much
smaller bounded scan and/or use the buffer size the string actually owns.

Server side is not at fault

Verified by calling POST /api/workspace.create with the full path directly — the server registers the
workspace correctly. fs.realpath, the RPC transport, and the payload schema all handle Unicode paths
fine. The truncation happens purely in the client-side native picker's readUtf16.