E2B Desktop Sandbox: ein isolierter Linux-Desktop als Ziel für Computer-Use-Agenten

Welches Problem der Sandbox-Desktop löst und für wen

Ein Agent, der eine grafische Anwendung bedienen soll, braucht drei Dinge gleichzeitig: einen Ort, an dem die Anwendung läuft, einen Weg, den Bildschirminhalt an das Modell zu geben, und einen Weg, Klicks und Tastenanschläge zurückzuspielen. Das Repository adressiert genau diese drei Punkte in einer Vorlage. Der Text beschreibt die Sandbox als virtuellen Desktop, der sich mit jedem LLM verbinden lässt und der für Computer Use gedacht ist. Jede Sandbox ist laut README von den anderen isoliert und kann mit eigenen Abhängigkeiten angepasst werden. Die Zielgruppe sind damit Entwickler, die einen Agenten gegen echte Desktop-Software testen wollen (Browser, Editor, Terminal) und dafür keine eigene VM-Infrastruktur mit VNC und Eingabe-Injektion aufsetzen möchten. Die beiden verlinkten Beispielprojekte zeigen die Richtung: Open Computer Use arbeitet laut Beschreibung mit vollständig offenen LLMs, Surf ist ein Next.js-Agent auf Basis der OpenAI-Computer-Use-Funktion.

Aufteilung des Repositories: Vorlage hier, SDKs im Monorepo

Wer den Code sucht, der die Methoden wie left_click oder stream.start implementiert, wird in diesem Repository nicht fündig. Ein Hinweis im README stellt klar, dass die Quellen der SDKs @e2b/desktop und e2b-desktop inzwischen im E2B-Monorepo liegen, und zwar unter packages/desktop-js und packages/desktop-python. Issues und Pull Requests zu den SDKs sollen dort eingereicht werden. Dieses Repository behält die Sandbox-Vorlage und die Beispiele. Für die Bewertung des Wartungsaufwands ist das relevant: Ein Fehler im Python-Client wird nicht hier behoben, und die Release-Historie, die für dieses Repository genannt wird, enthält trotzdem Einträge für @e2b/desktop-python und @e2b/desktop. Die Veröffentlichung der Pakete und die Pflege des Vorlagen-Repositories laufen also nicht zwangsläufig im selben Takt. Wer sich auf eine bestimmte Version verlassen will, muss deshalb prüfen, welche Version des SDK tatsächlich installiert wurde und ob die dazu passende Vorlage noch im hiesigen Repository liegt.

Sandbox erstellen und eine Anwendung starten

Der Einstieg ist kurz. Nach pip install e2b-desktop beziehungsweise npm install @e2b/desktop wird in Python ein Objekt über Sandbox.create() erzeugt. Danach folgt der Start einer Anwendung, im README mit desktop.launch('google-chrome') und dem Hinweis, dass auch vscode oder firefox möglich sind. Anschließend wartet das Beispiel mit desktop.wait(10000) zehn Sekunden, damit die Anwendung Zeit hat, sich zu öffnen. Bemerkenswert ist, dass dieser Wartevorgang explizit im Code steht. Es gibt im gezeigten Material keine Rückmeldung darüber, ob die Anwendung tatsächlich bereit ist, also muss der Aufrufer mit einer festen Zeitspanne arbeiten. Das ist ein einfacher, aber fragiler Mechanismus: Auf einem langsam startenden System oder bei einer schweren Anwendung kann die Wartezeit zu kurz sein, während sie in den meisten Fällen unnötig lang ist. Der JavaScript-Pfad ist identisch aufgebaut, nur mit await vor jedem Aufruf und camelCase in den Optionsnamen, etwa requireAuth statt require_auth.

Streaming: ein Stream gleichzeitig, Fenster oder ganzer Desktop

Der Bildschirminhalt wird über desktop.stream.start() bereitgestellt. Ohne Argumente wird der gesamte Desktop gestreamt, mit window_id nur ein einzelnes Fenster. Die ID kommt entweder aus desktop.get_current_window_id() für das aktive Fenster oder aus desktop.get_application_windows("Firefox"), das laut Beispiel eine Liste von Fenster-IDs zurückgibt. Die URL liefert desktop.stream.get_url(), optional mit view_only=True, um die Interaktion für den Betrachter zu sperren. Drei Einschränkungen stehen ausdrücklich im README. Erstens existiert immer nur ein Stream gleichzeitig, ein weiterer Start erfordert vorher desktop.stream.stop(). Zweitens schlägt das Streamen eines Fensters fehl, wenn die Anwendung noch nicht geöffnet ist. Drittens endet der Stream, sobald die Anwendung geschlossen wird. Für Agenten, die nacheinander verschiedene Programme bedienen, ist das handhabbar. Für Szenarien, in denen ein Mensch parallel zuschauen und ein Agent in einem anderen Fenster arbeiten soll, ist die Ein-Stream-Regel eine harte Grenze, die sich nicht umgehen lässt, ohne die Bibliothek zu verlassen.

Zugriffsschutz über einen generierten Schlüssel

Ein gestreamter Desktop ist ohne Schutz im Netz erreichbar, weshalb das SDK einen optionalen Authentifizierungsschritt anbietet. Mit require_auth=True beim Start des Streams wird ein Schlüssel erzeugt, den desktop.stream.get_auth_key() zurückgibt. Die URL enthält diesen Schlüssel dann als Parameter, wie das Beispiel desktop.stream.get_url(auth_key=auth_key) zeigt. Ohne diesen Parameter bleibt der Stream offen. Das ist eine bewusste Entscheidung zugunsten einer niedrigen Einstiegshürde, aber sie bedeutet auch, dass der Standardfall ungeschützt ist. Wer den Stream-URL in einem Protokoll, einem Chat oder einem Log ablegt, gibt damit Zugriff auf den Desktop, solange der Stream läuft. Das Material sagt nichts darüber, wie lange ein solcher Schlüssel gültig bleibt oder ob er widerrufen werden kann. Diese Frage lässt sich aus dem README nicht beantworten und sollte vor einem produktiven Einsatz geklärt werden.

Maussteuerung als eigentliche Schnittstelle des Agenten

Der umfangreichste Teil der gezeigten API ist die Maus. Verfügbar sind double_click, left_click, right_click und middle_click, jeweils ohne Argumente für die aktuelle Position oder mit x und y. Dazu kommen scroll(10) mit positiven Werten für nach oben und negativen für nach unten, move_mouse(100, 200) sowie drag((100, 100), (200, 200)) für eine Bewegung von einem Punkt zu einem anderen. mouse_press("left") und mouse_release("left") erlauben es, eine Taste gedrückt zu halten und später loszulassen, was für Ziehvorgänge und für Tastenkombinationen mit gedrückter Maustaste nötig ist. Die Koordinaten sind Pixelwerte, die sich auf den gestreamten Desktop beziehen. Wer die Koordinaten aus einem Screenshot ableitet, muss also dieselbe Auflösung und denselben Skalierungsfaktor verwenden, den der Stream liefert. Das README macht dazu keine Angabe, und genau hier liegt eine typische Fehlerquelle: Ein Klick um einige Pixel daneben trifft eine andere Schaltfläche oder gar nichts. Die API ist damit präzise genug für ein Modell, das Koordinaten aus einem Bild vorhersagt, aber sie verzeiht keine Abweichung.

Wann eine Steuerung über das Dateisystem oder das Netzwerk die bessere Wahl ist

Die naheliegende Alternative ist, den Agenten gar nicht über Pixel und Maus arbeiten zu lassen, sondern über die Schnittstellen der Anwendung: eine Shell im Sandbox-Dateisystem, eine HTTP-API, ein Kommandozeilenwerkzeug. Playwright oder ein vergleichbares Browser-Automatisierungswerkzeug steuert eine Seite über das Document Object Model an, also über stabile Selektoren statt über Bildschirmkoordinaten. Der Unterschied im Ansatz ist grundlegend. E2B Desktop Sandbox liefert ein Bild und nimmt Klicks entgegen, wodurch der Agent auch Programme bedienen kann, die keine Skriptschnittstelle besitzen, etwa einen älteren Editor oder einen Dialog, der nur grafisch existiert. Der Preis dafür ist Fehleranfälligkeit: Jede Layoutänderung, jede verschobene Schaltfläche und jede Verzögerung beim Zeichnen kann den nächsten Klick ins Leere laufen lassen. Wer eine Webanwendung automatisiert, sollte zuerst prüfen, ob ein DOM-basierter Weg existiert. Der Desktop-Pfad lohnt sich dort, wo es keinen gibt.

Wartung, Versionen und Lizenz

Das Repository steht unter Apache-2.0, einer permissiven Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen gekennzeichnet werden. Für eine Einbindung in ein eigenes Produkt ist das eine niedrige Hürde. Rechtliche Fragen, etwa zu Patenten oder zu den Bedingungen der gehosteten E2B-Plattform, klärt die Lizenz nicht, und eine Rechtsberatung ersetzt sie ohnehin nicht. Wartungsseitig ist die Lage zweigeteilt. Die SDK-Pakete werden versioniert veröffentlicht, im Material sind @e2b/desktop-python@2.4.2 und @e2b/desktop@2.3.1 als jüngste Einträge genannt, und die Python- und JavaScript-Versionen laufen nicht synchron: 2.4.x gegen 2.3.x. Wer beide Sprachen im selben Projekt verwendet, muss die Optionsnamen auseinanderhalten, require_auth gegen requireAuth, get_auth_key gegen getAuthKey. Ein Upgrade der SDK-Pakete berührt die Sandbox-Vorlage in diesem Repository nicht automatisch, und umgekehrt. Vor einem Versionssprung lohnt deshalb ein Blick auf die Beispiele im Ordner examples, weil dort beide Aufrufkonventionen nebeneinander stehen und Abweichungen schnell sichtbar werden.

Redaktionelles Fazit

Wer einen LLM-Agenten gegen eine grafische Oberfläche laufen lassen will, ohne dafür eigene VM-Images, VNC und Eingabe-Injektion zu bauen, findet hier eine Vorlage mit passenden SDKs in Python und JavaScript. Wer Fenster-Streaming als dauerhaften, parallelen Dienst für mehrere Zuschauer braucht oder die SDK-Quellen im selben Repository wie die Vorlage erwartet, ist hier falsch. Vor dem ersten produktiven Einsatz sollte man prüfen, ob der eigene Agent Maus- und Tastatureingaben synchron aus dem Stream ableitet oder ob er auf die im README beschriebenen Methoden wie left_click und move_mouse zurückgreift, denn nur für den zweiten Fall ist die API ausgelegt.

Offizielle Quellen

1. e2b-dev/desktop on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases