Bug: `SendUserFile` reports success but delivers nothing (VS Code extension)

Looks like same bug Claude Fable suggested I report:

Environment: Claude Code VSCode extension session, driven remotely from the Claude mobile app (remote-control view).

Bug: Images delivered via the harness SendUserFile tool never render in the mobile transcript:

• PNG (640x480) sent with display: "render" -> not rendered
• Same file re-sent with display omitted (client default) -> not rendered

However, the same PNG returned inline as a tool result image (agent viewing the file with the Read tool) renders fine in the mobile view, both times.

Expected: SendUserFile-delivered images should render (or at least be viewable) in mobile remote sessions, matching desktop behavior.

Also noticed: /bug typed in the mobile remote session is not intercepted by the client - it falls through to the model as plain message text, so there is no way to file feedback from the mobile remote view.

`Additional data point: reproduced on native Windows 11, not Remote-WSL, and
symptom 3 isolated with a three-sample control that rules out the three most
likely causes.

Environment

| | |
| --- | --- |
| OS | Windows 11 Pro 10.0.26200 (native, no WSL, no Remote-SSH) |
| VS Code | 1.133.0 |
| Extension | anthropic.claude-code@2.1.234 |
| Model | Claude Opus 5 |

Symptom 3 (SendUserFile) — three samples, one variable changed at a time

All three were sent with SendUserFile in the same session, minutes apart. In
every case the tool returned 1 file delivered to user and the sidebar showed
only the raw tool-call text (IN { "files": [...] } / OUT 1 file delivered
to user) with no file card, thumbnail or preview.

| # | file | location | tracked by git | size | rendered? |
| --- | --- | --- | --- | --- | --- |
| A | gestosc-porownanie.png | outside the workspace (%LOCALAPPDATA%\Temp\claude\...\scratchpad\) | n/a | 2.5 MB | no |
| B | same bytes as A (md5 verified identical) | inside the workspace, but in a .gitignored directory | no | 2.5 MB | no |
| C | assets/images/icon.png | inside the workspace | yes | 17 KB | no |

Because A→B changes only the location, B→C changes only ignore-status and size,
and all three fail identically, this rules out:

• the file being outside the workspace root (a localResourceRoots-style

restriction was my first hypothesis — it is wrong);

• the file being git-ignored;
• payload size (17 KB behaves exactly like 2.5 MB).

The same files render correctly on the paired Remote Control mobile client,
which is consistent with the original report: the data is intact, the sidebar
does not render it.

Symptom 2 (fake user turn) — reproduced on native Windows

Confirming this one outside Remote-WSL. A Read on a 2388 × 1688 PNG was
followed by a turn attributed to the user, containing no user text at all,
only:

[Image: original 2388x1688, displayed at 2000x1414. Multiply coordinates by 1.19 to map to original image.]

The human had typed nothing. This matches the reported threshold (image wider
than ~2000 px, i.e. downscaling occurred).

Worth spelling out why this one is worse than a cosmetic glitch: the assistant
cannot distinguish this injected turn from real user input. In an agentic
session it can land while the assistant is waiting for a human decision, and be
read as an answer that nobody gave.

Note on the documented workaround

#66194 suggests using Read instead of SendUserFile. On this setup that is
not a workaround — Read does not render inline in the sidebar either, and it
is the path that triggers symptom 2.

What does work, for anyone blocked by this

Write the image to a path the user can open outside the extension (their
desktop, or inside the repo) and state that path in the reply as text. Treat
SendUserFile as best-effort for the mobile client rather than as delivery.
`

Another reproduction, with two details that narrow this past what's in the report.

It is not specific to display: "render", and not specific to images. I sent two probes in one session and both were silently dropped:

| # | file | display | result returned | actually appeared |
|---|---|---|---|---|
| 1 | 481-byte SVG | render | 1 file delivered to user. | nothing |
| 2 | 113-byte .txt | attach | 1 file delivered to user. | nothing |

The user saw only the tool-call block itself (IN/OUT) in the transcript — no file card, no side-panel preview, in either mode. So this doesn't look like an image-preview or renderer problem; the whole delivery path appears to be inert, with attach — which should only need a download card — failing identically.

Environment: VS Code extension anthropic.claude-code 2.1.252 (darwin-arm64), macOS 26.6.0. The original report is against CLI 2.1.207/2.1.205, so this has survived a good number of releases.

Why the success return is the expensive part. In the session that prompted this, an agent sent six figures over a long working session and narrated each one as though it had been seen. None had. Because the call returns success, nothing in the loop can detect the failure — not the agent, not any convention built on top of it. The user only discovered it by opening a deployed artifact himself. A failed send would have cost one retry; a silent one cost a whole session of misleading narration.

If a fix isn't near-term, returning an error (or even an explicit "delivery unconfirmed on this client") would be a large improvement over the current success, because it lets callers fall back.

Workaround, confirmed on macOS. Both of these put a file in front of the user reliably where SendUserFile does not:

open <path>                              # default viewer
open -a "Visual Studio Code" <path>      # opens as an editor tab

Caveat worth stating: open returning 0 only means the launcher started — it is no more a delivery confirmation than 1 file delivered was. What makes it usable is that the file persists at a known path, so printing the absolute path alongside gives the user something they can check and contradict.