Can You Use CodeSandbox AI Offline Safely?

The direct answer: no offline mode exists

CodeSandbox is not something you install and run locally anymore. Since Together AI acquired the company in December 2024, the product is sandbox infrastructure: you call Sandbox.create() or the equivalent SDK method, and CodeSandbox provisions a microVM on its own servers for your code to run in. There is no local binary, no air-gapped build and no setting that keeps a sandbox entirely on your machine. If your network is down, that call has nothing to reach.

That also answers the secure codesandbox ai offline search a lot of people run. It is not that an offline mode exists and happens to be insecure. There is no offline mode to evaluate in the first place. The security question that actually applies is what protects your code and data while the sandbox runs in CodeSandbox's cloud, which is a different question with a real answer below.

• CodeSandbox provisions remote microVMs by API call. It is cloud infrastructure, not a local tool.
• There is no offline, air-gapped or local-only mode.
• If you need code execution that never leaves your machine, CodeSandbox is the wrong tool, not a misconfigured one.

What CodeSandbox AI means today, briefly

The short version: the browser IDE many developers remember, fork a React template and share a link, still exists, but the company's investment and its AI-facing product is the CodeSandbox SDK, built for running AI-generated code safely rather than hand-building a UI. We cover the SDK itself, what it costs and how to provision a sandbox, in a separate guide at /guides/building-ai-apps-codesandbox-cloud-environments, if you're building on top of it rather than just asking whether it's safe to use.

What matters for this page is simpler. Wherever CodeSandbox AI shows up, from the SDK to Together AI's own Together Sandbox platform, the execution happens on their infrastructure, over the network, every time.

What secure actually covers in a cloud sandbox

Each CodeSandbox microVM gets its own guest kernel and a dedicated filesystem, which is a real isolation boundary between one sandbox and another, and between a sandbox and CodeSandbox's own infrastructure. That is the kind of security a cloud sandbox can promise: your AI-generated code cannot escape into someone else's sandbox or reach the host machine underneath it.

It is not the kind of security that keeps your code private from the provider. The code, the data you send in, and anything the sandbox prints out all pass through Together AI's systems to run at all. If your threat model includes a rule that your source code or customer data should never leave your own network, a cloud microVM does not satisfy it, no matter how well isolated it is from other tenants.

• Isolation: your sandbox cannot be reached by another tenant's sandbox.
• Not covered: the provider still processes your code and data to run it at all.
• Network egress is available by default, so a sandbox can call out to anything you let it reach.

Handling API keys when the sandbox is remote

Anything your AI-generated code calls, OpenAI, Anthropic, a database, needs a credential, and that credential now has to reach a machine you do not control. Set it as an environment variable when you create the sandbox rather than writing it into a file, so it never sits in a project that could be forked, inspected or accidentally committed.

The same caution applies to logging. A debugging habit as simple as printing the environment to find a missing variable prints every key in it too, and anyone who can see that sandbox's output sees the keys. Scope what you log, and rotate a key the moment you suspect it printed somewhere you did not intend.

• Pass secrets as environment variables at sandbox creation, never hardcoded in a file.
• Never log the full environment to debug a missing variable.
• Rotate a key the moment it may have been exposed in output you did not control.

When a remote sandbox is the wrong choice

If your code or data cannot leave your own network for legal, contractual or simple comfort reasons, the fix is not a hidden CodeSandbox setting. It is choosing infrastructure that actually runs locally: a Docker container on your own machine, a local VM, or a desktop app that sandboxes an agent in a real terminal you can see.

That is a different tradeoff. A local sandbox gives up the instant snapshot-and-fork workflow CodeSandbox is built around, and you're back to managing your own machine's resources, but your code genuinely never leaves it.

• A local container or VM is the honest alternative when code must stay on your machine.
• You give up instant cloning and snapshots. You keep full control of where the code runs.

How Forkbench handles the local alternative

Forkbench is a desktop app that runs coding agents in real terminals on a Mac, which is the local counterpart to a CodeSandbox-style cloud sandbox. A Thread can be locked to its own folders by the macOS kernel sandbox, so an agent working in it cannot read ~/.ssh, other repositories or the rest of Documents, and the Vault lets a command use an API key from your Keychain by name instead of putting the value in a file or the conversation.

State the limit honestly. The folder lock is opt-in and does not restrict the network, so a locked agent can still send out whatever it is allowed to read, and an unpinned Vault key can still be read by the program that was run with it. Forkbench governs what the agent holds and the folders you lock, not a sealed box with no egress at all, which is a different promise than nothing leaving this machine, period.

• Folder lock: opt-in, enforced by the macOS kernel, confines reads and writes to the Thread's folders.
• Vault: an agent uses a Keychain-stored key by name. The value stays out of its context.
• Limit: the folder lock does not restrict the network, and an unpinned key can still be read by the program using it.

A short checklist before you pick either option

Decide the actual requirement before choosing a tool. Fast, disposable, and lets you fork and compare agent runs side by side points at CodeSandbox or a similar cloud sandbox. Must never leave my machine points at a local container, VM or a supervised terminal.

Either way, keep the credential hygiene the same: environment variables instead of files, no full-environment logging, and a rotation plan for anything that might have leaked.

• Pick cloud sandboxes for speed, disposability and side-by-side agent runs.
• Pick local isolation when code or data cannot leave your network.
• Keep secrets as environment variables and rotate anything that may have leaked, regardless of which you pick.