You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE(app)]: display image attachments from tool results in chat UI #21227
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
When a tool returns image data — via webfetch fetching an image URL, or an MCP server returning an ImageContent block — the image is stored in part.state.attachments and correctly forwarded to the model via the supportsMediaInToolResults pipeline in message-v2.ts. However, the image is never rendered in the chat UI. The user has no visual feedback that a tool produced image output.
Current behavior
Images in part.state.attachments are invisible in the UI. The only indication something happened is the tool call row (e.g. "Called webfetch") with no image shown.
Expected behavior
Images from tool result attachments render inline below the tool call row, with click-to-fullscreen preview — consistent with how user-uploaded image attachments are displayed in UserMessage.
Proposed fix
In ToolPartDisplay (message-part.tsx), after the tool component renders, check part.state.attachments for entries where mime.startsWith("image/") and render them using the existing dialog.show(() => <ImagePreview .../>) pattern. CSS scoped to [data-component="tool-part-wrapper"].
No new dependencies
No changes outside packages/ui
Applies to all tools that populate attachments — built-in (webfetch, read) and MCP alike
Reacted by bm, zhboner, Emmanuel Deloget, filatovzru, Pavel, Bernhard Berger, Andreas Hald, Ali MoezGholami, TheOriginal92, Mauricio Scheffer and 3 more
I’m also hitting this in OpenCode web: image attachments from tool results are not rendered in the chat UI, so I have to expose the image through a temporary URL and paste a link instead.
#21352 appears to address this directly and still merges conflict-free against current dev.
Another concrete case for this: I drive a fairly large MCP stack from opencode web (1.18.5 in Docker), and several of those tools return screenshots.
The pipeline works right up to the last step. session/tools.ts turns MCP image content into a data:<mime>;base64,… attachment, it lands in part.state.attachments, the SDK exposes it on SessionMessageToolStateCompleted, and the model receives it. Only the UI drops it, so the images are invisible to the person sitting in front of the session — which is exactly the case where you want to see them.
Worth noting the same data path also covers the built-in read tool, which builds identical data URIs in tool/read.ts. A UI-side fix would therefore cover both without touching the server.
There are now two closed PRs for this (#21352 and #38846), both closed by the automated cleanup without a review, plus one open draft (#39817). Since the contributing guidelines route UI features through a design review first: is there a preferred direction from the team? Happy to test whichever lands.
Reacted by Yves Renier, Mauricio Scheffer and Alex Gvozden
To restate it: when a tool returns an image (an MCP ImageContent block, or webfetch on an image URL), the image is sent to the model but never shown in the chat. You'd like it shown under the tool call, with click-to-preview like user-attached images.
The current v2 app still works this way. The tool row shows only the text parts of a tool's result. The one exception is the read tool, which loads its image from disk. Image results from MCP tools and webfetch aren't displayed. Maintainers will consider this.
Activity
zhboner commentedon Apr 8, 2026
Besides gemini images, standard markdown image format, e.g.,
is not supported in UI either. :(
bernhardberger commentedon May 29, 2026
I’m also hitting this in OpenCode web: image attachments from tool results are not rendered in the chat UI, so I have to expose the image through a temporary URL and paste a link instead.
#21352 appears to address this directly and still merges conflict-free against current
dev.AndreasHald commentedon Jul 15, 2026
Would love this aswell, I can ask the ai to take screenshots from my phone via Opencode web, but it can't show me the screenshot
TheOriginal92 commentedon Aug 31, 2026
Another concrete case for this: I drive a fairly large MCP stack from opencode web (1.18.5 in Docker), and several of those tools return screenshots.
The pipeline works right up to the last step.
session/tools.tsturns MCPimagecontent into adata:<mime>;base64,…attachment, it lands inpart.state.attachments, the SDK exposes it onSessionMessageToolStateCompleted, and the model receives it. Only the UI drops it, so the images are invisible to the person sitting in front of the session — which is exactly the case where you want to see them.Worth noting the same data path also covers the built-in
readtool, which builds identical data URIs intool/read.ts. A UI-side fix would therefore cover both without touching the server.There are now two closed PRs for this (#21352 and #38846), both closed by the automated cleanup without a review, plus one open draft (#39817). Since the contributing guidelines route UI features through a design review first: is there a preferred direction from the team? Happy to test whichever lands.
opencodejr commentedon Oct 29, 2026
Thanks for the detailed request, @neilli418!
To restate it: when a tool returns an image (an MCP
ImageContentblock, orwebfetchon an image URL), the image is sent to the model but never shown in the chat. You'd like it shown under the tool call, with click-to-preview like user-attached images.The current v2 app still works this way. The tool row shows only the text parts of a tool's result. The one exception is the
readtool, which loads its image from disk. Image results from MCP tools andwebfetcharen't displayed. Maintainers will consider this.Related:
read-tool images in the timeline.This can't be built as a GUI plugin yet, because the plugin API has no way to render tool results.