Skip to main content
Utilisez votre propre agent IA de codage, ou vos propres scripts, avec une app Base44 en vous connectant à son sandbox. Le sandbox est un environnement cloud privé qui contient le code de la branche actuellement active dans l’éditeur d’app, et exécute son serveur de développement. C’est le même environnement, et le même code, que l’éditeur d’app Base44 lui-même modifie, sans fork ni copie à synchroniser. Quand vous écrivez un fichier via une commande sandbox, vous modifiez directement votre vraie app, sur sa branche active, comme le ferait l’éditeur d’app. Ça vous permet de développer une app avec vos propres outils au lieu de l’éditeur d’app, sans checkout local et sans rien à installer. Travaillez sur une app depuis une machine qui n’en a pas de copie, ou scriptez un changement sur une app entièrement construite dans l’éditeur d’app.
Éditer via le sandbox n’est pas la même chose que publier. Votre édition devient partie du code de l’app immédiatement et apparaît dans l’éditeur d’app et son aperçu en direct, mais atteindre le site public de l’app nécessite toujours la même étape de publication qu’un changement fait 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 un plan, les commandes échouent avec PREMIUM_REQUIRED.
Le sandbox lui-même est un processus de calcul actif, pas juste 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, car il vit dans git plutôt que dans ce processus. Si le sandbox n’est pas en cours d’exécution, la première commande le démarre, et cet appel prend plus de temps que ceux qui suivent.

​
Deux façons de se connecter

Le sandbox expose le même ensemble d’opérations via deux surfaces, soutenues par la même implémentation. Utilisez celle qui convient à votre configuration.
  • CLI : Convient à tout ce qui s’exécute sur votre propre machine, y compris un agent de codage local et vos propres scripts. Authentifiez-vous une fois avec base44 login, puis ciblez l’app avec --app-id ou la variable d’environnement BASE44_APP_ID. Aucun projet local n’est requis.
  • Serveur MCP : Convient à 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. Connectez-le une fois et autorisez avec OAuth.
Les connecteurs ne passent pas par le système de fichiers du sandbox, donc ils ne sont pas dans le tableau ci-dessus. Pour configurer un connecteur sur une app avec laquelle vous travaillez de cette façon, utilisez plutôt connectors initiate. Ça cible le même app id directement, sans sandbox ni projet local.
La façon la plus rapide de démarrer avec votre propre agent de codage est d’utiliser Send to Coding Agent dans l’éditeur d’app Base44. Sur desktop, ouvrez More actions (les trois points à côté de Publish, en haut à droite) et sélectionnez Send to Coding Agent. Choisissez un agent CLI local ou un chat web, et il vous donne un prompt prêt à coller, donc vous n’avez rien à configurer à la main. Ça n’est pas proposé pour les apps mobiles ou les apps avec du code source non géré.

​
Les changements se sauvegardent automatiquement

Un appel sandbox write ou sandbox edit commit le changement pour vous dans la même requête, avant que la commande ne retourne, donc il n’y a pas d’étape séparée de sauvegarde, déploiement ou push. Un changement de fichier fait via sandbox run, comme rm ou mv, commit quelques secondes plus tard, une fois qu’une courte fenêtre de debounce se ferme. Si vous écrivez ou éditez à nouveau avant qu’un commit debounced précédent ne soit arrivé, le nouvel appel attend celui-ci et échoue avec COMMIT_FLUSH_PENDING s’il ne peut pas confirmer que ce commit s’est terminé à temps. Une fois qu’un commit arrive :
  • Le changement est visible dans l’éditeur d’app Base44.
  • Il est sûr même si l’environnement de calcul du sandbox est recyclé après être resté inactif, car un nouveau part toujours de votre dernier commit plutôt que d’un snapshot plus ancien.
  • Il est inclus la prochaine fois que vous publiez l’app.
Les ressources structurées se synchronisent de la même façon : contrairement à un projet local, où vous exécuteriez entities push ou functions deploy après avoir ajouté un fichier, créer base44/functions/send-email/entry.ts dans le sandbox suffit à ajouter cette fonction.
  • N’exécutez pas deploy, functions deploy, entities push ou les autres commandes push contre une app que vous éditez dans son sandbox. Ces commandes synchronisent un projet local vers Base44, et il n’y a pas de projet local en travaillant 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 est encore un instant en retard. Attendez quelques secondes avant de vous déconnecter.

​
Points de restauration

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

​
Travailler en parallèle de 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 et pas de session à libérer. Les changements des deux côtés arrivent au même endroit, donc traitez ça comme un collègue qui édite le même projet.
Il n’y a pas d’étape de fusion. Si votre agent de codage et l’éditeur d’app changent le même fichier en même temps, l’écriture qui arrive en dernier gagne, et le changement précédent est perdu. Évitez que les deux côtés touchent le même fichier dans la même session de travail.

​
Permissions

Deux vérifications séparées contrôlent l’accès au sandbox : si vous pouvez accéder à cette app du tout, et si votre session actuelle a reçu un accès en écriture.

​
Accès à l’app

Vous avez besoin d’un accès admin à l’app elle-même, soit comme admin de workspace, soit comme collaborateur sur cette app spécifique. L’accès est vérifié à chaque appel, donc un changement de votre rôle dans le workspace prend effet immédiatement. Un simple visualiseur de workspace ne peut pas atteindre le sandbox du tout. L’unique exception est un visualiseur qui a aussi un rôle éditeur par app hérité d’avant que votre workspace passe à l’accès basé sur les rôles. Cette combinaison peut toujours lire depuis le sandbox, mais rien changer. Les superagents ne prennent pas en charge les commandes sandbox.

​
Portée de la session

Au-delà de l’accès à l’app, lire et modifier le sandbox nécessitent des permissions différentes sur votre session : Les permissions de votre session sont fixées à sa création et ne peuvent pas être élargies plus tard. La 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 base44 login à nouveau, ou reconnectez le serveur MCP et approuvez l’accès au sandbox, pour démarrer une session qui l’a.

​
Limites et garde-fous

Les commandes de fichier 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 via les commandes de fichier, et échouent avec PROTECTED_PATH, car ils contiennent les secrets et les identifiants de dépôt de votre app. L’unique exception est .agents/skills, que vous pouvez lire et écrire pour que votre agent puisse travailler avec les skills installés sur l’app. Sur l’ensemble de 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 de ces limites échoue avec RATE_LIMITED. La page de référence de chaque commande couvre ses propres limites de taille et de nombre, comme combien de chemins sandbox read accepte ou quelle taille de fichier sandbox write permet.

​
Voir aussi

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