What are the sandbox limits of the Claude API code execution tool?

The Claude API code execution tool runs Python and bash in a server-side sandboxed container with internet access completely disabled, 5 GiB of memory, 5 GiB of disk, 1 CPU, and file access limited to the workspace. Containers expire 30 days after creation, and container data is retained for up to 30 days. This is a different design from a coding agent that clones your repository.

What it is

Anthropic describes the tool as letting Claude analyze data, create files, run system commands, and process uploaded files inside an API conversation, in a sandboxed environment. It is documented as generally available on the Claude API, with the page also noting that it is not eligible for zero data retention. That last point matters for compliance reviews, so read the eligibility notes on the page for your own case.

It differs from a hosted coding agent in a basic way. There is no repository clone and no git credential. You pass files through the Files API, Claude runs code in a container, and results come back as text and files.

Documented limits

Because there is no internet, Claude cannot install packages at run time. Only the pre-installed libraries are available. If a task needs a library that is not there, you need another approach.

What this means for risk

Exfiltration over the network. With outbound requests disabled inside the container, the container itself has no route out. Data still returns to you through the API response, and your application decides what to do with it. Treat the returned content as untrusted input, since it came from a model working on data that may include hostile text.

Retention. Container data, including artifacts, uploaded files, and outputs, is retained for up to 30 days according to the documentation. If you upload sensitive files, that retention applies. Decide whether the data may be placed there at all before you build the feature.

Reuse. If you reuse a container across requests to keep files, you also keep whatever earlier requests left behind. Treat a reused container like any reused environment: one trust level, one purpose.

Identity. A container is scoped to a workspace. Check who in your organization can call the tool in that workspace, since anyone who can send requests there can run code in it.

A worked example: analyzing a customer export

An illustrative design for a team that wants Claude to summarize a CSV of support tickets.

1. Strip personal data that the analysis does not need before upload.
2. Upload through the Files API into the workspace for this project.
3. Send a request enabling code execution, and do not reuse containers across customers.
4. Receive the result, validate it as data, and render it without executing anything it contains.
5. Delete uploaded files you no longer need and note the retention window for what remains.
6. Log the request metadata and the container ID so you can trace outputs.

This design uses the no-internet property for what it is good at, a place to compute on data without a path out, and does not pretend it removes retention concerns.

Compare with a coding agent sandbox

Checklist before you ship a feature on it

1. Confirm the data classification allows upload and 30 day retention.
2. Confirm whether your compliance regime needs zero data retention and read the eligibility notes.
3. Limit who can call it in the workspace.
4. Never execute returned code or macros automatically.
5. Do not reuse containers across tenants.
6. Record usage for review.

Mistakes teams make with managed code sandboxes

Treating no internet as no risk. The container cannot reach out, but the data you upload sits there for the retention window, and what comes back flows into your application. Both ends matter.

Using one container for many users. Reuse keeps files between requests. If two users share a container ID, they share files. Create separate containers per user task, and pass IDs back only within one task.

Executing returned artifacts. A generated spreadsheet with macros or a script file is content, not trusted code. Open it in a restricted viewer or treat it as a download from the internet.

Forgetting the audit trail. Record who called the tool, which container ID it used, which files went in, and which came out. If a data question arrives later, that record is the answer.

Assuming parity with other products. Another provider's code tool has different expiry, memory options, and network documentation. Compare facts from each page and avoid carrying assumptions across. The practical lesson is to write down the properties you depend on, with the source and the date you read it, and to recheck when you upgrade.

Review questions for a security team

1. Which data classes may be uploaded to a managed code sandbox, and which may not?
2. Is the 30 day retention acceptable for each class?
3. Who in the workspace can call the tool, and is that list reviewed?
4. How is returned content validated?
5. What happens to containers when an employee leaves?

Try it yourself

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

Look at which tools are exposed to a model and what each is allowed to read or change, then compare that with the fixed limits of a managed code sandbox.

Where Safeguard fits

Safeguard does not operate this tool. Its policies, agent identity, and MCP Guardrail cover agent use inside your organization, and its dependency scanning applies to code your teams ship.

Quick check

Sources

• Code execution tool (Anthropic documentation)

Last reviewed: 19 October 2026.