Prerequisites
- A configured object store behind the artifact service
- An agent equipped with a tool that reads files — the shell
(
agentarea/shell) or the file tool (agentarea/files) - The file model for how task scoping works
Steps
Stage the file and get a ref
Two ways, and they produce the same kind of The response carries The response gives
staging/{id}/{filename} ref.Server-proxied, for small files and quick scripting. One request, no checksum
to compute, but the bytes pass through the API process:ref, filename, size, sha256, and content_type.Presigned direct upload, for large files or when you want content
verification. Pick this when the file is big enough that proxying it is
wasteful, or when you want the store itself to reject a corrupted body:ref, upload_url, and expires_in (3600 seconds). The
declared SHA-256 is bound into the signature as ChecksumSHA256, so the object
store rejects a body that does not hash to it. Upload with:Create the task with the refs
Pass the refs in The API HEADs each ref to resolve its verified digest, size, and content type,
then copies it server-side into the task’s content-addressed store. The bytes
never transit the API process on this leg.
attachments:Let the agent find them
Each attachment lands at
inputs/attachments/<filename>, and the agent is told
so in its prompt — the exact relative paths are listed, with instructions not to
ask for the files again. Before the first bash command runs, the shell tool
copies the task’s durable inputs onto the sandbox filesystem at the same relative
paths, so cat inputs/attachments/report.csv works.Files staged under a project prefix are materialized the same way at
inputs/project/.Verify
List what the task actually received:inputs/attachments/. To confirm they reached the
sandbox disk rather than only durable storage, have the agent run
ls -la inputs/attachments/ and check the event stream for the output — the file
should be listed with its expected byte size.
Troubleshooting
422 "Invalid attachment ref"
422 "Invalid attachment ref"
The ref does not begin with
staging/ . Only staged refs are accepted; a
workspace path or an arbitrary object key is rejected. Re-stage with
purpose=attachment or the presigned endpoint.404 "attachment ref not found"
404 "attachment ref not found"
The staging object is not there — usually the presigned PUT was never
completed, or it failed the checksum and the store discarded it. Confirm the
upload returned 200 before creating the task.
413 on upload or on task create
413 on upload or on task create
A single attachment is capped at 268435456 bytes (256 MiB). The task’s whole
durable workspace is separately capped, so several large files can pass
individually and still exceed the aggregate. See limits
.
Two files with the same name and only one arrives
Two files with the same name and only one arrives
They do not collide — duplicate basenames are disambiguated
deterministically, so a second
report.csv becomes report-1.csv . Tell
the agent to expect the suffixed name, or stage with distinct filenames.The agent cannot find the files on disk
The agent cannot find the files on disk
Materialization happens once per shell session. If the sandbox pod was
replaced mid-task, the inputs are not copied again, so the durable copy
exists while the disk one does not. The file tool still reads them, because
it falls back to durable storage on a miss; bash does not. Check whether the
pod was reclaimed — see
debug a failed task .
Related
Run a command in a sandbox
Using the files
Collect artifacts and logs
Getting results back
Limits
Size ceilings
The file model
Why inputs are task-scoped
Artifacts
The durable store behind this