[BUG] Images sent by agent via SendUserFile never render in Desktop app chat (local session, claude.ai webview)
Environment
- Claude Desktop for Windows (MS Store build)
1.12603.1.0, bundled Claude Code2.1.170 - Windows 11 Pro 10.0.26200
- Local session (working dir on local disk), chat UI = claude.ai webview inside the desktop app
What happens
When the agent sends image files to the user with the SendUserFile tool, the tool reports success ("N files delivered to user") and the session transcript records correct attachment metadata. But nothing renders in the chat UI — no inline image, no usable preview.
Tested with PNGs from 22 KB (1280x413) up to 6 MB (10000px tall) — none render. So this is not the API image limits (5 MB / 2000px): fully compliant small images fail the same way.
Evidence
Transcript record (session .jsonl) for one of the calls:
{"caption":"...","attachments":[{"path":"F:\\...\\starter-1.png","size":22772,"isImage":true,"media_type":"image/png"}]}
%APPDATA%\Claude\logs\main.logcontains no errors and no file-load attempts around delivery time — silent failure.- Renderer log (
claude.ai-web.log) has no entries at delivery time either.
Likely root cause
Same architecture gap as #48466: the chat UI talks to the local session through the API bridge, which only streams messages and tool results (text). There is no channel for binary file content, so the claude.ai-hosted UI can never fetch local-path attachments. #48466 covered the preview pane in remote-control sessions and was closed as not planned — but this affects inline rendering of agent-sent images even in a plain local desktop session, where SendUserFile is the primary way for an agent to show generated artifacts (screenshots, diagrams, comparisons).
Expected
Images delivered via SendUserFile render inline in chat, or at minimum appear as an attachment chip whose preview opens.
Repro
- Desktop app, local session.
- Ask the agent to create a small PNG and send it with
SendUserFile. - Tool result says "1 file delivered to user" — chat shows nothing.
---
Investigated and drafted by Claude Code (transcript + local logs on the affected machine), filed by the user.
3 Comments
Confirming on macOS, latest build — still present.
Environment
Same symptom: PNG and JPG files delivered via SendUserFile render as blank,
non-interactive cards (type badge + filename + size, no thumbnail, clicking does
nothing). It also affects HTML files, not just images — same blank card.
Silent failure, confirmed in logs: at delivery time there is no file-load or
network attempt and no error in either ~/Library/Logs/Claude/main.log or
claude.ai-web.log. The transcript records correct attachment metadata; the UI just
never renders a preview. This matches the "no binary-content channel from the local
session to the remote claude.ai webview" analysis in this issue.
What works (rules out account/GPU/cache): inline SVG/visualize widgets render
fine in the same session, and user-pasted screenshots are received fine. The same
account renders HTML artifacts inline correctly in claude.ai web mode.
Related but likely separate bug (Artifacts panel): in the same local session the
Artifacts version call fails with HTTP 400 because the local_ session id is used
where a bare UUID is required:
GET /api/organizations/<org>/artifacts/local_<sessionUUID>/versions?source=w
-> 400 "path.conversation_uuid: Input should be a valid UUID ... found
lat 1"The identical call in web mode uses a real conversation UUID and returns 200. Note
that stripping the "local_" prefix yields a valid UUID, so a prefix-strip on the
local-session path would fix that one. Filing as a heads-up; happy to split into its
own issue if preferred.
Fixed in the next release!
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.