Every turn of every loop runs somewhere, which makes where does my code run? the single most important question about TaskGoblin. It has one answer: in an isolated cloud sandbox, never on anyone's laptop. This page explains what that sandbox is, why it is isolated, and how it stays that way as your team grows.
What the sandbox is
A sandbox is an isolated container in the cloud with a checkout of your repository. When you hand off a task, the agent runs inside that container — it reads and edits files, runs commands, and inspects the repo there, with no access to your machine and no dependency on it being switched on.
Because the sandbox lives in the cloud, the work is asynchronous by nature — and it is what lets a loop fire at 03:00 with nobody awake, or ten loops fire at once without queueing behind each other.
Isolation: one boundary per organisation
Each organisation's work runs inside its own sandbox. That boundary is the core of TaskGoblin's data isolation — one organisation can never read or write another organisation's code, repositories, or run history. The agent only ever sees the workspaces, repositories, and projects you explicitly connect; disconnect a connection and it loses access on the spot.
Persistence: it remembers the setup, not just the task
The sandbox is persistent and reused across a thread's messages. A follow-up on the same issue lands in an environment that already has the repository cloned and the previous run's state in place — so the agent resumes quickly instead of starting from an empty box every time. This is what makes iterating on a task feel continuous rather than repetitive. (For how that continuity carries decisions across runs, see The brain.)
Secrets stay outside the agent
The agent never sees your credentials. Git access inside the sandbox is provisioned per organisation at run time — a GitLab OAuth token or a freshly minted GitHub installation token — and injected into the environment around the agent rather than handed to it as something to read. The agent can use the access it needs to clone and push, without your secrets ever entering its transcript or context.
This is a deliberate boundary, not a side effect: the credential is available to the git tooling in the sandbox, but it is never part of the material the agent reads or reasons over.
Custom sandboxes
You can bring a custom sandbox — a container image preloaded with the toolchain, system packages, and services your project needs to build and test. When the agent's work depends on more than a bare checkout (a specific runtime, a database, private build tooling), a custom sandbox means the environment is ready the moment a task starts, and the agent's changes can be verified in a realistic setup.
Self-hosted sandboxes
Teams with compliance or data-residency requirements can run sandboxes on their own infrastructure. The control plane still schedules and drives the work, but the container where your code is checked out and executed lives inside your environment — so source, build artifacts, and run state never leave a boundary you control. This is the option to reach for when "in the cloud" needs to mean your cloud, and it is also the cheapest way to run: $0.10 a minute, paired with your own LLM account. See Bring your own sandbox server for how to register one — and why platform model credentials are never placed on infrastructure you control.
Where to go next
- How a run works — the full trigger-to-merge-request flow inside a single turn.
- Loops — the primitive every sandbox run serves.
- Bring your own sandbox server — running goblins on your own infrastructure, and what it costs.
- Schedule loops — unattended runs using the same sandbox model on a cadence.