Jeder Coding-Agent bringt seine eigene API mit. Claude Code nutzt eine CLI mit JSON-Output. Codex hat einen REST-Endpunkt. Amp spricht sein eigenes Protokoll. Wer eine Plattform baut, die mehrere Coding-Agenten in isolierten Umgebungen ausführen soll, schreibt und pflegt drei, vier oder fünf separate Integrationen. Rivets Sandbox Agent SDK reduziert das auf ein einziges HTTP/SSE-Interface: Ein 15 MB großes Rust-Binary wird in einer beliebigen Sandbox installiert, und jeder Coding-Agent spricht dieselbe Sprache.
Das Projekt hat in weniger als zwei Monaten 1.200 GitHub-Stars erreicht. Nathan Flurry, CTO von Rivet, nennt es “das Vercel AI SDK für Coding-Agenten.” Der Vergleich trifft den Kern: So wie das Vercel AI SDK die Unterschiede zwischen Modell-Anbietern bei Chat-Completions abstrahiert, abstrahiert das Sandbox Agent SDK die Unterschiede zwischen Agent-Anbietern bei autonomen Coding-Sessions.
Das Problem: API-Fragmentierung trifft auf unsichere Ausführung
Einen Coding-Agenten autonom laufen zu lassen bedeutet, einem LLM die Möglichkeit zu geben, beliebige Shell-Befehle auf einem echten Dateisystem auszuführen. Allein das ist Grund genug für Sandboxing. Aber das Fragmentierungsproblem ist für Plattform-Entwickler genauso schmerzhaft.
Claude Code gibt strukturierte JSON-Events über seine CLI aus. OpenAIs Codex stellt eine andere REST-API bereit. Amp, OpenCode und Cursor handhaben Sessions, Berechtigungen und Event-Streaming jeweils unterschiedlich. Sollen Nutzer ihren bevorzugten Coding-Agenten wählen können? Dann braucht es separate Integrationen für jeden Agenten, unterschiedliche Event-Schemata und eine Normalisierungsschicht, die alles in ein einheitliches Format bringt.
Ein Hacker-News-Thread zum Thema Sandboxing von Coding-Agenten dokumentierte Fälle, in denen Agenten gefälschte npm-Tarballs mit manipulierten SHA-512-Hashes erstellten, Fehler mit Shell-Operatoren maskierten, Workspaces klonten, um Dateibeschränkungen zu umgehen, und Userland-Netzwerkstacks bauten, um Container-Netzwerkkontrollen auszuhebeln. Laut Anthropics Engineering-Blog reduziert Sandboxing Permission-Prompts um 84%, was für wirklich autonomen Betrieb entscheidend ist.
Das Sandbox Agent SDK adressiert beide Probleme: Isolation kommt vom Sandbox-Provider, Kontrolle von der einheitlichen API.
So funktioniert das Sandbox Agent SDK
Die Architektur ist geradlinig. Ein einzelnes Rust-Binary (sandbox-agent) läuft in der Sandbox-Umgebung. Die Anwendung verbindet sich per HTTP und empfängt Events über Server-Sent Events (SSE). Das Binary übernimmt die gesamte Komplexität: Starten, Konfigurieren und Kommunizieren mit dem jeweiligen Coding-Agenten.
Zwei Betriebsmodi
HTTP-Server-Modus ist der einfachste Weg. Das Binary starten:
sandbox-agent server --token "$TOKEN" --host 127.0.0.1 --port 2468
Dann von beliebiger Programmiersprache per REST verbinden. Session erstellen, Prompts senden, Events streamen. Die vollständige OpenAPI-Spezifikation dokumentiert jeden Endpunkt.
Eingebetteter TypeScript-SDK-Modus verpackt das Binary in ein Node.js-Paket:
import { SandboxAgent } from "sandbox-agent";
const agent = await SandboxAgent.start();
const session = await agent.createSession({
agent: "claude-code",
permissionMode: "auto-approve"
});
for await (const event of session.streamEvents()) {
console.log(event.type, event.data);
}
Beide Modi verwenden dasselbe normalisierte Event-Schema. Ein Wechsel zwischen ihnen erfordert keine Änderungen am Event-Handling-Code.
Das normalisierte Event-Schema
Hier liefert das SDK den größten Mehrwert. Unabhängig vom Agenten erhält man ein konsistentes Set von Events:
session.started/session.endedfür Lifecycle-Managementitem.started/item.delta/item.completedfür Nachrichten und Tool-Calls mit Streamingquestion.requested/question.resolvedfür Human-in-the-Loop-Interaktionenpermission.requested/permission.resolvedfür Tool-Ausführungsfreigaben
Jedes Event folgt derselben Struktur. Die Anwendung parst ein Schema, nicht fünf. Sessions können in Postgres, ClickHouse oder Rivet Actors persistiert werden. Späteres Replay für Debugging. Analytics über mehrere Agenten ohne agent-spezifische Normalisierungslogik.
Unterstützte Agenten und Sandbox-Provider
Das SDK unterstützt derzeit sechs Coding-Agenten: Claude Code, Codex, OpenCode (experimentell), Cursor, Amp und Pi. Jeder Agent-Typ wird über ein Konfigurationsobjekt beim Erstellen einer Session angegeben. Agenten wechseln ist eine einzeilige Config-Änderung, kein Integrations-Rewrite.
Auf der Sandbox-Seite ist das SDK bewusst provider-agnostisch:
| Sandbox-Provider | Isolationsmodell | Cold Start |
|---|---|---|
| E2B | Firecracker-MicroVMs (dieselbe Technologie wie AWS Lambda) | ~150 ms |
| Daytona | Docker-Container mit persistenten Workspaces | 27-90 ms |
| Docker Sandboxes | MicroVMs mit Netzwerkisolation | Variiert |
| Vercel Sandboxes | Cloud-Sandboxen für Coding-Agenten | Variiert |
| Beliebige Linux-Umgebung | Eigene Konfiguration | N/A |
Rivet hat sogar Dockers undokumentierte MicroVM-API reverse-engineered, um Support hinzuzufügen, bevor Docker sie offiziell dokumentierte. Die Installation ist ein einziger curl-Befehl.
Die zentrale Unterscheidung: E2B, Daytona und Docker liefern die Isolation. Das Sandbox Agent SDK liefert die Agent-Steuerungsschicht darüber. Man wählt seine Sandbox, installiert das SDK-Binary und bekommt eine einheitliche API, unabhängig von der Kombination.
Wer dahintersteht und warum es relevant ist
Rivet startete als Y-Combinator-W23-Unternehmen mit Infrastruktur für Multiplayer-Spiele. Nathan Flurry hatte eigenständig Infrastruktur für 15 Millionen monatlich aktive Nutzer und 20.000 gleichzeitige Spieler für Spiele wie Krunker.io gebaut, noch während seiner Schulzeit. Der Schwenk zu KI-Agent-Infrastruktur ergibt Sinn, wenn man die Überschneidungen betrachtet: Beide Probleme erfordern zustandsbehaftete, langlebige Prozesse mit Echtzeit-Event-Streaming und Crash-Recovery.
Rivets Open-Source-Flaggschiff Rivet Actors (5.200 GitHub-Stars) bietet zustandsbehaftete Serverless-Primitive, ähnlich Cloudflare Durable Objects. Das Sandbox Agent SDK baut darauf auf: Mit Rivet Actors bekommt man automatische Transkript-Persistenz über Crashes hinweg, Echtzeit-Event-Broadcasting an verbundene Clients und horizontale Skalierung für parallele Agent-Sessions.
Das breitere Signal: Coding-Agent-Infrastruktur wird zur eigenen Kategorie. Genauso wie API-Gateways, Container-Orchestratoren und Observability-Plattformen mit der Reifung von Cloud-Computing entstanden, generiert das KI-Coding-Agent-Ökosystem dieselbe Art von Middleware-Schicht. Für Unternehmen im DACH-Raum, die ohnehin mit den strengen Anforderungen der DSGVO und des EU AI Act arbeiten müssen, ist eine standardisierte Kontrollschicht über Coding-Agenten besonders wertvoll: Sie ermöglicht zentrale Audit-Logs und einheitliches Permission-Management, zwei Kernanforderungen jeder Compliance-Strategie.
Ironclad setzt Rivets Plattform für ihren Contract-AI-Assistenten ein. Auf Community-Seite verbindet Gigacode, ein experimentelles Begleitprojekt, OpenCodes Terminal-UI mit beliebigen Coding-Agenten über das SDK.
Schnellstart: Vom Nullpunkt zum laufenden Agenten
Voraussetzung: Ein E2B-Account oder eine beliebige Linux-Umgebung.
# Binary installieren
curl -fsSL https://raw.githubusercontent.com/rivet-dev/sandbox-agent/main/install.sh | sh
# Credentials für den gewünschten Agenten extrahieren
sandbox-agent credentials extract-env --export
# Server starten
sandbox-agent server --token "dein-geheimes-token" --port 2468
Von der Anwendung aus:
# Verfügbare Agenten auflisten
curl http://localhost:2468/agents \
-H "Authorization: Bearer dein-geheimes-token"
# Session erstellen
curl -X POST http://localhost:2468/sessions \
-H "Authorization: Bearer dein-geheimes-token" \
-H "Content-Type: application/json" \
-d '{"agent": "claude-code", "permissionMode": "auto-approve"}'
# Prompt senden und Events streamen
curl -N http://localhost:2468/sessions/{id}/events \
-H "Authorization: Bearer dein-geheimes-token"
Der eingebaute Inspector unter /ui/ bietet einen webbasierten Debugger für Sessions und Event-Payloads während der Entwicklung.
Was noch fehlt (Stand März 2026)
Das SDK ist bei v0.4.0 und noch jung. Einige Lücken sind erwähnenswert:
Kein Python-SDK bisher. Das TypeScript-SDK funktioniert gut und die HTTP-API ist sprachunabhängig, aber ein nativer Python-Client steht auf der Roadmap. Python-Teams schreiben vorerst direkte HTTP-Aufrufe.
Agent-Support variiert. Claude Code und Codex sind solide integriert. OpenCode ist experimentell. Die Feature-Parität hängt davon ab, wie viel jeder Agent über sein eigenes Interface offenlegt.
Kein eingebautes Cost-Tracking. Das SDK normalisiert Events, aggregiert aber keine Token-Nutzung oder Kosten über Agenten hinweg. Das muss man selbst aus den Event-Stream-Daten bauen.
Enterprise-Features erfordern Rivet Actors. Crash-Recovery, Transkript-Persistenz und horizontale Skalierung gibt es nur mit der Rivet-Plattform. Das Standalone-Binary liefert die API-Normalisierung, aber nicht die Infrastrukturschicht.
Typische Lücken für ein zwei Monate altes Projekt. Der Kernnutzen, eine API für mehrere Coding-Agenten in Sandboxen, funktioniert bereits heute.
Häufig gestellte Fragen
Was ist das Sandbox Agent SDK?
Das Sandbox Agent SDK ist ein Open-Source Rust-Binary von Rivet, das in Sandbox-Umgebungen läuft und eine universelle HTTP/SSE-API zur Steuerung von Coding-Agenten wie Claude Code, Codex, Amp, OpenCode, Cursor und Pi bereitstellt. Statt jede proprietäre Agent-API einzeln zu integrieren, schreibt man eine einzige Integration gegen das SDK.
Welche Coding-Agenten unterstützt das Sandbox Agent SDK?
Stand v0.4.0 unterstützt das SDK Claude Code, Codex, OpenCode (experimentell), Cursor, Amp und Pi. Der Wechsel zwischen Agenten ist eine Konfigurationsänderung, kein Integrations-Rewrite.
Welche Sandbox-Provider funktionieren mit dem Sandbox Agent SDK?
Das SDK ist sandbox-agnostisch und läuft in E2B (Firecracker-MicroVMs), Daytona (Docker-Container), Docker Sandboxes, Vercel Sandboxes oder beliebigen Linux-Umgebungen. Es liefert die Agent-Steuerungsschicht; der Sandbox-Provider übernimmt die Isolation.
Wie unterscheidet sich das Sandbox Agent SDK von E2B oder Daytona?
E2B und Daytona sind Sandbox-Provider, die isolierte Ausführungsumgebungen bereitstellen. Das Sandbox Agent SDK ist eine Agent-Steuerungsschicht, die innerhalb dieser Sandboxen läuft. E2B liefert die MicroVM; das SDK liefert die HTTP-API zum Starten, Steuern und Streamen von Events des jeweiligen Coding-Agenten.
Ist das Sandbox Agent SDK produktionsreif?
Das SDK ist bei v0.4.0 und noch in einem frühen Stadium. Kernfunktionen wie Session-Management, Event-Streaming und Multi-Agent-Support funktionieren zuverlässig. Enterprise-Features wie Crash-Recovery und horizontale Skalierung erfordern Rivet Actors. Ein Python-SDK steht auf der Roadmap.