Mantén los secretos fuera del entorno de trabajo y deniega el acceso a los archivos sensibles. Empieza combinando estas dos medidas.
El modo de solo lectura, las aprobaciones y la exclusión del entrenamiento tienen objetivos distintos. Comprueba cada control por separado para saber si puede impedir el acceso a archivos secretos.
Comprueba por separado la lectura, la ejecución y la transmisión
Retira del entorno de trabajo los secretos innecesarios. Considera una regla de lectura deny para los archivos sensibles.
Comprueba quién revisa las aprobaciones. Evita ampliar los límites mediante Full access o permisos para ejecutar fuera del sandbox.
Comprueba por separado la red de los comandos, la transmisión al modelo y el acceso del navegador o de MCP.
La documentación de OpenAI sobre Permissions, Sandbox, aprobaciones, seguridad y configuración se revisó el 8 de octubre de 2026. Esta guía se centra en comandos dentro de un sandbox local. La configuración de ejemplo no se ha aplicado ni se ha comprobado su cumplimiento en un equipo real. No se modificó ninguna configuración del dispositivo o de la cuenta.
Contenido
- 1. Solo lectura, aprobaciones y ajustes de entrenamiento
- 2. Mantener los secretos fuera del entorno de trabajo
- 3. Ejemplo de configuración para denegar lecturas
- 4. Patrones .env y aspectos que hay que comprobar
- 5. Qué bloquea y qué no bloquea desactivar la red de los comandos
- 6. Variables de entorno, sistemas operativos y Cloud
- 7. Verificar con archivos de prueba
- Preguntas frecuentes
1. Solo lectura, aprobaciones y ajustes de entrenamiento
Impedir que se modifiquen archivos no equivale a impedir que se lean.
Modo que restringe la escritura. No oculta como secretos los contenidos de archivos que se pueden leer.
Define dónde se permite editar. No necesariamente limita la lectura a esas mismas ubicaciones.
| Control | Qué regula principalmente | Qué no garantiza por sí solo |
|---|---|---|
| Modo de solo lectura | Si se pueden modificar los archivos | Que no se lean archivos secretos accesibles |
| Política de aprobación | Quién revisa las acciones que cruzan un límite | Una revisión humana de cada lectura dentro del ámbito permitido |
| Reglas de denegación de archivos | Rechazo de lecturas y escrituras en rutas especificadas | Eliminar contenido ya pegado o impedir el acceso mediante otras herramientas |
| Restricciones de red de los comandos | Destinos de red de los comandos ejecutados en el sandbox | Bloquear todo el tráfico de modelos, autenticación, navegadores, MCP y otros servicios |
| Ajustes de entrenamiento | Si los datos procesados se usan para mejorar modelos | Que los datos no se procesen ni se transmitan |
Incluso con on-request, los comandos dentro del ámbito permitido pueden ejecutarse sin aprobación adicional. Si necesitas revisión humana, comprueba tanto la política de aprobación como quién recibe la solicitud de revisión.
En qué se diferencia la revisión automática por IA
approvals_reviewer = "auto_review" dirige la revisión correspondiente a una IA. No es una revisión humana ni añade una revisión obligatoria a cada acción que ya estaba permitida.
Fuente: OpenAI: aprobaciones y límites del sandbox. El entrenamiento se trata por separado en ajustes de entrenamiento de ChatGPT y Codex e información confidencial.
2. Mantener los secretos fuera del entorno de trabajo
Un cambio de interfaz puede requerir solo código fuente y datos ficticios. Las claves de API de producción, los datos de clientes y los documentos familiares no tienen por qué estar en ese mismo entorno.
Mover los archivos a otra carpeta no basta. Si siguen existiendo permisos amplios de lectura, esos archivos podrían continuar siendo accesibles.
Incluye solo lo necesario en la copia de trabajo
Usa entradas pequeñas que reproduzcan el problema en lugar de datos de producción.
Los ejemplos de configuración deberían contener solo nombres de campos. Revisa también registros, copias de seguridad e historial.
Comprueba si se puede acceder a otras carpetas, al directorio personal, al almacenamiento compartido o a aplicaciones conectadas.
¿Las reglas de exclusión de Git impiden la lectura?
.gitignore especifica los archivos sin seguimiento que Git debe ignorar. No elimina los permisos de lectura del sistema operativo. Aunque una herramienta de búsqueda normalmente omita un archivo, eso no garantiza que se deniegue leerlo mediante su ruta explícita. Añadir una regla de exclusión tampoco afecta a los archivos que Git ya sigue. Documentación de Git: alcance de gitignore.
Instrucciones frente a denegación efectiva del acceso
Escribir «no leas secretos» en AGENTS.md puede aportar instrucciones útiles de trabajo. No crea por sí solo restricciones de acceso del sistema operativo. Combina las instrucciones con una denegación efectiva del acceso. Consulta precauciones al introducir información en herramientas de IA para ver ejemplos de anonimización de entradas.
3. Ejemplo de configuración para denegar lecturas
Los perfiles de permisos son una función beta. Comprueba los entornos compatibles y la configuración seleccionada en la sesión actual antes de usarlos.
read: lecturaPermiso para leer el destino
write: ediciónPermiso para escribir en el destino
deny: denegaciónDeniega tanto la lectura como la escritura en el destino
Atención a los conflictos con los ajustes anteriores del sandbox
Los perfiles de permisos podrían no usarse si siguen activos los ajustes anteriores.
Comprueba los ajustes en conflicto y los controles del administrador
No mezcles los ajustes anteriores: default_permissions y [permissions] no están pensados para combinarse con los ajustes anteriores sandbox_mode o [sandbox_workspace_write]. Normalmente, si la configuración cargada contiene sandbox_mode o se inicia con --sandbox, se utiliza el mecanismo anterior. Los controles del administrador mediante allowed_permission_profiles constituyen una condición aparte.
Lo siguiente es una propuesta de configuración ilustrativa que añade denegación de archivos secretos y aprobación humana al ejemplo oficial limitado al espacio de trabajo. No sustituyas toda tu configuración existente por ella. Comprueba la compatibilidad de la versión, las restricciones de la organización y las rutas de ejecución necesarias; después, pruébala en un entorno ficticio.
Dónde configurarlo: ajustes del usuario y del proyecto
~/.codex/config.toml
.codex/config.toml
Difieren en su ámbito y en las condiciones de carga. La configuración del proyecto solo se carga en proyectos de confianza.
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = false¿Qué rutas cubre este ejemplo?
Se aplica al espacio de trabajo actual y a cada espacio adicional
.envDestinado a denegación.env.productionDestinado a denegaciónsecrets/ y su contenidoDestinado a denegaciónsubfolder/.envComprobar por separadoSecretos renombrados o copias en registrosComprobar por separado:root deniega la lectura. Hay excepciones como :minimal para la ejecución y los directorios temporales permitidos por el perfil heredado.
Hereda el acceso de edición de :workspace y deniega las rutas concretas indicadas arriba. Este ejemplo no detecta secretos incrustados en la salida.
Nombres de perfiles, varios espacios de trabajo y archivos temporales
project-private es el nombre elegido para este ejemplo. :workspace_roots se aplica al espacio de trabajo actual y a los adicionales, y afecta a las rutas indicadas directamente dentro de cada raíz. secrets afecta a un archivo o subárbol con ese nombre.
Esta configuración no impide todas las lecturas fuera del espacio de trabajo. También debes evitar copiar secretos al almacenamiento temporal.
Fuente: OpenAI: configuración, denegación y ámbito de los perfiles de permisos. Este artículo no informa de haber aplicado el ejemplo a un equipo real y comprobado el aislamiento.
4. Patrones .env y aspectos que hay que comprobar
Los nombres exactos son adecuados para secretos guardados en ubicaciones conocidas. Al usar patrones, recuerda que *.env y .env.* son distintos. No supongas que el ejemplo oficial **/*.env también deniega .env.production bajo las mismas condiciones.
| Regla de ejemplo | Destino previsto | Comprobar por separado |
|---|---|---|
.env | Un archivo con este nombre directamente en la raíz del espacio de trabajo | Subcarpetas y nombres de archivo con un sufijo añadido |
.env.production | El archivo de configuración de producción en la raíz | Configuraciones de producción con otros nombres o copias |
secrets | La ruta con este nombre en la raíz y su contenido | Copias en otros lugares, como registros o copias de seguridad |
**/*.env | Archivos terminados en .env en distintos niveles de directorio | Nombres con sufijo, profundidad del escaneo y cambios tras el inicio |
Comprueba la profundidad de directorios y los archivos añadidos después del inicio
En Linux, WSL y Windows nativo, los patrones de denegación que contienen ** sin restricciones pueden requerir una expansión acotada antes del inicio. La documentación oficial explica cómo establecer glob_scan_max_depth en al menos 1, o especificar la profundidad mediante patrones como *.env, */*.env y */*/*.env. Si usas directorios más profundos, verifica la cobertura hasta esa profundidad.
Algunos mecanismos de aplicación recopilan las rutas coincidentes antes del inicio. Comprueba si se deniegan los archivos creados posteriormente en el sistema operativo, la versión y el entorno de ejecución que utilizas. No consideres los patrones de denegación una regla universal que necesariamente protegerá todos los secretos futuros.
¿Qué regla prevalece si se superponen los permisos?
Una regla de ruta más específica puede sustituir a una más amplia. La denegación prevalece para una misma ruta, pero también puede crearse un permiso limitado dentro de una denegación amplia. Comprueba las capas de configuración adicionales y la herencia de los perfiles superiores.
Fuentes: OpenAI: denegar lecturas mediante rutas y patrones, orden de carga de la configuración. El archivo del proyecto .codex/config.toml solo se carga en proyectos de confianza. Distingue entre lo escrito en un archivo y lo activo en la sesión actual.
5. Qué bloquea y qué no bloquea desactivar la red de los comandos
Desactivar la red de los comandos restringe el uso de red de los programas ejecutados dentro del sandbox correspondiente. Sin embargo, las solicitudes de modelos y autenticación del cliente Codex son independientes de los controles de red de los comandos. Que el interruptor de red de los comandos esté desactivado no demuestra que el código leído por Codex no vaya a transmitirse como contexto del modelo.
Qué cubren las restricciones de red de los comandos
Actividad de red de los comandos, scripts y sus procesos secundarios.
Modelos y autenticación, búsqueda web, aplicaciones conectadas, MCP, navegador y Computer Use, y tareas en la nube.
Para permitir la red y restringir los destinos, debes activar el proxy de red además de definir reglas de dominio. Enumerar dominios permitidos en un perfil no activa por sí solo esas reglas.
| Red de los comandos | Proxy | Resultado |
|---|---|---|
| Desactivada | Cualquier ajuste | La red de los comandos no está permitida |
| Activada | Desactivado | Es posible conectarse directamente; no se aplican las reglas de dominio del perfil |
| Activada | Activado | El proxy aplica las reglas de dominio y deniega los destinos externos si no hay ninguno permitido |
Los secretos aún pueden enviarse a un destino permitido. Restringir dominios no equivale a inspeccionar el contenido enviado. Al aprobar una ejecución fuera del sandbox, no supongas que las reglas de denegación actuales siguen protegiéndote sin cambios. Comprueba qué amplía esa aprobación. OpenAI: permisos de red y requisitos del proxy.
6. Variables de entorno, sistemas operativos y Cloud
Los secretos no se limitan a los archivos. Si el shell contiene una clave de API, un proceso secundario puede usar su valor mediante variables de entorno heredadas aunque se deniegue el acceso al archivo. La herencia del entorno se gestiona por separado mediante shell_environment_policy.
Exclusión automática de variables: true frente a false
true | Valor predeterminadoNo aplica la exclusión automática de variables cuyos nombres contienen KEY, SECRET o TOKEN
falseAplica esa exclusión automática
ignore_default_excludes. Es independiente de las reglas de denegación de archivos y filtra por nombre de variable; no detecta todos los secretos.Esto no protege variables con otros nombres ni valores que los programas obtienen de otro lugar. set se aplica después de la exclusión y puede restaurar variables excluidas. OpenAI: herencia del entorno y precedencia.
Windows: comprueba también la implementación del sandbox
Los perfiles de permisos locales están documentados para macOS, Linux, WSL y Windows nativo, pero sus implementaciones difieren. En Windows, el sandbox con privilegios elevados se describe como la opción más robusta. El sandbox sin elevación ofrece un aislamiento de red más débil y no puede aplicar algunas políticas de aislamiento de lectura y escritura. Según la documentación, las políticas no compatibles provocan el rechazo de la ejecución. Un error no es motivo para cambiar a Full access. OpenAI: aplicación según el sistema operativo.
Cloud: no reutilices los ajustes locales sin cambios
Comprueba por separado los ajustes del entorno concreto de Codex Cloud. No supongas que los perfiles locales se aplican automáticamente a todo Cloud o al entorno en la nube de dot. No reutilices sin cambios la propuesta local de este artículo como configuración de la nube. Consulta Codex Remote, Cloud y requisitos de conexión del PC para conocer las diferencias entre ubicaciones de ejecución.
7. Verificar con archivos de prueba
«Le indiqué que no leyera», «guardé la configuración» y «la lectura se denegó realmente» son evidencias distintas. No necesitas probar haciendo que Codex lea secretos reales. Lo siguiente es un plan de verificación para el usuario o el administrador, no un informe de pruebas en este dispositivo.
- Registra el entorno: Anota la versión de Codex, el sistema operativo, la ubicación de ejecución y los permisos seleccionados. En la CLI, comprueba el ámbito del espacio de trabajo con
/statusy los permisos seleccionados con/permissions. - Comprueba los conflictos de configuración: Revisa los ajustes del usuario, los del proyecto de confianza, el perfil seleccionado, los parámetros de inicio y las restricciones del administrador. No pegues archivos de configuración completos ni valores secretos en la conversación para diagnosticarlos.
- Prepara archivos ficticios: En un espacio de trabajo separado sin secretos, crea archivos que deban permitirse y denegarse. Usa marcadores ficticios como contenido.
- Verifica tanto la autorización como la denegación: Mediante la misma vía de ejecución, confirma que los archivos permitidos se pueden leer y que las lecturas denegadas producen un error. Que Codex decida voluntariamente no leer un archivo no demuestra una denegación efectiva.
- Prueba diferentes ubicaciones: Comprueba archivos ficticios en la raíz, subcarpetas, nombres con sufijo y archivos creados tras el inicio. No apruebes una acción que eluda la denegación. Si una lectura inesperada tiene éxito, deja de usar ese entorno e investiga.
- Comprueba también las salidas: Comprueba si las pruebas o compilaciones imprimen secretos en registros o pasan la misma información a otras herramientas MCP, navegadores o aplicaciones conectadas.
La información disponible varía según la versión de la CLI y la interfaz; comprueba la salida real en lugar de depender de los nombres de comandos. La CLI oficial también ofrece comprobaciones específicas por sistema operativo mediante codex sandbox. Antes de considerarlas equivalentes, verifica que los ajustes probados con un comando auxiliar coincidan con los activos en tu sesión habitual de escritorio o IDE. OpenAI: pruebas del sandbox.
Añadir reglas de denegación después no revierte el contenido ya leído. Comprueba por separado el almacenamiento de conversaciones anteriores, registros y archivos, junto con los ajustes de entrenamiento. Una lectura correcta de un archivo no demuestra por sí sola que se haya divulgado a terceros. Evalúa por separado qué se leyó, dónde se envió y si las credenciales requieren atención.
Los usuarios también han solicitado formas de excluir archivos secretos en una incidencia pública de Codex. Esto muestra una preocupación real, pero no demuestra que la función siga sin estar disponible hoy. Las afirmaciones de este artículo sobre las especificaciones se basan en la documentación oficial actual de Permissions y no en publicaciones antiguas.
Preguntas frecuentes
¿El modo de solo lectura impide enviar .env?
El modo de solo lectura no ofrece esa garantía: restringe los cambios. Para impedir que el contenido legible de .env se convierta en contexto del modelo, comprueba por separado la denegación de lectura del archivo y un entorno de trabajo sin secretos.
¿Bastan .gitignore o AGENTS.md?
No sustituyen una denegación efectiva de lectura. Las reglas de exclusión de Git, las instrucciones de trabajo y los permisos impuestos por el sistema operativo son mecanismos distintos. Verifica con archivos ficticios que la denegación funciona en el entorno de ejecución actual.
¿Desactivar la red hace que Codex se ejecute íntegramente en el dispositivo?
No. Las restricciones de red de los comandos no desactivan la comunicación con modelos ni servicios de autenticación. Los ajustes del navegador, MCP, aplicaciones conectadas y nube también son independientes.
¿Este ejemplo protege completamente los secretos en Windows?
No se garantiza una protección completa. Debes comprobar la compatibilidad de la función beta, la implementación del sandbox del sistema operativo, las capas de configuración reales, las rutas y las herramientas utilizadas. El ejemplo de este artículo no se ha aplicado ni probado en un equipo real.
