How do OpenAI Code Interpreter containers expire and handle files?

OpenAI's Code Interpreter runs model-written Python in a sandboxed container. A container expires after 20 minutes without use, after which its data is discarded and cannot be recovered. Memory tiers range from 1 GB by default up to 64 GB and are fixed for a container's life. Files enter and leave through the container file endpoints and message annotations.

What the documentation says

OpenAI's guide describes a container as a fully sandboxed virtual machine where the model runs Python, holding files you upload or files the model generates. There are two ways to get one. In auto mode, the Responses API tool configuration creates a container or reuses an active one from an earlier call. In explicit mode, you create one through the containers endpoint and pass its ID.

The guide recommends treating containers as ephemeral, storing data you need on your own systems, and downloading required files while the container is active. It does not discuss network access on that page, so do not assume either way. Check the current documentation or ask OpenAI before relying on a network property.

File handling

Files in model input are uploaded to the container automatically. Files the model creates are written there and cited in message annotations with the container ID, file ID, and filename. You can download them with the container file content method, and you can also upload, list, and download files manually. Supported formats include CSV, JSON, PDF, Office files, images, ZIP, and many code and text types.

For security design, three things follow.

1. Uploaded content is in the container. Anything you upload can be read by the code the model runs.
2. Generated files are untrusted. A model working on hostile content can produce a file that carries hostile content. Scan and validate before opening or serving it.
3. Archives and documents deserve care. ZIP and Office files are common carriers for malicious content, so handle returned archives and documents like any other untrusted download.

A worked example: a document summarizer

An illustrative design for an internal tool that summarizes uploaded contracts using Code Interpreter.

1. The user uploads a PDF to your service, not directly to the container.
2. Your service removes metadata and checks the file type.
3. It creates an explicit container, so you know the ID and can track it.
4. It uploads only the file needed and asks for a summary as text.
5. It reads the response annotations, downloads any generated files, and validates them.
6. It deletes the uploaded file from the container when finished, and does not rely on expiry alone for sensitive content.
7. It stores the summary and the container ID in your audit log.

The 20 minute expiry is a backstop, not a retention policy. If you need data gone sooner, delete files explicitly.

Choosing a memory tier

The tier is fixed for the container's life, so choose it for the task. A larger tier gives more RAM, and the page notes higher tiers are billed at built in tool rates, which we do not discuss here. For security, a smaller tier limits how much a runaway or malicious computation can consume. Start with the default and raise it only when a task fails for memory reasons.

Pitfalls

• Assuming state persists. After expiry the Python objects are gone. Design for that.
• Letting users reuse containers across tenants. Keep one container per user task.
• Skipping output validation. Returned files and text can carry injected content.
• Ignoring rate limits. An abused feature can hit the organization limit and block legitimate use.

Checklist

1. Use explicit containers for sensitive work so you control IDs and cleanup.
2. Upload the minimum data.
3. Delete files when done.
4. Validate everything returned.
5. Log container IDs with requests.
6. Confirm network behavior with current documentation before design depends on it.

Mistakes teams make with managed code sandboxes

Relying on expiry for deletion. Twenty idle minutes is short, but any operation on the container resets the timer, so a busy integration can keep one alive far longer than you expect. Delete files you uploaded when you are done.

Sharing containers across users. Auto mode can reuse an active container from an earlier call. If your application serves several users, make sure each task gets its own container, and use explicit mode when you need to control that.

Trusting returned files. A document or archive that the model produced after reading hostile content may carry that content forward. Validate type, size, and structure, and scan it where you can before opening.

Ignoring the rate limit as a security factor. A documented per organization limit means a single abused feature can crowd out legitimate use. Add your own per user limits.

Assuming parity with other products. Another provider's code sandbox documents different limits, including network access and retention. Write down the properties you depend on, with the source and the date, and recheck them when you upgrade.

Review questions for a security team

1. Which data may be uploaded into containers?
2. How do we delete files before expiry for sensitive tasks?
3. How are containers assigned to users and tasks?
4. How is returned content validated?
5. Where is network behavior confirmed in writing, since the guide does not cover it?

Try it yourself

Click through it at your own pace, or open it full screen.

Look at what an assistant is connected to and what it can request, which is the surface your uploaded data and returned files pass through.

Where Safeguard fits

Safeguard does not operate Code Interpreter. It can connect to assistants such as ChatGPT, and its MCP Guardrail, agent identity, and policies cover what agents may do in your environment.

Quick check

Sources

• Code Interpreter guide (OpenAI documentation)

Last reviewed: 19 October 2026.