Sandboxing

The boundary

When tAI runs code on your behalf, that execution happens inside an isolated sandbox. tCode working against a real project directory on your machine is one example. tAI itself generating a chart, processing an uploaded file, or testing something you asked it to build is another. That sandbox is physically separate from the servers holding your account data, your conversation history, and everything else about your account that isn't specifically the code being run at that moment. That separation is deliberate and structural. It isn't an incidental detail of how the system happens to be deployed. It means a bug, an unexpected result, or an outright malicious payload executing inside that sandbox does not have a direct path to anything outside it. That holds regardless of what that code attempts to do once it's running.

This boundary is worth dwelling on. It changes what kind of failure is even possible in the first place, rather than just making a given failure less likely. A system without this separation would need every single piece of executed code to be individually verified safe before it ran. That's an unreasonable standard to hold arbitrary, model-generated code to. A system with this separation instead only needs the boundary itself to hold. That's a much smaller, more tractable thing to build, test, and verify with confidence. It's the reason this page exists as a distinct part of the security section, rather than being treated as an implementation detail not worth documenting publicly.

tCode's specific scoping

tCode's file and command access is scoped specifically to the working directory it was started in. That scoping is enforced at the sandbox level. It is not left to the model's own judgment about where it should and shouldn't look on a given machine. It cannot read or write outside that directory, even if a particular task seemed, from the model's perspective, to call for reaching beyond it. The boundary is structural rather than advisory. That's the same distinction described in more general terms on the Tool-use safety page, between a model-level judgment and a product-level guarantee that holds regardless of that judgment.

Version-control changes stay entirely local to that sandboxed session. They land as a local commit on a working branch. They stay there until you personally review and push the result yourself, through your own normal tools and your own judgment about whether the change is ready. Nothing tCode does lands on a live, shared branch on its own, under any circumstance. There is no configuration or request that causes it to skip that human review step. Removing that step entirely would undermine the entire point of keeping a human in the loop for consequential, hard-to-reverse actions, described more broadly on the tool-use safety page.

No general network access by default

Code running inside the execution sandbox has no general outbound network access by design. A script that tried to reach an arbitrary external service from inside that sandbox simply cannot. That's true regardless of what the code itself attempts to do, or how cleverly it's written to try. This isn't a policy enforced by watching what code does and blocking suspicious-looking requests after the fact. It's a structural property of the sandbox environment itself. That's the same distinction between an enforced boundary and a monitored one that shows up throughout this page and the pages around it.

Where a specific task genuinely needs network access, that's handled a specific way. Fetching a page during research is the most common example. It's handled through a scoped, purpose-built tool call designed specifically for that action. It is not handled by handing general, unrestricted connectivity to arbitrary code that happens to be executing at the time. That distinction, a narrow tool built for one job versus broad access handed to code that could do anything with it, runs through this entire section. It's the same underlying design principle described for connector access on the Connector safeguards page: access should be as narrow as the actual task requires, never broader just because broader would have been simpler to build.

Why this is a separate layer from the model

Everything described on this page is enforced outside the model entirely, at the infrastructure level. That's deliberate, not incidental to how the system happens to be built. The scoping and network restrictions described here hold even in a scenario where a model-level judgment about what was safe to do turned out, in that specific case, to be wrong. That's exactly the layered-defense principle described in more depth on the Tool-use safety page. The model's own judgment is evaluated and reported on there. This page is the independent backstop to that judgment, not a restatement of it dressed up in infrastructure language.

We think it's worth being explicit that these two pages describe genuinely different things. It would be easy to read them as saying the same thing twice in different words. The tool-use safety page answers one question: how good is the model's own judgment about what it should and shouldn't do. That's measured through evaluation and improved through training. This page answers a different question entirely: what happens if that judgment is wrong. The answer, by design, is that the damage is contained by a boundary that doesn't depend on the model's judgment being right in the first place.

Resource limits, not just access limits

Everything described above is about where a sandboxed session can reach: which files, which directory, which network destinations. A separate set of limits governs how much of a shared resource a single session can consume while it runs. CPU time, memory, and total execution duration are all bounded per session. That's a genuinely different kind of protection from access scoping. A script doesn't need to reach outside its sandbox to cause a real problem for other users on shared infrastructure; it only needs to consume far more of a shared resource than any legitimate task actually requires, whether that happens by design or by an entirely unintentional runaway loop in generated code. An infinite loop or a memory leak in generated code is a far more common real-world scenario than a deliberate attempt to exhaust resources, and these limits catch both equally.

A session that hits one of these limits is stopped, and that's surfaced back to you directly, rather than silently killed with no explanation and no way to tell what happened. You see that a limit was hit, not just that a task quietly stopped producing output. This applies identically regardless of whether the underlying code was written by tAI itself, requested explicitly by you, or came from somewhere else entirely; the sandbox doesn't try to guess intent before applying its limits. That's consistent with the rest of this page: a boundary that holds the same way every time, rather than one that depends on a judgment call about whether a particular case seems trustworthy. The specific limit values aren't published here, for a similar reason methodology detail is withheld elsewhere in this section: publishing an exact ceiling mostly helps someone trying to work right up against it. What matters for a legitimate user is that a genuinely reasonable task essentially never comes close to hitting one.