Open Science lets you attach files directly to your messages — the agent receives them as part of the prompt context, enabling it to analyze data, reference documents, or process images. Any file type can be attached; the agent receives it as a best-effort text resource or binary content block depending on its size and type.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/aipoch/open-science/llms.txt
Use this file to discover all available pages before exploring further.
Attaching Files
Using the attachment button: click the + icon in the bottom-left corner of the composer to open a native file picker. You can select multiple files at once. Drag and drop: drag files from your operating system’s file manager and drop them onto the composer area. Paste from clipboard: paste an image directly from the clipboard into the composer textarea. Open Science detects clipboard items with animage/ MIME type, intercepts the paste event, and stages each image automatically.
Once staged, each attached file appears as a chip above the textarea showing the filename and file size. Click the × on any chip to remove that file from the composer before sending.
How Files Are Sent to the Agent
Before a message is sent, the attached files are read as base64 by the browser’sFileReader API and staged in a temporary upload store via stageFiles. When you press Send (or Enter), the staged files are finalized and passed to the agent in one of three ways depending on the file’s type and size:
| Condition | Delivery method |
|---|---|
| Image files (any size) | Encoded as a base64 image ContentBlock — embedded directly in the prompt |
| Text or JSON files ≤ 1 MB | Embedded as an inline resource block in the prompt context |
| Text or JSON files > 1 MB, or binary files | Passed as a resource_link pointing to the staged file path on disk |
The 1 MB threshold (
MAX_EMBEDDED_TEXT_UPLOAD_BYTES = 1024 * 1024) applies to files whose MIME type starts with text/ or equals application/json. Files above this limit are still fully available to the agent — they are referenced via a resource_link that the agent can read from the filesystem.Staged Upload Lifecycle
Uploads follow a three-phase lifecycle managed by theUploadRepository:
stageFiles — create the staged record
When you attach files,
stageFiles reads each file as base64 content, sanitizes the filename, and writes it to a temporary staging directory under uploads/<project>/.pending/. A unique UploadedAttachment record is returned for each file, containing the id, path, name, originalName, mimeType, and size.finalizePendingSessionUploads — move to the session store
When you send the message,
finalizePendingSessionUploads copies each staged file from the .pending directory into a durable per-session directory (uploads/<project>/<sessionId>/) and updates the attachment record with the new path. The copy uses COPYFILE_EXCL to prevent filename collisions.UploadedAttachment Fields
TheUploadedAttachment type is the attachment record used throughout the upload lifecycle:
| Field | Type | Description |
|---|---|---|
id | string | UUID assigned when the file was staged |
sessionId | string | .pending during staging; the real session ID after finalization |
name | string | Sanitized filename safe for the filesystem |
originalName | string | The original display name provided by the user or clipboard |
path | string | Absolute path to the file on disk (main-process validated) |
mimeType | string? | MIME type of the file, if known |
size | number | File size in bytes, measured after writing to disk |
StageUploadFile Fields
When the renderer callsstageFiles, it sends an array of StageUploadFile objects over IPC:
| Field | Type | Description |
|---|---|---|
name | string | Original filename, used to derive a safe filesystem name |
content | string | Base64-encoded file content (browser FileReader output, data-URI prefix stripped) |
mimeType | string? | MIME type of the file, if known |
Security and Path Validation
All upload paths are validated in the Electron main process before any file operation. TheUploadRepository enforces two layers of checks on every delete or read request:
- Path containment check: the requested path must resolve to a location inside the upload storage root.
- Symlink check: after
realpathresolution, the canonical path is checked again to catch symlinks that start inside storage but point outside it.