Screenshots & attachments

Sending an image#

Attach an image to a message the way you would to anyone, and put the instruction in the same message:

[screenshot]  the spacing on this button is wrong, tell claude

The image rides along with whatever session command that message produces — starting a new session, or sending a follow-up to an existing one. Up to four images per command.

What the bridge does with it#

Nothing about this path trusts a filename, an extension or a Content-Type header. The bytes are what decide.

1. The control plane fetches the image from the messaging provider with a 15-second timeout and a hard byte cap, sniffs the real image type from magic bytes, hashes it, and stores it at an opaque path in a private bucket.
2. The bridge never sees the provider's URL. It receives a device-bound, short-lived reference: an attachment id, a signed download URL good for ten minutes, the expected sha256, the size and the MIME type.
3. The bridge downloads it with its own 15-second timeout, refuses anything larger than the declared size, and rejects it if the hash does not match or if the magic bytes are not one of the four accepted image formats.
4. It writes the file mode 0600 into ~/.pagr/tmp/, passes that local path to the agent, and deletes it in a finally block as soon as the agent call returns — whether it succeeded or not.
5. It reports back an attachment.consumed event with the id and whether it worked. No image bytes are ever sent to the cloud by the bridge.

Limits#

What is not supported#

• Video, audio, PDFs and archives. Only the four image formats above pass the sniff; anything else is rejected as unsupported.
• Images out of Pagr. Agents report back in text. Pagr does not send you screenshots of your own machine.
• Attachments in the dev simulator. The local /dev/imessage simulator has no attachment path; images need a real messaging provider.

What the cloud stores about an attachment, and for how long, is set out in configuration.