​

Développer une application Base44 à distance via MCP

Démarrage le plus simple : dans l’éditeur d’application Base44, cliquez sur Send to Coding Agent. Pour un agent local, cela vous donne un prompt prêt à coller (qui récupère un README et pilote le sandbox via MCP ou le CLI base44 sandbox — Section 10) ; pour le web, cela donne un prompt à coller dans un chat claude.ai (avec le connecteur MCP Base44) plus un bouton Open Claude. Le bouton est la surface de découverte — le reste de cette compétence est la référence.

Deux transports : les agents web utilisent claude.ai avec le connecteur MCP Base44 (sections 1-9) — notez qu’il s’agit du chat claude.ai régulier, pas de Claude Code sur le web (claude.ai/code), qui s’exécute dans son propre sandbox basé sur un repo. Un agent local peut se connecter à ce même serveur MCP, ou piloter le sandbox avec le CLI base44 sandbox (un token CLI Base44, Section 10) — mêmes outils, même comportement, mêmes codes d’erreur ; le CLI les expose simplement sous des noms de commande plus courts (sandbox read, sandbox ls, …).

​

1. Se connecter au serveur MCP

https://app.base44.com/mcp

claude mcp add --transport http base44 https://app.base44.com/mcp

​

2. S’authentifier

claude

/mcp

​

Scopes

​

3. Choisir l’application et s’orienter

Using the base44 tools on appId <APP_ID>:
1. list_directory on the app root (recursive, depth 2)
2. read_file src/App.jsx and src/pages.config.js
3. grep for the component I want to change
Summarize the structure before editing.

Démarrage à froid : si l’application n’a pas de sandbox en cours d’exécution, le premier appel d’outil en fait apparaître un de manière transparente depuis votre dernier commit — cela prend juste un peu plus longtemps. Les appels suivants sont rapides.

Noms CLI : via le CLI base44 sandbox (Section 10), ces outils de lecture sont list_directory → sandbox ls, read_file → sandbox read, et grep → sandbox grep.

​

4. Effectuer des changements

• edit_file (sandbox edit dans le CLI) — préféré pour modifier des fichiers existants. Fournissez des éditions exactes old_text→new_text. Chaque old_text doit être unique dans le fichier sauf si vous définissez replace_all. Toutes les éditions d’un appel s’appliquent atomiquement (tout ou rien) et vous récupérez un diff unifié. Passez dry_run: true pour prévisualiser le diff sans écrire.
• write_file (sandbox write dans le CLI) — pour créer de nouveaux fichiers. Pour écraser un fichier existant, vous devez passer overwrite: true (il n’écrase jamais silencieusement).
• run_command (sandbox run dans le CLI) — exécute n’importe quelle commande bash dans le sandbox (build, install, scaffolding, codemods). Le répertoire de travail par défaut est la racine de l’application ; cd ne persiste pas entre les appels, utilisez donc le paramètre cwd ou chaînez les commandes (cd sub && cmd). Le timeout par défaut est 120s (max 600s) ; la sortie est plafonnée à ~1 Mo.
• create_checkpoint (sandbox checkpoint dans le CLI) — enregistre un point de restauration nommé vers lequel l’utilisateur peut revenir plus tard. Prend un name facultatif (message/titre ; auto-généré si omis). Les changements en attente sont flushés et commités d’abord pour que le point de contrôle s’ancre sur votre dernier code ; il retourne ensuite l’id du point de contrôle, son nom et son hash de commit git. Utilisez-le pour marquer un état connu-bon avant ou après un bloc d’éditions. (Si un auto-commit récent ne peut pas encore être confirmé durable, il refuse avec le COMMIT_FLUSH_PENDING retryable plutôt que de marquer un état obsolète — réessayez rapidement.)

On appId <APP_ID>, use edit_file to change the homepage heading in
src/pages/Home.jsx from "Welcome" to "Welcome back". Show me the diff first
with dry_run, then apply it.

​

5. Prévisualiser et vérifier (la boucle edit → check)

• Voir en direct : get_app_preview_url fait apparaître le serveur de dev et retourne l’URL d’aperçu. Vite HMR reflète vos éditions à mesure que vous les faites.
• Statut du build : get_app_status retourne ready / processing / error.
• Faire apparaître les erreurs de build/type/lint à la demande avec run_command :
  npm run build       # bundler/compile errors
  npx tsc --noEmit    # type errors
  npm run lint        # lint errors
  
• Lire les logs du dev-server (Vite) — le serveur de dev géré écrit dans /tmp/vite.log. Faites-en un tail via run_command pour voir les erreurs HMR/compilation :
  tail -c 32000 /tmp/vite.log
  
  (C’est en dehors de l’arbre de l’application, donc uniquement accessible via run_command, pas les outils de fichiers — et nécessite donc sandbox:write.)

Les erreurs runtime navigateur (un composant qui compile mais lève à l’affichage, un appel API client qui échoue) apparaissent dans la console du navigateur, pas dans /tmp/vite.log. Ouvrez l’URL d’aperçu pour les attraper.

​

6. Comment vos changements persistent

• survit à la mort du sandbox (le sandbox est recréé depuis le dernier commit),
• apparaît dans les onglets Library/Data du builder,
• garde les déploiements de fonctions backend cohérents, et
• est inclus lors de la publication de l’application.

• Il y a une petite fenêtre de perte (~5s) — ne tuez pas la session immédiatement après la dernière édition ; laissez-lui un moment pour committer.
• Les éditions sur les entités, agents, workflows, fonctions backend et routage de pages sont synchronisées dans Base44 automatiquement après le commit. Les éditions ordinaires de pages/composants/CSS vivent dans git et n’ont besoin de rien de plus.

​

7. Concurrence : vous vs. le builder Base44

• Pendant que vous utilisez activement les outils du sandbox, le chat du builder Base44 est bloqué (« An external agent is currently working on this app »). Votre session est implicite — les appels d’outil récents sont la session ; elle se termine après une brève période d’inactivité (~10 min).
• Si le builder Base44 est en cours de build, vos outils mutants retournent BUILDER_BUSY. Interrogez get_app_status et réessayez une fois qu’il est ready. Les outils en lecture seule fonctionnent toujours pendant un build.

​

8. Garde-fous et limites

• Les chemins sont confinés à l’application. Les outils de fichiers n’opèrent que dans le répertoire de l’application ; les traversées/chemins absolus sont rejetés (PATH_OUTSIDE_SANDBOX).
• .agents/ est interdit aux outils de fichiers (PROTECTED_PATH) — il contient la config et les secrets gérés par l’agent (.agents/.env). N’essayez pas de le lire ou de le modifier via les outils de fichiers.
• Des limites de taux s’appliquent par application : lectures ~120/min, mutations ~60/min, commandes ~30/min. Si vous atteignez RATE_LIMITED, ralentissez.
• delete_file n’est pas un outil dédié — supprimez via run_command rm.

​

Codes d’erreur que vous pouvez voir

​

9. Conseils et astuces

• Lisez avant d’écrire. Un passage rapide de list_directory + read_file (ou grep) coûte peu et améliore drastiquement la précision des éditions.
• Utilisez dry_run sur edit_file pour confirmer le diff avant de vous engager sur un changement, surtout pour les appels multi-éditions.
• Préférez edit_file à write_file pour les fichiers existants — les éditions chirurgicales évitent l’écrasement et produisent un diff revisable.
• Lisez des plages de lignes avec offset/limit de read_file sur les gros fichiers plutôt que de tout tirer dans le contexte.
• Quand quelque chose « semble cassé », tailer /tmp/vite.log avant de deviner — il nomme généralement le fichier et la ligne exacts.
• Laissez-le committer. Pausez quelques secondes après votre édition finale pour que l’auto-commit atterrisse avant de vous déconnecter ou de publier.
• Points de contrôle sur les états connus-bons. Utilisez create_checkpoint (sandbox checkpoint) pour marquer un point de restauration avant ou après un bloc d’éditions risquées — il flushe d’abord les changements en attente, l’utilisateur peut donc toujours revenir à ce point.
• Un agent à la fois. La fonctionnalité est conçue pour un seul agent externe par application ; ne lancez pas de sessions parallèles contre la même application.

​

10. Agents locaux via le CLI base44 sandbox

npx base44 sandbox read --app-id <APP_ID> src/App.jsx

npx base44 sandbox checkpoint --app-id <APP_ID> --name "before refactor"

https://app.base44.com/api/sandbox/<APP_ID>/local-agent/readme.md

​

11. Connecteurs (intégrations OAuth)

• Scopes déclaratifs (remplacer, pas fusionner). initiate_connector_connection définit le connecteur sur exactement les scopes que vous passez. Les scopes omis sont retirés et l’utilisateur est réinvité à consentir. Appelez toujours list_connectors d’abord, puis passez l’ensemble complet souhaité (les scopes existants à conserver plus les nouveaux).
• OAuth nécessite un humain. L’outil retourne soit already_authorized: true (rien à faire), soit une redirect_url que l’utilisateur doit ouvrir dans un navigateur pour se connecter et consentir — vous ne pouvez pas le faire vous-même. Après qu’il ait terminé, appelez à nouveau list_connectors pour vérifier et lire les scopes accordés (un fournisseur peut accorder moins que ce qui a été demandé).