[BUG] Images sent by agent via SendUserFile never render in Desktop app chat (local session, claude.ai webview)

Status Fixed / completed
Reported on v2.1.170
Maintainer reply None cached
Activity 3 comments · opened Jun 12, 2026 · closed Jun 24, 2026

Environment

  • Claude Desktop for Windows (MS Store build) 1.12603.1.0, bundled Claude Code 2.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.log contains 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

  1. Desktop app, local session.
  2. Ask the agent to create a small PNG and send it with SendUserFile.
  3. 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.

View original on GitHub ↗

3 Comments

apiekar · 3 months ago

Confirming on macOS, latest build — still present.

Environment

  • Claude desktop app 1.14271.0 (macOS, Apple Silicon M4), macOS Darwin 25.5.0
  • Bundled Claude Code 2.1.181, local Claude Code session, chat UI = claude.ai webview

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 l at 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.

chaoshuai-ant · 3 months ago

Fixed in the next release!

github-actions[bot] · 1 month ago

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.