Glossary · Agents

Agent sandbox

An agent sandbox is where a coding agent’s work lives on KERNSTACK: a dedicated agent/<id> branch in hosted git, deployed to its own agent-<id> environment. Your main branch is never touched, and nothing leaves the sandbox without a reviewed plan.

Agent SandboxesHosted Git
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Definition: Agent sandbox

An agent sandbox is where a coding agent’s work lives on KERNSTACK: a dedicated agent/<id> branch in hosted git, deployed to its own agent-<id> environment. Your main branch is never touched, and nothing leaves the sandbox without a reviewed plan.

How the sandbox is shaped

Mention @agent in a project conversation (code mode, with Agents enabled and hosted git available) and the agent builds its demo on a fresh agent/ branch and deploys it to the agent- environment, replying with the live link. External harnesses — Cursor, Claude Code, Codex, Pi — work the same way: agent work is branch work, and each branch can carry its own running environment for click-through review.

Leaving the sandbox is a decision

Keeping the work means moving it to a feature/ branch, which kernstack use offers when you target another environment from an agent branch. Deploying an agent branch outside its own environment asks for confirmation. Discarding is the default fate: the branch and its environment retire together, and the record of the attempt stays in the project’s history.

FAQ

Frequently asked questions

Not through the sandbox’s doors. Agent work lives on its branch and environment; production changes require promotion through a reviewed plan, and projects can set the deploy gate to require review-approved source.

Open the demo link for the running version, check out the branch with kernstack git checkout agent/<id> for the code, and read kernstack plan for the platform consequences — three views of the same change.

Its branch and agent environment are discarded together. The attempt remains visible in the project history, which matters: knowing what was tried and refused is half the point of the board.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudHow KERNSTACK unifies infrastructure, code, intelligence, and collaboration.Platform · AgentsAgent sandboxesIsolated sandboxes for coding agentsPlatform · SourceHosted GitRepository hosting inside the projectGlossary · AccessEnvironment isolationEnvironment isolation is the separation between a project’s targets — default (production), preview targets, and agent-<id> environments — each instantiating the same stack.json with its own data, routes, and keys, so work in one cannot touch another.Glossary · WorkflowHuman approvalHuman approval is a workflow step — { "human": { "title": "..." } } — that pauses a run until a named person decides. The decision, the decider, and the record as shown are stored in the run, and the workflow resumes with the outcome as data.Glossary · DeliveryOpenSpec planAn OpenSpec plan is the change a KERNSTACK topic asks @agent to write in Plan mode: a proposal, requirements with scenarios, and a task list, shown as a card in the thread. Product files and deploys stay closed until someone on the topic approves that card.Glossary · DeliveryPlan diffA plan diff is the preview kernstack plan produces before any deploy: the creates, updates, and deletes the new stack.json would cause — with deletes listed under “Will delete” and refused until a person passes --confirm-destructive. It is also available as kernstack plan --json.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →