Skip to main content

Workspace Files

Every agent has a workspace: a folder where it writes notes, plans and finished work with file tools, and where you can put files for it to work on. It is on local disk by default (./workspace/files/), or in S3 or R2 when several machines need the same files.

The agent writes a file

Workspace files are on by default; there is nothing to switch on.
The agent’s notes/plan.md is ./workspace/files/notes/plan.md on your disk. What it writes will differ on your run; where it lands will not.

Give the agent your files

To give the agent existing files — a project to review, data to analyze — put them under the workspace’s files/ folder before the run. This example also moves the workspace to ./review-ws:
review-ws/files/project/app.py on disk is project/app.py to the agent’s tools. When the agent runs commands in a sandbox, its workspace files are copied in too.

Work in a directory you already have

To have the file tools work in an existing directory instead of copying files in, name it files_dir. The runtime’s own files (traces, offloaded results) stay in workspace_dir, out of your directory:
myproject/app.py is app.py to the tools, and nothing of the runtime’s was written into myproject. files_dir is for a local workspace; with S3 or R2 it is refused. The Harbor integration uses it to put the agent’s files in the task’s own directory.

How it works

The workspace has three areas: The agent works in files/ with these tools: These are workspace tools, not a shell: every path is relative to files/, and a path that leads outside it is refused. They work the same on local disk, S3 and R2. Their names are reserved while workspace files are on, so give your own tools other names. Under governance each is a capability — workspace.files.read, .write, .delete, .move, .clear — that a policy can allow, ask about or deny (security model).

Where the workspace lives

One machine. Files survive restarts; other machines cannot see them.

Or from the environment

With no workspace_config at all, the workspace is read from environment variables, so a deployment can choose it without code changes:
A workspace_config you pass replaces these variables entirely: none of them is read, so {"workspace_backend": "s3"} alone fails for want of a bucket even when AWS_S3_BUCKET is set. Pass everything the backend needs in the dictionary, or pass no workspace_config and set it all in the environment. (For S3, boto3 still finds credentials its own way when none are given.)

Options

Every setting is in the agent settings reference.

When things go wrong

One of your tools has the name of a workspace tool. Raised by run:
Rename your tool (read_app_file), or set enable_workspace_files to False.
Raised by run when the S3 or R2 settings are incomplete:
With a workspace_config dictionary, the settings must be in it (s3_bucket, r2_bucket_name, …): the environment is not read.
Seeded files belong under files/: ./workspace/files/project/app.py, not ./workspace/project/app.py. And the workspace is relative to the working directory the agent runs in unless workspace_dir is absolute.
A failed file call is an answer to the model, not an exception; it usually corrects itself. It is recorded as the tool call’s error (outcome error in the trajectory), with the same text. For example:
write_file in create mode on an existing file answers with a preview of it and Use mode='append' or mode='overwrite'.

Next

Context engineering

Large tool results saved as artifacts, and context kept under the limit.

Execution

Commands in a sandbox, with the workspace copied in and out.

Memory

The conversation, kept across restarts.

Agent Skills

Instructions and scripts the agent uses when a task calls for them.