Execution
An agent can run code in three ways. They share one rule: every one of them is authorized by policy before it runs, and recorded afterwards.Turning them on
execute tool appears only when governance is on and the configured
sandbox can run commands, so an agent never has a way to run code that policy
has not seen. What the sandbox is — network, image, working directory — is
sandbox_manifest, next to sandbox_config
(Sandbox providers); what it asks
for is authorized when the run’s session opens.
What each one is governed as
strict-production allows none of these without a rule you write.
Files
Commands run with the agent’s workspace files in the sandbox’s working directory. After each command, text files it created or changed are copied back as governed workspace writes. The sandbox never mounts your workspace, and a file the policy protects is not copied in or out (security model). Two things never come back: a folder a command made that holds a.git (a
checkout; clone repositories outside the workspace folder, the model is told
so), and a background run’s own records (run.json, events.jsonl), which
also never go in. To copy less, give the bridge glob patterns over workspace
paths; * crosses folders, and the default copies everything:
In the trace
Each run records its sandbox session (with the provider’s own name for it,sandbox_ref), every command (exit code, duration, output size, the rule
that allowed it), every file copy, and every tool call a program made, nested
under its run_code call. Run totals count the sandbox commands. See
Observability.
A sandbox that dies mid-run — the provider stopped it, its lifetime ran out,
someone killed it — is not a slow command: the model is told the sandbox was
lost and that the next command runs in a fresh one (with the workspace files
copied in again, and whatever else was in the old sandbox gone), and the
trace records the session closed with lost: true.
A run that pauses for approval mid-execution, or whose process dies, continues
where it stopped: Durable Runs.