I run Claude inside agent sandboxes on a Kubernetes cluster to automatically fix errors and consume issue request tickets on the loop. One sandbox consumes issue tickets, turns them into PRs, and assigns them back to another review agent. Another triggers on Sentry webhooks to diagnose and patch runtime bugs. You can also configure the agent to create follow-up issues or to-do tasks when it finds other areas to improve, allowing it to stay focused on the main task. This is the bigger loop, operating outside the local Claude Code session loop, and where the new Kubernetes Agent Sandbox CRD fits while keeping track with product vision and internal knowledge base docs.

Many providers offer similar sandboxing environments, such as Blackbox.ai, e2b.dev, Cloudflare Sandbox, and Claude Managed Agents. However, running them on Kubernetes is a great fit if you work in an enterprise or use local models.

That's the bigger loop: not just one agent running a single task, but a pipeline that runs continuously—issues in, PRs out; errors in, fixes out. Doing this by hand means provisioning a StatefulSet, a headless Service, a PVC, and a pile of RBAC and NetworkPolicy rules for every agent runner. Agent Sandbox wraps that entire boilerplate into a single CRD.

Agent Sandbox Kubernetes: Core Components

Agent Sandbox is designed to run AI agents securely and efficiently in isolated, short-lived environments on Kubernetes.

Instead of managing complex resources manually, it provides a single custom resource (CRD) to handle the lifecycle of agent containers. Existing Kubernetes objects aren't a good fit:

• Deployments are stateless and designed for scaling web servers.
• StatefulSets are stable but built for long-running database clusters, not quick, one-off agent tasks.

The Sandbox CRD fills this gap by offering three key features:

• Stable identity: Each Sandbox gets its own hostname and network identity.
• Persistent storage: Your agent's files and workspaces stay intact even if the container crashes and restarts.
• Lifecycle management: The controller lets you create, delete, pause, and resume sandboxes. If an agent is idle, you can freeze it and pick up exactly where it left off later.

Agent Sandbox Kubernetes: Core Components & Extensions

The extensions module adds CRDs and controllers to the core Sandbox API for advanced workflows:

• SandboxTemplate: Defines reusable templates to easily create similar Sandboxes.
• SandboxClaim: Creates Sandboxes from a warm pool, hiding the underlying configuration details.
• SandboxWarmPool: Manages a pool of pre-warmed Sandboxes to reduce start times.

The Architecture Diagram:

For most workloads, start with the Core Sandbox. The extensions are only needed when you manage many similar Sandboxes and want to avoid startup delays or boilerplate configuration.

Use Cases for Agent Sandbox

The examples directory contains projects you can build depending on your needs:

• code-interpreter-agent-on-adk: A code interpreter built on the Antigravity SDK (ADK).
• hermes-agent: Long-running agents.
• langchain: Agents using the LangChain framework.
• jupyterlab and vscode-sandbox: Interactive development environments.
• chrome-sandbox (browser automation) and mcp-server-sandbox (running an MCP server inside a Sandbox).
• sandbox-ksa: Using a dedicated Kubernetes Service Account (KSA) inside a Sandbox.

Use case: The Claude Agent SDK - Self-Fixing Agent

I used to manually copy and paste Sentry errors or ad-hoc requests blindly into a Claude Code session with the /fix-and-push command without double-checking. Most of the time, this only required one short prompt. Since my codebase context is now stable, I automated this process.

Now, a Sentry runtime error triggers a FastAPI webhook. A sandbox boots, reads the stack trace, reproduces the failure, writes a fix, and opens a pull request. This PR triggers our build and test pipeline, where another agent reviews and auto-merges it. This allows the system to patch itself.

To make this safe, you need strong CI/CD guards, smoke tests on staging, and controlled promotion to production. The Sandbox makes this secure because each run is isolated and temporary. The agent cannot access the Kubernetes cluster API, so an agent pushing a fix at 3:00 AM cannot damage the rest of the cluster.

How it works

In my runner setup, the FastAPI control plane creates a Sandbox for each task, and that Sandbox creates the Pod where Claude runs.

GitHub issues, Sentry errors, and assigned or tagged pull requests all route through the FastAPI control plane. The control plane creates a Sandbox, which then starts the Pod where the agent runs. I built an example, claude-agent-runner, using the Claude Agent SDK. It is configured with a system prompt, skills, and MCP tools so it has enough context to do the job correctly. It can post status updates, create PRs, or close issues.

Context is important: I recommend checking out Goal and Loop: The Knowledge Base to learn how to build and use an internal knowledge base to keep track of it.

Self-fixing loop

Self-improvement loop

If you want a simpler option, Claude Code GitHub Actions is an easy alternative if you already use GitHub. It provides the same context and works in a similar way without needing a custom control plane.

Self-improving learning loop

I want to remind you again: the most important factor is context. During a goal-and-loop run, you can configure the agent (or set up a StopHook) to automatically summarize its findings and learn to create or update existing skills related to the codebase, business logic, and internal concepts. For example, imagine running this prompt at the end of a complex session that required deep research to ensure Claude remembers the context for future sessions without having to re-do the research:

/skill-creator Analyze this entire conversation and extract the core workflow, formatting guidelines, and preferences we established, etc to create a custom Claude Skill (SKILL.md) that I can use in future sessions. Ask me for confirmation before finalizing the skill.

Example Code

The Claude Agent Runner image is public here with a detailed architecture design. You can extend it further with custom code, the Antigravity SDK, and other agent frameworks.

Security

"The agent cannot access the Kubernetes cluster API" is only true if the sandbox actually isolates the agent's process from the host. By default, a Kubernetes Pod is just a runc container: it shares the host kernel with every other Pod on the node through Linux namespaces and cgroups. That's fine for your own trusted code, but an LLM agent running arbitrary shell commands, installing dependencies, and executing model-generated code is a different threat model — a kernel exploit or container escape in that Pod reaches the host and every other workload on it. This is why the sandboxing runtime you pick under Agent Sandbox matters as much as the CRD itself.

Three runtimes solve this differently:

• containerd + runc (default): namespaces + seccomp carve out a view of one shared kernel. Fastest, but one syscall exploit away from the host.
• gVisor: intercepts every syscall in userspace via a sandboxed kernel ("Sentry") — no direct host syscalls, no hardware virtualization needed. What GKE Sandbox and Cloud Run use.
• Kata Containers: each Pod gets a real guest kernel in a microVM (QEMU/Cloud Hypervisor + KVM) — hardware isolation, at the cost of a second kernel to patch and slower cold starts.

Agent Sandbox exposes runtimeClassName in the Sandbox's podTemplate, so this is a one-line choice per SandboxTemplate: runc for trusted, low-risk tasks; gvisor as the default for agent-generated shell/code execution; kata for anything touching untrusted external input.

This doesn't replace the basics — NetworkPolicy egress limits, a minimal-RBAC ServiceAccount, non-root PodSecurityContext. The runtime raises the cost of a kernel escape; it doesn't substitute for keeping the agent's cluster permissions minimal.