[Bug] Inline file links with Windows paths open wrong path: Markdown backslash escaping breaks _-prefixed segments; sidebar reports file-not-found

[zzchx]

[Bug] Inline file links with Windows paths open a wrong path: Markdown \_ escaping breaks _-prefixed segments, sidebar reports "文件不存在"

Environment

• DSH Desktop 0.2.1-rc.3 (dshBuildCommit: be72761ee1a6736ebcdf4f3739363b083ae53c98), Windows 11 zh-CN
• Affected surface: the right-hand "sidebar" document preview panel

Symptom

Clicking an inline file link rendered from a reply opens the wrong path in the sidebar and shows the empty-state text "文件不存在，可能已被移动或删除" (file does not exist), while the tool-result card for the same file ("在侧边栏预览") opens it correctly.

Reproduction

1. Agent writes G:\AI\_dsh_tools\_issue-body.md.

2. Agent replies with a Markdown link:

   [\_issue-body.md](G:\AI\_dsh_tools\_issue-body.md)

3. Click the inline link → the sidebar tries G:/AI/_dsh_tools_issue-body.md → "文件不存在".

4. Click the tool-result card → opens G:\AI\_dsh_tools\_issue-body.md correctly.

Checks on the machine:

Test-Path G:\AI\_dsh_tools\_issue-body.md        -> True   (real file)
Test-Path G:\AI\_dsh_tools_issue-body.md         -> False  (what the sidebar tried)

Root cause (two channels, one is lossy)

• Tool-result card: uses structured meta.path (absolute, from the tool call) → reliable.

• Inline link: uses the Markdown-authored text path. CommonMark backslash escapes apply inside link destinations — \_ becomes _ (while \A stays literal) — so

  G:\AI\_dsh_tools\_issue-body.md → G:\AI_dsh_tools_issue-body.md

  The client then normalizes \ → / in fileAddressFor() and opens the result without any existence check or fallback; the only failure surface is the sidebar's error.notFound string.

Bundle references (0.2.1-rc.3):

• dsh-client-ui-reference/lib/client.js → fileAddressFor(sessionId, cwd, path) (~line 194): only path.replace(/\\/g, "/") + relative-join; no validation, no fallback.
• dsh-client-ui-sidebar-documentpreview/lib/client.js line 1467 → "error.notFound": "文件不存在，可能已被移动或删除", no retry/fallback.
• dsh-client-ui-deliverables/lib/client.js line 1115 → if (typeof meta.path === "string" && isAbsoluteWorkspacePath(meta.path)) return meta.path; — this is why cards work.

Impact

Deterministic (not intermittent) for any Windows path whose segment starts with _ after a backslash — e.g. _dsh_tools, _dsh_probe, _dsh_export, _issue-body.md. This is a very common naming pattern on Windows dev machines, so the failure is systematic rather than rare.

Suggested fix (any of these)

1. Fallback on open failure: resolve by basename within the session workspace, or match against the turn's tool-call meta.path list, and open the unique match.
2. Prefer structured paths: render inline file references from the tool-result meta.path where available instead of trusting authored Markdown text.
3. Validate before opening: if keeping text links, decode and existence-check the destination against the workspace, and show "did you mean ?" instead of a dead end.

[PerryLink]

这条已经修了，在 c262a09fd0b（PR #7098，Fixes #7095）。

它改在 markdown 层：CommonMark 把 \. 当转义，现在 destination 看起来像 Windows 路径时保留作者写的反斜杠；没有 scheme 的相对路径也一起处理，字符引用仍然正常解码。测试钉在 Markdown file-links 的 Web 快照里。

版本：这个提交在 master（0.2.2-alpha.2，f3803c96）里，不在 rc.4（504a01a9）里。所以 rc.3/rc.4 上还会打开错误路径，得等 0.2.2-alpha.x。

在那之前：把反斜杠换成正斜杠，或者加 file:// 前缀，都能正常打开。

只读了提交和源码。