Send a file to a running agent

While a task is running you can hand its agent a file — a screenshot of the bug, a failing log, a design reference, a data sample. The file is written into the agent’s workspace and your message names its path, so the agent can open it immediately.

Where the file lands

Every attachment is written to /workspace/attachments/ inside the agent’s workspace, and the message you send gets a line appended: [Attached screenshot: /workspace/attachments/intervention_…_screen.png]. That is the path to reference if you write further instructions about the file.

From the web UI

1. Open the running task’s detail page and find the intervention composer.

2. Attach the file and type your message — for example “the login button overlaps the logo, see the screenshot”.

3. Send. The file is written into the agent’s workspace before the agent is handed your message, so the path it names always exists.

From Telegram

Send a photo to the bot. With exactly one running task the photo attaches to it automatically; with several, put the task id first in the caption and your message after it:

3f9a1c2e-…  the login button overlaps the logo

The bot confirms delivery and the agent receives your caption with the photo’s path appended.

Several files at once

One intervention can carry several attachments. Each is written under its own name and each is named in the message, so the agent can tell them apart. Two files that happen to share a name do not overwrite each other.

Limits

Limit	Value	What happens beyond it
One attachment	4 MiB	Refused with a message naming the limit and the actual size
All attachments on one message	8 MiB	Refused — send them across several messages
Attachments per message	16	Refused

Nothing is ever silently truncated or dropped: an attachment either arrives byte-for-byte intact, or you get an error that says why.

Runner fleets

This works identically whether the task runs on the SupaCloud host itself or was dispatched to a separate runner. The file travels with your message on the same channel, and the machine running the agent writes it — there is nothing to reach across. Interventions, approvals, interrupts and mid-run model or effort changes reach a dispatched task the same way.

Launch-time attachments

Files attached when you start a task follow the same route: they are written to /workspace/attachments/ before the agent’s first turn, on a local run and on a fleet runner alike.

If the agent cannot see images

When the task’s model has no vision capability, SupaCloud describes each attached image in text and appends the description to your message, so a non-vision agent still knows what the screenshot shows. The raw file stays in the workspace either way.

Which model writes that description is a setting, not a fixed choice: Settings → Models → Vision model. Leave it empty and the workspace inherits the instance default; enter a model id to override it for this workspace. The same model is also the fallback the visual-verification judge uses when a project has pinned no judge model of its own.

If no usable vision model is configured — nothing set anywhere, or the configured id is unknown to the model catalog or has no credential — the description cannot be produced. SupaCloud then says so in the task’s activity feed (“… could not be described for this model”) instead of quietly ignoring the picture. The raw file is still delivered; the agent simply cannot read it unless it opens the file itself.

Send a photo with a /run caption (Telegram)

In Telegram you can start a task straight from a picture: send the photo with /run <project> <agent> <prompt> as its caption. The photo is attached to the new task exactly as it would be from the web composer, and the “cannot see images” rule above applies to it unchanged. A photo whose caption is anything else is still delivered to a running task as an intervention.