Skip to main content
Cada app de Base44 tiene un sandbox: un entorno privado en la nube que contiene el código de la app y ejecuta su servidor de desarrollo. Es el mismo entorno, y el mismo código, que usa el editor de la app, sin fork ni copia que mantener sincronizada. Conéctate vía la CLI, un cliente MCP o la API para leer, buscar, editar y ejecutar comandos contra tu app desde cualquier máquina, sin checkout local y sin nada que instalar. Cuando escribes un archivo a través del sandbox, estás cambiando tu app real directamente, de la misma forma que lo haría el editor de la app. La razón más común para hacer esto es traer tu propio agente de codificación a una app que construiste en el editor de la app.
Necesitas un plan Builder o superior para acceder al sandbox de una app desde fuera del editor de la app. Sin él, los comandos fallan con PREMIUM_REQUIRED.

​
Cuándo usar el sandbox

Puedes trabajar en el código de una app que construiste en el editor de la app de las siguientes formas: El sandbox y la integración con GitHub son los que más se solapan, ya que ambos te permiten trabajar con tus propias herramientas. La diferencia es dónde vive el código mientras trabajas. Con la integración con GitHub, desarrollas en un clon local y tus cambios llegan a Base44 cuando se fusionan a main. Con el sandbox, trabajas en el código de la app en el sitio. No hay nada que descargar, un asistente basado en web puede usarlo, y cada cambio aparece en la vista previa en vivo del editor de la app tan pronto como se realiza.

​
Formas de conectarse

Puedes acceder al sandbox de las siguientes formas: Los connectors no pasan por el sistema de archivos del sandbox, así que no están en la tabla anterior. Para configurar un connector en una app con la que estás trabajando de esta forma, usa connectors initiate en su lugar. Apunta directamente al mismo app id, sin un sandbox o un proyecto local.

​
Ramas

Los comandos del sandbox apuntan a la rama main de la app a menos que digas lo contrario. Para trabajar en otra rama, ejecuta branches list para encontrar su nombre exacto, luego pasa --branch <name> en cada comando del sandbox. Las lecturas y ediciones se aplican entonces solo a esa rama.

​
Los cambios se guardan automáticamente

Una llamada a sandbox write o sandbox edit confirma el cambio por ti como parte de la misma solicitud, antes de que el comando devuelva, así que no hay un paso separado de guardar, desplegar o hacer push. Un cambio de archivo hecho a través de sandbox run, como rm o mv, se confirma unos segundos después en su lugar, una vez que se cierra una corta ventana de debounce. Si escribes o editas de nuevo antes de que se haya realizado un commit debounced anterior, la nueva llamada espera por él y falla con COMMIT_FLUSH_PENDING si no puede confirmar que ese commit terminó a tiempo. Los recursos estructurados se sincronizan de la misma forma. En un proyecto local, ejecutarías entities push o functions deploy después de añadir un archivo. En el sandbox, crear base44/functions/send-email/entry.ts es todo lo que se necesita para añadir esa función.
Dos reglas al editar en un sandbox:
  • No ejecutes deploy, functions deploy, entities push u otros comandos push contra una app que estás editando en su sandbox. Esos comandos sincronizan un proyecto local con Base44, y no hay proyecto local cuando trabajas con un sandbox.
  • Si tu última acción fue un comando de shell ejecutado a través de sandbox run en lugar de una llamada write o edit, su commit sigue estando un momento atrás. Dale unos segundos antes de desconectarte.

​
Edición y publicación

Editar a través del sandbox no es lo mismo que publicar. Tu edición pasa a formar parte del código de la app de inmediato y aparece en el editor de la app y en su vista previa en vivo. Llegar al sitio público de la app aún requiere el mismo paso de publicación que un cambio hecho en el editor de la app.

​
Checkpoints

Un checkpoint es un punto de restauración en el historial de versiones de la app, anclado a un commit específico. Crea uno con sandbox checkpoint para marcar un estado conocido como bueno, luego restáuralo desde el editor de la app si un cambio posterior sale mal. Los cambios pendientes se confirman antes de que se tome el checkpoint, así que siempre captura tu código más reciente.

​
Trabajar junto al editor de la app

Tu agente de codificación y el editor de la app de Base44 pueden trabajar en la misma app al mismo tiempo. No hay un lock que adquirir ni una sesión que liberar. Los cambios de cualquier lado aterrizan en el mismo lugar, así que trátalo como tratarías a un colega editando el mismo proyecto.
No hay paso de merge. Si tu agente de codificación y el editor de la app cambian el mismo archivo al mismo tiempo, gana la escritura que aterrice más tarde, y el cambio anterior se pierde. Evita que ambos lados toquen el mismo archivo en el mismo tramo de trabajo.

​
Iniciar y detener

El sandbox es un proceso en ejecución, no solo almacenamiento. Se apaga cuando permanece inactivo durante un rato y se vuelve a encender con el siguiente comando. Tu código no se ve afectado de cualquier manera. Los cambios confirmados viven en git, y un sandbox reiniciado siempre parte de tu último commit. Si el sandbox no está en ejecución, el primer comando lo inicia, lo que significa que esa llamada probablemente tarde más que las siguientes.

​
Permisos

Dos comprobaciones separadas controlan el acceso al sandbox. Una es si puedes acceder a la app en absoluto, y la otra es si a tu sesión actual se le concedió acceso de escritura a ella.

​
Acceso a la app

Necesitas acceso de admin a la app en sí, ya sea como admin de workspace o como colaborador en esta app específica. El acceso se comprueba en cada llamada, así que un cambio en tu rol de workspace tiene efecto inmediato. Un simple visor de workspace no puede acceder al sandbox en absoluto. La única excepción es un visor que también tiene un rol de editor por app heredado de antes de que tu workspace se moviera al acceso basado en roles. Esa combinación aún puede leer desde el sandbox, pero no cambiar nada. Los Superagents no admiten los comandos del sandbox.

​
Alcance de la sesión

Más allá del acceso a la app, leer y cambiar el sandbox requieren permisos diferentes en tu sesión: Los permisos de tu sesión son fijos cuando se crea y no se pueden ampliar más tarde. La CLI pide sandbox:write durante base44 login, y por MCP lo concedes en el paso de consentimiento OAuth. Renovar una sesión existente no lo añade. Así que si los comandos de lectura funcionan pero los de cambio fallan con NOT_AUTHORIZED, estás en una sesión que nunca tuvo sandbox:write. Ejecuta base44 login de nuevo, o vuelve a conectar el servidor MCP y aprueba el acceso al sandbox, para iniciar una sesión que lo tenga.

​
Límites y salvaguardas

Los comandos de archivos están confinados a la raíz de la app. Las rutas absolutas y las rutas que suben por encima de la raíz se rechazan con PATH_OUTSIDE_SANDBOX. Los directorios .agents y .git no son accesibles desde los comandos de archivos y fallan con PROTECTED_PATH, porque contienen los secretos de tu app y las credenciales del repositorio. La única excepción es .agents/skills, que puedes leer y escribir. En toda la función, tienes un tope de 120 solicitudes de lectura, 60 solicitudes de cambio y 30 comandos de ejecución por minuto, por app. Superar cualquiera de estos falla con RATE_LIMITED. La página de referencia de cada comando cubre sus propios límites de tamaño y cantidad, como cuántas rutas acepta sandbox read o cuán grande puede ser un archivo que sandbox write permite.

​
Ver también

Esta página fue traducida con IA. Para obtener la información más precisa y actualizada, consulta la versión en inglés.