Modificare tramite la sandbox non è lo stesso che pubblicare. La tua modifica diventa parte del codice dell’app subito e appare nell’editor dell’app e nella sua anteprima live, ma per raggiungere il sito pubblico dell’app serve comunque lo stesso passaggio di pubblicazione che servirebbe per una modifica fatta nell’editor.
Due modi per connettersi
La sandbox espone lo stesso insieme di operazioni tramite due superfici, supportate dalla stessa implementazione. Usa quella che si adatta alla tua configurazione.- CLI: adatto a qualsiasi cosa in esecuzione sulla tua macchina, incluso un agente di codifica locale e i tuoi script. Autenticati una volta con
base44 login, poi indirizza l’app con--app-ido la variabile d’ambienteBASE44_APP_ID. Non è richiesto un progetto locale. - Server MCP: adatto a un assistente AI che si connette tramite MCP, inclusi gli assistenti basati sul web che non possono eseguire una CLI. Connettilo una volta e autorizza con OAuth.
I connettori non passano attraverso il file system della sandbox, quindi non sono nella tabella sopra. Per configurare un connettore su un’app con cui stai lavorando in questo modo, usa invece
connectors initiate. Indirizza lo stesso app id direttamente, senza sandbox o progetto locale.
Le modifiche vengono salvate automaticamente
Una chiamatasandbox write o sandbox edit fa il commit della modifica come parte della stessa richiesta, prima che il comando termini, quindi non c’è un passaggio separato di salvataggio, deploy o push. Una modifica al file fatta tramite sandbox run, come rm o mv, viene invece committata qualche secondo dopo, una volta che si chiude una breve finestra di debounce. Se scrivi o modifichi di nuovo prima che un commit precedente sotto debounce sia atterrato, la nuova chiamata attende su di esso e fallisce con COMMIT_FLUSH_PENDING se non può confermare che quel commit sia terminato in tempo. Una volta che un commit atterra:
- La modifica è visibile nell’editor dell’app Base44.
- È al sicuro anche se l’ambiente di calcolo della sandbox viene riciclato dopo essere rimasto inattivo, poiché uno nuovo parte sempre dal tuo commit più recente piuttosto che da uno snapshot più vecchio.
- È inclusa la prossima volta che pubblichi l’app.
entities push o functions deploy dopo aver aggiunto un file, creare base44/functions/send-email/entry.ts nella sandbox è tutto ciò che serve per aggiungere quella funzione.
Checkpoint
Un checkpoint è un punto di ripristino nella cronologia delle versioni dell’app, ancorato a un commit specifico. Creane uno consandbox checkpoint per contrassegnare uno stato noto come funzionante, poi ripristinalo dall’editor dell’app se una modifica successiva va storta. Le modifiche in sospeso vengono committate prima che il checkpoint venga preso, così cattura sempre il tuo codice più recente.
Lavorare a fianco dell’editor dell’app
Il tuo agente di codifica e l’editor dell’app Base44 possono lavorare sulla stessa app allo stesso tempo. Non c’è alcun lock da acquisire e nessuna sessione da rilasciare. Le modifiche da entrambi i lati atterrano nello stesso posto, quindi trattalo come tratteresti un collega che modifica lo stesso progetto.Permessi
Due controlli separati regolano l’accesso alla sandbox: se puoi accedere a questa app in generale, e se la tua sessione corrente ha ottenuto l’accesso in scrittura ad essa.Accesso all’app
Hai bisogno dell’accesso admin all’app stessa, come admin del workspace o come collaboratore su questa specifica app. L’accesso viene controllato a ogni chiamata, quindi una modifica al tuo ruolo nel workspace ha effetto immediato. Un semplice viewer del workspace non può raggiungere la sandbox. L’unica eccezione è un viewer che possiede anche un ruolo legacy di editor per app da prima che il tuo workspace passasse all’accesso basato sui ruoli. Quella combinazione può ancora leggere dalla sandbox, ma non modificare nulla. I superagent non supportano i comandi sandbox.Ambito della sessione
Oltre all’accesso all’app, leggere e modificare la sandbox richiede permessi diversi sulla tua sessione:
I permessi della tua sessione sono fissati quando viene creata e non possono essere ampliati in seguito. La CLI chiede
sandbox:write durante base44 login, e tramite MCP lo concedi nel passaggio di consenso OAuth. Rinnovare una sessione esistente non lo aggiunge.
Quindi se i comandi di lettura funzionano ma quelli di modifica falliscono con NOT_AUTHORIZED, sei su una sessione che non ha mai avuto sandbox:write. Esegui di nuovo base44 login, o riconnetti il server MCP e approva l’accesso alla sandbox, per avviare una sessione che ce l’ha.
Limiti e protezioni
I comandi sui file sono confinati alla radice dell’app. I percorsi assoluti e i percorsi che salgono sopra la radice sono rifiutati conPATH_OUTSIDE_SANDBOX. Le directory .agents e .git non sono raggiungibili dai comandi sui file, e falliscono con PROTECTED_PATH, perché contengono i secret della tua app e le credenziali del repository. L’unica eccezione è .agents/skills, che puoi leggere e scrivere in modo che il tuo agente possa lavorare con le skill che l’app ha installato.
In tutta la funzionalità, sei limitato a 120 richieste di lettura, 60 richieste di modifica e 30 comandi run al minuto, per app. Superare uno qualsiasi di questi fallisce con RATE_LIMITED. La pagina di riferimento di ogni comando copre i suoi limiti di dimensione e conteggio, come quanti percorsi accetta sandbox read o quanto grande può essere un file sandbox write.
Vedi anche
- Server MCP di Base44: connetti un assistente AI al tuo account Base44
- Panoramica CLI: installa e usa la CLI Base44
- Struttura del progetto: come sono organizzati i file di un progetto Base44
- Sviluppo locale: esegui un progetto Base44 sulla tua macchina
- Skill: insegna agli agenti di codifica AI come lavorare con Base44
connectors initiate: configura un connettore su un’app senza sandbox o progetto locale
Questa pagina è stata tradotta con l’AI. Per le informazioni più accurate e aggiornate, consulta la versione inglese.