How to Accept OpenAI Hosted Sandboxes? 2026 Agents API Cloud Agent Launch Checklist

A demo runs once, but the next Agent run loses its files, retries an external write, or fails without an audit trail.

The fastest fix is to use the OpenAI Hosted Sandboxes acceptance checklist before launch: approve the workload boundary first, then verify permissions, dependencies, file lifecycle, network behavior, recovery, observability, and cost controls. Hosted Sandboxes can accelerate code-executing Agent validation, but they should not be treated as a production environment by default.

Who should use this checklist?

This guide is for Agent developers who need a model to run code or handle files safely.

It is also for platform engineers managing credentials, sandbox policies, network access, and logs, plus technical leads deciding whether a hosted environment can support a long-running workflow.

Last updated: September 22, 2026. Facts about OpenAI Agents API capabilities and sandbox behavior should be rechecked against the official Agents API introduction, the current sandbox documentation, and the relevant release notes before approval.

Start with the workload boundary, not the API call

The first acceptance decision is not whether the Agent can call a tool. It is whether the task belongs in a hosted execution boundary.

Use Hosted Sandboxes as a candidate when the Agent needs to:

• Run bounded scripts or transformations.
• Generate files that can be reviewed or downloaded.
• Process user-provided documents under a defined retention policy.
• Produce reports, structured data, or other reversible artifacts.
• Validate an OpenAI Agents API workflow before committing to a larger platform design.

Treat the workload as a gray-area candidate when it must contact an external service. You need to verify outbound network behavior, authentication, timeout handling, and whether a retry can repeat an external action.

Do not move directly to production approval when the task:

• Handles regulated or highly sensitive data without a documented isolation and retention model.
• Requires private network paths, internal databases, or complex routing.
• Performs irreversible writes such as financial actions, account changes, or destructive data operations.
• Depends on a long-lived local filesystem as its source of truth.
• Needs a specific operating system, hardware device, region, or network topology that the hosted environment does not explicitly guarantee.

The official OpenAI material describes Agents API and SDK capabilities, but product documentation is not a substitute for your own workload acceptance test. Resource limits, regional availability, billing, network access, and permission behavior can change. Verify the current version before you promise a delivery date or operating model.

A procurement view of the boundary

Advantages of Hosted Sandboxes

• Faster path from an Agent demo to a repeatable execution test.
• Less infrastructure to maintain during early validation.
• A clearer place to isolate code execution from the main application process.
• Useful separation between model instructions and the execution environment when tools are narrowly scoped.

Risks that require an explicit owner

• Temporary files may not have the lifecycle your application assumes.
• Dependency installation can become a hidden source of failed or non-reproducible runs.
• Broad tool permissions can turn a harmless instruction into an excessive filesystem or network action.
• A retry can duplicate an external side effect unless the operation is idempotent.
• Logs may show that a task failed without showing enough context to reconstruct why.

If your team cannot name the owner for each risk, the sandbox is not ready for a production-like trial.

First decision: what should remain hosted?

Use this comparison before spending time on implementation details.

This is a decision tool, not an OpenAI capability matrix. “Candidate” means you still need evidence from your own tests and the current official documentation.

Step one: define permissions and data boundaries

Before the first execution, create a short permission contract for the Agent. It should answer five questions:

1. Which tools may the model call?
2. Which directories may each tool read or write?
3. Which file extensions or MIME types are accepted?
4. Which network destinations are allowed?
5. Which credentials can be injected, and for how long?

Use the narrowest answer that still supports the task. For example, a report-generation Agent may need to read an input directory and write an output directory. It does not automatically need access to the application source tree, a home directory, or every environment variable.

Keep secrets out of prompts and ordinary files. Inject task-scoped credentials through the supported runtime mechanism, and make sure generated artifacts cannot accidentally include them. Test failure behavior with an invalid or expired credential. A clean denial is better evidence than a successful call made with an overly powerful secret.

The OpenAI explanation of computer environments is useful for separating an Agent’s ability to operate in an environment from your own authorization decision. The model can be capable of using a tool without being authorized to use it for every task.

For data handling, write down:

• What enters the sandbox.
• What may be copied into logs.
• What remains after the task ends.
• Where output files go.
• Who can download or inspect them.
• What happens when the task is cancelled.

This is also the point to decide whether a hosted environment is unsuitable. If you cannot explain the file and credential boundary in a short review, stop before adding more tools.

Step two: prove dependencies, files, and restart behavior

A common acceptance mistake is running one successful script from an already prepared environment. That proves very little. Your test should begin from the state a new task is expected to receive.

Use a repeatable sample that includes:

• A known input file.
• A declared entry point.
• At least one required package.
• A generated output artifact.
• A deliberate failure branch.
• A second run after interruption or restart.

Record the exact installation command, package source, expected version range, and exit status. Do not assume that a package installed during one run will be available to the next run unless the current documentation explicitly defines that lifecycle.

The file test should cover both small and realistic artifacts. Confirm that the Agent can locate the working directory it was given, distinguish input from output, and return the result through the intended download or handoff path. Then remove the local state and repeat the task. If the second run succeeds only because the first run left behind a hidden file, you have found a deployment defect.

OpenAI’s sandbox Agent documentation should be used alongside your implementation notes. It describes the supported SDK pattern, but your acceptance record must still capture what happened in your selected runtime.

Observable evidence for this stage

Approve the dependency and file stage only when you can show:

• A fresh task installs or accesses its declared dependencies through a documented process.
• The entry point works from the expected working directory.
• An input file cannot be overwritten accidentally by the output path.
• A generated artifact is available through the intended handoff method.
• A restarted task does not silently rely on stale state.
• A failed task leaves a clear status and an understandable partial-output policy.

FAQ: production suitability and file handling

Can OpenAI Hosted Sandboxes be used for production?

They can be a strong fit for controlled validation and some staged workloads, but you should not treat a hosted sandbox as a complete production platform by default. Confirm the current resource, network, persistence, billing, and regional rules in the official documentation. Sensitive data, complex private connectivity, and irreversible external writes usually require a separate isolation design.

How can I restrict file and network access for an Agents API sandbox?

Start with an allowlist of directories, file types, tools, and destinations. Inject only task-specific credentials, keep secrets outside the working directory, and test no-network and restricted-network modes separately. A tool being callable by the model does not mean it should have broad filesystem or outbound access. Record every attempted access and the resulting decision.

What should I check before launching cloud AI agent code execution?

Run repeatable tests for dependency installation, entry-point behavior, working-directory assumptions, generated files, timeouts, interruption, retry behavior, and partial output retention. Then confirm that requests, tool calls, execution results, errors, artifacts, and resource usage are observable. A single successful demonstration is not enough evidence for launch approval.

How should OpenAI Hosted Sandboxes handle dependencies and persistent files?

Treat installed packages and local files as disposable until the current documentation confirms their lifecycle. Define a reproducible installation step, pin or verify dependency versions where possible, and upload required inputs explicitly. Store durable outputs outside the temporary execution area through an approved path. Test a fresh run and a restarted run to expose hidden state.

Step three: test network limits, timeouts, and recovery

The gray area between “code execution” and “production Agent” is usually network behavior. Run the same task under three conditions:

1. No network access.
2. Restricted access to an explicit allowlist.
3. A real external service call with a test credential and a reversible operation.

For each condition, record whether the request is blocked, delayed, retried, or reported as an application error. Do not infer network policy from a single successful call. A service may be reachable during one test and unavailable under another route or policy.

Your timeout test should interrupt a task at a controlled point. Then check:

• Does the caller receive a definite timeout or cancellation status?
• Is the process actually stopped?
• Are temporary files removed or retained?
• Does an automatic retry start from a clean state?
• Can the same external action be performed twice?
• Can an operator identify the original attempt and its replacement?

Design every external write with an idempotency strategy where possible. If an Agent creates a ticket, uploads a file, or changes a record, a retry must not create an unexplained duplicate. If idempotency is impossible, require human approval or move that operation behind a service designed for transactional control.

The Agents SDK running and tracing guidance can help you structure runtime observation. It does not remove the need to test the failure modes of your own tools.

Scenario: a report Agent fails halfway through

Suppose an Agent reads several files, generates a report, and sends the report to another service. The code may execute correctly, yet the workflow can still fail in three different ways:

• The process stops after generating a partial report.
• The network request times out after the receiving service accepted the file.
• A retry generates a second report and sends it again.

Your acceptance test should force each condition. The expected result must specify whether the partial file is deleted, marked incomplete, or retained for investigation. It must also specify how the operator learns whether the external service accepted the previous request.

If the answer is “check the sandbox manually,” the workflow is not ready for unattended operation.

Step four: make logs and cost controls part of acceptance

A production candidate needs more than a final success message. At minimum, your audit record should connect:

• The Agent request and a correlation identifier.
• The selected tool and its arguments, subject to secret redaction.
• Sandbox start, stop, timeout, and cancellation events.
• Dependency installation results.
• Process exit status and error output.
• Input and output artifact identifiers.
• Network decision or external service response.
• Retry and recovery actions.
• Usage and billing-relevant information available through the supported interface.

Use the Agents SDK tracing documentation to review the available tracing model. Also review the usage documentation so your application can associate execution activity with an internal project, tenant, or cost center where supported.

Do not invent a price ceiling from a generic example. OpenAI resource pricing, availability, and billing rules must be checked on the current official pricing material before you set a budget. Your engineering control can still be concrete:

• Reject tasks that exceed the approved execution duration.
• Cap concurrent tasks according to your tested capacity.
• Limit input size and generated artifact size.
• Stop repeated retries after a defined policy decision.
• Alert when usage crosses the team’s approved budget.
• Require approval before enabling external writes.

The exact threshold belongs in your service configuration and procurement record, not in a generic blog post. The acceptance evidence should show that the limit triggers predictably and that an operator can identify the task that caused it.

The Go/No-Go acceptance review

Use the following checklist in a launch review. Mark each item only when you have an observable test result, log record, or approved documentation reference.

Go when all required controls have evidence

• [ ] The workload is classified as bounded execution, file processing, reversible external work, or a higher-risk category.
• [ ] Sensitive data, credentials, and generated artifacts have documented boundaries.
• [ ] Agent tools are allowlisted by task rather than enabled globally.
• [ ] Read and write directories are separated where the workflow permits it.
• [ ] Dependencies install or load through a repeatable process.
• [ ] The entry point works from a clean starting state.
• [ ] Generated files can be retrieved through the intended path.
• [ ] A restart test proves whether local state survives and whether that behavior is acceptable.
• [ ] No-network and restricted-network tests have been completed.
• [ ] External calls use reversible or idempotent test actions.
• [ ] Timeout, cancellation, interruption, retry, and partial-output behavior are recorded.
• [ ] Logs connect the request, tool call, execution result, artifact, and error.
• [ ] Secrets are redacted from prompts, logs, command output, and files.
• [ ] Duration, concurrency, retry, resource, and budget safeguards are active.
• [ ] An operator can stop a running task and determine what happened afterward.
• [ ] The team has a rollback or migration path if the hosted boundary no longer fits.

No-Go conditions

Reject the launch if any of these statements is true:

• The Agent can reach systems it does not need.
• The team cannot determine whether a file persists after restart.
• A retry can repeat an external write without detection.
• Logs omit the tool arguments or execution outcome needed for investigation.
• Credentials are copied into a working directory or artifact.
• The workload requires private connectivity that has not been tested.
• A failed task leaves an unknown state in an external system.
• The only evidence is a successful demonstration from a prepared environment.

When should you move beyond Hosted Sandboxes?

Continue with Hosted Sandboxes when the workload is bounded, the data is appropriately classified, the network is simple, the file lifecycle is explicit, and every failure path has an operator-visible result.

Evaluate a private sandbox or VPC when you need private service access, controlled egress, dedicated identity boundaries, stricter data residency requirements, or a durable operational model that the hosted environment does not guarantee. That migration adds infrastructure and maintenance work, so make it in response to a verified requirement rather than architectural fashion.

A cloud Mac environment is a separate option when the Agent must use macOS-specific tooling, remote development workflows, or Mac-oriented build and test steps. Review Kvmzen’s cloud Mac use cases and the service context on the Kvmzen overview page only after you have defined those requirements. A Mac host does not automatically solve Agent permission, secret, network, or audit problems; those controls still need to be designed.

The alternative to Hosted Sandboxes is not automatically better. A self-managed sandbox can provide more control, but you now own patching, isolation, monitoring, capacity, incident response, and recovery. A cloud Mac can provide the required operating environment, but it may be a poor fit for large fleets of short-lived Linux-style code tasks. Make the choice from the acceptance evidence.

For a quick validation, download or copy this checklist into your launch review and run one clean task, one interrupted task, and one restricted-network task before approving the next stage. If your current environment cannot provide repeatable files, narrow permissions, reliable audit records, or predictable recovery, using Kvmzen for a controlled Mac-based test environment may give you a clearer operational boundary than extending an unverified hosted workflow.

Frequently asked questions