Ejecutar Codex o un agente de codificación en una caja de arena segura

Ejecuta un agente de codificación en una caja de arena proporcionándole un espacio de trabajo de repositorio delimitado, una ruta de ejecución de terminal controlada, permisos de archivo explícitos, políticas de red e instalación de paquetes, secretos aislados, registros de comandos, artefactos y una ruta de aprobación clara para cambios de alto riesgo antes de la fusión o el despliegue. Ese patrón funciona tanto si el agente es estilo Codex, conectado al IDE, activado por CI o integrado en tu propia plataforma de desarrollo: el modelo puede planificar y editar, pero la caja de arena decide qué puede tocar, qué puede ejecutar, qué puede obtener y qué evidencia recibe un revisor.

¿Qué es una caja de arena para agentes de codificación?

Una caja de arena para agentes de codificación es un entorno de ejecución aislado donde un sistema de IA puede inspeccionar código, editar archivos, ejecutar comandos de terminal, instalar dependencias cuando la política lo permita, ejecutar pruebas, iniciar servidores de vista previa y devolver un diff revisable sin recibir acceso amplio a la máquina del desarrollador ni al entorno de producción.

El cambio importante es que la caja de arena no es solo un envoltorio de chat alrededor de un modelo. Es el límite operativo para el trabajo. El modelo propone acciones; la caja de arena impone el espacio de trabajo, las herramientas, los permisos y la pista de evidencia.

Para un asistente de código simple, un checkout local y un copiar-pegar manual pueden ser suficientes. Para un agente que puede ejecutar comandos o continuar durante muchos pasos, necesitas límites más fuertes:

• Un espacio de trabajo dedicado para cada tarea o sesión.
• Un estado de repositorio y una rama conocidos.
• Una interfaz de ejecución de comandos con aprobaciones para operaciones riesgosas.
• Una política de instalación de paquetes para npm, pip, cargo, apt y herramientas similares.
• Reglas de salida de red para registros, documentación, API y acceso a vistas previas.
• Secretos delimitados a la tarea y ocultos de los registros cuando sea posible.
• Salida estándar, error estándar, códigos de salida, cambios de archivo, artefactos generados y URL de vista previa capturados.
• Una puerta de revisión antes de la fusión, el despliegue o la publicación externa.

Por eso, “ejecutar Codex en una caja de arena” debe entenderse como un patrón de infraestructura, no como una simple bandera de CLI o una integración de un solo proveedor. El propio Codex CLI está documentado como un agente de codificación que se ejecuta localmente en tu computadora, y la documentación de Codex de OpenAI describe un flujo de trabajo orientado a terminal. Si operas ese tipo de agente para un equipo, sistema de CI o flujo de trabajo de producto, el entorno de ejecución circundante se convierte en el plano de control.

Arquitectura de caja de arena para agentes de codificación

La arquitectura más limpia separa el bucle del modelo del límite de ejecución:

Capa	Responsabilidad	Preguntas a responder
Interfaz del agente	Convierte la intención del usuario en planes, ediciones de archivos, llamadas a herramientas y resúmenes de revisión	¿Qué modelo o agente de codificación se utiliza? ¿Cómo se gestionan los prompts, el contexto y los esquemas de herramientas?
Gestor del espacio de trabajo	Crea la caja de arena, descarga el repositorio, establece la rama y monta los archivos permitidos	¿Cada tarea está aislada? ¿Se conoce el commit base? ¿Se puede restablecer el espacio de trabajo?
Ejecutor de terminal	Ejecuta los comandos aprobados y transmite los resultados al agente	¿Qué comandos se permiten automáticamente, requieren aprobación o están bloqueados?
Capa de políticas	Controla el ámbito del sistema de archivos, los secretos, la salida de red, las instalaciones de paquetes, los límites de tiempo de ejecución y la limpieza	¿Puede el agente obtener paquetes? ¿Puede llamar a internet público? ¿Puede leer credenciales?
Capa de evidencia	Almacena registros, diffs, resultados de pruebas, vistas previas y artefactos	¿Puede un revisor reconstruir lo sucedido sin confiar en el resumen del modelo?
Puerta de revisión	Requiere un humano o una automatización confiable antes de fusionar, publicar o desplegar	¿Quién aprueba los cambios riesgosos? ¿Qué verificaciones deben pasar primero?

En la práctica, una sola plataforma puede combinar varias de estas capas. La arquitectura sigue siendo importante porque mantiene honestas las elecciones del producto. Si una herramienta le da a un agente una terminal pero no puede mostrar registros de comandos, diffs de archivos o políticas de salida, puede ser conveniente para prototipos pero insuficiente para una revisión en producción.

¿Cómo debería funcionar el acceso a la terminal en una caja de arena para agentes de codificación?

La terminal es donde un agente de codificación se vuelve operativamente útil y operativamente riesgoso. Puede ejecutar pruebas, compilar activos, inspeccionar archivos generados, iniciar servidores locales y diagnosticar fallos. También puede eliminar archivos, filtrar variables de entorno, ejecutar scripts de instalación inesperados o consumir grandes recursos de cómputo.

Un buen modelo de terminal tiene tres partes.

Primero, define clases de comandos. Los comandos seguros de solo lectura, como ls, sed, rg, git diff y comandos de estado de prueba, a menudo pueden ejecutarse automáticamente. Los comandos de compilación y prueba, como npm test, pytest, cargo test y npm run build, pueden permitirse con tiempos de espera. Los comandos destructivos o de impacto externo, como rm -rf, git push, gh pr merge, CLI de despliegue, publicación de paquetes, migración de bases de datos o mutación de recursos en la nube, deben requerir aprobación explícita o bloquearse por completo.

Segundo, transmite los resultados con estructura. El agente y el revisor deben ver el comando, el directorio de trabajo, la hora de inicio, el código de salida, stdout, stderr, el estado de tiempo de espera y la política de salida truncada. Una captura de pantalla de la terminal no es suficiente; el sistema debe preservar registros legibles por máquina.

Tercero, maneja las sesiones de larga duración deliberadamente. Los agentes de codificación a menudo necesitan un servidor de desarrollo en segundo plano, un observador, un proceso de automatización del navegador o una pila de pruebas de integración. Trata los procesos de larga duración como recursos con identificadores: inícialos, transmite registros, expón solo el puerto de vista previa requerido y detenlos durante la limpieza. No permitas que un proceso en segundo plano se convierta en un efecto secundario no rastreado de una sesión de chat.

Aislamiento del repositorio y control de ramas para cambios del agente

El estado del repositorio es la columna vertebral de un flujo de trabajo de agente de codificación revisable. El agente no debe trabajar en una carpeta ambigua con ediciones locales desconocidas a menos que el usuario haya elegido explícitamente ese modo.

Para flujos de trabajo en equipo, comienza cada tarea desde una URL de repositorio, rama base y SHA de commit conocidos. Crea una rama de tarea o un espacio de trabajo separado. Mantén los cambios del usuario separados de los cambios del agente y captura el diff exacto antes de la revisión. Si la caja de arena admite sesiones persistentes, persiste el espacio de trabajo intencionalmente; no confíes en el estado accidental del proceso.

El patrón predeterminado se ve así:

1. Crear espacio de trabajo aislado para tarea-123.
2. Descargar el repositorio en main@<base_sha>.
3. Crear rama agent/tarea-123.
4. Ejecutar instalación de dependencias según la política.
5. Permitir que el agente inspeccione, edite, pruebe e itere.
6. Capturar git diff, salida de pruebas, artefactos generados y URL de vista previa.
7. Abrir una solicitud de extracción o entregar el parche a un revisor humano.
8. Destruir o archivar el espacio de trabajo según la política de retención.

El detalle clave es el paso 6. Un agente de codificación útil no solo dice “lo arreglé”. Devuelve los archivos modificados, por qué existe cada cambio, qué validación se ejecutó, qué falló y qué queda sin verificar.

Políticas de comandos, paquetes y red para agentes de codificación en caja de arena

Las instalaciones de paquetes son una de las partes más difíciles del aislamiento de agentes de codificación. Muchas tareas reales necesitan dependencias. Muchos incidentes de la cadena de suministro también comienzan con la obtención de dependencias, scripts posteriores a la instalación o binarios opacos.

Una política práctica no es “nunca instalar paquetes”. Es “instalar paquetes solo a través de rutas conocidas, con registro y ámbito”.

Control	Implementación práctica
Gestores de paquetes	Decidir qué gestores de paquetes están disponibles según el lenguaje y el tipo de repositorio.
Acceso a registros	Permitir registros aprobados; bloquear fuentes de paquetes arbitrarias cuando la tarea no las necesite.
Archivos de bloqueo	Preferir archivos de bloqueo existentes y comandos de instalación reproducibles.
Scripts posteriores a la instalación	Decidir si los scripts del ciclo de vida pueden ejecutarse automáticamente o requieren aprobación.
Paquetes del sistema	Tratar las instalaciones de paquetes del sistema (como apt, brew) como de mayor riesgo que las instalaciones de dependencias del proyecto.
Cachés	Usar cachés de paquetes controlados cuando se necesite velocidad y reproducibilidad.
Registro	Almacenar nombres de paquetes, versiones, URL de registro, sumas de verificación cuando estén disponibles y la salida de la instalación.

La política de red debe ser igualmente explícita. Un agente de codificación puede necesitar leer documentación pública, llamar a una API de staging, descargar un paquete o exponer una vista previa local. Esas son diferentes del acceso a internet sin restricciones. Separa las descargas de paquetes de salida, la navegación web, las llamadas a API, la entrega de webhooks y el acceso a vistas previas entrantes. Si tu producto maneja código o datos sensibles, pregúntate si el DNS, los registros de proxy y los espejos de registros están cubiertos por la misma política que el tráfico HTTP.

Secretos, registros y pistas de auditoría para espacios de trabajo de agentes

Los secretos deben limitarse a la superficie útil más pequeña. Un agente de codificación normalmente no necesita credenciales de producción. Puede necesitar un token de Git de solo lectura, un token de registro de paquetes, una clave de API de staging o un token de despliegue de vista previa. Cada uno debe estar limitado a la tarea, ser temporal cuando sea posible y no estar disponible para comandos que no lo requieran.

Evita colocar secretos en archivos que el agente pueda leer a menos que la tarea realmente lo requiera. Prefiere el acceso intermediado: la caja de arena puede realizar una operación, pero el modelo no ve la credencial en bruto. Cuando las variables de entorno sean necesarias, los registros deben redactar patrones de secretos conocidos, y los artefactos del revisor no deben incluir volcados completos del entorno.

Para las pistas de auditoría, almacena más que el parche final:

• Solicitud del usuario y metadatos de la tarea.
• URL del repositorio, commit base, rama y commit o diff final.
• Comandos solicitados, aprobados, bloqueados y ejecutados.
• Salidas de comandos, códigos de salida y tiempos de espera.
• Lecturas y escrituras de archivos cuando la plataforma pueda capturarlas.
• Registros de red y obtención de paquetes al nivel que admita tu política.
• URL de vista previa y rutas de artefactos generados.
• Aprobaciones humanas y decisiones de fusión.

Esto no es burocracia. Es cómo un revisor distingue una reparación real de una historia plausible.

Diffs, vistas previas y puertas de revisión antes de la fusión

La salida más útil de un agente de codificación es un conjunto de cambios revisable. Eso significa que la caja de arena debe producir los mismos artefactos que un ingeniero cuidadoso esperaría de una solicitud de extracción:

• Un diff enfocado.
• Pruebas o comandos de compilación que se ejecutaron.
• Fallos que permanecen.
• Capturas de pantalla, URL de vista previa o archivos descargables cuando la interfaz de usuario o los activos generados cambiaron.
• Una breve explicación del cambio de comportamiento previsto.

Mantén la fusión o el despliegue final detrás de una puerta controlada por humanos a menos que tu organización haya construido una política de automatización confiable separada para ese repositorio y nivel de riesgo exactos. La revisión humana es especialmente importante cuando los cambios tocan autenticación, facturación, acceso a datos, llamadas de red, infraestructura, versiones de dependencias, migraciones generadas o contenido visible para el usuario.

El manejo de vistas previas merece su propia regla: expón solo el servicio y el puerto necesarios para la revisión. Una caja de arena que inicia una aplicación web debe dar a los revisores una URL de vista previa delimitada, no un acceso amplio a la red al espacio de trabajo.

Estrategia de limpieza y restablecimiento para sesiones de agente de larga duración

Toda caja de arena necesita un ciclo de vida. Sin uno, la infraestructura de agentes de codificación de larga duración se convierte en un montón de espacios de trabajo obsoletos, registros filtrados y procesos aún en ejecución.

Para tareas cortas, un modelo efímero funciona bien: crear una caja de arena, ejecutar el trabajo, extraer artefactos y luego destruirla. Para tareas más grandes, la persistencia puede ser valiosa: el agente puede necesitar pausar, esperar la revisión, reanudar desde la misma rama o mantener un servidor de desarrollo en ejecución durante una sesión de revisión. La persistencia debe ser una característica explícita del producto con vencimiento, propietario y reglas de retención.

Define la limpieza para:

• Procesos en segundo plano y puertos abiertos.
• Archivos temporales y salidas de compilación.
• Cachés de paquetes y archivos descargados.
• Secretos limitados a la tarea.
• Registros y artefactos.
• Ramas o árboles de trabajo que han sido reemplazados.

El restablecimiento es igualmente importante. Un revisor debe poder volver a ejecutar la validación del agente desde el commit base o la rama final. Si el resultado solo funciona debido a un estado invisible dentro de una sesión de larga duración, el flujo de trabajo es difícil de confiar.

Dónde encaja Novita Agent Sandbox en este flujo de trabajo

Novita Agent Sandbox está diseñado para infraestructura de agentes donde la ejecución de código, la automatización del navegador, los flujos de trabajo estilo computer-use, el análisis de datos, las evaluaciones y los flujos de trabajo de agentes de mayor duración necesitan un entorno de ejecución aislado. La documentación de Novita Agent Sandbox describe el producto como un entorno con estado para ejecutar cargas de trabajo de agente, con rutas SDK y CLI para trabajar con el ciclo de vida de la caja de arena, archivos, comandos, sesiones de navegador y primitivas de flujo de trabajo relacionadas.

Para equipos que ya usan las API de modelo de Novita AI, una capa de caja de arena puede reducir la brecha entre la inferencia del modelo y la ejecución de acciones. El modelo puede razonar, llamar a herramientas y planificar cambios de código; la caja de arena puede proporcionar el espacio de trabajo aislado donde esas acciones se ejecutan, registran, previsualizan y revisan.

Usa límites de producto conservadores al diseñar tu flujo de trabajo:

• Trata Novita Agent Sandbox como el entorno de ejecución, no como una garantía de seguridad general.
• Mantén los secretos, las instalaciones de paquetes, la salida de red y las acciones de publicación detrás de tu propia política.
• Valida los detalles actuales del SDK, CLI, precios y límites de cuenta de la documentación de Novita antes de codificarlos en la automatización de producción.
• Evalúa los límites de aislamiento, la compatibilidad con agentes de terceros y los requisitos de cumplimiento según tu propia política antes de confiar en cualquier caja de arena en producción.

Esa separación mantiene la utilidad de las pautas de implementación incluso cuando la capa del agente cambia. Puedes usar agentes estilo Codex, agentes de codificación internos, agentes de navegador o trabajadores de evaluación mientras mantienes las mismas preguntas de control de la caja de arena.

Lista de verificación de implementación de caja de arena para agentes de codificación

Usa esta lista de verificación antes de mover una caja de arena para agentes de codificación más allá de un prototipo.

Área	Pregunta mínima de producción
Espacio de trabajo	¿Cada tarea obtiene un sistema de archivos delimitado y un commit base de repositorio conocido?
Ramificación	¿Los cambios del agente están aislados en una rama o parche que los revisores puedan inspeccionar?
Terminal	¿Los comandos se registran con directorio de trabajo, salida, código de salida y tiempo de espera?
Aprobación	¿Qué comandos se ejecutan automáticamente, requieren aprobación o están bloqueados?
Paquetes	¿Las instalaciones de dependencias son reproducibles y están registradas?
Red	¿La salida de red está separada por descargas de paquetes, navegación de documentación, llamadas a API y acceso a vistas previas?
Secretos	¿Las credenciales están limitadas a la tarea y redactadas de los registros?
Vistas previas	¿Los puertos de vista previa son explícitos y fáciles de cerrar?
Artefactos	¿Los archivos generados, capturas de pantalla, informes y registros se adjuntan a la revisión?
Persistencia	¿La pausa/reanudación de la sesión es intencional, con propietario y vencimiento?
Limpieza	¿Se eliminan procesos, puertos, archivos temporales, secretos y espacios de trabajo obsoletos?
Revisión	¿Un humano aprueba la fusión, publicación o despliegue de cambios riesgosos?

Si tu configuración actual no puede responder varias de estas preguntas, mantén el flujo de trabajo en un carril de prototipo. El agente aún puede ser útil, pero no debe recibir acceso amplio al repositorio, la red o las credenciales.

Preguntas frecuentes

¿Puedo ejecutar el propio Codex dentro de una caja de arena en la nube?

Conceptualmente, sí: un agente de codificación de terminal puede ejecutarse dentro de un espacio de trabajo aislado si el entorno admite el sistema operativo, la ruta de autenticación, la E/S de terminal, el acceso al sistema de archivos y el acceso a la red que el agente requiere. No asumas una integración oficial o compatibilidad total a menos que el proveedor de la caja de arena y el proveedor del agente lo documenten para tu configuración exacta.

¿Es suficiente Docker para una caja de arena de agente de codificación?

Docker puede ser útil para el desarrollo local, trabajos de CI y entornos repetibles, pero “suficiente” depende de tu modelo de amenaza. Pregunta qué comparte el núcleo, qué montajes de archivos existen, cómo se controla la salida de red, si los secretos están expuestos al contenedor y cómo se manejarían las fugas o el compromiso de dependencias. Para cargas de trabajo sensibles, los equipos de seguridad a menudo evalúan límites de aislamiento más fuertes y controles de salida más estrictos.

¿Debería un agente de codificación tener acceso a internet?

Solo cuando la tarea lo necesite, y solo a través de una política que puedas explicar. La consulta de documentación, el acceso al registro de paquetes, las llamadas a API de staging y la navegación arbitraria son permisos diferentes. Registra lo que el agente obtuvo, mantén las instalaciones de paquetes reproducibles y evita dar acceso a la red de producción a una sesión de codificación de uso general.

¿Qué debería revisar un revisor antes de fusionar el código generado por el agente?

Revisa el diff, los comandos que se ejecutaron, la salida de pruebas/compilación, los cambios de dependencias, los artefactos generados, el comportamiento de la vista previa y cualquier validación omitida. Presta especial atención a autenticación, permisos, manejo de datos, llamadas de red, migraciones, scripts de instalación y secretos.

¿Cómo ayuda Novita con las cajas de arena para agentes de codificación?

Novita Agent Sandbox proporciona un entorno de ejecución de agente aislado para cargas de trabajo como ejecución de código, automatización del navegador, tareas estilo computer-use, análisis de datos, evaluaciones y flujos de trabajo de mayor duración. Combínalo con políticas explícitas de repositorio, comandos, paquetes, red, secretos y revisión al construir un flujo de trabajo de agente de codificación.

Artículos recomendados

• AI-Generated Code Sandbox Requirements for Production Apps
• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs
• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• Build an AI Data Analyst with Sandboxed Python and Controlled Package Access