SendUserFile renders image deliverables as a generic file chip instead of inline, unlike Read

What happens

When the agent shows me an image two different ways, I get two different results:

• Read <image>.png → the picture renders inline in the conversation.
• SendUserFile with an equivalent .png → I get a generic file chip ("1 file delivered to user", PNG badge + filename + size), not the picture.

Both files were valid PNGs sitting in the same folder, with the same permissions and the same ~110–125 KB size class. The only variable is which tool surfaced them. So it isn't the file, the location, or permissions — SendUserFile simply never uses the inline image-render path that Read uses.

Why this matters

SendUserFile is documented as the tool to use "when the file is the deliverable… you want it surfaced." For an image, the entire point is to see it. Today the agent picks the semantically-correct tool to present an image and the user gets a click-to-open card instead — so the agent is actually better off (mis)using Read to display images, which is backwards.

This isn't platform-specific

Inline image rendering already shipped (#2266, #29254 — both closed/completed); that's the Read path, and it works. But the SendUserFile gap was independently reported from iOS → remote Linux in #61995:

SendUserFile with .svg → file card under the message, not inline

with ask #1:

SendUserFile with an image mime renders the image inline above the message instead of as a generic file card.

That issue was auto-closed as a duplicate of #2266 — but #2266 is specifically about terminal graphics-protocol support, which doesn't address how SendUserFile deliverables are rendered, so the actual point was lost. I now see the identical behavior on the Windows 11 (ARM) GUI client — two different platforms and CPU architectures, same result, which rules out anything OS- or arch-specific.

Ask

When SendUserFile (or any file-delivery path) hands the user a file with an image MIME type (PNG/JPG/SVG/etc.), render it inline / as a thumbnail preview — the same render path Read already uses — instead of (or in addition to) the generic file chip. Falling back to the chip for non-previewable types is fine.

Environment

• Claude Code 2.1.168
• Windows 11 (ARM), GUI client (not raw terminal)
• Repro: have the agent Read a PNG (renders inline), then SendUserFile a second PNG from the same folder (renders as a chip)

Related (all closed)

• #61995 — same gap, iOS / remote Linux, auto-closed as a duplicate
• #2266 / #29254 — terminal graphics protocol (the Read path), completed
• #36088 — auto-display generated images, closed completed ("use Read")