Skip to main content
Bring deinen eigenen KI-Coding-Agenten oder deine eigenen Skripte zu einer Base44-App, indem du dich mit ihrer Sandbox verbindest. Die Sandbox ist eine private Cloud-Umgebung, die den Code für den derzeit im App-Editor aktiven Branch enthält und ihren Entwicklungsserver ausführt. Es ist dieselbe Umgebung und derselbe Code, den auch der Base44-App-Editor selbst bearbeitet, ohne Fork oder Kopie zum Synchronhalten. Wenn du eine Datei über einen Sandbox-Befehl schreibst, änderst du deine echte App direkt in ihrem aktiven Branch, genauso wie es der App-Editor tun würde. So kannst du eine App mit deinen eigenen Tools statt mit dem App-Editor entwickeln, ohne lokales Checkout und ohne etwas zu installieren. Arbeite an einer App von einem Rechner aus, der keine Kopie davon hat, oder skripte eine Änderung über eine App, die du komplett im App-Editor gebaut hast.
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 dessen Live-Vorschau, aber um die öffentliche Website der App zu erreichen, ist weiterhin derselbe Publish-Schritt nötig, wie bei einer im App-Editor gemachten Änderung.
Du brauchst einen Builder-Plan oder höher, um die Sandbox einer App von außerhalb des App-Editors zu erreichen. Ohne einen solchen Plan schlagen Befehle mit PREMIUM_REQUIRED fehl.
Die Sandbox selbst ist ein aktiver Rechenprozess, kein reiner Speicher: Sie fährt herunter, wenn sie eine Weile inaktiv ist, und fährt beim nächsten Befehl wieder hoch. Dein Code bleibt in jedem Fall unberührt, da er in Git lebt und nicht in diesem Prozess. Wenn die Sandbox derzeit nicht läuft, startet sie beim ersten Befehl, und dieser Aufruf dauert länger als die danach.

​
Zwei Wege zur Verbindung

Die Sandbox stellt dieselben Operationen über zwei Oberflächen bereit, die durch dieselbe Implementierung gestützt werden. Nimm die, die zu deinem Setup passt.
  • CLI: Passt zu allem, was auf deinem eigenen Rechner läuft, einschließlich eines lokalen Coding-Agenten und deiner eigenen Skripte. Authentifiziere dich einmal mit base44 login, und richte dich dann mit --app-id oder der Umgebungsvariable BASE44_APP_ID auf die App. Kein lokales Projekt erforderlich.
  • MCP-Server: Passt zu einem KI-Assistenten, der sich über MCP verbindet, einschließlich webbasierter Assistenten, die überhaupt keine CLI ausführen können. Verbinde ihn einmal und autorisiere ihn mit OAuth.
Connectors laufen nicht über das Sandbox-Dateisystem und stehen daher nicht in der Tabelle oben. Um einen Connector auf einer App einzurichten, an der du auf diese Weise arbeitest, nutze stattdessen connectors initiate. Es richtet sich direkt an dieselbe App-ID, ohne Sandbox oder lokales Projekt.
Der schnellste Weg, mit deinem eigenen Coding-Agenten zu starten, ist Send to Coding Agent im Base44-App-Editor. Auf dem Desktop öffnest du More actions (die drei Punkte neben Publish oben rechts) und wählst Send to Coding Agent. Wähle einen lokalen CLI-Agenten oder einen Web-Chat, und du erhältst einen fertigen Prompt zum Einfügen, sodass du nichts davon manuell einrichten musst. Für mobile Apps oder Apps mit nicht verwaltetem Quellcode wird es nicht angeboten.

​
Änderungen speichern automatisch

Ein Aufruf von sandbox write oder sandbox edit committet die Änderung als Teil derselben Anfrage, bevor der Befehl zurückkehrt, sodass es keinen separaten Speicher-, Deploy- oder Push-Schritt gibt. Eine Dateiänderung über sandbox run, etwa rm oder mv, committet stattdessen einige Sekunden später, sobald ein kurzes Debounce-Fenster schließt. Wenn du erneut schreibst oder bearbeitest, bevor ein früherer debounced Commit angekommen ist, wartet der neue Aufruf darauf und schlägt mit COMMIT_FLUSH_PENDING fehl, wenn er nicht rechtzeitig bestätigen kann, dass der Commit abgeschlossen ist. Sobald ein Commit ankommt:
  • Die Änderung ist im Base44-App-Editor sichtbar.
  • Sie ist sicher, selbst wenn die Rechenumgebung der Sandbox nach Inaktivität recycelt wird, da eine neue immer von deinem neuesten Commit startet, nicht von einem älteren Snapshot.
  • Sie ist beim nächsten Publish deiner App enthalten.
Strukturierte Ressourcen synchronisieren sich auf dieselbe Weise: Anders als bei einem lokalen Projekt, wo du nach dem Hinzufügen einer Datei entities push oder functions deploy ausführen würdest, reicht es aus, base44/functions/send-email/entry.ts in der Sandbox zu erstellen, um diese Funktion hinzuzufügen.
  • 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 mit Base44, und es gibt kein lokales Projekt, wenn du mit einer Sandbox arbeitest.
  • Wenn deine letzte Aktion ein über sandbox run ausgeführter Shell-Befehl war und kein write- oder edit-Aufruf, ist ihr Commit noch einen Moment zurück. Gib ihm ein paar Sekunden, bevor du dich trennst.

​
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 Anlegen des Checkpoints committet, sodass er immer deinen neuesten Code erfasst.

​
Neben dem App-Editor arbeiten

Dein Coding-Agent und der Base44-App-Editor können gleichzeitig an derselben App arbeiten. Es gibt keine Sperre, die erworben werden muss, und keine Sitzung, die freigegeben werden muss. Änderungen von beiden Seiten landen am selben Ort. Behandle es also so, wie du eine Kollegin behandeln würdest, die dasselbe Projekt bearbeitet.
Es gibt keinen Merge-Schritt. Wenn dein Coding-Agent und der App-Editor gleichzeitig dieselbe Datei ändern, gewinnt derjenige Schreibvorgang, der zuletzt ankommt, und die frühere Änderung ist verloren. Vermeide es, dass beide Seiten dieselbe Datei im selben Arbeitsabschnitt anfassen.

​
Berechtigungen

Zwei separate Prüfungen kontrollieren den Zugriff auf die Sandbox: ob du überhaupt auf diese App zugreifen kannst und ob deiner aktuellen Sitzung Schreibzugriff darauf gewährt wurde.

​
App-Zugriff

Du brauchst Admin-Zugriff auf die App selbst, entweder als Workspace-Admin oder als Mitarbeiter an dieser konkreten 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 auch eine ältere pro-App-Editor-Rolle aus der Zeit vor der rollenbasierten Zugriffssteuerung deines Workspace hält. Diese Kombination kann weiterhin aus der Sandbox lesen, aber nichts ändern. Superagenten unterstützen die Sandbox-Befehle nicht.

​
Sitzungsumfang

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

​
Grenzen und Leitplanken

Dateibefehle sind auf das App-Root beschränkt. Absolute Pfade und Pfade, die über das Root hinausklettern, werden mit PATH_OUTSIDE_SANDBOX abgelehnt. Die Verzeichnisse .agents und .git sind von den Dateibefehlen aus nicht erreichbar und schlagen mit PROTECTED_PATH fehl, weil sie die Secrets und Repository-Zugangsdaten deiner App enthalten. Die einzige Ausnahme ist .agents/skills, das du lesen und schreiben kannst, damit dein Agent mit den Skills arbeiten kann, die die App installiert hat. Über das gesamte Feature bist du auf 120 Lese-Anfragen, 60 Änderungs-Anfragen und 30 Run-Befehle pro Minute und App begrenzt. Ein Überschreiten einer dieser Grenzen schlägt mit RATE_LIMITED fehl. Die eigene Referenzseite jedes Befehls behandelt seine Größen- und Anzahlgrenzen, 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.