Code Execution: run bounds, isolation, and safety
Code Execution runs bounded Python or JavaScript in isolated sandboxes within a Task, covering run limits, network modes, and safety constraints.
This page covers Code Execution bounds, package reproducibility, network access modes, retry safety, and result interpretation for bounded Python or JavaScript runs.
- Code run bounds: language, source size, time, memory, packages, and output limits.
- Package version pinning for reproducibility.
- Network access modes and external-action boundaries.
- Retry safety and idempotency requirements for external changes.
- Result outcomes: Failed, Outcome unknown, and Blocked.
Summaries were generated by AI.
Code Execution runs bounded Python or JavaScript work within a Task. Use it for calculations, data transformation, or checking generated code. Describe the required result in the Task instruction: the model writes the code and chooses its options. No SDK method runs Code Execution directly.
What one code run can do
Each code run has these bounds:
| Bound | Current contract |
|---|---|
| Language | Python or JavaScript |
| Source code | At most 100,000 characters |
| Run time | 1 to 300 seconds; 30 seconds when the model does not choose a value |
| Memory | 128 to 2,048 MiB; 512 MiB when the model does not choose a value |
| Packages | At most 50; each package request is 3 to 214 characters and includes a version constraint, which can be open |
| Environment variables | At most 50 values, which the model sets |
| Output | At most 1,000,000 characters of standard output and 100,000 of standard error |
- Bound
- Language
- Current contract
- Python or JavaScript
- Bound
- Source code
- Current contract
- At most 100,000 characters
- Bound
- Run time
- Current contract
- 1 to 300 seconds; 30 seconds when the model does not choose a value
- Bound
- Memory
- Current contract
- 128 to 2,048 MiB; 512 MiB when the model does not choose a value
- Bound
- Packages
- Current contract
- At most 50; each package request is 3 to 214 characters and includes a version constraint, which can be open
- Bound
- Environment variables
- Current contract
- At most 50 values, which the model sets
- Bound
- Output
- Current contract
- At most 1,000,000 characters of standard output and 100,000 of standard error
Each run executes in its own isolated sandbox, separate from your systems and from other runs. It starts with fresh writable files and process state. A later run or a retry inherits nothing from an earlier one, so use your own storage when information must persist.
Ask for exact packages when reproducibility matters
The model can request packages for a run, including versions that are not pinned. The package policy can refuse a package, and a requested version can be unavailable. A package name or version does not prove that its contents or license were reviewed. When reproducibility matters, name the exact reviewed versions in the Task instruction.
To prepare a requested package, Duale AI can fetch it from the public package registry of the language when it does not already hold that package. Data protection states what crosses that path.
Keep network access explicit
Network access is off by default. For each run, the model can turn it on in one of three modes:
- the package registries of the language only;
- a list of named domains and their subdomains;
- any destination.
The model chooses the mode for each run, so plan as if a run can reach any destination.
Network access can let generated code read or change an external system. Treat every destination, and the data sent to it, as an external-action boundary. Never put a credential or another secret in the Task instruction or its material: the model can copy it into the code or into the environment variables of a run.
Run code only where a repeat is safe
A retry can run the code again. Use Code Execution for a material external change only when the destination enforces an independently stable idempotency key. Otherwise use an SDK Tool or a remote service that owns authorization, the business-operation identifier, and reconciliation. Fresh writable state does not provide exactly-once execution.
Interpret the result as a report, not an Effect
A run either completes with its output, or fails with a reason: an error, a timeout, or a forced stop, for example after it exceeds its memory limit. A failed run keeps the output captured before it stopped. It also has a Tool Call outcome:
- Failed when the code ran and did not succeed.
- Outcome unknown when a run with network access timed out or was stopped. It can have changed an external system before it stopped.
- Blocked when the package policy refused a requested package.
Print the values the Task needs to use; do not rely on an optional structured return value being present. If no result arrives in time, the Task can receive a timeout result instead.
A reported result tells the Task what the code run observed. It does not prove that an external operation ran or produced the intended change. Verify a material change at the system that owns it. Program output is text you do not control: the Threat model lists it among those sources. Agent harness defines Action and Effect.