Skip to main content
Give a Response access to the sandbox platform through either shell or code_interpreter. Both tools run on the same sandbox platform and return execution output to the model so it can continue its response. Use shell for broader workspace tasks: running commands and scripts, working with files, and combining command-line tools. Use code_interpreter when the task is specifically to write and run code, such as a calculation or data analysis. Shell can run code too; the distinction is the interface and kind of task you want to give the model. For sessions and commands controlled directly by your application, use the standalone Sandbox API.

Choose a tool

The API key needs both read:sandbox and write:sandbox, as well as permission to create responses. The examples use X-On-Behalf-Of to keep execution scoped to one end user; replace its placeholder with your end-user ID. Omit it consistently if your application operates as the API-key identity. The OpenAI SDK examples use its custom-request method to send MKA1 tool configuration without changing field names to match another provider’s tool types.

Run a shell command

This request lets Responses provision the sandbox. The model decides when to invoke the tool; the prompt explicitly asks it to run a calculation and report the result.

Analyze an uploaded file

Upload a CSV file first and replace <file-id> with its file ID. The automatic code-interpreter container accepts file_ids so the model can analyze the supplied file. This example expects a numeric amount column.

Reuse an existing session

Use an existing session when your application needs to prepare a workspace or retrieve files directly:
  1. Create a session and wait for it to be running.
  2. Upload your input files if the task needs them.
  3. Set the shell environment to container_reference and use that session’s ID.
  4. After the response finishes, inspect or download the workspace files through the Sandbox API.
The request below creates a small CSV artifact in the selected workspace. Replace <session-id> with the ID of the running session. Use the same API key and end-user identity used to create it.
For code_interpreter, pass the existing session ID as the tool’s container string instead of an automatic-container object.

Retrieve generated files

A model’s statement that it wrote a file is not the file itself. For the existing-session example, inspect the workspace and download /workspace/squares.csv using the same session ID and its session token. Check that the file exists before treating the task as complete. Download artifacts before terminating the session or allowing it to expire. The standalone guide covers file transfer, workspace inspection, and session-token handling in each supported client.

Session lifetime and identity

Automatically created tool sessions use the gateway’s default idle timeout and can be reused for the same caller. Do not assume each response starts with an empty workspace. To control session lifetime or prepare a specific workspace, create the session explicitly and pass its ID. Session access is scoped to the organization, team, and user. Keep X-On-Behalf-Of consistent when creating, using, and downloading from a session. A different end user cannot reuse that session simply by knowing its ID. For an explicitly managed session, terminate it once the response and any downloads have finished. See lifetime and states for expiration behavior.

Inspect results and handle failures

Check the response status and error before relying on its output. Inspect tool output as well as the final answer: a completed response can still describe a command that failed. Confirm expected artifacts through the Sandbox API. For longer execution, use background responses and wait for completion before downloading artifacts or terminating the session. Avoid blindly retrying a command that may already have changed the workspace.