Attachments in the conversation

You can send files and images to the agent along with the message. There are three ways to do it, and all three end in the same place:

1. Choosing a file through the composer’s picker. The native dialog returns the path in one go and respects your system’s window manager.
2. Pasting. A screenshot, an image copied from a page and a file copied in the file manager all work. The bytes come from the paste event itself, not from the system clipboard — because reading the clipboard comes back empty when the image was copied as a file, which was exactly the case that attached nothing.
3. Dragging and dropping the file from your system onto the composer.

Images travel whole; everything else travels as a path

The difference is not aesthetic — it is what the agent can do with the attachment:

• An image travels embedded in the message. It is the only way for the model to see what you sent: a file path would force it to call a tool, which costs a round and an authorisation, and fails when the file is outside the project.
• Any other file travels as a path reference. The agent reads PDFs, notebooks and text better with its own reading tool than with anything we pushed embedded — and a large embedded file would blow the context before getting there.

The file type decides, and there is a ceiling for the embedded path: an image above the ceiling becomes a path reference instead of being refused. The agent still reaches the image, only through the reading tool.

Limits you will run into

Limit	Value	Why it exists
Items per picker gesture	20	It was never a size limit: it is what keeps a “all files in this folder” selection from becoming four thousand attachments in one message.
Thumbnail on the attachment chip	96 px per side	Resizing in the main process avoids shipping 8 MB of photo over internal messaging just to draw a small square.
Image opened at full size	24 MB	A larger photo does not cross the app’s internal messaging: it opens in the system viewer.
Thumbnail source	24 MB	Above that decoding is not even attempted; the chip falls back to the type icon, which is information enough.

Pasted files are written to a temporary folder of their own, not loose in the system temporary directory: that way the original name is preserved without the risk of colliding with another paste. The name is sanitised before becoming a write path.

Conversation on a remote host (SSH)

Here the rule changes, and it is worth understanding why: a local path does not exist on the server. Sending your machine’s path to an agent running on a Linux server produces a “not found” with no useful explanation.

• Images still travel embedded, because they arrive the same way on any host.
• Any other file is uploaded to the host — to a conversation attachments folder in the server account — and the agent receives the path from there. The upload happens over the connection’s exec channel, not over file transfer, because the transfer protocol does not exist when the connection uses the system’s SSH client.
• A failed upload becomes a notice on the message itself, never a non-existent path presented as valid.

Limits worth knowing now

• Do not promise uniform byte delivery. Embedded image and path reference are different behaviours, and what holds on one provider or host may not hold on another.
• What decides the path is the adapter being in use. Where the surface is not on the provider’s structured path, the attachment is still pasted as a path in the text, by the screen itself — it is not the same feature under another name.
• Paste and drag-and-drop were not exercised locally and on a remote host for each publishable provider. That is this page’s pending scenario, and it is what decides whether the limits above can be published as verified behaviour.

State of this page. It describes the next release’s target behaviour, based on inspecting the reference revision’s source code. No scenario was executed in a build during this collection; where there is live measurement, the text says so.