Remote control: iOS-attached photos silently dropped (empty message, no image block) on desktop session

Same symptom from a slightly different host, plus a static analysis that points at a concrete mechanism lining up with your "no image block" finding.

My setup: Claude Desktop app 1.12603.1 (macOS) hosting the remote-control session (not the VS Code extension), iOS Claude app as the remote client, bundled CLI 2.1.178. For me this has been broken for a long time, not only since the recent iOS update, which I think is consistent with the mechanism below.

I statically analyzed the desktop app bundle and the CLI binary. The image bytes are dropped in the host app, before claude-code ever sees them.

claude-code (CLI) is not at fault. Every image-block constructor copies source.data verbatim from whatever it is handed; none zeroes it for remote-origin messages, and there is no path that resolves an image's bytes by file_uuid (the only by-uuid fetch is document/PDF text). So if the CLI is handed an empty/absent image, it simply forwards that. The empty payload originates upstream.

The host app's inbound handler never forwards inline images. In the local-agent bridge, the inbound user-message handler extracts only:

• text blocks (a helper that concatenates blocks where type === "text"), and
• a top-level file_attachments array, whose schema is a server-side reference ({ file_uuid, file_name, is_image? }) that carries no bytes.

Inline type: "image" / source: { type: "base64", data } content blocks are silently skipped, and the handler calls the session's sendMessage(...) with the images argument hard-coded to undefined. The one function that materializes inline base64 into an image content block is therefore never reached for phone-relayed photos. That matches your observation exactly: the desktop session receives a user message with no image content block.

The app's own code documents the gap. The message-content builder filters images and logs, verbatim, that it is dropping empty-base64 image because an upstream guard is missing. That missing upstream guard is the inbound handler not passing images through.

Why this is consistent with your iOS-update trigger: if the iOS app sends the photo as an inline image content block, the handler above drops it, so no image block reaches the session. If the older iOS app populated something the handler does read and the update switched to inline-image (or to a file_attachments reference whose download then fails and is silently filtered), you would see exactly this regression with the desktop side unchanged.

Suggested fix: have the inbound user-message handler also extract message.content[].type === "image" blocks and pass them as the images argument to sendMessage (which already knows how to build them). For the file_attachments path, add an inline-base64 fallback for when the fetch returns empty (today such failures are filtered out silently).

Environment: macOS, Claude Desktop 1.12603.1, claude-code 2.1.178, iOS Claude app as remote client.

Confirming this on my setup as well.

Symptom: When I attach a photo from the Claude mobile app while
remote-controlling a local Claude Code session, the image is silently dropped.
The text in the same message arrives fine, but the agent receives no image
content block. There is no error on my end (no 400, no failure indicator) - the
message just shows as sent and the model never sees the image.

Environment:

• Mobile app: iOS, app version v1.260611.1 (27595752627)
• VS Code extension version: 2.1.186
• Desktop is unaffected - attaching the same image from the computer works every time.

Regression: This used to work from the phone and stopped recently, which
lines up with the ~2026-06-16 regression noted in this issue.

Note this is distinct from #50681, which is a 400 API error from a malformed
payload. In my case the text goes through and there is no error at all, only the
image is missing. So #53596 looks mis-closed as a duplicate of #50681 and
actually belongs here.

fixed in 2.1.207

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.