Skip to main content
Chaque app Base44 a un sandbox : un environnement cloud privé qui contient le code de l’app et exécute son serveur de développement. C’est le même environnement, et le même code, que celui utilisé par l’éditeur d’app, sans fork ni copie à synchroniser. Connectez-vous via le CLI, un client MCP ou l’API pour lire, rechercher, modifier et exécuter des commandes sur votre app depuis n’importe quelle machine, sans checkout local et sans rien à installer. Quand vous écrivez un fichier via le sandbox, vous modifiez directement votre vraie app, comme le ferait l’éditeur d’app. La raison la plus courante de faire cela est d’apporter votre propre agent de codage à une app que vous avez construite dans l’éditeur d’app.
Vous avez besoin d’un plan Builder ou supérieur pour atteindre le sandbox d’une app depuis l’extérieur de l’éditeur d’app. Sans plan, les commandes échouent avec PREMIUM_REQUIRED.

​
Quand utiliser le sandbox

Vous pouvez travailler sur le code d’une app que vous avez construite dans l’éditeur d’app de plusieurs façons : Le sandbox et l’intégration GitHub se chevauchent le plus, puisque tous deux vous permettent de travailler avec vos propres outils. La différence est l’endroit où vit le code pendant que vous travaillez. Avec l’intégration GitHub, vous développez dans un clone local, et vos modifications atteignent Base44 quand elles sont fusionnées dans main. Avec le sandbox, vous travaillez sur le code de l’app sur place. Il n’y a rien à télécharger, un assistant basé sur le web peut l’utiliser, et chaque modification apparaît dans l’aperçu en direct de l’éditeur d’app dès qu’elle est faite.

​
Façons de se connecter

Vous pouvez atteindre le sandbox des façons suivantes :
  • CLI : Pour un agent de codage ou des scripts qui s’exécutent sur votre propre machine. Aucun projet local n’est requis. Pour la configuration, voir Connecter un agent local avec le CLI.
  • Serveur MCP : Pour un assistant IA qui se connecte via MCP, y compris les assistants basés sur le web qui ne peuvent pas exécuter de CLI. Pour la configuration, voir Connecter un agent via MCP.
  • App Management API : Pour vos propres intégrations, avec les endpoints listés ci-dessous.
Les connectors ne passent pas par le système de fichiers du sandbox, ils ne sont donc pas dans le tableau ci-dessus. Pour configurer un connector sur une app avec laquelle vous travaillez de cette façon, utilisez plutôt connectors initiate. Il cible directement le même app id, sans sandbox ni projet local.

​
Branches

Les commandes sandbox ciblent la branche main de l’app sauf indication contraire. Pour travailler sur une autre branche, exécutez branches list pour trouver son nom exact, puis passez --branch <name> sur chaque commande sandbox. Les lectures et modifications ne s’appliquent alors qu’à cette branche.

​
Les modifications sont enregistrées automatiquement

Un appel sandbox write ou sandbox edit commit la modification pour vous dans le cadre de la même requête, avant que la commande ne rende la main, il n’y a donc pas d’étape séparée d’enregistrement, de déploiement ou de push. Une modification de fichier effectuée via sandbox run, telle que rm ou mv, commit à la place quelques secondes plus tard, une fois qu’une courte fenêtre de debounce se ferme. Si vous écrivez ou modifiez à nouveau avant qu’un commit debounced antérieur ne soit arrivé, le nouvel appel attend ce commit et échoue avec COMMIT_FLUSH_PENDING s’il ne peut pas confirmer que ce commit s’est terminé à temps. Les ressources structurées se synchronisent de la même manière. Dans un projet local, vous exécuteriez entities push ou functions deploy après avoir ajouté un fichier. Dans le sandbox, créer base44/functions/send-email/entry.ts suffit à ajouter cette fonction.
Deux règles lors d’une modification dans un sandbox :
  • N’exécutez pas deploy, functions deploy, entities push, ou les autres commandes push sur une app que vous modifiez dans son sandbox. Ces commandes synchronisent un projet local vers Base44, et il n’y a pas de projet local quand vous travaillez avec un sandbox.
  • Si votre dernière action était une commande shell exécutée via sandbox run plutôt qu’un appel write ou edit, son commit a encore un instant de retard. Laissez-lui quelques secondes avant de vous déconnecter.

​
Modifier et publier

Modifier via le sandbox n’est pas la même chose que publier. Votre modification devient partie du code de l’app immédiatement et apparaît dans l’éditeur d’app et son aperçu en direct. Atteindre le site public de l’app nécessite toujours la même étape de publication qu’une modification faite dans l’éditeur d’app.

​
Checkpoints

Un checkpoint est un point de restauration dans l’historique de version de l’app, ancré à un commit spécifique. Créez-en un avec sandbox checkpoint pour marquer un état connu comme bon, puis restaurez-le depuis l’éditeur d’app si une modification ultérieure tourne mal. Les modifications en attente sont commitées avant que le checkpoint ne soit pris, il capture donc toujours votre dernier code.

​
Travailler en parallèle avec l’éditeur d’app

Votre agent de codage et l’éditeur d’app Base44 peuvent travailler sur la même app en même temps. Il n’y a pas de verrou à acquérir ni de session à libérer. Les modifications de chaque côté atterrissent au même endroit, traitez cela comme vous traiteriez un collègue qui modifie le même projet.
Il n’y a pas d’étape de fusion. Si votre agent de codage et l’éditeur d’app modifient le même fichier en même temps, la dernière écriture qui atterrit gagne, et la modification antérieure est perdue. Évitez que les deux côtés touchent au même fichier durant la même période de travail.

​
Démarrage et arrêt

Le sandbox est un processus en cours d’exécution, pas seulement du stockage. Il s’arrête quand il reste inactif un moment et redémarre à la commande suivante. Votre code n’est pas affecté dans les deux cas. Les modifications commitées vivent dans git, et un sandbox redémarré part toujours de votre dernier commit. Si le sandbox n’est pas en cours d’exécution, la première commande le démarre, ce qui signifie que cet appel prend probablement plus de temps que ceux qui suivent.

​
Autorisations

Deux vérifications distinctes contrôlent l’accès au sandbox. L’une est de savoir si vous pouvez du tout accéder à l’app, et l’autre est de savoir si votre session actuelle a reçu un accès en écriture à cette app.

​
Accès à l’app

Vous avez besoin d’un accès admin à l’app elle-même, soit en tant qu’administrateur du workspace, soit en tant que collaborateur sur cette app spécifique. L’accès est vérifié à chaque appel, un changement de votre rôle de workspace prend donc effet immédiatement. Un simple viewer du workspace ne peut pas du tout atteindre le sandbox. La seule exception est un viewer qui détient également un rôle éditeur par app hérité, datant d’avant le passage de votre workspace à l’accès basé sur les rôles. Cette combinaison peut encore lire depuis le sandbox, mais rien modifier. Les Superagents ne prennent pas en charge les commandes sandbox.

​
Portée de session

Au-delà de l’accès à l’app, lire et modifier le sandbox nécessitent des autorisations différentes sur votre session : Les autorisations de votre session sont fixées à sa création et ne peuvent pas être élargies ensuite. Le CLI demande sandbox:write lors de base44 login, et via MCP vous l’accordez à l’étape de consentement OAuth. Renouveler une session existante ne l’ajoute pas. Donc si les commandes de lecture fonctionnent mais que celles de modification échouent avec NOT_AUTHORIZED, vous êtes sur une session qui n’a jamais eu sandbox:write. Exécutez à nouveau base44 login, ou reconnectez le serveur MCP et approuvez l’accès sandbox, pour démarrer une session qui l’a.

​
Limites et garde-fous

Les commandes de fichiers sont confinées à la racine de l’app. Les chemins absolus et les chemins qui remontent au-dessus de la racine sont rejetés avec PATH_OUTSIDE_SANDBOX. Les répertoires .agents et .git ne sont pas accessibles depuis les commandes de fichiers, et échouent avec PROTECTED_PATH, car ils contiennent les secrets et les identifiants de dépôt de votre app. La seule exception est .agents/skills, que vous pouvez lire et écrire. À travers toute la fonctionnalité, vous êtes plafonné à 120 requêtes de lecture, 60 requêtes de modification et 30 commandes run par minute, par app. Dépasser l’une d’elles échoue avec RATE_LIMITED. La page de référence de chaque commande couvre ses propres limites de taille et de nombre, comme le nombre de chemins que sandbox read accepte ou la taille d’un fichier que sandbox write autorise.

​
Voir aussi

Cette page a été traduite à l’aide de l’IA. Pour les informations les plus précises et à jour, consultez la version anglaise.