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.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’sfiles/ 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 itfiles_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
- Local disk (default)
- S3
- R2
Or from the environment
With noworkspace_config at all, the workspace is read from environment
variables, so a deployment can choose it without code changes:
Options
Every setting is in the agent settings reference.
When things go wrong
ValueError: Tool name conflict: built-in workspace tools reserve these names
ValueError: Tool name conflict: built-in workspace tools reserve these names
One of your tools has the name of a workspace tool. Raised by Rename your tool (
run:read_app_file), or set enable_workspace_files to
False.ValueError: S3 workspace backend requires AWS_S3_BUCKET
ValueError: S3 workspace backend requires AWS_S3_BUCKET
Raised by With a
run when the S3 or R2 settings are incomplete:workspace_config dictionary, the settings must be in it
(s3_bucket, r2_bucket_name, …): the environment is not read.The agent cannot find the file I put there
The agent cannot find the file I put there
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.What the model sees when a file call fails
What the model sees when a file call fails
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.