Skip to main content
Jede Base44-App hat eine Sandbox: eine private Cloud-Umgebung, die den Code der App enthält und ihren Entwicklungsserver ausführt. Es ist dieselbe Umgebung und derselbe Code, den auch der App-Editor verwendet, ohne Fork oder Kopie, die synchron gehalten werden muss. Verbinde dich per CLI, MCP-Client oder API, um deine App von jedem Rechner aus zu lesen, zu durchsuchen, zu bearbeiten und Befehle darauf auszuführen, ohne lokalen Checkout und ohne Installation. Wenn du eine Datei über die Sandbox schreibst, änderst du direkt deine echte App, so wie es der App-Editor tun würde. Der häufigste Grund dafür ist, deinen eigenen Coding-Agenten mitzubringen für eine App, die du im App-Editor gebaut hast.
Du benötigst einen Builder-Tarif oder höher, um von außerhalb des App-Editors auf die Sandbox einer App zuzugreifen. Ohne einen solchen Tarif schlagen Befehle mit PREMIUM_REQUIRED fehl.

​
Wann du die Sandbox verwenden solltest

Du kannst auf folgende Weise am Code einer App arbeiten, die du im App-Editor gebaut hast: Sandbox und GitHub-Integration überschneiden sich am meisten, da beide dich mit deinen eigenen Tools arbeiten lassen. Der Unterschied ist, wo der Code lebt, während du arbeitest. Mit der GitHub-Integration entwickelst du in einem lokalen Klon, und deine Änderungen erreichen Base44, wenn sie in main gemergt werden. Mit der Sandbox arbeitest du direkt am Code der App. Es gibt nichts herunterzuladen, ein webbasierter Assistent kann sie nutzen, und jede Änderung erscheint in der Live-Vorschau des App-Editors, sobald sie gemacht ist.

​
Verbindungsmöglichkeiten

Du kannst die Sandbox auf folgende Weisen erreichen: Connectors laufen nicht über das Sandbox-Dateisystem und stehen daher nicht in der obigen Tabelle. Um einen Connector auf einer App einzurichten, an der du auf diese Weise arbeitest, verwende stattdessen connectors initiate. Er richtet sich direkt an dieselbe App-ID, ohne Sandbox oder lokales Projekt.

​
Branches

Sandbox-Befehle zielen auf den main-Branch der App, sofern du nichts anderes angibst. Um an einem anderen Branch zu arbeiten, führe branches list aus, um seinen genauen Namen zu finden, und übergib dann --branch <name> bei jedem Sandbox-Befehl. Lese- und Bearbeitungsvorgänge gelten dann nur für diesen Branch.

​
Änderungen werden automatisch gespeichert

Ein Aufruf von sandbox write oder sandbox edit committet die Änderung für dich als Teil derselben Anfrage, bevor der Befehl zurückkehrt, es gibt also keinen separaten Save-, Deploy- oder Push-Schritt. Eine Dateiänderung, die über sandbox run erfolgt, etwa rm oder mv, wird stattdessen ein paar Sekunden später committet, sobald ein kurzes Debounce-Fenster geschlossen ist. Wenn du erneut schreibst oder bearbeitest, bevor ein früheres debouncedes Commit gelandet ist, wartet der neue Aufruf darauf und schlägt mit COMMIT_FLUSH_PENDING fehl, wenn er nicht bestätigen kann, dass das Commit rechtzeitig abgeschlossen wurde. Strukturierte Ressourcen synchronisieren sich auf die gleiche Weise. In einem lokalen Projekt würdest du nach dem Hinzufügen einer Datei entities push oder functions deploy ausführen. In der Sandbox reicht es, base44/functions/send-email/entry.ts zu erstellen, um diese Funktion hinzuzufügen.
Zwei Regeln beim Bearbeiten in einer Sandbox:
  • Führe deploy, functions deploy, entities push oder die anderen Push-Befehle nicht gegen eine App aus, die du in ihrer Sandbox bearbeitest. Diese Befehle synchronisieren ein lokales Projekt zu Base44, und es gibt kein lokales Projekt, wenn du mit einer Sandbox arbeitest.
  • Wenn deine letzte Aktion ein Shell-Befehl über sandbox run war und nicht ein write- oder edit-Aufruf, ist sein Commit noch einen Moment im Rückstand. Warte ein paar Sekunden, bevor du die Verbindung trennst.

​
Bearbeiten und Veröffentlichen

Das Bearbeiten über die Sandbox ist nicht dasselbe wie das Veröffentlichen. Deine Bearbeitung wird sofort Teil des App-Codes und erscheint im App-Editor und seiner Live-Vorschau. Die öffentliche Site der App zu erreichen erfordert weiterhin denselben Publish-Schritt wie eine im App-Editor gemachte Änderung.

​
Checkpoints

Ein Checkpoint ist ein Wiederherstellungspunkt im Versionsverlauf der App, verankert an einem bestimmten Commit. Erstelle einen mit sandbox checkpoint, um einen bekannten guten Zustand zu markieren, und stelle ihn dann aus dem App-Editor wieder her, falls eine spätere Änderung schiefgeht. Ausstehende Änderungen werden vor dem Checkpoint committet, sodass dieser immer deinen neuesten Code erfasst.

​
Zusammenarbeit mit dem App-Editor

Dein Coding-Agent und der Base44-App-Editor können gleichzeitig an derselben App arbeiten. Es gibt keine Sperre, die zu erwerben wäre, und keine Session, die freigegeben werden müsste. Änderungen von beiden Seiten landen am selben Ort, behandle es also wie eine Kollegin oder einen Kollegen, die dasselbe Projekt bearbeiten.
Es gibt keinen Merge-Schritt. Wenn dein Coding-Agent und der App-Editor gleichzeitig dieselbe Datei ändern, gewinnt der Write, der zuletzt landet, und die frühere Änderung ist weg. Vermeide es, dass beide Seiten dieselbe Datei in derselben Arbeitsphase berühren.

​
Starten und Stoppen

Die Sandbox ist ein laufender Prozess, nicht nur Speicher. Sie fährt herunter, wenn sie eine Weile untätig ist, und beim nächsten Befehl wieder hoch. Dein Code ist davon unbetroffen. Committete Änderungen leben in git, und eine neu gestartete Sandbox beginnt immer von deinem neuesten Commit. Wenn die Sandbox nicht läuft, startet der erste Befehl sie, was bedeutet, dass dieser Aufruf wahrscheinlich länger dauert als die darauffolgenden.

​
Berechtigungen

Zwei separate Prüfungen kontrollieren den Zugriff auf die Sandbox. Die eine ist, ob du überhaupt auf die App zugreifen kannst, und die andere, ob deiner aktuellen Session Schreibzugriff darauf gewährt wurde.

​
App-Zugriff

Du benötigst Admin-Zugriff auf die App selbst, entweder als Workspace-Admin oder als Kollaborator dieser spezifischen App. Der Zugriff wird bei jedem Aufruf geprüft, sodass eine Änderung deiner Workspace-Rolle sofort wirksam wird. Ein reiner Workspace-Viewer kann die Sandbox überhaupt nicht erreichen. Die einzige Ausnahme ist ein Viewer, der zusätzlich eine ältere App-spezifische Editor-Rolle aus der Zeit vor der Umstellung des Workspaces auf rollenbasierten Zugriff hält. Diese Kombination kann weiterhin aus der Sandbox lesen, aber nichts ändern. Superagents unterstützen die Sandbox-Befehle nicht.

​
Session-Umfang

Über den App-Zugriff hinaus erfordern Lesen und Ändern der Sandbox unterschiedliche Berechtigungen für deine Session: Die Berechtigungen deiner Session sind bei ihrer Erstellung festgelegt und können später nicht erweitert werden. Die CLI fragt während base44 login nach sandbox:write, und über MCP gewährst du sie im OAuth-Zustimmungsschritt. Das Erneuern einer bestehenden Session fügt sie nicht hinzu. Wenn also die lesenden Befehle funktionieren, aber die ändernden mit NOT_AUTHORIZED fehlschlagen, bist du in einer Session, die nie sandbox:write hatte. Führe base44 login erneut aus oder verbinde den MCP-Server erneut und genehmige den Sandbox-Zugriff, um eine Session zu starten, die sie hat.

​
Grenzen und Leitplanken

Datei-Befehle sind auf das App-Root beschränkt. Absolute Pfade und Pfade, die über das Root hinausgehen, werden mit PATH_OUTSIDE_SANDBOX abgelehnt. Die Verzeichnisse .agents und .git sind über die Datei-Befehle nicht erreichbar und schlagen mit PROTECTED_PATH fehl, da sie die Secrets deiner App und die Repository-Zugangsdaten enthalten. Die einzige Ausnahme ist .agents/skills, das du lesen und schreiben kannst. Über das gesamte Feature hinweg bist du auf 120 Leseanfragen, 60 Änderungsanfragen und 30 Run-Befehle pro Minute und App begrenzt. Wenn du eines dieser Limits überschreitest, schlägt der Aufruf mit RATE_LIMITED fehl. Die Referenzseite jedes Befehls behandelt seine Größen- und Anzahllimits, etwa wie viele Pfade sandbox read akzeptiert oder wie groß eine Datei bei sandbox write sein darf.

​
Siehe auch

Diese Seite wurde mit KI übersetzt. Die genauesten und aktuellsten Informationen findest du in der englischen Version.