Clanker Cloud now offers hosted sandboxes for agents.
The idea is simple: before an agent asks for the user's app install, local files, provider credentials, or production cloud access, it can get a real runtime of its own. It can run shell commands, inspect a repo, test a plan, generate artifacts, publish a small public static document on Standard Pro, and explain what is running before handoff.
This is instant infrastructure, but the default unit is not a static website. The default unit is an agent workspace.
Quick Answer
Clanker Cloud sandboxes are hosted workspaces for AI agents. Anonymous calls can create a one-hour sandbox. Free authenticated accounts get about eight hours. Standard Pro gets persistent sandboxes, public simple-static hosted documents, and /explain. Agents and users can create accounts through the API, then create, inspect, operate, and delete sandboxes through /api/sandboxes.
The launch is aimed at agents first: Codex, Claude Code, OpenClaw, Hermes, Clanker CLI, MCP-capable tools, and custom automation agents that need somewhere safe to work.
Why Agent Sandboxes Matter
Agents are getting better at long-running work, but they still need a place to do that work safely.
Local laptops are personal and messy. Production cloud accounts are high-trust environments. CI is often too narrow for exploratory work. A chat transcript is not a runtime. A model session cannot replace a shell, a filesystem, a process boundary, and a clean lifecycle.
Agent sandboxes fill that gap.
They let an agent move from "I think this will work" to "I ran commands in a clean workspace and here is what happened." They also give the user a boundary: this is the disposable place where the agent can prepare, test, and summarize before it asks for the real environment.
That is especially useful for infrastructure and developer workflows:
- a coding agent can clone a repo and run build commands;
- a DevOps agent can inspect manifests and draft a deploy plan;
- an onboarding agent can prepare a workspace before asking the user to install the desktop app;
- a support agent can generate a status page or handoff report;
- a custom agent can run repeatable setup tasks in an isolated runtime.
What Shipped
The first Clanker Cloud sandbox release includes:
POST /api/sandboxesfor sandbox creation;- anonymous one-hour sandboxes with a returned
sandboxToken; - account-owned sandboxes with API-key authentication;
/api/auth/registerfor user account creation;/api/auth/agent/registerfor agent account creation;- command execution through
/api/sandboxes/{id}/commands; - terminal-style command execution through
/api/sandboxes/{id}/terminal; - message and future vision routes for runtime agent surfaces;
- Standard Pro simple-static site hosting through
/api/sandboxes/{id}/sites; - Standard Pro runtime summaries through
/api/sandboxes/{id}/explain; - explicit delete so agents can release the runtime when work is complete.
The lifecycle is intentionally direct: create, operate, explain, delete.
How The Account Model Works
Anonymous sandboxes are for first contact. They are short-lived and return a token scoped to that sandbox. The user does not need to create an account before an agent tries the runtime.
Free authenticated accounts are for normal work sessions. They last about eight hours per sandbox and give the account a listable workspace lifecycle.
Standard Pro is for durable agent infrastructure. These sandboxes persist until deleted and unlock public simple-static hosted documents plus /explain. That makes them suitable for longer runs, team handoffs, generated reports, and agent workflows that need to survive beyond a single trial session.
The account creation endpoints are deliberately available to agents:
- humans can call
/api/auth/register; - agents can call
/api/auth/agent/register.
An agent should not need to collect cloud provider credentials to create a sandbox account. Provider credentials remain part of the local-first Clanker Cloud app and MCP workflow.
What /explain Does
The /explain endpoint is there because agents need to report state clearly.
A sandbox can have a runtime, a TTL, routes, commands, published sites, and pending cleanup. Without a summary endpoint, the user has to piece that together from logs and chat messages. That is a bad handoff.
With /explain, a paid account can ask the sandbox what infrastructure is currently running and what the user should know. It is the agent-readable and user-readable state summary for the workspace.
This is also a pattern Clanker Cloud will keep using: every piece of agent infrastructure should be able to explain itself.
Hosted Sites Are For Agent Outputs
Simple-static website hosting is included with Standard Pro, but the product is not a general-purpose application host.
The site feature exists because agents often need to publish an output: a run report, a generated preview, a checklist, a status page, or a handoff artifact. Putting that behind the sandbox API keeps the output attached to the runtime that produced it.
Current /sites/{slug}/ documents are public and share a Worker hostname. Each is forced into a Content Security Policy sandbox without allow-same-origin, giving it an opaque browser origin. It cannot use or read shared cookies, localStorage, IndexedDB, Cache Storage, or service workers, and cannot read another tenant's page or a same-origin API response through browser APIs. Classic scripts and forms remain allowed; ES modules and apps that depend on storage or readable same-origin APIs may fail.
Use this route for simple reports, status pages, handoff documents, and compatibility-tested previews. Do not publish secrets or confidential or regulated customer data, and do not weaken or work around the isolation header. Protected, sovereign, and government hosting is unavailable until per-site tenant-isolated registrable origins and a separately contracted, verified environment exist.
That makes the story easier to audit:
- the agent created a sandbox;
- the agent ran commands;
- the agent published an artifact;
/explaincan summarize what is still running;- the user can decide whether to keep or delete it.
The hosted site is the artifact. The sandbox is the workspace.
How This Fits With Clanker Cloud MCP
Sandboxes do not replace the Clanker Cloud desktop app.
The desktop app remains the local-first control surface for real infrastructure: cloud credentials, kubeconfigs, provider context, topology, cost, GitHub state, local files, MCP, and review-before-apply workflows.
Sandboxes are the safer first step for an agent. They let the agent prepare before asking for local context or production access. Once the workflow needs real environment state, the agent should move to Clanker Cloud MCP and keep high-impact actions behind review.
That gives users a cleaner trust ladder:
- anonymous sandbox for a quick trial;
- authenticated sandbox for a longer work session;
- Standard Pro sandbox for persistent agent infrastructure and public simple-static outputs;
- local-first MCP for real cloud context and approved production actions.
What Comes Next
This is the first step toward Clanker Cloud becoming a fuller cloud provider for agents.
Agents will need more than a shell. They will need durable workspaces, hosted artifacts, secrets boundaries, model routing, eval loops, browsers, observability, deployment previews, infrastructure summaries, and a clean way to graduate from sandbox work to real infrastructure changes.
The sandbox launch creates the base primitive. From here, Clanker Cloud can add more agent-native infrastructure without forcing every workflow through a user's laptop first.
Read More
Give your agent live infrastructure context
Download Clanker Cloud, expose the local MCP surface, and let coding agents work from current cloud, Kubernetes, GitHub, and cost state instead of guesses.