2026 DeepSeek Harness: E2B-Sandbox oder persistente Umgebung?

Ein persönlicher Testlauf ist ein guter Kandidat für E2B, wenn das Ergebnis aus wenigen Dateien, einem Log und einem reproduzierbaren Befehl besteht. Beispiele sind ein einmaliger Parser-Test, ein kleiner Build-Check oder die Prüfung eines Pull Requests aus einer unbekannten Quelle. Wenn das Arbeitsverzeichnis danach gelöscht werden kann und sich der Zustand aus Repository, Lockfile und Konfigurationsvorlage wiederherstellen lässt, bringt eine kurzlebige Umgebung wenig dauerhafte Last in den Betrieb.

Eine persistente Umgebung ist direkter, sobald der Agent über mehrere Sitzungen hinweg mit demselben lokalen Zustand arbeitet. Dazu gehören:

• bereits installierte private Abhängigkeiten;
• Build-Caches, lokale Datenbanken und Testdaten;
• laufende Entwicklungsserver;
• manuelle Eingriffe über Terminal oder grafische Oberfläche;
• Sitzungsdateien, Zwischenstände und wiederaufnehmbare Agent-Verläufe;
• feste Berechtigungen für ein bestimmtes Repository oder Team.

Der erste versteckte Kostenpunkt ist damit nicht der Rechenpreis. Es ist die Wiederherstellung. Wenn ein Entwickler nach jedem Sandbox-Lauf Abhängigkeiten, Testdaten und Sitzungsnotizen erneut aufbauen muss, wird der scheinbar günstige Einmallauf durch Wartezeit und Fehlersuche teurer.

Der zweite Kostenpunkt ist die Beweiskette. Ein Harness-Lauf muss einer Aufgaben-ID, einem Commit, einem Eingabepaket und einem Artefaktpaket zugeordnet werden. Ohne diese Zuordnung können wir später nicht sicher sagen, welche Datei der Agent verändert hat, welches Tool sie erzeugt hat und ob ein Fehler aus dem Modell, der Umgebung oder der Übergabe stammt.

Der dritte Punkt ist die Berechtigung. Eine isolierte Ausführungsfläche verhindert nicht automatisch Prompt Injection, Datenabfluss oder missbräuchliche Tool-Aufrufe. Wenn der Agent Internetzugang, private Tokens oder Schreibrechte auf externe Systeme erhält, bleibt die Risikosteuerung eine Aufgabe der Schnittstellen und Richtlinien. E2B ist eine Ausführungsisolation, kein vollständiges Governance-System. Das offizielle E2B-Repository beschreibt Sandboxes als isolierte Cloud-Umgebungen für AI-generierten Code, nicht als automatische Garantie gegen jede Form von Fehlverhalten.

Die folgende Tabelle ist unser Entscheidungspunkt. Sie beantwortet nicht, welche Umgebung technisch „besser“ ist, sondern welcher Verantwortungstyp zu welcher Umgebung passt.

E2B unterstützt laut eigener Dokumentation eine konfigurierbare Sandbox-Laufzeit. In der aktuellen Dokumentation werden bis zu 24 Stunden für den Pro-Betrieb und 1 Stunde für den Base-Betrieb genannt; bei Pause und Wiederaufnahme kann der Zustand erhalten bleiben. Diese Angaben sind Betriebsparameter der E2B-Sandbox, nicht automatisch die Lebensdauer einer DeepSeek-Harness-Sitzung. (E2B-Dokumentation)

Genau diese Unterscheidung wird häufig übersehen:

1. Sandbox-Lebenszyklus: Läuft der Prozess weiter, wird er pausiert oder beendet?
2. Harness-Sitzung: Bleiben Verlauf, Tool-Aufrufe, Plan und Zwischenstatus abrufbar?
3. Arbeitsbereich: Sind Dateien, Abhängigkeiten, Datenbanken und Cache noch vorhanden?
4. Artefakte: Wurden Ergebnisse vor dem Ende zuverlässig exportiert?
5. Berechtigungen: Sind Tokens nach dem Neustart noch gültig oder bewusst abgelaufen?

Ein „Ja“ bei Punkt zwei sagt daher nichts über Punkt drei aus. Eine gespeicherte Sitzung ohne Arbeitsverzeichnis kann zwar den Gesprächsverlauf zurückbringen, aber nicht den Zustand eines laufenden Servers oder eine ungesicherte Datenbank.

Für persönliche Experimente empfehlen wir einen kleinen Vorfilter. Eine Aufgabe darf in E2B, wenn alle folgenden Aussagen zutreffen:

• Das Repository lässt sich mit einem dokumentierten Befehl aus einem sauberen Zustand aufbauen.
• Der Agent benötigt keine lokale Keychain und keine physische Geräteverbindung.
• Das Ergebnis besteht aus bekannten Dateien oder strukturierten Logs.
• Der Auftrag kann ohne manuelle Fortsetzung beendet werden.
• Externe Schreibzugriffe sind entweder deaktiviert oder auf ein Testsystem begrenzt.
• Ein Fehlschlag darf die Umgebung vollständig verwerfen.

Typische Kandidaten sind Dependency-Checks, statische Analyse, Code-Formatierung, Testdatengenerierung und die Prüfung eines kleinen Skripts. Für einen langen Refactoring-Lauf mit wiederholter menschlicher Übernahme ist die persistente Umgebung praktischer. Dort bleiben Terminalhistorie, lokale Werkzeuge und Zwischenstände sichtbar.

Wir würden für den ersten persönlichen Probelauf nicht sofort einen dauerhaften Arbeitsbereich aufbauen. Zuerst sollte eine einzelne Aufgabe mit leerem Zustand, begrenztem Dateisatz und ohne Produktionsgeheimnisse erfolgreich durchlaufen. Erst wenn der Export und die Wiederaufnahme dokumentiert sind, lohnt die Entscheidung für einen festen Arbeitsbereich.

Anwendungsteams sollten vor der Umgebungsauswahl eine Rekonstruktionsliste erstellen. Wir markieren jede Abhängigkeit mit „aus Repository wiederherstellbar“, „extern zu speichern“ oder „nur im persistenten Arbeitsbereich vorhanden“.

Besonders wichtig sind:

• Build-Cache: Kann er gelöscht werden, ohne dass sich das Ergebnis ändert?
• Private Pakete: Wird ein Token zum Installieren benötigt, und wer darf ihn ausstellen?
• Datenbank: Wird sie aus Migrationen und Testdaten reproduziert oder enthält sie manuelle Zustände?
• Sitzungsdateien: Sind sie nur Komfort oder Bestandteil der Agent-Logik?
• Arbeitsprodukte: Müssen sie in das Repository, in ein Artefaktarchiv oder in einen persistenten Ordner?
• Laufende Prozesse: Muss ein Server zwischen zwei Agent-Schritten aktiv bleiben?
• Netzwerk: Sind eingehende Verbindungen notwendig, oder genügt ein ausgehender Zugriff?

Wenn mindestens eine kritische Abhängigkeit nicht reproduzierbar ist, sollte die Aufgabe nicht als vollständig wegwerfbar behandelt werden. Sie kann trotzdem zweistufig ausgeführt werden: E2B erzeugt einen Patch oder ein Prüfprotokoll; die persistente Umgebung übernimmt Build, Integration und manuelle Validierung.

Für Teams mit mehreren Repositories ist eine feste Aufgaben-ID entscheidend. Wir empfehlen, bei jedem Lauf mindestens folgende Metadaten zu speichern:

1. Repository und Commit;
2. Harness-Konfiguration und Plugin-Version;
3. Sandbox- oder Host-ID;
4. Eingabedateien und erlaubte Quellen;
5. zurückgegebene Artefakte;
6. Grund für Abbruch oder Übergabe.

Das ist keine automatische Sicherheitsfunktion. Es ist eine Betriebsanforderung, damit ein späterer Fehler nicht zwischen Modell, Plugin und Umgebung verloren geht.

Sobald der Agent Xcode, iOS-Signierung, Simulator, Safari, Keychain oder andere macOS-spezifische Funktionen benötigt, bleibt ein echter Mac die Ausführungsfläche. E2B darf in diesem Ablauf eine Vorstufe übernehmen: untrusted Code analysieren, Dateien entpacken, Abhängigkeiten prüfen oder einen Patch gegen definierte Regeln testen. Der freigegebene Teil wird danach auf einem kontrollierten Mac ausgeführt.

Apple dokumentiert für Xcode eine konkrete Zuordnung zwischen Xcode-Versionen, unterstützten macOS-Versionen, SDKs, Simulatoren und Gerätetypen. Das ist ein Versions- und Plattformproblem, das eine allgemeine Linux-Sandbox nicht ersetzt. Die Apple-Systemanforderungen für Xcode sollten deshalb vor jedem macOS-relevanten Einsatz geprüft werden.

Auch die Signierung ist nicht nur ein Dateischritt. Provisioning-Profile verbinden unter anderem Zertifikate, Bundle-ID und Geräteinformationen. Apple beschreibt dafür sowohl automatische als auch manuelle Abläufe in Xcode. Die Apple-Anleitung zu Provisioning-Profilen liefert die maßgeblichen Grenzen.

Bei der Keychain gilt dieselbe Regel. macOS kann mehrere Keychains verwalten und den Zugriff auf einzelne Einträge kontrollieren. Ein Agent, der Signierzertifikate oder gespeicherte Zugangsdaten benötigt, braucht daher eine ausdrücklich kontrollierte Mac-Umgebung. Die Apple-Dokumentation zu Keychain Services beschreibt die relevanten Speicher- und Zugriffskontrollen.

Wir würden für ein macOS-Toolchain-Team mindestens diese Trennung festlegen:

• E2B: Eingangsanalyse, untrusted Tests, Entpacken und statische Prüfung;
• persistenter Mac: Xcode-Build, Simulator, Signierung, Safari und Keychain;
• Übergabepaket: Commit, Patch, Prüfsumme, Testprotokoll und erlaubte Zielaktionen;
• Freigabe: menschliche oder policy-basierte Bestätigung vor Signierung und externem Upload.

Dabei darf niemand aus der Existenz einer E2B-Stufe ableiten, dass der gesamte Ablauf sicher ist. Ein bösartiger Patch kann auch nach der Prüfung gefährlich sein, wenn die Mac-Stufe zu weitreichende Rechte besitzt.

Für Plattformverantwortliche ist der Doppelbetrieb meist die belastbarste Architektur. Die persistente Umgebung hält Harness-Konfiguration, Aufgabenstatus, Auditdaten, Freigaben und Fehlerwarteschlangen. E2B übernimmt nur den Schritt, der von Isolation und Wegwerfbarkeit profitiert.

Die Schnittstelle zwischen beiden Flächen muss klein und prüfbar sein. Wir definieren sie in fünf Teilen:

1. Aufgaben-ID: Jede Ausführung erhält eine unveränderliche Kennung.
2. Dateisynchronisierung: Eingaben werden als erlaubte Dateiliste übertragen, nicht als kompletter Arbeitsbereich.
3. Artefaktrückgabe: E2B liefert Patch, Log, Testbericht und Exit-Status zurück.
4. Zustandsentscheidung: Das Kontrollsystem entscheidet, ob die Sitzung fortgesetzt, verworfen oder an den Mac übergeben wird.
5. Fehlerübergabe: Ein Timeout, fehlender Export oder unerwarteter Netzwerkzugriff erzeugt einen klaren manuellen Prüfpunkt.

Die Sandbox-Dokumentation nennt Sandbox-ID, Template, Metadaten sowie Start- und Endzeit als technische Bezugspunkte. Diese Daten eignen sich für die Zuordnung, ersetzen aber nicht die Harness-Auditdaten.

Ein häufiger Fehler ist die unkontrollierte Dateisynchronisierung. Wenn nach jedem Lauf das gesamte Arbeitsverzeichnis zurückkopiert wird, gelangen möglicherweise Geheimnisse, Cache-Dateien oder vom Agent erzeugte Skripte in den dauerhaften Bereich. Wir übertragen deshalb nur definierte Artefakte und behandeln alle übrigen Dateien als verworfen.

Ein zweiter Fehler ist die Vermischung von Sitzungsfortsetzung und Prozessfortsetzung. Ein wiederhergestellter Agent-Verlauf bedeutet nicht, dass der zuvor gestartete Server, Socket oder lokale Datenbankprozess noch existiert. Die Plattform muss den Prozesszustand separat prüfen.

Bei riskanten Eingaben sollte die E2B-Sandbox grundsätzlich ohne Produktionsschlüssel starten. Für die meisten Validierungsläufe genügen Testtokens, kurzlebige Zugangsdaten oder vollständig lokale Fixtures. Ein Agent benötigt selten gleichzeitig Schreibrechte auf ein Repository, Zugriff auf Produktionsdaten und freien Internetzugang.

Wir prüfen vor dem Start:

• Welche Eingaben stammen aus externen oder untrusted Quellen?
• Welche Tools darf DeepSeek Harness tatsächlich aufrufen?
• Welche Umgebungsvariablen werden an E2B weitergegeben?
• Darf der Agent Netzwerkverbindungen aufbauen?
• Welche externen Systeme akzeptieren Schreiboperationen?
• Wer genehmigt die Übergabe in die persistente Mac-Umgebung?
• Wie werden Logs und Artefakte auf personenbezogene Daten geprüft?

E2B unterstützt die Übergabe von Umgebungsvariablen und bietet unterschiedliche Sandbox- und Zugriffsmechanismen. Das muss mit den eigenen Geheimnisrichtlinien abgeglichen werden, nicht blind übernommen werden. Die technische Grundlage ist im E2B-Repository dokumentiert; die konkrete Berechtigungsarchitektur bleibt Aufgabe des betreibenden Teams.

DeepSeek Harness befindet sich laut offiziellem Repository in der Developer Preview. Das Repository weist auf mögliche kompatibilitätsbrechende Änderungen hin. Deshalb sollten Plattformteams E2B nicht als unveränderliche Produktionsschnittstelle behandeln. Das DeepSeek-Harness-README ist vor jeder Aktualisierung erneut zu prüfen.

1. Aufgaben klassifizieren.
   Teilen Sie alle Agent-Aufträge in „wegwerfbar“, „zustandsabhängig“, „macOS-gebunden“ und „extern wirksam“ ein.

2. Rekonstruktionsdatei anlegen.
   Dokumentieren Sie Repository, Lockfile, private Abhängigkeiten, Datenbankstart, Sitzungsdateien und erforderliche Prozesse.

3. Minimalen E2B-Lauf definieren.
   Verwenden Sie eine kleine Eingabemenge, Testgeheimnisse und eine erlaubte Befehlsliste. Produktionszugänge bleiben ausgeschlossen.

4. Artefaktvertrag festlegen.
   Definieren Sie vorab, welche Dateien, Logs und Statuswerte zurückgegeben werden. Alles andere gilt als nicht übergeben.

5. Sitzung und Sandbox getrennt testen.
   Beenden Sie die Sandbox absichtlich. Prüfen Sie anschließend separat, ob Harness-Verlauf, Dateien, Prozesse und Artefakte verfügbar sind.

6. Mac-Übergabe mit einem harmlosen Auftrag prüfen.
   Verwenden Sie zuerst einen nicht signierenden Build oder einen Simulator-Test. Erst danach folgen Keychain, Provisioning und externe Uploads.

7. Fehlerverantwortung schriftlich zuweisen.
   Plattformteams verantworten Timeout, Export und Identität. Entwicklungsteams verantworten Repository, Build und fachliche Abnahme. Sicherheitsverantwortliche genehmigen Geheimnisse und externe Nebenwirkungen.

E2B-Sandbox wählen, wenn:

• [ ] der Auftrag einmalig oder kurzlebig ist;
• [ ] der Code aus einer bekannten Quelle oder bewusst untrusted stammt;
• [ ] das Repository den Zustand vollständig rekonstruieren kann;
• [ ] keine macOS-exklusive Funktion erforderlich ist;
• [ ] Testgeheimnisse ausreichen;
• [ ] ein vollständiger Artefaktexport definiert ist;
• [ ] der Verlust des lokalen Zustands akzeptabel ist.

Persistente Umgebung wählen, wenn:

• [ ] mehrere Sitzungen auf demselben Arbeitsbereich aufbauen;
• [ ] lokale Prozesse oder Datenbanken weiterlaufen müssen;
• [ ] Xcode, Safari, Keychain oder Signierung erforderlich sind;
• [ ] häufige manuelle Übernahme erwartet wird;
• [ ] private Abhängigkeiten und Build-Caches erhalten bleiben müssen;
• [ ] die Aufgabe langfristig an einen festen Mac gebunden ist.

Doppelbetrieb wählen, wenn:

• [ ] riskante Eingaben und dauerhafte Arbeitsprodukte im selben Prozess vorkommen;
• [ ] E2B die Vorprüfung übernehmen kann;
• [ ] ein persistenter Mac die Plattform- oder macOS-Schritte ausführt;
• [ ] Dateiübergabe und Berechtigungsgrenzen technisch getestet sind;
• [ ] ein klarer Abbruchpfad für fehlende oder manipulierte Artefakte existiert.

Für Teams, die zunächst den Mac-Anteil bewerten möchten, ist die Übersicht zur Auswahl zwischen lokalem und cloudbasiertem Mac der passende nächste Schritt. Wenn ein einzelner macOS-Arbeitsbereich für Build- und Debugging-Aufgaben benötigt wird, kann auch die Mac-mini-M4-Bestellung als Referenz für die benötigte Ausführungsfläche dienen. Die Entscheidung sollte dabei von Toolchain, Zustandsbindung und Zugriffsmodell ausgehen, nicht von der bloßen Bezeichnung „Sandbox“.

Der aktuelle Ansatz mit einer reinen E2B-Ausführung hat drei reale Schwächen: macOS-Werkzeuge fehlen, langfristiger lokaler Zustand muss zusätzlich rekonstruiert werden, und jede Artefakt- oder Geheimnisübergabe braucht eigene Kontrolle. Eine reine lokale Umgebung hat dagegen die gegenteiligen Nachteile: untrusted Code landet schneller neben langlebigen Geheimnissen, die Bereinigung bleibt beim Team, und parallele Einmalläufe belegen denselben Arbeitsbereich. Wenn temporäre Rechen- oder Testumgebungen gebraucht werden, kann MESHLAUNCH für den persistenten Mac-Anteil eine praktischere Betriebsfläche bieten. Entscheidend ist, nur die Aufgaben dorthin zu geben, die tatsächlich Mac-Zustand, macOS-Tools oder kontinuierliches Debugging benötigen.