Photo attachment sent as first message to a stale/long-running session silently fails to arrive

Summary: Sending a photo (or photos) as the entirety of the first message to a stale/long-running Claude Code session — no accompanying text — silently fails to arrive. No error is shown; the assistant's reply correctly reports seeing no attachment at all (not a garbled/partial one). Resending the identical image(s) alongside a text message in the same or next turn works reliably.

Reproduced three times independently:

• 2026-07-11: An image uploaded to a long-running session (asking about a web page) was never seen by the session — no attachment processed, no error surfaced. Confirmed the image was genuinely visible in the user's own client-side chat history, ruling out "never actually sent."
• 2026-07-14: Same pattern recurred in a different long-running session — a photo sent cold (no text) to an already-long-running session didn't come through; resending after adding a text message worked.
• 2026-07-15: Reproduced again, this time observed directly by the assistant in the same conversation, back to back: four screenshots sent as the entire first message after a gap in a multi-day session did not arrive (the assistant's reply correctly stated it saw no email/attachment). The user immediately resent the identical four images alongside a short text message in the very next turn, and all four arrived and were successfully read.

Pattern: the trigger appears to be (1) a session that has been running for a while / is not freshly opened, and (2) an attachment sent completely alone, with no text in the same message. Adding any text to the same message as the attachment reliably fixes it.

Impact: silent data loss from the user's perspective — no error, no indication the attachment didn't arrive, discovered only because the assistant's reply made clear it hadn't seen anything.

Workaround (confirmed effective across all 3 occurrences): always include a short text message in the same send as any photo/attachment, especially to a session that's been open for a while — never send an attachment completely alone.

Related to a separate but similarly-shaped bug already reported by the same reporting account: queued text lost when switching away from a busy session and back (issue #77451). Both look like client-side message/attachment-delivery bugs in Remote Control, not server-side model issues.