Files and attachments
Attach a supported file to a Thread, state its purpose, watch the upload and Task, then inspect the Receipt before sharing.
Attach a file only when its contents are needed for the current request. Keep a connected repository or service as the source of truth, and use an uploaded copy as working context.
#1. Arrive and open a Thread
Sign in and open the Thread that should own the work. Check its audience before you add private material. On the web, use /c/<thread> or open the Thread inside its Project.
#2. Choose a supported file
Open the composer's add menu and choose a file. The web picker accepts these types:
| Kind | Accepted type |
|---|---|
| Images | Any image/ MIME type |
| Text and source | Any text/ MIME type |
| Documents | application/pdf |
| Structured data | application/json |
Keep each file at or below 25 MB. Atoi rejects empty files and other MIME types. An image also needs a model that can see images.
Atoi checks the file's MIME type, not its name. Renaming a binary to
.txtdoes not make it text.
#3. Wait for the attachment state
Read the chip beside each attachment. Remove a rejected file, retry a failed upload, or wait for an attachment identity before you send. Choosing a local file does not mean it reached the Thread.
#4. Ask with an explicit purpose
Tell Atoi what the file is and what outcome you want. Ask it to compare a screenshot with the current page, extract decisions from a PDF, or change a named source file. The attachment alone does not state the job.
Use a context reference instead of another upload when the material already lives in a Project, Connection, or Workspace.
#5. Answer an Ask
If Atoi asks which file wins, who may see it, or whether it may change the source, read the options and answer in the Thread or Inbox. On a client without Inbox decisions, open the same record on the web or in the terminal.
#6. Watch the Task
Long file work can become a Task. Open it from the Thread and watch the state. Use the terminal when you need to start, cancel, or continue the Task; use the web, Apple app, or terminal when you need to read Task proof.
#7. Read the Receipt
Check Result, Changes, Checks, and Proof. Confirm which input file Atoi used, whether any output is a new artifact or a change to the source, and whether the checks opened or parsed the file successfully.
#8. Review before you share
Open every returned artifact and remove keys, private paths, personal data, and internal screenshots before you add someone to your Workspace or publish. An uploaded copy never replaces the original, and sharing a Thread can expose its history. Follow the sharing checklist.
#Know what kind of file you have
- An attachment is working context for one Thread.
- A Project file is material the whole Project can use.
- A Project document is durable writing, such as a plan.
- A connected repository or service remains the source of truth.
#On this surface today
Every client (web, Apple, Android, TUI, and CLI) can send attachments with a message and attach context references. The accepted types, the 25 MB limit, the model check, and the upload states described above come from the web app; the picker and upload states may differ on other clients.
MCP cannot send chat messages or attachments. Task proof is readable on the web, in the Apple apps, in the TUI, and through the CLI and MCP; starting, stopping, and continuing a Task works only in the TUI and through the CLI and MCP.
#Where it differs
- Compared with the web, Apple and Android send attachments with a message, but their picker, validation, and upload states may differ.
- Compared with the web, the TUI and CLI use terminal-native attachment and context flows instead of the web file picker.
- Compared with the web, MCP verifies Project, Workspace, Task, and proof records, not chat attachments.
Was this useful?