【bug report】打开工作区选择目录的时候，目录名字里【开发】之后的字符串会被截断

[zhengwx1995]

虽然听起来很离奇，但是确实如此。
我删除了所有的.dsh文件，然后换了个新的port重启避免浏览器缓存问题。仍然能复现。

选中...\Codex\开发设置，得到的结果是...\Codex：

选中...\Codex\插件开发，得到的结果是找不到路径。

我的环境是win11 + @deepseek-ai/dsh@0.1.0-rc.7

codex已经找到了原因，按照指引修复下吧。

[zhengwx1995]

字符编码的世界真是无奇不有😂

[argszero]

English summary: source-verified the ENTIRE host-side chain at rc.7 (99f6f02) — browse picker backend, RPC schemas, fetch wire, and the native Win32 dialog UTF-16 decode are all clean for CJK. The truncation is therefore client-side (the browser UI's directory-picker widget) or in the workspace-open consumer, NOT in the host chain. Three candidate client mechanisms + one discriminating diagnostic (DevTools Network: if host.listDirectory returns the full 开发设置 path, the bug is in the UI's rendering/navigation; if truncated, it's host-side). Also: this may be a new member of the wire-truncation family I track (emoji/CJK truncation class, 6 known poison paths). Please also paste codex's diagnosis as text — the screenshot is unreadable.

字符编码的世界确实无奇不有，但这次可以先把嫌疑范围精确缩小。我对 rc.7（99f6f02fec）把宿主侧整条链路都源码验证了一遍——结论：截断不在宿主侧。

1. 宿主侧全链路验证（全部干净）

环节	位置	CJK 安全性
浏览型列目录后端	directory-picker-browse/src/index.ts:217-297	✅ opendir + join(parent, name) 全路径，无任何字符处理
面包屑	ancestryCrumbs :28-38	✅ dirname/basename（Node path，UTF-16 安全）
窗口排序	boundedInsert :76-96	✅ localeCompare（只影响顺序，不截断）
RPC schema	apiproxy/src/api/host.schema.ts:32-36	✅ z.string() 无长度上限、无过滤
fetch 线	apiproxy/src/fetch/client.ts:321	✅ 标准 JSON.stringify + fetch，浏览器按 UTF-8 字节算 Content-Length
原生 Win32 对话框	directory-picker-native/src/win32-dialog-bindings.ts:37-42	✅ readUtf16 读 NUL 结尾 UTF-16；开发设置 全部 BMP 字符，无代理对问题

所以截断必然发生在浏览器侧的 UI 组件（dsh-client-ui-directory-picker-browse，独立发布包，不在本 checkout）或 workspace-open 消费端——不是宿主返回了截断路径，而是 UI 拿到完整路径后自己弄丢了。

2. 三个最可能的客户端机制（按概率）

1. 行路径的 URL 编码导航：browse UI 大概率用 parent + '/' + name 拼 URL 片段导航。CJK 段必须按段 encodeURIComponent——若漏编码、或 decodeURIComponent 被调两次（路径先进了一次 URL 解析、又手动解一次），CJK 段会被浏览器/解析器吞掉。开发设置 整段消失 = 段在 URL 层被丢弃（父段保留）——和你第一个症状完全吻合；乱码段 → 不存在的路径 → "找不到路径"——和第二个症状吻合。
2. 行 path 字段在客户端被二次 join：若 UI 不用后端返回的完整 path，而是用 currentPath + name 重拼，且 name 在到达 UI 时已损坏（如 \u5f00\u53d1 字面量没解码），就会得到坏路径。
3. breadcrumb 点击目标：ancestryCrumbs 返回的每条 crumb 带完整 path（:34），若 UI 对 crumb 路径做了同样的 URL 处理，同样中招。

3. 一个判别性诊断（30 秒）

打开 DevTools → Network，选中 开发设置 后看 host.listDirectory（或 pickDirectory）的响应体：

• 响应里有完整 ...\Codex\开发设置 → 宿主没问题，bug 在 UI 的渲染/导航层（上面机制 1/2/3）——那么问题就出在 dsh-client-ui-directory-picker-browse 包；
• 响应里就没有 → 反而奇怪（我源码验证不该发生），请把响应贴出来，那会是宿主侧新 bug。

这一步直接把"编码世界之谜"变成"哪一层的问题"，作者自己或官方都能立刻定位。

4. 家族关联（若最终是宿主侧截断）

我在跟踪一个 wire 截断家族（emoji/CJK 多字节字符在序列化/线上被截断，6 条已知毒径，永久 400 类事故）。开发 截断若在宿主侧复现，就是这个家族的第 7 个成员——机制大概率是"按 UTF-16 单元数算长度、按字节截断"那一类。目前验证结果指向客户端，但值得留这个口子。

5. 请求

你贴的 codex 诊断截图分辨率不够，请把 codex 的结论文字直接贴出来（哪一行代码、什么机制）——如果它已经定位到客户端包的具体行，我们直接对照验证，比从头猜快得多。截图里的路径/报错文本也请转成文字。

中文摘要见上。若确认是客户端 UI 层，官方修复点 = dsh-client-ui-directory-picker-browse 的路径编码/导航逻辑；社区侧可以先在插件里绕过（用后端返回的完整 path 而非重拼）。

[zhengwx1995]

社区有很多类似的bug report。

已经找到根因，发生在 Windows 原生目录选择器的 UTF-16 解码。
调用链是：
pickNativeDirectory() → Win32 IFileOpenDialog → GetDisplayName(SIGDN_FILESYSPATH) → readUtf16()。
问题代码在：
win32-dialog-bindings.ts:37

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

这里每次按 UTF-16 两字节读取，却只检查第一个字节。汉字“开”的 UTF-16LE 编码是：
00 5F
第一个字节正好是 0x00，于是被错误判断为字符串结束，所以路径会被截断在“开发”之前。
当前 npx @deepseek-ai/dsh 使用的 rc.7 已发布包也包含同样代码：
worker.cjs:21
因此后端工作区、JSON/RPC、持久化都没有截断；它们只是接收了原生选择器已经截断的路径。
修复应改为按完整 UTF-16 code unit 判断：

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

[zoahdev]

核验通过（对照 main/master HEAD 99f6f02 rc.7）——根因定位字节级精确，修复正确。

1. 代码确认。 packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-45：

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)
}

每步按 UTF-16LE 两字节推进，却只检查 bytes[end]（低字节）是否为 0——任何低字节为 0x00 的合法字符都会被误判为串结束。

2. "开发" 字节实测：UTF-16LE 编码 = 00 5F D1 53——"开"（U+5F00）低字节正好是 0x00，循环在第一个 code unit 处停止，路径截断在"开"之前。与 #3188 现象（目录名【开发】之后被截断）完全吻合。

3. 修复正确：(bytes[end] !== 0 || bytes[end + 1] !== 0) 按完整 code unit 判断 NUL；end + 1 < bytes.length 的边界守卫保证不会越界读。唯一建议：把循环提成纯函数（如 utf16Len(bytes)）便于单测，加一个"低字节为 0 的字符在中间"的回归用例（例如 "a开发b" 的完整 buffer），防未来回归——当前函数是模块私有，只能靠 native 集成测试覆盖，提纯后成本更低。

另外确认你的观察成立：后端工作区/JSON-RPC/持久化没有截断，只是收到了原生选择器已截断的路径——所以修复点唯一在 readUtf16，不会牵动其它层。

[argszero]

Correction to my earlier reply in this thread. I source-verified the host chain and concluded the truncation was client-side — that was wrong, and I apologize for the misdirection.

The root cause is the native dialog's readUtf16 in packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-42: the terminator scan checks only the low byte (bytes[end] !== 0), so any Han character with a zero low byte (U+XX00 — 开 U+5F00, 中 U+4E2D, 一 U+4E00, …) truncates the path right there. Your two symptoms map 1:1:

• ...\Codex\开发设置 → 开 is the first char (bytes 00 5F) → path becomes ...\Codex ✅ matches your screenshot
• ...\Codex\插件开发 → 开 is the 3rd char → path becomes ...\Codex\插件 → "找不到路径" ✅

Two independent reports (#3291 victorwwd, #3279 dandaogc) plus my empirical reproduction (node, same decode loop, both your exact paths) confirm it. The one-line fix (check both bytes: bytes[end] !== 0 || bytes[end+1] !== 0) restores full paths. Details + regression-test note in my reply on #3291. This closes #3188 = #3279 = #3291 as one bug.

[naipi11]

Until this is patched, you can avoid the affected picker when starting DSH for a new workspace: in PowerShell, run Set-Location 'C:\path\to\开发设置', then npx @deepseek-ai/dsh web. The launcher uses its invoking directory as the default workspace root, so new sessions start there without opening the picker.