Upload Files in Chat

Drop a file into a Pinchy chat and the agent receives its content directly — no copy-pasting, no separate upload step.

Supported file types

Saved to the workspace — the agent reads them on demand

PDF (with text extraction and vision analysis)
Text data: .txt, .md, .csv, .json, .yaml/.yml
Images: JPEG, PNG, WebP, GIF, HEIC/HEIF (also sent inline to vision models)

Drop a .csv or a .md just like a PDF: the file lands in the agent's workspace and the agent reads the whole thing on demand. This is the path for data-analysis work, where the agent needs the file as a file it can re-read, slice, and reference.

Sent inline as text — content pasted into the conversation, not stored

Microsoft Word (.docx) — text extracted at upload time
Source code: .ts, .js, .tsx, .jsx, .py, .go, .rs, .sh, .sql, .html, .css, .xml, .toml, and similar

These are pasted into the conversation as text rather than stored, so the agent sees the content immediately without a read step.

Size limit

15 MB per file.

How files are used

For a workspace file (PDF, image, or text data), two things happen:

The file is saved to the agent's workspace at uploads/<filename>. The agent reads it on demand from there.
Images are also sent inline to the LLM when the model supports vision, so the agent can "see" an image without a separate read step.

Word documents and source code are the exception: their content is sent inline as text and not stored in the workspace.

For PDFs, Pinchy automatically picks the best vision-capable model available in your provider configuration. Anthropic Claude and Google Gemini handle PDFs natively; other vision-capable models fall back to a text-and-image extraction step.

For Microsoft Word .docx files, Pinchy converts the document to Markdown at upload time — headings, lists, and GitHub-flavored tables all survive — and ships it directly to the agent as text. No vision model required. Embedded images are replaced with a [image] placeholder until a future release adds vision-based descriptions.

Workspaces are isolated per agent: file-reading tools only see files in that agent's own workspace, never another agent's files or the host system. The user-attached file lives in uploads/; if the agent has Write Files permission and produces a deliverable (an export, a draft, a generated report), it writes to the sibling workbench/ directory instead — that separation keeps "what the user gave me" and "what I made" easy to tell apart. See Agent Workspaces for the full picture.

Chat isn't the only door into uploads/. An agent with email Read access can pull attachments out of a connected mailbox with email_get_attachment, and they land in this same uploads/ folder — readable with the same tools described above. This is how an "invoice email → Odoo" workflow chains together: email_get_attachment downloads the invoice PDF into uploads/, the agent reads it the same way it would a chat-uploaded PDF, and odoo_attach_file attaches it to the matching Odoo record. See Attachments from email and Connect Email for the full flow.

Shared agents

Files uploaded to a shared agent are visible to all users with access to that agent — they live in a workspace that everyone with access to the agent shares. Pinchy shows a reminder of this in the upload UI. If you're uploading sensitive content, use a personal agent instead. See Agent Workspaces for the privacy implications.

Preview attachments in chat

Pinchy renders an inline preview next to your chat message:

PDFs show a small first-page thumbnail. Click to open the browser's PDF viewer in a modal — zoom, page-nav and download all work as you'd expect.
Images render as a thumbnail. Click to enlarge.

Both previews survive page reloads — the file lives in the agent workspace, not in browser memory, so it's still there hours or days later.

Security

Pinchy validates every uploaded file against its actual content, not just the browser-reported MIME type. A file renamed to .pdf that contains executable code will be rejected. Filenames are also sanitized before being written to disk.