Bridge — drive the agent from your phone
Attachments
Files attached to a message can reach the agent — on some paths, within a size limit, and landing on disk rather than in the conversation.
Status: not observed end to end. The contract defines this and both halves are implemented, but no file has yet been watched travelling the whole way. If yours does not arrive you will see it: the agent is told explicitly that an attachment did not reach it, rather than silently working without it.
Which paths carry attachments
This is a property of how the task was created, not of your setup.
| Task created from | Attachments reach the agent |
|---|---|
| a chat message | yes |
| a schedule, a todo, or a sensor poll | yes |
| inside a team run | no |
| delegation from a head agent | no |
Attach a file in chat and the work then fans out into a delegated subtask, and the file does not travel with it. Say what the file contains in the instruction if the subtask needs it.
What happens to a file that does arrive
The bytes are fetched onto disk, into .snaga/attachments/<task id>/, and the
agent is told the path — not the contents:
[ATTACHMENTS: the user attached 1 file(s), saved to the workspace.
Read them with your file tools:
.snaga/attachments/<task id>/a1b2c3d4-report.pdf (48213 bytes)]
That is deliberate: a large document pasted into a message is re-sent with the whole history on every retry, and the gateway caps a request body at 1 MiB. The file goes to disk; the agent opens it with its ordinary file tools.
Filenames are sanitised before they touch a path. The name comes from a client's
file picker, so it is untrusted all the way here; only the final component
survives, only characters that cannot mean anything to a path are kept, and the
file id is prefixed so two uploads called report.pdf in one message do not
collide.
Limits
This client refuses anything over 8 MiB, before spending the fetch. The server's own upload cap is 50 MiB, so the tighter of the two is deliberate: the file lands in somebody's working directory, and nothing in the toolchain reads a 50 MiB binary usefully.
When one does not arrive
An id can still reach the agent with no file behind it: the file was deleted, or its download marker expired, between the task being created and the agent picking it up. The id is sent anyway on purpose — dropping it would mean the agent never learns an attachment was meant to exist.
An id that never named anything you can see is a different case and no longer gets this far: the platform resolves file ids when the task is created and refuses the request outright, naming the id it could not resolve. Only the race survives, because nothing can resolve at creation time a file that still existed then.
So the fetch is attempted, fails, and the agent is told:
[SYSTEM NOTE: 1 attachment(s) the user sent did NOT reach you: report.pdf
(could not be retrieved). Do not guess what they contain. Say plainly that
they did not arrive.]
The underlying error is not put in front of you or the model — it can carry a gateway error page or an upstream trace verbatim. You get the filename and what happened to it; the detail goes to the operator's log.
Why this page is marked unverified
The client half and the server half were built and tested separately, and the schema was checked against the wire contract on both sides. What has not happened is a file being watched from a phone to a working directory in one observed run. Until it has, this page says so.