Sandboxes Übersicht

Sandboxes bilden das Ausführungsrückgrat von CodeCourier. Immer wenn ein KI-Coding-Agent eine Aufgabe ausführt, Code schreibt oder einen Befehl ausführt, geschieht das innerhalb einer Sandbox -- einer isolierten, ephemeren Cloud-Linux-VM, angetrieben von E2B. Diese Architektur sorgt dafür, dass Agentenaktivitäten vollständig gekapselt, reproduzierbar und sicher sind, ohne Risiko für Ihre lokale Maschine oder Produktivinfrastruktur.

Was ist eine Sandbox?

Eine Sandbox in CodeCourier ist eine vollwertige Linux-Umgebung, die in der Cloud läuft. Jede Sandbox bringt ein komplettes Dateisystem, Netzwerkzugriff, Prozessausführung und vorinstallierte Entwicklungs-Tools mit. Unter der Haube nutzt CodeCourier das E2B SDK, um diese Umgebungen on-demand bereitzustellen. Beim Start einer Sandbox erstellt E2B eine leichtgewichtige VM aus einem Template, spielt Ihre Konfiguration ein (API-Schlüssel, System-Prompts, Skills, Learnings) und übergibt die Kontrolle an Ihren gewählten KI-Coding-Agenten.

Sandboxes sind keine Container -- es sind vollwertige Mikro-VMs mit eigenem Kernel, die stärkere Isolationsgarantien als Docker bieten. Damit kann ein in einer Sandbox laufender KI-Agent weder andere Sandboxes, Ihr Hostsystem noch die Umgebung anderer Nutzer beeinflussen.

Warum Sandboxes wichtig sind

KI-Coding-Agenten auf Ihrer lokalen Maschine laufen zu lassen, birgt echte Risiken. Ein Agent mit Dateisystemzugriff kann Dateien überschreiben, schadhafte Pakete installieren oder in Ihrer Umgebung gespeicherte Secrets lesen. Da CodeCourier jede Agentenaufgabe in einer Sandbox ausführt, eliminiert es diese Risiken vollständig.

• Sicherheit -- Jede Sandbox ist eine isolierte Mikro-VM. Agenten können nicht auf den Host entkommen, andere Sandboxes erreichen oder Dateien außerhalb ihrer Umgebung lesen.
• Reproduzierbarkeit -- Sandboxes starten aus einem bekannten Template-Zustand. Jeder Run beginnt mit derselben Basisumgebung, sodass Ergebnisse deterministisch und debuggbar sind.
• Ressourcensteuerung -- Sie konfigurieren CPU, Speicher und Timeout pro Sandbox. Läuft ein Agent zu lange oder verbraucht zu viel Speicher, wird die Sandbox automatisch beendet.
• Parallele Ausführung -- Mehrere Sandboxes können gleichzeitig laufen und an unterschiedlichen Aufgaben arbeiten. Workflow-Schritte, Issue-Sitzungen und Standalone-Sandboxes arbeiten unabhängig voneinander.

Architektur

Die Sandbox-Architektur in CodeCourier umfasst drei Schichten:

E2B-Infrastruktur

E2B stellt die VM-Infrastruktur bereit. Fordert CodeCourier eine Sandbox an, provisioniert E2B eine Mikro-VM aus einem Template (z. B. dasclaude-Template für Claude-Code-Sandboxes oder dasopencode-Template für OpenCode). Die bereitgestellte VM enthält eine Basis-Linux-Umgebung mit Node.js, Python, Git und gängigen Entwicklungs-Tools vorinstalliert.

Trigger.dev-Orchestrierung

Lang laufende Sandbox-Operationen werden von Trigger.dev-Hintergrundtasks verwaltet. Startet eine Workflow-Ausführung, erstellt Trigger.dev die E2B-Sandbox, führt Setup-Skripte aus (Git-Clone, Abhängigkeitsinstallation, Konfigurations-Injektion), führt das KI-Agenten-Kommando aus, streamt die Ausgabe zurück in die Datenbank und übernimmt das Cleanup nach Abschluss oder Fehler.

Convex-Datenbank

Jede Sandbox hat einen entsprechenden Datensatz in der Convex-Datenbank, der ihren Zustand verfolgt. Die Datenbank speichert den Status der Sandbox (creating, running, paused,killed oder error), ihre Konfiguration (Template, Timeout, CPU, Speicher), ihre Beziehungen zu Runs und Workflows sowie Metadaten wie PR-URLs, Branch-Namen und Learning-Extraktionsstatus. Da Convex reaktiv ist, aktualisiert sich die Dashboard-UI in Echtzeit, wenn sich der Sandbox-Zustand ändert.

Sandbox-Typen

Sandboxes in CodeCourier werden in verschiedenen Kontexten erstellt, jeder mit leicht unterschiedlichen Lebenszyklus-Eigenschaften:

Standalone-Sandboxes

Direkt von der Sandboxes-Seite erstellt. Das sind interaktive Umgebungen, in denen Sie Nachrichten an den KI-Agenten senden, gestreamten Terminal-Output sehen und den Lebenszyklus manuell steuern können. Standalone-Sandboxes eignen sich ideal für Ad-hoc-Aufgaben, Debugging und Exploration.

Workflow-Run-Sandboxes

Werden automatisch erstellt, wenn eine Workflow-Ausführung läuft. Jeder Schritt in der Pipeline (Designer, Checker, Optimizer) erhält eine eigene Sandbox. Diese Sandboxes werden vom Workflow-Orchestrator verwaltet -- Sie überwachen sie typischerweise über die Run-Detailansicht statt über die Sandboxes-Seite.

Issue-Sitzungs-Sandboxes

Werden während Issue-Sitzungen erstellt. Eine Issue-Sitzungs-Sandbox führt einen KI-Agenten aus, der Ihr Repository analysiert, die Codebasis erkundet und Probleme sowie Verbesserungen identifiziert. Issue-Sitzungs-Sandboxes arbeiten unabhängig von Workflows.

Issue-Sitzungs-Sandboxes

Werden während Issue-Analyse-Sitzungen erstellt. Diese Sandboxes führen einen KI-Agenten aus, der Ihr GitHub-Repository prüft, Issues und Verbesserungen identifiziert und strukturierte Issue-Karten mit Vorschlags-Prompts erzeugt.

Sandbox-Konfiguration

Jede Sandbox wird mit einem Konfigurationsobjekt erstellt, das ihre Ressourcen und ihr Verhalten steuert:

• Template-ID -- Welches E2B-Template verwendet wird (z. B. claude, opencode, codex,pi). Bestimmt das vorinstallierte CLI-Tool und die Basisumgebung.
• Timeout -- Maximale Ausführungszeit, von 1 Minute bis 4 Stunden (60.000 bis 14.400.000 Millisekunden). Überschreitet die Sandbox dieses Timeout, wird sie automatisch beendet.
• Speicher -- RAM-Zuteilung in MB, zwischen 256 MB und 8.192 MB. Mehr Speicher wird für große Codebasen und aufwendige Kompilierung benötigt.
• CPU -- CPU-Anzahl, zwischen 1 und 8. Mehr CPUs helfen bei parallelen Builds und Test-Ausführungen.
• Designer-Modell -- Das KI-Modell für Designer-Schritte (z. B. claude-opus-4-6,claude-sonnet-4-6).
• Checker-Modell -- Das KI-Modell für Checker-Schritte (kann sich vom Designer-Modell unterscheiden).
• Denkleistung -- Modellspezifische Denkleistungs- Einstellungen (z. B. high, medium,low).

Beziehung zu anderen Features

Sandboxes sind mit nahezu jedem Feature in CodeCourier verknüpft:

• Workflows nutzen Sandboxes zur Ausführung jedes Schritts.
• Personas definieren die Agentenkonfiguration, die während Workflow-Ausführungen in Sandboxes eingespielt wird.
• Issue-Sitzungen laufen in dedizierten Sandboxes.
• Learnings werden nach Abschluss aus der Sandbox-Nachrichtenhistorie extrahiert.
• Pull Requests werden aus dem Sandbox-Branch-Zustand erstellt, wenn eine Sandbox ihre Arbeit beendet.
• Nutzungsverfolgung erfasst die Kosten jeder Sandbox-Sitzung (E2B-Compute, KI-Token-Nutzung).