侧边栏 Markdown 文档预览不渲染本地/相对路径图片（未接入 pathImages 改写器）

[addozhang]

说明：仓库未开放 Issues，故将此问题反馈发在 Discussions；如需最小示例工程或补充信息可以留言。

环境

• dsh 0.1.6-alpha.2（npm 全局安装）
• Web GUI（127.0.0.1:3080），macOS + Chrome

现象

• 在侧边栏 preview 打开工作区内的 .md 文件，标准 Markdown 图片语法 ![alt](images/xxx.png) 不渲染图片，只显示 alt 文本
• 同一文件在 VS Code / Obsidian / GitHub 中渲染正常（语法与相对路径均无问题）
• 对比：聊天消息流中，Markdown 里以 / 开头的绝对路径图片可以正常显示（经 /api/file?path=... 加载）

复现步骤

1. 工作区放置 demo.md，内容包含 ![示例](images/example.png)，且 images/example.png 存在
2. Web GUI 侧边栏打开 demo.md
3. 图片位置仅显示 alt 文本「示例」

根因分析（源码定位）

dsh-client-ui-primitives 中 imageSource(url, pathImages) 的逻辑：非 http(s)/blob/data 协议的图片 URL 必须由 pathImages.resolve() 改写，否则返回 undefined，渲染层退化为 alt 文本 span：

function imageSource(url, pathImages) {
  const remote = remoteImageUrl(sanitizeUrl(normalizeUri(url)));
  if (remote !== void 0) return remote;
  const rewritten = pathImages?.resolve(url);
  return rewritten === void 0 ? void 0 : vocabularyImageUrl(rewritten);
}

两个调用方的差异：

• 聊天渲染（dsh-client-ui-chat 的 AssistantMarkdown）：传入了 pathImages，resolver localPathMediaUrl 把以 / 开头的绝对路径改写为 ${origin}/api/file?path=${encodeURIComponent(value)} —— 所以聊天里本地图可见；
• 侧边栏文档预览（dsh-client-ui-sidebar-documentpreview 的 MarkdownBody）：调用共享渲染器 MarkdownText 时只传 text / streaming / labels，未传 pathImages —— 导致侧边栏预览中本地图片（相对路径、绝对路径均）一律降级为 alt 文本。

期望行为

侧边栏 Markdown 预览支持本地图片：

1. 至少与聊天一致：支持以 / 开头的绝对路径；
2. 更理想：支持相对路径，按被预览文件所在目录解析（与 VS Code / Obsidian 行为一致），这样工作区内可移植的 Markdown 文档开箱即读。

修复建议

• MarkdownBody 构造与 chat 相同的 pathImages resolver；
• 相对路径先 join 被预览文件所在目录得到绝对路径，再交给 /api/file；
• 解析结果应限制在 workspace 根目录内，防止目录穿越。

补充

• /api/file?path= 路由已存在（无鉴权直接请求返回 401），鉴权加载链路可用；
• 社区已有 dsh-md-reader、dsh-sidebar-frog 等插件通过自带渲染器实现 Markdown 图片预览，可佐证该需求的普遍性。

[Minhyuin]

补充一条：这个问题在 @deepseek-ai/dsh-desktop 0.2.1-rc.5（Windows）上仍能复现，但根因与上面这版不同。

当前版本里 MarkdownBody 已经会传 pathImages，所以当初那条「未接入 pathImages 改写器」的缺陷本身已经修掉了。残留的一层是：正文调用共享渲染器时传 streaming: !content.eof，而增量渲染器为新冻结节点和 tail 构造的上下文是 { streaming: true, …, pathImages: void 0 }，本地目标（相对、绝对都一样）继续降级成 alt 文字；http(s) 目标不受影响，因为它们走另一条分支，不查 pathImages。

另外这次是桌面端（页面源 dsh-app://app/），但取图通道本身是好的：在页面里 fetch('dsh-app://app/api/file?path=…') 返回 200 image/png。

详细证据、源码定位和三个可选修法见 #12120。