Remote Control (macOS desktop app host + iOS): attached photos never reach the model (no image content block in the session)

Summary

Photos attached from the iOS Claude app to a remote-controlled Claude Code session hosted by the macOS desktop app never reach the model. Attaching/sending appears to succeed on the phone, but the desktop session receives a user message with no image content block (an effectively empty message).

Why this is high impact

The only known workaround is to place the image in a folder on the host machine and have Claude Read it locally. But a remote client cannot be assumed to have local filesystem access to the host, so for Remote Control sessions this workaround does not generally apply. Image input over Remote Control therefore has no reliable recourse today.

Environment

• Host: Claude Desktop app 1.12603.1 (macOS, Apple Silicon), hosting the remote-control session
• Bundled CLI: 2.1.178
• Remote client: Claude iOS app
• Mode: Remote control

Repro

1. Run the Claude desktop app with remote control enabled.
2. From the iOS app, open the remote session.
3. Attach a photo and send it (with or without accompanying text).
4. The phone shows it as sent; the model replies that no image arrived.

Root cause (static analysis of the desktop app bundle and the CLI binary)

The image bytes are dropped in the desktop host app, before claude-code ever sees them.

• claude-code (CLI) is not at fault. Every image-block constructor copies source.data verbatim; 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). A handed-empty image is forwarded as-is and the API rejects it with "image cannot be empty".
• The desktop app's inbound handler never forwards inline images. In the local-agent bridge, the inbound user-message handler extracts only text blocks and a top-level file_attachments reference array ({ file_uuid, file_name, is_image? }, which carries no bytes). Inline type: "image" / source: { type: "base64", data } content blocks are silently skipped, and it calls the session's sendMessage(...) with the images argument hard-coded to undefined. The single function that materializes inline base64 into an image content block is therefore never reached for phone-relayed photos.
• 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.

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 via the message-content builder). For the file_attachments path, add an inline-base64 fallback for when the fetch returns empty (today such failures are filtered out silently).

Related

Same underlying drop as #68831 (VS Code extension host), #64240, and #68460, and the older #34338. Filing separately for the macOS desktop-app host.