Sidebar preview fails with ENOENT when the workspace is on a non-system drive (0.2.0-rc.2)

[sdf-jkl-gh]

Summary

In the official desktop host @deepseek-ai/dsh-desktop 0.2.0-rc.2, opening an existing file inside the workspace through the sidebar fails when the workspace lives on a non-system drive. The delivered path loses its workspace base and is rebased onto C:\.

Environment

• App: @deepseek-ai/dsh-desktop 0.2.0-rc.2 (@deepseek-ai/dsh-desktop-runtime 0.2.0-rc.2)
• Platform: Windows (x64), Electron 44.0.0, Node 24.18.1
• Session workspace: D:\workspace (drive D:, non-system drive)
• Update channel: nightly

Steps to reproduce

1. Set the session workspace to a path on a non-system drive, e.g. D:\workspace.
2. Create any file inside it, e.g. D:\workspace\.archify\demo\demo.html.
3. Ask the agent to open it in the sidebar. All three path forms reproduce the issue:
   • absolute, backslashes: D:\workspace\.archify\demo\demo.html
   • absolute, forward slashes: D:/workspace/.archify/demo/demo.html
   • workspace-relative: .archify\demo\demo.html

Observed

{"ok":false,"error":{"code":"internal","message":"ENOENT: no such file or directory, stat 'C:\\.archify\\demo\\demo.html'"}}

The target file exists and is readable (verified, ~742 KB), yet the delivered path is rebased onto C:\.

Discriminating experiments

#	Input	File exists?	Result
A	workspace-relative	no	"demo.html" does not exist (resolved to "D:\workspace\demo.html") — resolution is correct
B	absolute, backslashes	yes	queued → ENOENT with C:\.archify\...
C	absolute, forward slashes	yes	queued → same ENOENT
D	workspace-relative	yes	queued → same ENOENT

So path resolution is correct (A proves the base is the session workspace); the failure happens when the queued open is delivered — a different base is used at that point.

Code evidence

@deepseek-ai/dsh-api-workspace-files/lib/index.js documents the rule:

The selected Session header supplies the base for relative paths, with the sandbox policy root as its no-cwd fallback, not a read-containment restriction.

and resolves with:

const target = await this.ctx.fs.resolve(path, {
  cwd: workspaceRoot,
  signal
})

When cwd (the session workspace) is not carried along at delivery time, it falls back to the sandbox policy root — the C:\ side here — so a workspace on D: can no longer be stat'ed. Suspected fault: the sidebar-open delivery does not carry/use the session workspace as an absolute base.

Impact

Sidebar preview of workspace files (HTML / Markdown / images) is unavailable whenever the workspace is not on the same drive as the fallback root. Workarounds that do work: opening through the in-app deliverables card, or opening the file in an external browser. File contents and other features are unaffected.

Suggested fix

• Carry the session workspace as an absolute base when delivering a sidebar-open request (or pass an already-normalized absolute path) instead of relying on a fallbackable cwd.
• For cross-drive cases, the cwd fallback should be the workspace's own drive, not a fixed C:\.
• Add a regression case: workspace on a non-system drive + open an existing file inside it.

Version check (is it already fixed?)

Not fixed as far as I can obtain: the nightly feed reports the same version currently installed, so there is nothing newer to upgrade to.

Source	Version
Installed	0.2.0-rc.2
https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml → version	0.2.0-rc.2 (releaseDate: 2026-09-29T10:35:27.666Z)
Updater cache installer	0.2.0-rc.2

[PerryLink]

"路径被重基到 C:\"这个描述足以定位——请把那两个路径原样贴出来

1. 为什么这条描述已经很有用

你写"the delivered path loses its workspace base and is rebased onto C:\"——如果这属实，那么这是路径拼接问题（某处把一个驱动器根开头的片段当成了相对路径的基准），而不是文件真的不存在。这类缺陷有一个非常干净的判据：

同一份文件，工作区在系统盘时正常、在非系统盘时失败 ⇒ 与文件内容、权限、预览器都无关，只剩路径构造。

你已经有这个对照（"only when the workspace lives on a non-system drive"）⇒ 建议把它写成报告的第一句，它一步就把范围压死。

2. 请补两组原样的路径（这是最关键的取证）

1. 工作区路径（例如 D:\proj\...）与被打开文件的绝对路径；
2. 失败时那条 ENOENT 报错里的路径（逐字，含盘符与分隔符）。

只要这两条并排，就能看出是被拼成了 C:\… 还是被截成了相对路径——维护者不必复现就能定位。我这边检索了 packages/host/open-in-app/src，没有找到做这种重基的代码，所以它更可能在资源/预览投递那一层；两组路径能直接指出是哪一层。

3. 顺带一条同族线索

"预览报文件不存在、但文件确实存在"这一类此前也有独立报告（另一条帖子的现象是预览提示"文件不存在，可能已被移动或删除"，而文件确实在）。⇒ 建议交叉引用：如果两条是同一层的问题，合并后更容易被一次性修掉。

4. 请再补一样

"打开方式"这类入口在你那台机器上是否也失败（即只有侧栏预览失败，还是所有以该文件为目标的入口都失败）。这一条能区分"投递路径问题"与"预览器解析问题"。

5. 版本提醒（本轮基线）

HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1
npm: alpha = 0.2.1-alpha.1    next = 0.2.0-rc.2    latest = 0.2.0-rc.2

你在 @deepseek-ai/dsh-desktop 0.2.0-rc.2** 上 ⇒ 属当前发布线。⚠️ 注意 npm 的 latest**不再是旧的0.1.5-rc.3`。

一条边界

我确认的是这类缺陷的干净判据（系统盘 vs 非系统盘对照）、以及我在 open-in-app 里没有找到重基代码这一否定事实。具体被拼成了什么，要等你那两组原样路径——我没有在 Windows 上跑桌面端。

[q862877400-ux]

补充一组对照：alpha.5 上未能复现，但我的测试路径可能是你说的"能用"的那条

我的环境比报告者新，先给出对照数据。

环境

项	值
@deepseek-ai/dsh	0.2.1-alpha.5（app/production/package.json 依赖 ^0.2.1-alpha.5；源码 package.json version 也是 0.2.1-alpha.5）
平台	Windows（x64）
会话工作区	D:\Agent-Studio\Deepseek-Harness\DSH-Portable\workspace\oss-research-and-deployments（D 盘，非系统盘）

比报告者的 0.2.0-rc.2 和 PerryLink 给的 HEAD = dsh-v0.2.1-alpha.1 都新。

现象

在右侧栏打开一个确实存在的 .md 文件，报：

文件不存在，可能已被移动或删除

对应 ui-sidebar-documentpreview 的 error.notFound（packages/client/ui-sidebar-documentpreview/src/client/locales.ts）：

'error.notFound': '文件不存在，可能已被移动或删除',

源码里这个文案由 failure-line.ts 从 workspace-file/not-found 映射而来：

case 'workspace-file/not-found': return t('error.notFound')

而 workspace-file/not-found 由 packages/api/workspace-files/src/index.ts 的 inspect() 抛出：

const entry = await this.ctx.fs.lstat(path, { cwd: workspaceRoot }, signal)
if (entry === undefined) {
  throw new RemoteError('workspace-file/not-found', `no entry at "${path}"`, { path })
}

我做的对照（全部在 D 盘同一目录）

#	文件名	大小	结果
A	测试中文名.md	37 B	✅ 打开成功
B	test-ascii.md	37 B	✅ 打开成功
C	中文-连字符.md	31 B	✅ 打开成功
D	分析-abc对比XYZ.md	31 B	✅ 打开成功
E	cn-test-same-content.md（10 KB 内容，纯英文名）	10,114 B	✅ 打开成功
F	分析-text-to-cad对比SolidWorks-copy.md（同一份 10 KB 内容，中文名）	10,114 B	✅ 打开成功
G	分析-text-to-cad对比SolidWorks.md（原始触发文件）	10,114 B	❌ 失败

E / F / G 三份内容哈希完全相同（SHA-256 前 16 位 67382DDBC00DE842），只有文件名不同。

文件名逐字符核过：29 个字符 / 37 UTF-8 字节 / 全部是 U+5206 U+6790 U+002D t e x t ...，无控制字符、无零宽字符、无 BOM、NFC 规范化成立。

我核过、没有问题的两处

1. 地址编解码。 复现 fileAddressFor → sessionFileAddress → parseFileAddress 全链路，中文正确 percent-encode 且往返一致：

rel  = 分析-text-to-cad对比SolidWorks.md
addr = dsh-resource://file/session/session-86087c4b/%E5%88%86%E6%9E%90-text-to-cad%E5%AF%B9%E6%AF%94SolidWorks.md
back = 分析-text-to-cad对比SolidWorks.md   ← 一致

2. 磁盘层面。 便携版 Node 对中文路径 statSync / readFileSync 均正常，bytes = 10114。

关键限制：我可能没测到你那条路径

我的测试文件是通过 present（交付卡片） 呈现的，不是通过右侧栏的文件树逐级点进去。而你在报告里写过：

Workarounds that do work: opening through the in-app deliverables card, or opening the file in an external browser.

所以我这 6 个"成功"很可能全部走的是"能用"的那条路，不构成对你那条路径的反证。 这一点必须先说清楚，免得被当成"alpha.5 已修复"。

另一个可能的解释

G 是首次创建后立刻打开失败，E/F 是复制出来再打开成功。如果投递层按文件版本号（statOf() 里的 info.version）或某种首次读取的缓存做键，首次创建的文件可能落在一个尚未登记的状态上。这条我没有证据，只是列出与现有观察一致的一种可能。

想请报告者补的一条

你原文的四个 discriminating experiments 里，A 是"文件不存在 + 相对路径"，B/C/D 是"文件存在"。能不能补一条：文件存在 + 相对路径（不走交付卡片，纯右侧栏点开）？

如果 D（相对路径 + 存在）在你机器上也失败，那"交付路径丢失 workspace 基准"这个定位就更硬；如果 D 成功而 B/C 失败，问题就在绝对路径的重基，范围还能再窄一层。

我这边的结论

• 未能在 0.2.1-alpha.5 上复现 Sidebar preview fails with ENOENT when the workspace is on a non-system drive (0.2.0-rc.2) #9072 的 ENOENT ... 'C:\...' 形态（我这边报的是 not-found 文案，没有暴露底层路径）。
• 中文文件名不是触发条件（A–F 全成功）。
• 唯一失败的 G 目前无法用"名字/内容/大小/盘符"任一单一变量解释，归为不可复现。
• 我这 6 次成功走的是交付卡片路径，不覆盖右侧栏文件树，请按这个前提读。

如果需要在右侧栏文件树里做逐级对照，我可以再测一轮并把每一步的 dsh-resource:// 地址贴出来。