Ejecuta Codex o un agente de codificación en un sandbox seguro

Ejecuta un agente de codificación en un sandbox 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 del merge o el despliegue. Ese patrón funciona ya sea que el agente sea de estilo Codex, conectado a un IDE, activado por CI o integrado en tu propia plataforma de desarrollo: el modelo puede planificar y editar, pero el sandbox decide qué puede tocar, qué puede ejecutar, qué puede obtener y qué evidencia recibe un revisor.

¿Qué es un sandbox de agente de codificación?

Un sandbox de agente 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 permite, ejecutar pruebas, iniciar servidores de vista previa y devolver un diff revisable sin recibir acceso amplio a la máquina del desarrollador o al entorno de producción.

El cambio importante es que el sandbox no es solo un envoltorio de chat alrededor de un modelo. Es el límite operativo del trabajo. El modelo propone acciones; el sandbox hace cumplir el espacio de trabajo, las herramientas, los permisos y el rastro de evidencia.

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

• Un espacio de trabajo dedicado para cada tarea o sesión.
• Un estado y una rama de repositorio conocidos.
• Una interfaz de ejecución de comandos con aprobaciones para operaciones arriesgadas.
• 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, APIs y acceso a vistas previas.
• Secretos delimitados a la tarea y ocultos de los registros cuando sea posible.
• Captura de stdout, stderr, códigos de salida, cambios de archivo, artefactos generados y URLs de vista previa.
• Una puerta de revisión antes del merge, el despliegue o el lanzamiento externo.

Por eso, «ejecutar Codex en un sandbox» debe entenderse como un patrón de infraestructura, no solo un hábito local de CLI. El propio Codex CLI está documentado como un agente de codificación que se ejecuta a través de un flujo de trabajo de terminal, y el entorno de ejecución circundante se convierte en el plano de control cuando lo operas para un equipo, un sistema de CI o un flujo de producto. La plantilla de Codex Agent de primera parte de Novita ahora hace concreto ese patrón dentro de Novita Sandbox, en lugar de dejarlo como una posibilidad conceptual.

Arquitectura de un sandbox de agente 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 el sandbox, hace checkout del repositorio, establece la rama y monta los archivos permitidos	¿Está aislada cada tarea? ¿Se conoce el commit base? ¿Se puede restablecer el espacio de trabajo?
Ejecutor de terminal	Ejecuta los comandos aprobados y transmite los resultados de vuelta al agente	¿Qué comandos se permiten automáticamente, requieren aprobación o están bloqueados?
Capa de políticas	Controla el alcance 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 ocurrido sin confiar en el resumen del modelo?
Puerta de revisión	Requiere un humano o un paso de automatización confiable antes del merge, la publicación o el despliegue	¿Quién aprueba los cambios arriesgados? ¿Qué comprobaciones deben pasar primero?

En la práctica, una única plataforma puede combinar varias de estas capas. La arquitectura sigue importando porque mantiene honestas las decisiones de producto. Si una herramienta le da a un agente una terminal pero no puede mostrar registros de comandos, diffs de archivos o política de salida de red, puede ser conveniente para prototipos, pero escasa para la revisión en producción.

¿Cómo debería funcionar el acceso a la terminal en un sandbox de agente de codificación?

La terminal es donde un agente de codificación se vuelve operativamente útil y operativamente arriesgado. 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 los comandos de estado de pruebas, pueden ejecutarse automáticamente a menudo. Los comandos de compilación y pruebas, 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, CLIs de despliegue, publicación de paquetes, migraciones de bases de datos o mutación de recursos en la nube, deberían requerir aprobación explícita o bloquearse por completo.

Segundo, transmite los resultados con estructura. El agente y el revisor deberían 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 una terminal no es suficiente; el sistema debería conservar registros legibles por máquina.

Tercero, gestiona las sesiones de larga duración de manera deliberada. Los agentes de codificación a menudo necesitan un servidor de desarrollo en segundo plano, un watcher, 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 sus registros, expón solo el puerto de vista previa requerido y detenlos durante la limpieza. No dejes 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 los 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 debería trabajar en una carpeta ambigua con ediciones locales desconocidas, a menos que el usuario haya elegido explícitamente ese modo.

Para flujos de trabajo de equipo, empieza cada tarea desde una URL de repositorio conocida, una rama base y un SHA de commit. 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 el sandbox admite sesiones persistentes, persiste el espacio de trabajo de manera intencional; no dependas del estado accidental de los procesos.

El patrón predeterminado se ve así:

1. Crea un espacio de trabajo aislado para task-123.
2. Haz checkout del repositorio en main@<base_sha>.
3. Crea la rama agent/task-123.
4. Ejecuta la instalación de dependencias según la política.
5. Deja que el agente inspeccione, edite, pruebe e itere.
6. Captura el diff de git, la salida de pruebas, los artefactos generados y la URL de vista previa.
7. Abre un pull request o entrega el parche a un revisor humano.
8. Destruye o archiva 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 he arreglado». 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 sandbox

Las instalaciones de paquetes son una de las partes más difíciles del sandboxing de agentes de codificación. Muchas tareas reales necesitan dependencias. Muchos incidentes de cadena de suministro también comienzan con la obtención de dependencias, scripts post-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 alcance».

Control	Implementación práctica
Gestores de paquetes	Decide qué gestores de paquetes están disponibles según el lenguaje y el tipo de repositorio.
Acceso a registros	Permite los registros aprobados; bloquea fuentes de paquetes arbitrarias cuando la tarea no las necesita.
Lockfiles	Prefiere los lockfiles existentes y los comandos de instalación reproducibles.
Scripts post-instalación	Decide si los scripts de ciclo de vida pueden ejecutarse automáticamente o requieren aprobación.
Paquetes del sistema	Trata las instalaciones de paquetes del sistema (apt, brew, SO) como de mayor riesgo que las dependencias de proyecto.
Cachés	Usa cachés de paquetes controladas cuando necesites velocidad y reproducibilidad.
Registro	Almacena nombres de paquetes, versiones, URLs de registro, checksums cuando estén disponibles y la salida de la instalación.

La política de red debería 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. Eso es diferente del acceso a internet sin restricciones. Separa las descargas de paquetes salientes, la navegación web, las llamadas a APIs, la entrega de webhooks y la entrada de vistas previas. Si tu producto maneja código o datos sensibles, pregunta 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 deberían delimitarse 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 debería estar delimitado a la tarea, limitado en el tiempo cuando sea posible y no 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: el sandbox puede realizar una operación, pero el modelo no ve la credencial cruda. Cuando las variables de entorno sean necesarias, los registros deberían redactar patrones de secretos conocidos, y los artefactos del revisor no deberían 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 de obtención de paquetes al nivel que tu política soporte.
• URLs de vista previa y rutas de artefactos generados.
• Aprobaciones humanas y decisiones de merge.

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

Diffs, vistas previas y puertas de revisión antes del merge

La salida más útil de un agente de codificación es un conjunto de cambios revisable. Eso significa que el sandbox debería producir los mismos artefactos que un ingeniero cuidadoso esperaría de un pull request:

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

Mantén el merge o 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 afectan 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. Un sandbox que inicia una aplicación web debería dar a los revisores una URL de vista previa delimitada, no acceso amplio a la red dentro del espacio de trabajo.

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

Todo sandbox 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: crea un sandbox, ejecuta el trabajo, extrae los artefactos y luego destrúyelo. Para tareas más grandes, la persistencia puede ser valiosa: el agente puede necesitar pausar, esperar una 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 debería ser una característica explícita del producto con reglas de caducidad, propietario y retención.

Define la limpieza de:

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

El restablecimiento es igual de importante. Un revisor debería 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 de estilo computer-use, el análisis de datos, las evaluaciones y los flujos de trabajo de agentes de larga 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 agentes, con rutas de SDK y CLI para trabajar con el ciclo de vida del sandbox, archivos, comandos, sesiones de navegador y primitivas de flujo de trabajo relacionadas. Novita también documenta ahora una plantilla de Codex Agent de primera parte, lo que importa porque convierte la idea de «ejecutar Codex en un sandbox» en un flujo de trabajo publicado con detalles concretos de configuración.

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

Qué cambia en la práctica la plantilla de Codex de primera parte

La nueva plantilla de Codex no elimina la necesidad de políticas, pero sí aclara cómo un flujo de trabajo de Codex orientado a producción se asigna a los controles descritos anteriormente en este artículo.

• codex exec te ofrece un modo de ejecución no interactivo que se adapta mejor a trabajos en cola, orquestadores de agentes y ejecución de tareas revisable que una sesión de terminal puramente interactiva.
• --full-auto solo tiene sentido cuando el propio sandbox es el límite de aprobación confiable. En otras palabras, la autoaprobación es más fácil de justificar cuando el acceso a archivos, la salida de red, el alcance del repositorio y la limpieza ya están restringidos por el entorno de ejecución alrededor de Codex.
• --skip-git-repo-check es útil para tareas de arranque, pero el patrón más sólido para el trabajo de ingeniería real sigue siendo clonar un repositorio específico en el sandbox y ejecutar Codex desde ese checkout controlado.
• Escribir ~/.codex/auth.json y ~/.codex/config.toml dentro del sandbox hace que la personalización del proveedor y del modelo sea parte del entorno aislado, en lugar de algo tomado de la computadora portátil de un desarrollador.
• sandbox.git.clone encaja naturalmente con el aislamiento del repositorio y el control de ramas: incorpora solo el repositorio que la tarea necesita, ejecuta el agente en ese directorio delimitado y mantén la máquina anfitriona fuera del circuito.
• La reanudación de sesiones mediante --json, el thread_id capturado y codex exec resume <thread_id> es una forma práctica de manejar trabajos de larga duración sin pretender que la persistencia y la auditabilidad son lo mismo. Aún necesitas reglas explícitas de retención, captura de registros y propiedad para las sesiones reanudadas.

Esa es la división útil entre la documentación y la guía del blog. La documentación muestra la secuencia operativa. La decisión de flujo de trabajo es tratar esos mecanismos como evidencia de un patrón más seguro: ejecuta Codex dentro de un espacio de trabajo acotado, mantén la autoaprobación limitada a sandboxes confiables, preserva el estado del repositorio de manera intencional y haz que las sesiones reanudadas sean visibles para los revisores en lugar de una memoria opaca del agente.

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 de SDK, CLI, precios y límites de cuenta en la documentación de Novita antes de hardcodearlos 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 frente a tu propia política antes de depender de cualquier sandbox en producción.

Esa separación mantiene útil la guía de implementación incluso cuando la capa de agentes 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 del sandbox.

Lista de verificación para implementar un sandbox de agente de codificación

Usa esta lista de verificación antes de llevar un sandbox de agente 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?
Ramas	¿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 se registran?
Red	¿La salida de red está separada por descargas de paquetes, navegación de documentación, llamadas a APIs y acceso a vistas previas?
Secretos	¿Las credenciales están delimitadas 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 caducidad?
Limpieza	¿Se eliminan procesos, puertos, archivos temporales, secretos y espacios de trabajo obsoletos?
Revisión	¿Un humano aprueba el merge, la publicación o el despliegue de cambios arriesgados?

Si tu configuración actual no puede responder varias de estas preguntas, mantén el flujo de trabajo en una vía de prototipo. El agente puede seguir siendo útil, pero no debería recibir acceso amplio al repositorio, a la red o a las credenciales.

Preguntas frecuentes

¿Puedo ejecutar Codex dentro de un sandbox en la nube?

Sí. Novita ahora documenta una plantilla de Codex Agent de primera parte para Novita Sandbox, con un flujo publicado para ejecutar codex exec en un entorno aislado, clonar repositorios en el sandbox, personalizar la configuración del proveedor de Codex dentro de ~/.codex/ y reanudar sesiones anteriores con un thread_id capturado. La advertencia sigue aplicándose a nivel de cuenta y configuración: valida la ruta de autenticación exacta, las credenciales del repositorio, los límites de tiempo de ejecución y los controles de política para tu propio entorno, en lugar de asumir que cada flujo de trabajo local de Codex se transfiere sin cambios.

¿Es Docker suficiente para un sandbox 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 amenazas. Pregunta qué comparte un kernel, 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 los escapes o el compromiso de dependencias. Para cargas de trabajo sensibles, los equipos de seguridad a menudo evalúan límites de aislamiento más sólidos y controles de salida de red más estrictos.

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

Solo cuando la tarea lo necesita, 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 APIs 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 propósito general.

¿Qué debería revisar un revisor antes de fusionar código generado por un 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 la autenticación, los permisos, el manejo de datos, las llamadas de red, las migraciones, los scripts de instalación y los secretos.

¿Cómo ayuda Novita con los sandboxes de agentes de codificación?

Novita Agent Sandbox proporciona un entorno de ejecución de agentes aislado para cargas de trabajo como ejecución de código, automatización del navegador, tareas de estilo computer-use, análisis de datos, evaluaciones y flujos de trabajo de larga duración. Con la plantilla de Codex de primera parte, ese entorno también puede alojar flujos específicos de Codex, como ejecución no interactiva, checkouts delimitados al repositorio, configuración personalizada del proveedor y reanudación de sesiones. Combina esos mecanismos con políticas explícitas de repositorio, comandos, paquetes, red, secretos y revisión para que el sandbox siga siendo el límite de ejecución, en lugar de convertirse en un atajo desatendido alrededor de tus controles normales de ingeniería.

Artículos recomendados

• AI-Generated Code Sandbox Requirements for Production Apps
• Run Claude Code or Managed Agents in an Isolated Sandbox
• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs