Bounded Python and JavaScript code execution during a Task

Use Code Execution when an eligible Executor needs bounded Python or JavaScript work during a Task. The Platform hosts this built-in Tool and controls its time, memory, dependencies, environment variables, and network access. Your application does not call it through a public SDK method or an SDK Tool endpoint.

Treat Code Execution as one Tool Call, not an Agent

During execution, the Agent Runtime can dispatch one logical Code Execution Tool Call with the selected code and options. The call can settle before any code attempt, or the Platform can make one or more attempts before it supplies one terminal Tool Result to the execution. An attempt, also called a code run, is not an Agent, Agent Identity, Task, Executor, Context, or SDK Tool.

Each attempt receives fresh writable state. Files or process state left by one attempt do not become the next attempt’s state. The Threat model describes the package-snapshot and Tenant-isolation boundary.

Keep every request within the published bounds

The built-in Tool accepts these values:

The published package grammar accepts empty and wildcard version selectors. Use an exact reviewed version when reproducibility matters. A syntax-valid dependency can still be refused by the enforced package policy or because the requested version is unavailable. A package name or version is not evidence that its contents or license were reviewed. The Threat model describes package-preparation network access outside an attempt.

Keep network access explicit

Outbound access starts off for every run. Set allow_network=true to enable it; the domain setting is optional. Omitted or null domains restrict access to the runtime’s language package-registry defaults. allow_network=false is the only current block-all setting. For enabled runs, the domain setting has three meanings:

Network access can let agent-written code read or change an external system. Treat each enabled destination and every value the code sends as an external-action boundary. Do not put credentials or other secrets in the model-supplied environment variables.

An infrastructure failure can cause another isolated execution attempt before a terminal Tool Result settles. Use Code Execution for a material external Effect only when the code uses an independently stable idempotency key that the destination enforces. Otherwise use a custom SDK Tool or remote service that owns authorization, the business-operation identifier, and reconciliation. Fresh writable state is not exactly-once execution.

Interpret the result as a report, not an Effect

When the Code Execution host reports a result, its status is success, error, timeout, or killed. It can carry up to 1,000,000 characters of standard output and 100,000 characters of standard error. The wire contract permits an optional structured return value, but the current host path does not populate it; print values that the execution must observe. If the host does not answer before the Tool deadline, the Platform can instead supply the generic timeout Tool Result described in Authoring SDK Tools.

If the Tool Result settles, the Platform records it in Conversation History and can select it for a later Model Input Context. It reports what the code-execution path observed; it does not independently prove that an external request ran, succeeded, failed, or produced an Effect. Validate any material state change at the system that owns it.

Threat model explains the isolation, risks from output content, and external-network implications. Agent harness defines Tool Call, Tool Result, Action, and Effect.