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 when Atoi needs to read it to answer. This guide follows one attachment from the composer to a reviewed Receipt. Keep a connected repository or service as the source of truth, and treat 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, open it from Ideas or search, 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. Read Task proof on the web, in the Apple app, or in the terminal.
#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 each client today
The web, the Apple apps, Android, the TUI, and the CLI can all send an attachment with a message and attach a context reference. The accepted types, the 25 MB limit, the model check, and the upload states above come from the web app. Apple and Android use their own picker, and the terminal uses its own attachment flow.
An MCP client reads Project, Workspace, Task, and proof records. It cannot send a message or an attachment.
Read the sharing checklist before an attachment leaves your Workspace, or Storage and billing for what Atoi keeps and where.
Was this useful?