Where does an AI coding agent actually run?
Most of the risk in an AI coding agent is not the model; it is the place where the model's instructions touch real files. GROX Code runs builds in an isolated, single-use sandbox with real developer tools, and that sandbox is destroyed when the run ends.
What is a single-use sandbox?
A coding agent has to turn an instruction into changes on real files. That requires a place to run commands, search and edit. A single-use sandbox is an isolated environment created for one build or run. It contains a shell, file search and the ability to edit actual files, so the agent can work on real artefacts rather than simulate them. When the run finishes, the environment is destroyed.
The key word is isolated. The sandbox is not your laptop, not a shared server where other tasks run, and not a long-lived container collecting state. It exists for the length of one run. That limits what can leak across runs and makes the build's context easier to reason about.
- Isolated environment
- A temporary workspace created for a single build run.
- Real developer tools
- A shell, file search and the ability to edit real files.
- Single-use
- The environment is destroyed when the run ends.
- Provider key
- The credential used to call an AI model; it is held outside the sandbox.
Why does the sandbox never hold your provider key?
A coding agent needs to call a model. If the sandbox held the provider key, any process inside that environment could potentially read it. Instead, model calls go through GROX, which holds the keys. The sandbox runs tools, but it does not receive the credential that pays for reasoning. This separation matters because a shell and an editor can be made to read files or environment variables; keeping the key elsewhere removes that path.
This also clarifies what the sandbox is for. It is not where model access is granted; it is where instructions touch files. The model call is handled through that platform, and the resulting changes are applied inside the sandbox. The sandbox therefore receives commands and file operations, not the key that authorises the model.
What is destroyed when the run ends, and what is kept?
Single-use means the environment itself is destroyed when the run ends. That includes the shell session, temporary files and any tools loaded for the run. The result of the work, such as a built or deployed application, is not the sandbox; it is the output the agent returns. The useful output can be a real web or mobile application that is built, previewed and deployed, so what you evaluate after the run is the product, not the workspace that produced it.
Because the sandbox is destroyed, there is no long-lived workspace to drift between tasks. That is a real trade-off. If you want a persistent development container that keeps dependencies installed between sessions, a local environment or a dedicated container may suit you better. A single-use sandbox prioritises a clean boundary over convenience.
| Stage | What the sandbox has | What happens next |
|---|---|---|
| Start | A fresh isolated environment with a shell, file search and file editing | The agent can work on real files |
| During the run | Commands, edits and build artefacts for this task | Model calls pass through the platform; the sandbox holds no provider key |
| End of run | The completed build or error state produced by the agent | The sandbox is destroyed |
| Next run | A new isolated environment | No state is carried over from the previous sandbox |
When is a simpler tool the better choice?
A sandboxed coding agent is useful when you want an isolated run with real tools and no provider key inside the workspace. It is not always the lightest option. If the task is a small text change in a repository you already understand, opening a local editor may be faster. If you need a long-running environment with particular packages preinstalled, a dedicated container you control may be more comfortable. A single-use sandbox earns its place when isolation and clean teardown matter more than keeping a stateful workspace warm.
The decision is not about model quality alone. It is about where the work happens and what remains afterwards. An agent that can edit files is only as safe as the boundary around those edits. A single-use sandbox gives you a predictable boundary: there is a start, there is a run, then the environment is gone.
Common questions
Where does the coding agent run its builds?
The coding agent can run a build in an isolated, single-use sandbox that includes a shell, file search and edits on real files. The sandbox never holds a provider key; model calls go through the platform, which holds the keys. When the run ends, the sandbox is destroyed.
Why must a sandbox not hold a provider key?
A shell and file editing tools can read files and environment variables. If a provider key were stored inside the sandbox, any process in that environment could potentially access it. Keeping the key outside the sandbox means model calls flow through the platform, and the sandbox only receives the instructions and file operations it needs.
What is kept after a sandboxed run ends?
The sandbox itself is destroyed. The useful output, such as a built or deployed application, is returned by the agent rather than stored as sandbox state. Because the environment is single-use, no shell session or temporary workspace carries into the next run; each run begins from a clean isolated environment.
When is a local editor better than a sandboxed agent?
For a small, well-understood change, opening a local editor may be quicker than waiting for an agent to run in a sandbox. For work that needs a persistent environment with dependencies already installed, a dedicated container can be more convenient. A single-use sandbox is strongest when a clean boundary and guaranteed teardown matter more than keeping state warm.
See how GROX Code handles sandboxed builds, or read the Help Centre for setup guides.