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 acotado, 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 fusionarlos o desplegarlos. Ese patrón funciona ya sea que el agente sea estilo Codex, conectado a 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 aplica 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 puede ser suficiente. 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 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 egreso de red para registros, documentación, API y acceso de vista previa.
• Secretos que están acotados a la tarea y ocultos de los registros cuando sea posible.
• Capturas de stdout, stderr, códigos de salida, cambios de archivos, artefactos generados y URL de vista previa.
• Una puerta de revisión antes de fusionar, desplegar o lanzar externamente.

Es por esto que “ejecutar Codex en un sandbox” 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 CI o flujo de trabajo de producto, el entorno de ejecución circundante se convierte en el plano de control.

Arquitectura de sandbox para 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	¿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 alcance del sistema de archivos, secretos, egreso de red, instalación de paquetes, límites de tiempo de ejecución y 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 que sucedió sin confiar en el resumen del modelo?
Puerta de revisión	Requiere un paso humano o de automatización de confianza 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ítica de egreso, puede ser conveniente para prototipos pero insuficiente para 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 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. Comandos seguros de solo lectura como ls, sed, rg, git diff y comandos de estado de pruebas a menudo pueden ejecutarse automáticamente. 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 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 una terminal no es suficiente; el sistema debe preservar registros legibles por máquina.

Tercero, maneja sesiones de larga duración deliberadamente. Los agentes de codificación a menudo necesitan un servidor de desarrollo en segundo plano, un watcher, un proceso de automatización de navegador o un stack 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 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 en equipo, comienza cada tarea desde una URL de repositorio conocida, rama base y 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 intencionalmente; no confíes en el estado accidental del proceso.

El patrón predeterminado se ve así:

1. Crear un espacio de trabajo aislado para la tarea-123.
2. Hacer checkout del repositorio en main@<base_sha>.
3. Crear la rama agent/task-123.
4. Ejecutar la 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. Eliminar 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 cambiados, por qué existe cada cambio, qué validación se ejecutó, qué falló y qué permanece 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 la cadena de suministro también comienzan con la obtención de dependencias, scripts de 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	Decidir qué gestores de paquetes están disponibles según el idioma 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 de post-instalación	Decidir si los scripts de ciclo de vida pueden ejecutarse automáticamente o requieren aprobación.
Paquetes del sistema	Tratar apt, brew y las instalaciones de paquetes del sistema 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 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. Esos son diferentes del acceso irrestricto a internet. Separa las obtenciones de paquetes salientes, la navegación web, las llamadas API, la entrega de webhooks y el ingreso de vistas previas. Si tu producto maneja código o datos sensibles, pregúntate si DNS, registros de proxy y espejos de registro 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 estar acotados 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 acotado 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 acceso intermediado: el sandbox puede realizar una operación, pero el modelo no ve la credencial en bruto. Cuando las variables de entorno sean necesarias, los registros deben ocultar 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 tu política admita.
• 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 corrección real de una historia plausible.

Diffs, vistas previas y puertas de revisión antes de fusionar

La salida más útil de un agente de codificación es un conjunto de cambios revisable. Esto significa que el sandbox 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 creado una política de automatización de confianza 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. Un sandbox que inicia una aplicación web debe dar a los revisores una URL de vista previa acotada, no un acceso amplio a la red dentro del espacio de trabajo.

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

Cada 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: crear un sandbox, ejecutar el trabajo, extraer artefactos y luego destruirlo. Para tareas más grandes, la persistencia puede ser valiosa: el agente puede necesitar pausar, esperar 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 reglas de caducidad, propietario y 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 acotados a la tarea.
• Registros y artefactos.
• Ramas o árboles de trabajo que han sido reemplazados.

El restablecimiento es igualmente 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 de navegador, los flujos de trabajo estilo uso de computadora, 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 agentes, con rutas SDK y CLI para trabajar con el ciclo de vida del sandbox, archivos, comandos, sesiones de navegador y primitivas de flujo de trabajo relacionadas.

Para equipos que ya usan las API 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 a 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.

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, el egreso 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 sandbox en producción.

Esa separación mantiene útil la guía 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 del sandbox.

Lista de verificación de implementación de sandbox para agente de codificación

Usa esta lista de verificación antes de mover 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 acotado 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 están registradas?
Red	¿El egreso está separado por obtenciones de paquetes, navegación de documentación, llamadas API y acceso de vista previa?
Secretos	¿Las credenciales están acotadas a la tarea y ocultas 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 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 la fusión, publicación o despliegue para cambios riesgosos?

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

FAQ

¿Puedo ejecutar Codex dentro de un sandbox 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 del sandbox y el proveedor del agente lo documenten para tu configuración exacta.

¿Es Docker suficiente para un sandbox de agente de codificación?

Docker puede ser útil para desarrollo local, trabajos de CI y entornos repetibles, pero “suficiente” depende de tu modelo de amenaza. Pregunta qué comparte un kernel, qué montajes de archivos existen, cómo se controla el egreso 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 egreso 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 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 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, permisos, manejo de datos, llamadas de red, migraciones, scripts de instalación y secretos.

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

Novita Agent Sandbox proporciona un entorno de ejecución aislado para agentes para cargas de trabajo como ejecución de código, automatización de navegador, tareas estilo uso de computadora, 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

• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation
• How to Use Codex with Novita AI Models