Sandbox

Die Sandbox ist eine isolierte Umgebung, in der dein Assistent Code ausführen kann, sicher getrennt vom restlichen System.

Was ist die Sandbox?

Die Sandbox erlaubt es Assistenten, Code in einer kontrollierten Umgebung auszuführen. Sie wird vor allem für technische oder rechenintensive Arbeit genutzt und ist eng mit Code-Ausführung und manchen MCP-Setups verbunden. Das ist nützlich für:

• Berechnungen: Komplexe Formeln oder Datenauswertungen
• Datenverarbeitung: Transformation und Analyse von Daten
• Skriptausführung: Wiederkehrende Aufgaben automatisieren
• Tests: Code testen, bevor er in Produktion geht

Sandbox-Konfiguration

Wenn du die Sandbox für einen Space oder Assistenten aktivierst, stehen dir in den Einstellungen jetzt mehrere technische Optionen zur Verfügung.

Sandbox aktivieren

Mit Sandbox aktivieren schaltest du die Sandbox-Funktion für diesen Assistenten oder Space frei. Erst dann können Sandbox-Tools und lokale STDIO-MCP-Server diese Laufzeit nutzen.

Wichtig dabei:

• Ein normaler Chat startet die Sandbox nicht automatisch.
• Starten und stoppen kannst du die Umgebung über die Sandbox-Seite oder über passende Admin-/Tool-Aktionen.
• Ohne aktivierte Sandbox lassen sich viele lokale oder STDIO-basierte MCP-Setups nicht sinnvoll nutzen.

Laufzeit-Backend

Mit Laufzeit-Backend legst du fest, wo diese Space-Sandbox und ihre STDIO-MCPs laufen.

Zur Auswahl stehen:

• Kubernetes (Legacy): Das bisherige Verhalten. Die Sandbox läuft als Pod im vorhandenen Cluster.
• OpenSandbox: Die Sandbox nutzt den zentral konfigurierten OpenSandbox-Server.

Praktisch heißt das:

• Die Auswahl gilt für die Sandbox dieses Spaces und für STDIO-MCP-Server, die darin gestartet werden.
• Kubernetes ist die richtige Wahl, wenn ihr beim bisherigen Cluster-basierten Betrieb bleiben wollt.
• OpenSandbox ist nur auswählbar, wenn diese Option in eurer Umgebung bereits konfiguriert ist.
• Beim ersten Start mit OpenSandbox legt CLYE die nötige Zuordnung für diesen Space an.
• Wenn du später das Backend wechselst, beendet CLYE eine bereits laufende Space-Sandbox zuerst bestätigt und startet sie dann direkt über das neu konfigurierte Backend neu. Die Änderung greift dadurch sofort und nicht erst beim nächsten Chat- oder STDIO-MCP-Aufruf.
• Nutzt ein Chat oder die Spracheingabe eine OpenSandbox-Laufzeit, startet CLYE bei Bedarf jetzt auch ein noch nicht bereites Gateway dieser Laufzeit neu. So scheitern erste Nachrichten oder Transkriptionen seltener nur daran, dass die Runtime zwar schon existiert, ihr Gateway aber noch nicht wieder verbunden war.

Ausführungsmodus

Mit Ausführungsmodus legst du fest, ob die Sandbox als root oder non-root (UID 1000) startet.

Weitere technische Einstellungen

Je nach Setup kannst du zusätzlich technische Details anpassen, zum Beispiel:

• Docker Image
• Start-Skript
• Umgebungsvariablen
• Persistenzmuster
• Ressourcenlimits für CPU und Arbeitsspeicher

Sandbox-Manager

Der Sandbox-Manager gibt dir eine Übersicht über:

• Aktive Sandboxes: Welche Umgebungen laufen gerade?
• Verlauf: Welche Code-Ausführungen haben stattgefunden?
• Ressourcennutzung: Wie viel CPU/Zeit wurde verbraucht?

Sicherheitsaspekte

• Code läuft in einer isolierten Umgebung ohne Netzwerkzugriff (standardmäßig)
• Kein Zugriff auf das Dateisystem des Hosts
• Für bestimmte MCP-Setups ist eine laufende Sandbox Voraussetzung, zum Beispiel wenn ein STDIO-basierter MCP-Server lokal in dieser Umgebung gestartet werden soll
• Zeitbegrenzung: Läufe werden nach einer konfigurierten Zeit automatisch beendet
• Protokollierung: Alle Ausführungen werden aufgezeichnet

Was im Alltag wichtig ist

• Wenn ihr nur normale Assistenten ohne Code oder lokale MCP-Server nutzt, brauchst du die Sandbox oft gar nicht aktiv.
• Wenn ein STDIO-basierter MCP-Server eingerichtet werden soll, muss die Sandbox in der Regel verfügbar sein. Ohne laufende Sandbox lässt sich ein solcher Server oft nicht sinnvoll anlegen oder bearbeiten.
• In deinem Personal Space richtet sich der sichtbare Sandbox-Status deines persönlichen Assistenten jetzt wieder nach dem zugehörigen Basis-Assistenten. Wenn die Sandbox dort aktiviert ist, wird dieser geerbte Stand in den Einstellungen wieder korrekt angezeigt.
• Ein leeres Overlay oder ein intern gespeichertes sandbox: null im persönlichen Assistenten bedeutet dabei nicht mehr fälschlich „Sandbox aus“. Nur eine dort explizit gesetzte eigene Sandbox-Konfiguration überschreibt den geerbten Stand.
• Bereits laufende Python- oder Tool-Sitzungen bleiben dadurch im Alltag stabiler. Gerade bei längeren Analysen mit execute_python oder beim Bearbeiten von STDIO-basierten MCP-Servern geht laufender Zustand seltener durch einen unerwarteten Sandbox-Neustart verloren.
• Dasselbe gilt jetzt auch robuster in Aufgaben im eigenen Personal Space oder in Aufgaben deines persönlichen Assistenten: Wenn du dort ein Sandbox-Werkzeug wie js_execute auslöst, bleibt der Lauf zuverlässiger im bestehenden Aufgaben-Thread. So scheitern Datei- oder Sandbox-Schritte in laufenden Folgeaufgaben seltener an einem fehlenden Chat-Kontext.
• Python-basierte Sandbox-Unteraufrufe werden dabei jetzt enger an den laufenden Thread und den auslösenden Tool-Aufruf gebunden. Ergebnisse aus solchen Unteraufrufen erscheinen dadurch sauberer als verschachtelte Tool-Schritte im selben Verlauf, statt sich leichter einem falschen Thread unterschieben zu lassen.
• Der Thread-Dateizugriff unter /thread richtet sich dabei jetzt nach der Space-Mitgliedschaft statt nach einer einzelnen Nutzer-ID. Dadurch können auch Worker- oder Agent-Läufe ohne menschlichen Nutzerkontext ihre eigenen Thread-Dateien wie .tool-results/ weiter lesen und schreiben, solange der Lauf im richtigen Space stattfindet.
• Praktisch heißt das: In einem Space dürfen Mitglieder und zugehörige Agent- oder Worker-Läufe die Threads dieses Spaces im Thread-Dateisystem sehen, auch wenn der jeweilige Chat privat ist. Threads anderer Spaces bleiben weiterhin unsichtbar.
• Status, Start und Verbindungspfad wurden in der Oberfläche zuletzt stabiler und konsistenter gemacht, damit besser erkennbar ist, ob eine Sandbox wirklich bereit ist.
• Im globalen OpenSandbox-Inventar ist der Filter jetzt standardmäßig auf Space-Sandboxes gesetzt. Zusätzlich kannst du gezielt zwischen CLYE-Gateway-Sandboxes und MCP-Sandboxes (OAuth) wechseln. So erkennst du schneller, ob eine Laufzeit aus dem normalen Sandbox-Bereich deines Spaces stammt oder als eigene Ausführungs-Sandbox eines verbundenen MCP-Dienstes gestartet wurde.
• Wenn unter Space-Sandboxes noch nichts läuft, erklärt der leere Zustand jetzt klarer den Unterschied: MCP-Sandboxes entstehen nach der OAuth-Anmeldung, CLYE-Gateway-Sandboxes dagegen im Sandbox-Bereich des Space oder automatisch beim ersten STDIO-MCP-Aufruf.
• Wenn die Oberfläche erkennt, dass eine laufende Sandbox gerade von einer anderen Umgebung genutzt wird, zeigt der Status jetzt diese fremde Umgebung direkt an. In der Detailansicht weist ein Hinweis zusätzlich darauf hin, dass du die Sandbox mit Stoppen oder Neustarten für die aktuelle Umgebung übernehmen kannst.
• Eine offene und aktive MCP-SSE-Verbindung zählt jetzt zusätzlich als Lebenszeichen der Sandbox. Dadurch wird eine laufende, aber gerade ruhige Sandbox nicht mehr fälschlich als nicht erreichbar behandelt, nur weil zwischenzeitlich keine anderen Tool-Aufrufe stattfinden.
• Das Auto-Starten funktioniert zuverlässiger, und die kompakte Statusanzeige in der Oberfläche ist klarer lesbar.
• Beim Anlegen oder Bearbeiten eines STDIO-basierten MCP-Servers verhindert CLYE AI jetzt bewusster irreführende Zustände: Ohne verfügbare Sandbox lässt sich ein solcher Server nicht sinnvoll konfigurieren.
• In der OpenSandbox-Adminansicht zeigen Laufzeiten jetzt deutlicher ihren Typ: MCP-Sandboxes aus einer OAuth-Anmeldung sind als Ausführungs-Sandbox des verbundenen MCP-Dienstes erkennbar und zeigen passende Dienst-Icons, Verbindungsstatus und die Zahl der bereiten MCPs.
• In den Sandbox-Details gibt es für solche Laufzeiten zusätzliche Reiter für MCP-Verbindungen, Logs, Ereignisse und Terminal. So kannst du direkt in der Adminansicht prüfen, ob das CLYE-Gateway verbunden ist, welche MCP-Server des zugeordneten Space aktiv sind und ob die Laufzeit selbst Ereignisse meldet.
• Das obere Aktionen-Menü bleibt dabei auch in der Detailansicht verfügbar. Du musst für Start, Stopp oder weitere Verwaltungsaktionen also nicht erst zurück in die Übersicht wechseln.
• Sind für eine OAuth-Laufzeit mehrere zugehörige MCP- oder Gateway-Verbindungen vorhanden, zeigt die Detailansicht diese Verbindungen jetzt gesammelt und konsistent an, statt nur einen Teil der aktiven Einträge sichtbar zu machen.
• Im Reiter Logs kannst du zwischen Pod-Logs und Gateway-Logs wechseln und die letzten Zeilen mit automatischer Aktualisierung verfolgen. Im Reiter Terminal lassen sich kurze Befehle direkt in der ausgewählten Laufzeit ausführen; danach zeigt CLYE AI den Exit-Code und die kombinierte Ausgabe an.

So erreichst du die Sandbox-Einstellungen

1. Öffne den Space oder Assistenten
2. Gehe zu den Einstellungen
3. Wähle den Bereich Sandbox

Wenn ein Space die Sandbox-Einstellungen nur von deinem persönlichen Assistenten erbt, zeigt CLYE AI in diesem Space keine eigenen Sandbox-Felder mehr an. Öffne in diesem Fall die Einstellungen deines persönlichen Assistenten, wenn du die geerbte Konfiguration prüfen oder ändern willst.

warnung

Aktiviere die Sandbox nur, wenn der Assistent Code-Ausführung wirklich benötigt. Jede aktive Fähigkeit erhöht die Angriffsfläche.