For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegación principal
Theme

Sandbox

Cómo funciona el entorno aislado en los clientes de ChatGPT y Codex

El sandbox establece los límites que permiten al agente actuar de forma autónoma sin darle acceso irrestricto a tu computadora. Cuando un chat local ejecuta comandos en la aplicación de escritorio de ChatGPT, Codex CLI o la extensión para IDE, esos comandos se ejecutan de forma predeterminada en un entorno restringido, sin acceso completo.

Ese entorno define qué puede hacer el agente por su cuenta, por ejemplo, qué archivos puede modificar y si los comandos pueden usar la red. Mientras la tarea se mantenga dentro de esos límites, el agente puede continuar sin detenerse a pedir confirmación. Si necesita rebasarlos, se inicia el proceso de aprobación.

El entorno aislado y las aprobaciones son controles distintos que funcionan en conjunto. El sandbox establece los límites técnicos. La política de aprobación determina cuándo debe detenerse el agente y pedir permiso antes de rebasarlos.

Qué hace el sandbox

El sandbox se aplica tanto a los comandos que inicia el agente como a las operaciones integradas de manejo de archivos. Si el agente ejecuta herramientas como git, gestores de paquetes o herramientas de ejecución de pruebas, esos comandos heredan los mismos límites del sandbox.

Codex usa mecanismos nativos de cada sistema operativo para imponer los límites. La implementación varía entre macOS, Linux, WSL2 y Windows nativo, pero el principio es el mismo en todos los clientes: darle al agente un entorno de trabajo con límites claros dentro de los cuales pueda realizar tareas habituales de forma autónoma.

Por qué es importante

El sandbox reduce el desgaste que generan las solicitudes de aprobación frecuentes. En lugar de pedirte que confirmes cada comando de bajo riesgo, el agente puede leer archivos, editarlos y ejecutar comandos habituales del proyecto dentro de los límites que ya aprobaste.

También te da un modelo de confianza más claro para trabajar con agentes. Además de confiar en las intenciones del agente, puedes contar con que el entorno le impone límites. Así es más fácil dejar que trabaje por su cuenta y saber cuándo se detendrá para pedir ayuda.

Primeros pasos

El modo de permisos predeterminado usa un entorno aislado automáticamente.

Requisitos previos

En macOS, el entorno aislado funciona sin configuración adicional gracias al framework Seatbelt integrado.

En Windows, Codex usa el sandbox nativo de Windows cuando lo ejecutas en PowerShell y la implementación del sandbox de Linux cuando lo ejecutas en WSL2.

En Linux y WSL2, primero instala bubblewrap con tu gestor de paquetes:

Choose an option
sudo apt install bubblewrap

Codex usa el primer ejecutable bwrap que encuentra en PATH. Si no hay ningún ejecutable bwrap disponible, Codex recurre a un programa auxiliar incluido que requiere que el sistema permita a los usuarios sin privilegios crear espacios de nombres de usuario. Instalar el paquete de la distribución que proporciona bwrap ayuda a que esta configuración funcione de forma confiable.

Codex muestra una advertencia al iniciar si falta bwrap o si el programa auxiliar no puede crear el espacio de nombres de usuario necesario. En las distribuciones que imponen esta restricción mediante AppArmor, es preferible cargar el perfil de AppArmor para bwrap. Así, bwrap puede seguir funcionando sin desactivar la restricción en todo el sistema.

Nota sobre AppArmor en Ubuntu: en Ubuntu 25.04, instalar bubblewrap desde el repositorio de paquetes de Ubuntu debería ser suficiente, sin necesidad de configurar AppArmor. El perfil bwrap-userns-restrict viene incluido en el paquete apparmor, en /etc/apparmor.d/bwrap-userns-restrict.

En Ubuntu 24.04, incluso después de instalar bubblewrap, Codex podría advertirte que no puede crear el espacio de nombres de usuario necesario. Copia y carga el perfil adicional:

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

apparmor_parser -r carga el perfil en el kernel sin necesidad de reiniciar el sistema. También puedes volver a cargar todos los perfiles de AppArmor:

sudo systemctl reload apparmor.service

Si ese perfil no está disponible o no resuelve el problema, puedes usar este comando para desactivar la restricción de AppArmor que limita la creación de espacios de nombres de usuario por parte de usuarios sin privilegios:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Acceso a la computadora local con Work Cloud

En las tareas que usan el acceso a la computadora local con Work Cloud, la nube de OpenAI coordina la conversación. Las restricciones del sandbox dependen de dónde se ejecute cada paso:

  • Ejecución en la nube: los contenedores de Work en la nube usan las políticas existentes de Work Cloud. Las reglas de sitios del navegador de escritorio no se aplican automáticamente a los navegadores en la nube.
  • Ejecución local: los pasos que se ejecutan en una computadora conectada se rigen por los requisitos de ejecución local compatibles.

Tanto en el modo Work con acceso local como en los dots, la política Global compatible se aplica al orquestador compartido en la nube cuando está habilitada la política administrada. Los contenedores de Work en la nube y las computadoras de los dots en la nube usan sus propios requisitos y configuraciones de ejecución. Prueba la ejecución local y la ejecución en la nube por separado para confirmar qué controles se aplican en cada entorno. La política de un entorno no concede acceso a otro.

Dentro de una política, el orden de mayor a menor prioridad es el siguiente: configuración de entorno que prevalece para un sistema operativo específico → configuración de entorno que prevalece para todos los sistemas operativos → Global. La política de mayor prioridad prevalece incluso si la de menor prioridad es más específica. En la ejecución local, los requisitos de MDM y los requisitos heredados de los dispositivos administrados tienen prioridad sobre Agent Security, que a su vez tiene prioridad sobre el archivo de requisitos del sistema del dispositivo.

Consulta Configuración administrada para conocer las reglas de combinación de cada campo y los límites de ejecución. Revisa las restricciones de archivos y de red que se aplican en la práctica en Seguridad local de Work y Seguridad de Work en la nube.

Cómo funcionan los permisos

Usa el control de permisos de tu cliente para cambiar la forma en que Codex gestiona las acciones locales.

Las aprobaciones determinan cuándo se detiene Codex antes de realizar una acción. El sandbox determina a qué archivos y recursos de red pueden acceder los comandos. Si una solicitud de aprobación ofrece varios alcances, como aprobar una sola vez o para toda la sesión, elige el más limitado que permita continuar con la tarea. Mantén los límites del proyecto de forma predeterminada. Usa proyectos o worktrees separados en lugar de ampliar el acceso a repositorios que no están relacionados.

En la aplicación de escritorio de ChatGPT, usa el control de permisos que aparece debajo del editor. Según tu configuración, el menú puede incluir Solicitar aprobación, Aprobar por mí para las solicitudes de aprobación que cumplan los requisitos, Acceso completo y perfiles de permisos con nombre o personalizados.

Selecciona un modo para explorar este ejemplo de la documentación. Tu selección no cambia tus permisos de ChatGPT ni de Codex.

How should ChatGPT actions be approved?Learn more

Approve for me

Approve for me keeps the same workspace-write sandbox as Ask for approval, but eligible approval requests are routed through automatic review instead of showing a prompt for manual approval. More details about automatic review.

Sandbox
workspace-write
Approvals policy
on-request
Reviewer
auto_review

Configurar los valores predeterminados

Para que Codex se comporte de la misma manera cada vez que lo inicies, establece los valores predeterminados en config.toml. En Conceptos básicos de configuración se explica cómo funciona el archivo, y en la Referencia de configuración se documentan las claves exactas de sandbox_mode, approval_policy, approvals_reviewer y sandbox_workspace_write.writable_roots. Usa estos ajustes para decidir cuánta autonomía tiene el agente de forma predeterminada, en qué directorios puede escribir, cuándo debe detenerse para pedir aprobación y quién revisa las solicitudes de aprobación que cumplen los requisitos.

Los modos de sandbox más comunes son los siguientes:

  • read-only: el agente puede inspeccionar archivos, pero necesita aprobación para editarlos o ejecutar comandos.
  • workspace-write: el agente puede leer archivos, editar archivos dentro del espacio de trabajo y ejecutar comandos locales habituales dentro de esos límites. Es el modo predeterminado para trabajar de forma local con pocas interrupciones.
  • danger-full-access: el agente se ejecuta sin las restricciones del sandbox. Este modo elimina los límites de acceso al sistema de archivos y a la red. Úsalo solo cuando quieras que el agente actúe con acceso completo.

Las políticas de aprobación más comunes son las siguientes:

  • on-request: de forma predeterminada, el agente trabaja dentro del sandbox y pide aprobación cuando necesita rebasar sus límites.
  • never: el agente no se detiene para pedir aprobación.

Codex y ChatGPT Work ya no permiten seleccionar untrusted como política de aprobación. Si una configuración existente usa ese valor, consulta Migrar desde la política de aprobación retirada untrusted.

Cuando las aprobaciones son interactivas, también puedes elegir quién las revisa mediante approvals_reviewer:

  • user: las solicitudes de aprobación se muestran al usuario. Es la opción predeterminada.
  • auto_review: las solicitudes de aprobación que cumplen los requisitos se envían a un agente revisor (consulta Revisión automática).

El acceso completo se configura con sandbox_mode = "danger-full-access" junto con approval_policy = "never". Para la automatización local, la configuración predefinida de menor riesgo usa sandbox_mode = "workspace-write" junto con approval_policy = "on-request", o las opciones equivalentes de la CLI --sandbox workspace-write --ask-for-approval on-request. Luego puedes mantener approvals_reviewer = "user" para las aprobaciones manuales o establecer approvals_reviewer = "auto_review" para la revisión automática de las solicitudes de aprobación.

Si necesitas que el agente trabaje en más de un directorio, los directorios raíz con permiso de escritura te permiten ampliar el conjunto de ubicaciones donde puede hacer cambios sin eliminar por completo el sandbox. Si necesitas ampliar o reducir los límites de confianza, ajusta el modo de sandbox predeterminado y la política de aprobación en lugar de recurrir a excepciones puntuales.

Cuando un flujo de trabajo necesite una excepción específica, usa reglas. Las reglas te permiten indicar, según el prefijo de un comando, si se permite ejecutarlo fuera del sandbox, si se debe pedir aprobación o si se prohíbe su ejecución. Esto suele ser más adecuado que ampliar el acceso de forma general. Para saber dónde encontrar los ajustes específicos del IDE, consulta Configuración de la extensión de Codex para IDE.

La revisión automática, cuando está disponible, mantiene los límites del sandbox. Es una de las opciones de approvals_reviewer para las solicitudes de aprobación que surgen al alcanzar esos límites, por ejemplo, las solicitudes para ejecutar comandos fuera del sandbox, los intentos bloqueados de acceso a la red o las llamadas a herramientas con efectos secundarios que aún requieren aprobación. Las acciones que ya están permitidas dentro del sandbox se ejecutan sin revisión adicional. Para conocer el ciclo de vida del revisor, los tipos de eventos que activan la revisión, qué implica un rechazo y los detalles de configuración, consulta Revisión automática.

Encontrarás los detalles de cada plataforma en su documentación. Para obtener información sobre la configuración, el comportamiento y la solución de problemas en Windows nativo, consulta Windows. Para conocer los requisitos para administradores y las restricciones de la organización sobre el entorno aislado y las aprobaciones, consulta Aprobaciones y seguridad del agente.