verifyDesktopPath round-trip fails on routing filesystems: WSL workspaces report "Path has no verified Host path"

[Big-Dao]

Bug: verifyDesktopPath round-trip breaks against routing filesystems (translated / WSL workspaces) — "Path has no verified Host path"

Originally reported in dsh-plugin-wsl-env#37 with an inspector-grade root-cause analysis by @Anonso (reproduced on 0.2.1-rc.5 and verified unchanged in the 0.2.2-rc.1 sources; filing here at the reporter's request since the main repo has issues disabled).

Symptom

In a WSL workspace (\\wsl.localhost\Ubuntu\home\<user>\…), "open with default app" and "reveal in file manager" fail for any file: the sidebar reports RemoteError gateway/bad-request: "Path has no verified Host path". Browsing, editing and previewing the same file work; a drive-letter target works.

Root cause (verified against our sources too)

verifyDesktopPath requires processPath(resolve(processPathFromHostPath(hostPath))) === hostPath — i.e. it assumes processPath() returns the HOST spelling. But a routing filesystem intentionally translates coordinates: WslRoutingFileSystem.processPath() returns the LINUX spelling for a distro UNC target (docs/root-fs-routing.md §2.2), while processPathFromHostPath keeps the host implementation (UNC). The round trip can therefore never close for a translated target, and every entry of session.workspacePathApplications fails.

Suggested fix (from the report, option ①)

Relax the verification to what the security property actually needs: processPathFromHostPath(hostPath) non-empty AND fs.resolve(mapped) succeeding — do not treat processPath() as the host spelling for a routing fs. A plugin that translates coordinates (like ours) then composes correctly, and ordinary host filesystems keep today's strict check.

A plugin-side workaround (returning the host spelling from processPath) was tested and unblocks open-in-app immediately, but it degrades the change feed and stat.absolutePath spellings back to UNC — we are not shipping that globally; the upstream fix is the right home.

Environment: DSH 0.2.1-rc.5 / 0.2.2-rc.1 (unchanged between them), Windows 11 26H2, WSL 2.6.3, plugin 0.17.1 → 0.22.0 (all affected).

[PerryLink]

That round-trip contradicts the filesystem seam's contract.

verifyDesktopPath (packages/api/session-controller/src/index.ts:418-428) does:

const hostPath = resolve(path)
const mapped = fs.processPathFromHostPath(hostPath)
if (mapped === undefined || fs.processPath(await fs.resolve(mapped, { signal })) !== hostPath) throw ...

The seam says otherwise. processPath(target) returns "an absolute path in the backend's execution world" and is "deliberately separate" from the target key (packages/fs/fs/src/index.ts:160-167); processPathFromHostPath maps "from the harness host into this filesystem's execution world" (:168-180). A backend that translates coordinates is allowed to return the execution-world spelling, so comparing it to hostPath can never close for a WSL UNC target. The same code is at rc.5 (:418), rc.1 (:421) and master, so this is not a regression. The same code is at rc.5 (:418), rc.1 (:421) and master, so this is not a regression.

The security property the check needs is "this host path maps into this session's filesystem and still resolves", not "the backend's spelling equals the host's". Your option ① is the right shape: require a defined processPathFromHostPath(hostPath) and a successful fs.resolve(mapped), then hand the original hostPath to the native opener, which is a host affordance anyway. Keeping the strict comparison for backends that do not translate is fine as an extra, but it cannot be the only path.

A test that pins it: a fake fs whose processPath returns /translated/x for a host path ending x, with resolve succeeding. Today it throws; with the relaxed check it opens.

One caveat for the write-up: docs/root-fs-routing.md is not in this repository, so if you cite it, attribute it to the plugin's docs. The in-repo anchor is the fs seam comment above.

[Big-Dao]

插件更新通告 / Plugin update（2026-11-14）

dsh-plugin-wsl-env 文档全面改版，已合入仓库 main。npm 最新发布版仍为 0.26.0——本次只改文档，插件功能无变化：

• README 重写为「无插件 / 有插件」对照叙事，配中英双语架构图。核心痛点：两种工作区模式都缺 POSIX 执行环境——Windows 工作区落在 CMD / PowerShell（模型的弱项，训练语料以 POSIX 为主）；WSL 工作区只能经 wsl.exe 逐条包装（每次调用是孤立空间，环境、cwd 与进程状态不跨调用保持，多步脚本在接缝处断掉）。
• 明确 DSH 的两种交付形态：npm CLI（Web UI / headless）与桌面应用（macOS / Windows）。本插件只服务其中一种组合：Windows 桌面应用 + WSL 2 项目。
• VALUE 文档新增与 Remote-SSH 的对照（Windows 宿主）：到达范围（仅本机发行版 vs 任意 SSH 主机）、前置配置（无需 sshd / 密钥 / 端口转发）、发行版内足迹（一个内容寻址缓存 vs ~/.vscode-server）、命令沙箱（bubblewrap + DSH 权限档位 vs 无）。
• README 现在只演示桌面路径：DSH Desktop 不含 dsh 可执行文件，安装、验证、升级、卸载均以 Plugins 页为准。

CLI 能整个装进发行版时不需要本插件，判断表见 README。

Docs overhaul landed on main — the README pair now leads with the two-mode POSIX pain (CMD/PowerShell weakness on Windows workspaces, stateless wsl.exe wrapping on WSL workspaces), ships bilingual before/after diagrams, and VALUE gains a Remote-SSH comparison for the Windows host. Latest npm release (0.26.0) is functionally unchanged.