[FEATURE] VSCode extension: render images inline in the chat panel instead of the "[Image]" placeholder

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Claude Code VSCode extension's chat webview never displays an image to the user. Every path an image can take into the transcript ends at a text placeholder:

| Path | What the user sees |
|---|---|
| Read tool on a PNG file | [Image] |
| MCP tool result with an image content block ({type:"image", data, mimeType}) | [Image] |
| Markdown image syntax in an assistant reply (![alt](file:///...) or data URI) | [Image] |
| Raw <img> HTML in an assistant reply | escaped, shown as literal text |

Notably, the markdown renderer parses image syntax and deliberately substitutes the same [Image] placeholder used for tool results — so an image node type exists in the renderer; only the emit is stubbed out.

The model sees these images fine (vision works); only the human can't. For any visual workflow — agents taking screenshots of a running app, generating charts, iterating on UI — the user must open files manually to see what the agent is looking at.

This looks like an implementation gap rather than a platform limit:

• The chat panel is a standard VSCode webview; webviews render <img> with data URIs and vscode-webview-resource URIs today (the extension already uses base64 data URIs for its fonts). Other chat extensions (e.g. Copilot Chat) render images inline in the same host.
• #55863 showed the extension webview bundle receives message types it has no renderer for — the CLI and webview have separate rendering pipelines, and the webview is missing several emitters. Image blocks appear to be the same pattern.

Environment: extension v2.1.215, CLI v2.1.205, Windows 11 (behavior is platform-independent).

Proposed Solution

When a transcript entry contains an image content block (tool result or user attachment), render it inline in the webview — a constrained-height thumbnail that expands on click, or that opens the source file in an editor tab, would be plenty.

Markdown ![...]() image rendering would be a welcome second step, but tool-result image blocks are the high-value case: that's how MCP servers and the Read tool return visual state.

Alternative Solutions

Current workaround: instruct the agent to open the saved image in a VSCode editor tab (code <path>) after capturing it. It works but breaks conversation flow and requires every MCP server / prompt to carry that instruction.

Claude Desktop and claude.ai render the identical image content blocks inline, so switching clients is the only zero-effort alternative today.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

We use an MCP tool that captures screenshots of a running application so the agent can iterate on visual state. The model sees the screenshots and works with them fine — but the developer watching the conversation sees only [Image] and has to ask the agent to open the PNG in an editor tab as a workaround. Claude Desktop renders the identical MCP response inline.

Additional Context

Related issues:

• #55863 — webview lacks renderers the CLI has (closed, not planned)
• #20529 — Mermaid rendering in the extension webview (closed, not planned)
• #36088 — auto-display generated images inline in chat