Bug: sidebar Markdown preview never renders local images (desktop shell, dsh-app:// origin)

[Minhyuin]

Summary

In the right Sidebar document preview, a Markdown document that references a local
image — relative or absolute — renders only the alt text. No <img> element is
created inside [data-document-markdown]. Remote http(s) images in the same document
render normally, so the Markdown renderer, the <img> pipeline and the CSP are all fine.

The authenticated file route itself works: dsh-app://app/api/file?path=… returns
200 image/png from the page context.

Environment

• @deepseek-ai/dsh-desktop 0.2.1-rc.5, Windows 11 x64, Electron renderer whose shell origin is dsh-app://app/.
• Plugin in play: @deepseek-ai/dsh-client-ui-sidebar-documentpreview (registers md / markdown).

Steps to reproduce

1. Create t/index.md and t/figures/a.png.
2. index.md:

# t

![relative](<figures/a.png>)
![absolute](<C:/some/where/t/figures/a.png>)
![remote](<https://example.com/a.png>)

3. Open t/index.md in the right Sidebar preview.

Expected

The first two images render.

Actual

relative and absolute show as plain alt text; only remote renders.
In the console, right after the tab is open:

[...document.querySelectorAll('[data-document-markdown] img')].length  // 0
document.baseURI                                                       // "dsh-app://app/"
new URL('api/file?path=' + encodeURIComponent('C:/some/where/t/figures/a.png'),
        document.baseURI).href                                         // "dsh-app://app/api/file?path=…"

// the URL that should have been used is served fine:
await fetch('dsh-app://app/api/file?path=' + encodeURIComponent('C:/some/where/t/figures/a.png'))
  .then(r => [r.status, r.headers.get('content-type')])                // [200, 'image/png']

So: document.baseURI passes the fileMediaUrl() guard, fileMediaUrl() builds the
right URL, and that URL returns a real PNG — yet the preview never calls it.

Suspected cause

MarkdownBody hands the accumulated text to the shared MarkdownText primitive with

streaming: !content.eof

(two call sites in client.js; the Markdown one is followed by labels, pathImages).

When streaming is true, the primitive uses its incremental renderer, which builds the
per-node render context as

{ streaming: true, labels, fileMentions: void 0, pathImages: void 0, … }

for both the newly frozen nodes and the tail. With pathImages: void 0, the image
handler falls back to nU(pathImages?.resolve(dest)) → undefined → the alt-text span.
Already frozen elements are not re-rendered when pathImages later becomes available,
and the incremental memoisation is keyed on the text only.

Consequence: every local image destination degrades to alt text, while http(s)
destinations are unaffected because they are resolved by a different branch
(cw() / scheme allow-list) that never consults pathImages.

Suggested fix (any one)

1. Thread pathImages into the incremental renderer: pass it to the renderer class
   alongside labels, and use it in both contexts instead of pathImages: void 0
   (also include it in the memoisation key so a later-arriving resolver re-renders).
2. Or don't mark document-preview Markdown as streaming — MarkdownBody already
   re-renders on page append, and the full-parse path passes pathImages correctly.
3. Or have the image handler treat a missing pathImages as "not yet resolvable" and
   re-render once the resolver arrives.

Additional data point (not a bug, just context)

On the desktop shell the page origin is dsh-app://app/, the auth cookie lives only in
the main process (the forwarded response deliberately strips set-cookie), and only
dsh-app://app/* (via forwardWebRequest) and the ws://127.0.0.1/* RPC get it
attached. Therefore authoring an http://127.0.0.1:<port>/api/file?path=… URL in
Markdown can never authenticate, and dsh-app://app/api/file?… is the only viable form
— which is exactly what fileMediaUrl() produces. Path A in Markdown cannot express
it (the scheme allow-list rejects non-http(s) destinations), so the fix has to be on
the resolver side as described above.

Workaround

Serve the images from a local static HTTP server and author absolute http:// URLs in
the Markdown; those render (verified).

[Minhyuin]

中文版（同一问题的补充说明）

现象

桌面端右侧边栏的文档预览里，Markdown 中引用的本地图片——无论相对路径还是绝对路径——都只显示 alt 文字，[data-document-markdown] 容器内根本没有生成 <img> 元素。同一文档里的远程 http(s) 图片显示正常，说明 Markdown 渲染、<img> 渲染链路和 CSP 都没有问题。

已验证鉴权文件路由本身是好的：在页面上下文里 dsh-app://app/api/file?path=… 返回 200 image/png。

环境

• @deepseek-ai/dsh-desktop 0.2.1-rc.5，Windows 11 x64；Electron 渲染进程的页面源为 dsh-app://app/。
• 涉及插件：@deepseek-ai/dsh-client-ui-sidebar-documentpreview（注册 md / markdown）。

复现

1. 建 t/index.md 和 t/figures/a.png。
2. index.md 内容：

# t

![relative](<figures/a.png>)
![absolute](<C:/some/where/t/figures/a.png>)
![remote](<https://example.com/a.png>)

3. 在右侧 Sidebar 打开 t/index.md。

预期与实际

预期前两张图渲染；实际 relative 和 absolute 只剩 alt 文字，只有 remote 正常。

侧边栏该 tab 打开时，在控制台里可以看到：

[...document.querySelectorAll('[data-document-markdown] img')].length  // 0
document.baseURI                                                       // "dsh-app://app/"
new URL('api/file?path=' + encodeURIComponent('C:/some/where/t/figures/a.png'),
        document.baseURI).href                                         // "dsh-app://app/api/file?path=…"

// 本该被使用的地址其实是可用的：
await fetch('dsh-app://app/api/file?path=' + encodeURIComponent('C:/some/where/t/figures/a.png'))
  .then(r => [r.status, r.headers.get('content-type')])                // [200, 'image/png']

也就是说：document.baseURI 能通过 fileMediaUrl() 的白名单判断，fileMediaUrl() 拼出的地址正确，这个地址也确实返回真实 PNG——但预览从未调用它。

怀疑的根因

MarkdownBody 把累计文本交给共享的 MarkdownText 原语时传的是：

streaming: !content.eof

（client.js 里有两处；Markdown 那一处后面紧跟 labels, pathImages。）

当 streaming 为真时，原语走增量渲染器，它构造的逐节点渲染上下文是：

{ streaming: true, labels, fileMentions: void 0, pathImages: void 0, … }

新冻结的节点和 tail 都用这个上下文。由于 pathImages: void 0，图片处理器只能退到 nU(pathImages?.resolve(dest)) → undefined → 渲染成 alt 文字 span。而且已冻结的元素在 pathImages 稍后可用时不会被重新渲染，增量渲染的 memo 也只以文本为键。

结果就是：所有本地图片目标都降级为 alt 文字；而 http(s) 目标不受影响，因为它们走的是另一条分支（cw() / scheme 白名单），根本不查 pathImages。

建议的修法（三选一）

1. 把 pathImages 透传进增量渲染器：和 labels 一起传给渲染器实例，两处上下文都用它而不再写 pathImages: void 0（同时把它纳入 memo 键，使后到的 resolver 能触发重渲染）。
2. 或者干脆不要把文档预览的 Markdown 标记为 streaming——MarkdownBody 在追加页时本来就会重渲染，全量解析分支能正确传递 pathImages。
3. 或者让图片处理器把「pathImages 缺失」当作「暂不可解析」，等 resolver 到位后再渲染一次。

补充背景（不是 bug，只是定位信息）

桌面端的页面源是 dsh-app://app/，鉴权 Cookie 只存在于主进程（转发响应里刻意剔除了 set-cookie），只有 dsh-app://app/*（经 forwardWebRequest）和 ws://127.0.0.1/* 的 RPC 会被补上 Cookie。所以在 Markdown 里手写 http://127.0.0.1:<port>/api/file?path=… 永远无法通过鉴权，dsh-app://app/api/file?… 才是唯一可行的形式——而这正是 fileMediaUrl() 产出的地址。该地址在 Markdown 里也无法直接书写（scheme 白名单只放行 http(s)），因此修复必须落在 resolver 一侧，如上所述。

临时绕过

把图片放到本地静态 HTTP 服务，并在 Markdown 里写绝对 http:// 地址；这类目标实测可以正常显示。

[Minhyuin]

相关历史记录（发帖时漏搜了，补上）：

• 侧边栏 Markdown 文档预览不渲染本地/相对路径图片（未接入 pathImages 改写器） #7125（2026-09-19，dsh 0.1.6-alpha.2 + Web GUI）：同样的症状，当时的根因是 MarkdownBody 调 MarkdownText 时没有传 pathImages。
• 本报告是 0.2.1-rc.5 上的残留变体：pathImages 现在已传入，但正文以 streaming: !content.eof 调用渲染器，流式分支的渲染上下文把它置为 void 0，因此本地图片仍然只出 alt 文字；这也解释了为什么 http(s) 图片一直正常。
• 相邻但不同的问题：Sidebar preview fails with ENOENT when the workspace is on a non-system drive (0.2.0-rc.2) #9072（非系统盘工作区导致侧边栏预览 ENOENT）、[Bug report] Windows generated-image preview fails when Markdown escapes the attachment path #8806（Windows 路径转义导致生成图预览失败）。

[PerryLink]

根因就是这个流式分支：StreamingRenderer 根本不接受 pathImages。

调用方其实把两个都传了——packages/client/ui-sidebar-documentpreview/src/client/markdown/MarkdownBody.tsx:54：

<MarkdownText text={split?.body ?? text} streaming={!content.eof} labels={labels} pathImages={pathImages} />

但到了 packages/client/ui-primitives/src/markdown/MarkdownText.tsx:203-213 分叉了：

• streaming 为真 → new StreamingRenderer(labels, omitHtml)（:209），这个类没有 pathImages 这个参数，render(text) 完全不碰图片路径；
• !streaming → renderSettled(text, labels, fileMentions, pathImages, omitHtml)（:206），本地图片才会被重写。

所以不是调用方漏传（#7125 那个根因已经修了），是流式渲染器缺这个能力。这也解释了为什么 http(s) 图片一直正常：它们是绝对 URL，走不走进 pathImages 都一样。

"永远不渲染"这点值得再确认一下：如果预览内容的 content.eof 一直是 false，就永远停在流式分支。在你那个 [data-document-markdown] 的 tab 里打个断点或者看下组件 props 就能确认。

修法有两种形状，代价不一样：

1. 给 StreamingRenderer 加一个图片解析器，解析到 image 节点时同步重写本地路径——正解，但要动流式渲染的核心；
2. 文档预览在 eof 到达后强制重渲染一次（把 streaming 切回 false）——更小，前提是 eof 真的会到。

只读了 master fcc0ad46 的源码；你那个 eof 的实际值我没法看。