Documentación de ChatGPT
Español
Contacto goolvyouyou@gmail.com

Permisos

Configura perfiles de permisos beta de Codex para el acceso al sistema de archivos y a la red

La configuración administrada allowed_permission_profiles es la excepción: hace que Codex utilice perfiles de permisos. Elimina configuraciones anteriores como sandbox_mode y [sandbox_workspace_write] antes de desplegar una lista de permitidos de perfiles administrada. Para un despliegue empresarial con versiones mixtas, puedes mantener el requisito administrado allowed_sandbox_modes como restricción temporal de compatibilidad hasta que todos los clientes ejecuten Codex 0.138.0 o una versión posterior.

Los perfiles de permisos te permiten aplicar límites de privilegios mínimos a los comandos locales que Codex ejecuta en tu nombre. Un perfil es una política con nombre que combina reglas del sistema de archivos, que definen qué pueden leer o escribir los comandos, con reglas de red, que definen a qué destinos pueden llegar los comandos.

Usa perfiles para conceder a Codex acceso suficiente para el chat actual sin otorgarle un acceso amplio a tu equipo o red. Por ejemplo, un perfil de solo lectura puede permitir que Codex inspeccione un proyecto sin editarlo, mientras que un perfil con capacidad de escritura puede limitar las ediciones a las raíces seleccionadas del espacio de trabajo.

Los perfiles de permisos locales son compatibles con macOS, Linux, WSL y Windows nativo. Consulta Ámbito y aplicación para conocer los detalles y las salvedades específicos de cada plataforma.

Para conocer la configuración de red actual de Codex Cloud, consulta Conectarse a servicios. Para Codex Cloud (Legacy), consulta Acceso a internet.

Definir y seleccionar un perfil

Codex incluye tres perfiles de permisos integrados:

  • :read-only mantiene la ejecución local de comandos en modo de solo lectura.
  • :workspace permite escrituras dentro de las raíces activas del espacio de trabajo y los directorios temporales del sistema.
  • :danger-full-access elimina las restricciones del entorno aislado local y solo debe utilizarse cuando ese acceso amplio sea intencional.

Crea un perfil con nombre en [permissions.<name>] y, a continuación, establece la clave de nivel superior default_permissions en el nombre de ese perfil o en uno de los perfiles integrados anteriores. En este ejemplo, project-edit es un nombre de perfil definido por el usuario, no un valor integrado.

Los administradores empresariales pueden definir perfiles y restringir cuáles pueden seleccionar los usuarios mediante la configuración administrada requirements.toml. Una vez que allowed_permission_profiles está presente, los perfiles omitidos se deniegan, incluidos los perfiles integrados omitidos y los que se añadan en futuras versiones de Codex. Consulta Controlar los perfiles de permisos disponibles para ver la configuración administrada recomendada.

Los perfiles personalizados utilizan dos conceptos relacionados:

  • [permissions.<name>.workspace_roots] añade directorios concretos que deben contar como raíces del espacio de trabajo para ese perfil.
  • [permissions.<name>.filesystem.":workspace_roots"] define las reglas del sistema de archivos que Codex aplica dentro de cada raíz efectiva del espacio de trabajo: las raíces del espacio de trabajo en tiempo de ejecución de la sesión actual más las raíces definidas anteriormente por el perfil.

Los perfiles también utilizan el modelo normal de capas de configuración. Las capas con mayor precedencia pueden añadir o sustituir entradas con el mismo nombre de perfil sin volver a declarar todo el perfil.

Por ejemplo, una configuración a nivel de organización y otra a nivel de usuario pueden ampliar el mismo perfil de forma independiente:

# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true
# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = true

Cuando server está activo, ambas raíces del espacio de trabajo participan en el perfil efectivo.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"objects.githubusercontent.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

Este perfil:

  • Lee las rutas mínimas de tiempo de ejecución que necesitan las herramientas habituales para desarrolladores.
  • Aplica las mismas reglas de raíz del espacio de trabajo a la sesión actual y a las raíces definidas por el perfil.
  • Mantiene en modo de solo lectura la configuración relacionada con el IDE, como .devcontainer/, en cada raíz.
  • Deniega los archivos de entorno coincidentes mediante una regla glob.
  • Permite el acceso a la red únicamente mediante la política de dominios configurada.

Dentro de un perfil activo, las reglas de denegación más específicas siguen vigentes incluso cuando una ruta más amplia se puede leer o escribir. Por ejemplo, un perfil puede hacer que las raíces del espacio de trabajo sean escribibles y, al mismo tiempo, establecer una ruta .env coincidente en deny.

Ampliar un perfil

Usa extends cuando un perfil sea casi igual a uno integrado o a otro perfil con nombre. Es preferible extender un perfil integrado a empezar desde cero para conservar las protecciones básicas. Extender :workspace, por ejemplo, mantiene las rutas .git, .agents, .codex y .aws de la raíz del espacio de trabajo como de solo lectura a menos que sobrescribas explícitamente esas reglas. Define el perfil base una vez y luego añade o sobrescribe solo las reglas que sean diferentes.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Este perfil parte de :workspace, mantiene denegados los archivos que coinciden con .env y permite solicitudes a api.openai.com. Un perfil puede ampliar :read-only, :workspace u otro perfil con nombre. No puede ampliar :danger-full-access; Codex también rechaza perfiles principales desconocidos y ciclos de herencia.

Especificación de configuración

Entrada Tipo / valores Valor predeterminado Detalles
default_permissions Nombre de perfil como cadena Ninguno Indica el nombre del perfil de permisos que Codex aplica de forma predeterminada. Debe coincidir con un perfil definido en [permissions] o con uno integrado, como :workspace. Establécelo explícitamente para obtener un comportamiento predecible; los requisitos administrados solo pueden omitirlo cuando tanto :workspace como :read-only estén permitidos explícitamente. Codex usa la configuración anterior del entorno aislado, a menos que el ajuste administrado allowed_permission_profiles le indique que use perfiles de permisos en esta configuración.
[permissions.<name>] Tabla Ninguno Define un perfil con nombre. default_permissions selecciona un perfil como predeterminado; otros ajustes de los perfiles de permisos también usan el nombre del perfil.
permissions.<name>.description Cadena Ninguno Proporciona una descripción del perfil legible para las personas. Un perfil no hereda la descripción de su perfil padre mediante extends.
permissions.<name>.extends Nombre de perfil como cadena Ninguno Crea este perfil a partir de otro perfil con nombre o del perfil integrado :read-only o :workspace. Codex rechaza :danger-full-access, los perfiles padre desconocidos y los ciclos de herencia.
[permissions.<name>.workspace_roots] Tabla Ninguno Añade raíces del espacio de trabajo definidas en el perfil que reciben las reglas del sistema de archivos de :workspace_roots junto con las raíces del espacio de trabajo de la sesión actual en tiempo de ejecución.
permissions.<name>.workspace_roots."<path>" Booleano false Añade la ruta al conjunto de raíces del espacio de trabajo del perfil cuando el valor es true. Las entradas establecidas en false permanecen inactivas.
[permissions.<name>.filesystem] Tabla Ninguno Asocia rutas del sistema de archivos con valores de acceso o mapas de subrutas con un alcance definido. Si las tablas del sistema de archivos faltan o están vacías, el acceso al sistema de archivos permanece restringido y se emite una advertencia al iniciar.
permissions.<name>.filesystem.glob_scan_max_depth Número Ninguno Limita la expansión de patrones glob de denegación de lectura en Linux, WSL y Windows nativo cuando Codex captura las coincidencias antes de iniciar el entorno aislado. Los valores más altos pueden aumentar el trabajo de análisis al iniciar. Usa un valor de al menos 1 cuando un patrón ** sin límites necesite una expansión previa acotada.
[permissions.<name>.filesystem]."<path>" read, write o deny Ninguno Concede acceso directo a una ruta compatible. deny deniega el acceso y prevalece sobre las entradas write o read con el mismo nivel de especificidad. Codex rechaza las reglas de escritura directa que el entorno de ejecución activo no pueda aplicar.
[permissions.<name>.filesystem."<path>"]."<subpath>" read, write o deny Ninguno Concede acceso a un descendiente de <path>. Usa . para la ruta base. Las demás subrutas deben ser descendientes relativas y no pueden contener componentes . ni ...
[permissions.<name>.network] Tabla Ninguno Configura el acceso a la red de los comandos y la política que aplica un proxy de red activo. Habilita features.network_proxy, a menos que los requisitos de red administrados por el administrador inicien el proxy.
permissions.<name>.network.enabled Booleano false Habilita el acceso a la red para los comandos del perfil. No inicia el proxy de red; sin un proxy activo, los comandos pueden conectarse directamente sin restricciones de dominio.
[permissions.<name>.network.domains] Tabla Ninguno Asocia patrones de host con allow o deny. Las reglas solo se aplican cuando el proxy de red está activo. El proxy activo bloquea las solicitudes a dominios si no hay entradas allow, y las entradas de denegación prevalecen sobre las de autorización.
permissions.<name>.network.domains."<pattern>" allow o deny Ninguno Admite hosts exactos, *.example.com para subdominios, **.example.com para el dominio raíz y sus subdominios, y * como comodín global solo para autorización. Los patrones de host se normalizan eliminando los espacios de los extremos, convirtiéndolos a minúsculas y quitando el punto final y los números de puerto o corchetes.
[permissions.<name>.network.unix_sockets] Tabla Ninguno Define las excepciones a la lista de sockets Unix permitidos. Úsalo solo para integraciones locales, como Docker.
permissions.<name>.network.unix_sockets."<path>" allow o deny Ninguno Añade una ruta absoluta de socket Unix a la lista efectiva de permitidos con allow, o la rechaza con deny. Las entradas denegadas se omiten de la lista efectiva de permitidos.
permissions.<name>.network.proxy_url Cadena de URL http://127.0.0.1:3128 Punto de escucha del proxy HTTP utilizado para HTTP_PROXY, HTTPS_PROXY, las variables de proxy de WebSocket y las variables de entorno de proxy de herramientas relacionadas.
permissions.<name>.network.enable_socks5 Booleano true Habilita el punto de escucha SOCKS5 utilizado para ALL_PROXY y las variables de proxy de FTP.
permissions.<name>.network.socks_url Cadena de URL http://127.0.0.1:8081 Dirección del punto de escucha SOCKS5.
permissions.<name>.network.enable_socks5_udp Booleano true Habilita la compatibilidad con UDP de SOCKS5 cuando el punto de escucha SOCKS5 está habilitado.
permissions.<name>.network.allow_upstream_proxy Booleano true Permite que el proxy de red del entorno aislado respete los ajustes del proxy ascendente HTTP(S)_PROXY y ALL_PROXY para las solicitudes salientes.
permissions.<name>.network.allow_local_binding Booleano false Deshabilita la protección de red local/privada cuando el valor es true. Cuando el valor es false, los literales locales exactos, como localhost o 127.0.0.1, deben incluirse explícitamente en la lista de permitidos, y los nombres de host que se resuelvan en IP locales o privadas seguirán bloqueados.
permissions.<name>.network.dangerously_allow_non_loopback_proxy Booleano false Permite que los puntos de escucha del proxy se vinculen a direcciones que no sean de bucle local. Déjalo sin configurar para el desarrollo local habitual.
permissions.<name>.network.dangerously_allow_all_unix_sockets Booleano false Omite la lista de sockets Unix permitidos donde se admita el uso de un proxy para sockets Unix. Es una vía de escape local de amplio alcance.

Permisos del sistema de archivos

Las entradas del sistema de archivos utilizan read, write o deny:

Acceso Significado
read Permite que los comandos lean archivos y enumeren directorios bajo la ruta. Los comandos no pueden crear, modificar, cambiar el nombre ni eliminar archivos en ella.
write Permite que los comandos lean y modifiquen archivos bajo la ruta, lo que incluye crear, cambiar el nombre y eliminar archivos cuando el sistema operativo lo permita.
deny Deniega tanto las lecturas como las escrituras bajo la ruta. Úsalo para excluir una subruta denegada de una concesión read o write más amplia.

Las entradas más específicas prevalecen sobre las más amplias. Cuando dos entradas apuntan a la misma ruta, deny tiene precedencia sobre write, y write tiene precedencia sobre read.

Esta precedencia permite que un perfil describa primero un área de trabajo amplia y después excluya archivos o directorios que deben permanecer ilegibles:

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

En este ejemplo, la raíz del espacio de trabajo sigue siendo escribible, .devcontainer/ sigue siendo legible sin volverse escribible, y los archivos de entorno coincidentes permanecen inaccesibles para los comandos del entorno aislado.

Una ruta más específica también puede volver a abrir un subárbol más estrecho dentro de una denegación más amplia:

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

Formas de ruta compatibles:

Ruta Significado Subrutas con ámbito
:root La raíz del sistema de archivos Solo .
:minimal Rutas de plataforma y tiempo de ejecución que necesitan las herramientas habituales Solo .
:workspace_roots Las raíces del espacio de trabajo de la sesión actual más las raíces del espacio de trabajo habilitadas y definidas por el perfil Sí
:tmpdir La ubicación $TMPDIR, cuando haya una disponible Solo .
:slash_tmp La carpeta /tmp, si existe Solo .
/absolute/path Una ruta absoluta de la plataforma, como /path en macOS/Linux/WSL o C:\path en Windows nativo Sí
~/path Una ruta bajo el directorio de inicio del usuario actual Sí

En Windows nativo, las rutas relativas al directorio de inicio también pueden utilizar barras invertidas, como ~\work.

Utiliza :root solo cuando un perfil necesite intencionalmente una cobertura de lectura amplia:

[permissions.audit.filesystem]
":root" = "read"

Utiliza entradas anidadas en :workspace_roots para limitar el acceso a subrutas relativas a la raíz del espacio de trabajo:

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"          # each workspace root
"docs" = "read"        # each workspace-root docs directory
"generated" = "deny"   # each workspace-root generated directory

Las subrutas anidadas deben permanecer dentro de su raíz del espacio de trabajo. Se rechaza el recorrido al directorio principal, como ../other-repo.

Denegar lecturas con rutas exactas o globs

Utiliza deny para archivos o subárboles que Codex no deba leer, incluso cuando una regla de perfil más amplia conceda acceso en las proximidades. Las rutas exactas funcionan bien para ubicaciones estables como ~/.ssh. Los patrones glob funcionan mejor cuando un perfil necesita abarcar una familia de archivos confidenciales cuyas ubicaciones exactas varían entre repositorios.

Cuando un glob se encuentra bajo :workspace_roots, Codex lo interpreta con relación a cada raíz efectiva del espacio de trabajo. Por ejemplo:

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Esta regla deniega las lecturas de los archivos .env coincidentes que se encuentren bajo cada raíz del espacio de trabajo definida por el perfil o en tiempo de ejecución. Úsala cuando quieras conservar las escrituras normales en el espacio de trabajo y, al mismo tiempo, mantener ilegibles los archivos de entorno, secretos generados u otros archivos similares que contengan credenciales.

En Linux, WSL y Windows nativo con MXC o elevated, las coincidencias de los patrones glob de denegación de lectura se enumeran al iniciar cada proceso aislado. Los archivos coincidentes creados después no se añaden a la lista de denegación de ese proceso y siguen siendo legibles si sus demás permisos permiten el acceso. Por ejemplo, un shell, script, monitor de cambios o servidor de desarrollo de larga duración puede leer un archivo .env coincidente creado después de su inicio.

Esta instantánea dura toda la vida del proceso aislado, no toda la sesión de Codex. Al iniciar un nuevo proceso aislado a través de Codex, se vuelven a enumerar las coincidencias; seguir usando un proceso que ya está en ejecución no actualiza su lista de denegación. No confíes en un patrón glob para bloquear archivos recién creados en ese proceso en ejecución. Consulta Compatibilidad con MXC en Windows para conocer las limitaciones específicas de Windows.

Los patrones glob deny son compatibles como reglas de denegación de lectura. Los globs read o write son menos portables en los entornos aislados de Linux, WSL y Windows nativo, por lo que, cuando sea posible, es preferible utilizar rutas exactas o reglas de subárbol, como "docs/**" = "read".

En Linux, WSL y Windows nativo, un patrón de denegación de lectura ** sin límites puede necesitar una expansión previa acotada antes de que se inicie el entorno aislado. Establece glob_scan_max_depth cuando utilices un patrón sin límites como "**/*.env" = "deny":

[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

glob_scan_max_depth debe ser como mínimo 1. Los valores más altos analizan a mayor profundidad antes de iniciar el entorno aislado, lo que puede aumentar el trabajo de inicio en Linux, WSL y Windows nativo. Si prefieres no usar una expansión acotada, enumera profundidades explícitas como *.env, */*.env y */*/*.env.

Añade al perfil raíces reutilizables del espacio de trabajo cuando deban aplicarse las mismas reglas a más elementos que la raíz de la sesión actual:

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

Cuando este perfil está activo, Codex aplica las reglas :workspace_roots a las raíces del espacio de trabajo en tiempo de ejecución de la sesión actual y a cada raíz del espacio de trabajo habilitada y definida por el perfil.

En Windows nativo, se admiten como rutas absolutas las rutas con letra de unidad, como D:\work, y las rutas UNC, como \\server\share.

Permisos de red

El acceso a la red y el filtrado de red son configuraciones independientes. Establece permissions.<name>.network.enabled = true para permitir que los comandos accedan a la red y habilita features.network_proxy para aplicar las reglas de dominios del perfil:

[features]
network_proxy = true

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"example.com" = "allow"      # exact host
"*.example.com" = "allow"    # subdomains only
"**.example.com" = "allow"   # apex and subdomains
"ads.example.com" = "deny"   # deny wins over allow

El comportamiento resultante depende de ambas configuraciones:

  • Red desactivada: los comandos no pueden acceder a la red, independientemente de la función de proxy.
  • Red activada, proxy desactivado: los comandos tienen acceso directo y sin restricciones a la red. Las reglas de dominios del perfil de permisos no se aplican.
  • Red activada, proxy activado: los comandos utilizan el proxy, que aplica las reglas de dominios del perfil. Si el proxy activo no tiene dominios permitidos, bloquea los destinos externos.

Añadir [permissions.<name>.network.domains] o establecer permissions.<name>.network.enabled = true no habilita features.network_proxy. Como alternativa, los administradores pueden habilitar el proxy con [experimental_network] en requirements.toml. Consulta Configuración administrada.

Cuando está activo, el proxy del entorno aislado de red se enlaza de forma predeterminada a agentes de escucha locales:

[permissions.project-edit.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true

Mantén estos ajustes de los agentes de escucha en sus valores predeterminados, salvo que estés integrando un entorno de ejecución específico. Las claves de red dangerously_* son vías de escape para entornos especializados y no deben utilizarse para el desarrollo local habitual.

Redes locales y privadas

Cuando el proxy de red está activo, Codex aplica de forma predeterminada una protección de red local/privada como defensa contra la revinculación de DNS y el acceso accidental a servicios locales. Para permitir intencionalmente un destino local literal, incluye en la lista de permitidos el host o literal de IP exacto:

[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

Establece allow_local_binding = true solo cuando el perfil deba llegar a nombres de host incluidos en la lista de permitidos que se resuelvan en direcciones locales o privadas:

[permissions.project-edit.network]
enabled = true
allow_local_binding = true

[permissions.project-edit.network.domains]
"localhost" = "allow"

Sockets Unix

El uso de proxy para sockets Unix es una vía de escape local para herramientas como Docker. Utilízalo con moderación:

[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"

Utiliza deny para rechazar una ruta de socket, incluida una entrada de permiso heredada. Las rutas de socket denegadas se omiten de la lista de permitidos efectiva.

Cuando los sockets Unix estén habilitados, mantén los agentes de escucha del proxy enlazados a direcciones de bucle local.

Migrar desde la configuración anterior del entorno aislado

Los perfiles de permisos sustituyen la combinación anterior de sandbox_mode y sandbox_workspace_write cuando quieras que un único perfil reutilizable describa tanto el comportamiento del sistema de archivos como el de la red. Utiliza un sistema u otro en una sesión, pero no ambos.

Puntos de partida recomendados:

  • Para un flujo de trabajo de solo lectura, utiliza el perfil integrado :read-only o define un perfil personalizado con acceso de lectura solo donde sea necesario.
  • Para editar el espacio de trabajo, utiliza el perfil integrado :workspace o define un perfil personalizado que escriba mediante :workspace_roots y añada únicamente las rutas adicionales temporales o de caché que necesite el flujo de trabajo.
  • Para una ejecución local sin restricciones, utiliza :danger-full-access solo cuando quieras intencionalmente el modelo de acceso local más amplio.

Los perfiles describen la postura local predeterminada de una sesión. Los requisitos administrados por la organización aún pueden añadir restricciones que la configuración del usuario no debe ampliar. Consulta Configuración administrada para conocer las restricciones del sistema de archivos y la red aplicadas por los administradores.

Ámbito y aplicación

Acceso al equipo local con Work Cloud y política del entorno

Revisa la política de cada entorno en el que se utilice el acceso al equipo local con Work Cloud:

  • Requisitos empresariales: Para Work con acceso local y dots, la política Global compatible rige el orquestador compartido en la nube cuando la política administrada está habilitada; los requisitos de ejecución local aplicables rigen el equipo conectado.
  • Ejecución en la nube: Los contenedores de Work en la nube usan las políticas existentes de Work Cloud.
  • Orden de las políticas locales: MDM y los requisitos heredados de dispositivos administrados tienen mayor prioridad que Agent Security. El archivo de requisitos del sistema del dispositivo tiene menor prioridad que Agent Security.
  • Prioridad de las políticas: Una política de mayor prioridad prevalece aunque una de menor prioridad sea más específica. Dentro de una política, las excepciones de entorno específicas de un sistema operativo tienen prioridad sobre las excepciones de entorno para todos los sistemas operativos, seguidas de Global.

Algunos requisitos tienen reglas de combinación específicas de cada campo. Consulta Configuración administrada y la Referencia de configuración para conocer los campos compatibles y los límites de ejecución. No des por hecho que Work Cloud admite los perfiles de permisos de Codex que se muestran aquí.

Los perfiles de permisos definen los límites para la ejecución local de comandos en el entorno aislado. Utilízalos junto con las políticas de aprobación y los controles independientes para búsquedas web, conectores, MCP servers, el navegador integrado, Computer Use y Codex cloud.

Qué controlan los perfiles

  • Ejecución local de comandos: los perfiles de permisos rigen los comandos del entorno aislado que se ejecutan en tu equipo. Los conectores, los MCP servers, las superficies del navegador o de Computer Use, la configuración de entornos de Codex cloud y los escalamientos aprobados utilizan sus propios controles.
  • Escrituras en el sistema de archivos: un perfil con capacidad de escritura puede crear cambios persistentes. Considera confidenciales las escrituras en scripts, pasos de compilación, enlaces del gestor de paquetes, archivos de inicio del shell y directorios compartidos, porque otras herramientas o usuarios pueden ejecutar esos archivos posteriormente fuera del contexto del entorno aislado original.
  • Destinos salientes: las reglas de dominios de red limitan los destinos a los que puede dirigirse el tráfico de los comandos en el entorno aislado solo mientras el proxy de red está activo. No determinan si un destino permitido es de confianza, y las reglas de permiso con comodines siguen siendo amplias.
  • Servicios locales: un proxy de red activo bloquea de forma predeterminada los destinos de redes locales y privadas. Incluir localhost, direcciones IP privadas o sockets Unix en la lista de permitidos, o establecer allow_local_binding = true, abre explícitamente el acceso a servicios locales.

Qué no controla el proxy de red

El proxy de red solo filtra el tráfico procedente de comandos locales que se ejecutan dentro del entorno aislado. No aplica la lista de dominios permitidos del perfil a:

  • Búsqueda web: La herramienta de búsqueda alojada usa sus propios ajustes de acceso. Usa web_search y, para clientes administrados, allowed_web_search_modes para controlarla. tools.web_search.allowed_domains filtra los resultados de búsqueda, no el acceso a la red de los comandos.
  • Aplicaciones y conectores: Las herramientas basadas en conectores usan sus propias conexiones del lado del servicio, permisos del espacio de trabajo y ajustes de aplicaciones o herramientas.
  • MCP servers: Los MCP servers locales y remotos usan su propio proceso o transporte. Contrólalos mediante la configuración de mcp_servers y las listas administradas de servidores permitidos.
  • Navegador y Computer Use: La navegación y las acciones de uso del equipo usan sus propios controles de funciones y aprobación.
  • Tráfico de servicios de Codex: Las solicitudes de modelos, autenticación y otros servicios del cliente usan los ajustes independientes de HTTP y del proxy del sistema del cliente.
  • Codex Cloud: Estas tareas usan la configuración de red de su propio entorno. Codex Cloud (Legacy) tiene una configuración de acceso a internet independiente.

Para limitar estas superficies, configura cada capacidad directamente. Una lista de comandos con acceso a la red no es una política de red global para todas las acciones que Codex puede realizar.

Cómo funciona la aplicación

  • En macOS, Codex usa perfiles de entorno aislado de Seatbelt. Si el entorno aislado de la plataforma no puede aplicar la directiva seleccionada, Codex se niega a ejecutar el comando en lugar de ejecutarlo sin aislamiento de forma silenciosa.
  • En Linux y WSL, Codex usa bubblewrap y seccomp para aplicar restricciones al sistema de archivos. La opción heredada Landlock no puede aislar los sockets Unix de app-server y se rechaza para las políticas que restringen el sistema de archivos. Desactiva features.use_legacy_landlock al actualizar. Los hosts que bloquean las operaciones necesarias de bubblewrap no pueden ejecutar estas políticas.
  • En Windows, MXC usa aislamiento de procesos para los permisos del sistema de archivos y de red. Revisa la compatibilidad con MXC antes de activarlo. La alternativa heredada elevated usa usuarios dedicados de entorno aislado con menos privilegios, límites de permisos del sistema de archivos y reglas de firewall. unelevated es una alternativa heredada con un aislamiento de red más débil y no puede aplicar todas las excepciones que separan lectura y escritura, por lo que se rechazan las directivas no compatibles. Usa WSL cuando necesites el modelo de entorno aislado de Linux.

Orientación operativa

Elige el perfil más limitado que permita completar la tarea, especialmente cuando concedas acceso de escritura o a la red saliente. Mantén la política de aprobación, la gestión de secretos y las reglas de permiso alineadas con ese nivel de acceso.

Perfiles habituales

Solo lectura con lista de redes permitidas

default_permissions = "readonly-net"

[features]
network_proxy = true

[permissions.readonly-net.filesystem]
":minimal" = "read"

[permissions.readonly-net.filesystem.":workspace_roots"]
"." = "read"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"api.openai.com" = "allow"

Acceso a archivos limitado al espacio de trabajo

Este es un ejemplo de un perfil de permisos que hará que Codex pueda escribir en las carpetas de tu espacio de trabajo y, al mismo tiempo, denegará las lecturas del resto del sistema de archivos (con excepciones limitadas, según lo determinado por :minimal).

default_permissions = "workspace-only"

[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# paths such as .git/, .agents/, .codex/, and .aws/ within a workspace root
# are read-only while the rest of the folder is writable.
extends = ":workspace"

[permissions.workspace-only.filesystem]
# By default, deny read access to all files on disk.
":root" = "deny"

# Though in practice, a software agent needs to be able to read folders that
# contain common tools, such as `/usr/bin`, to get work done, so grant access
# to a "minimal" set of files and folders, as determined by Codex.
":minimal" = "read"

# By extending the :workspace profile, :tmpdir and :slash_tmp are "write" by
# default, though you can deny access to them altogether, if desired.
":tmpdir" = "deny"
":slash_tmp" = "deny"

Escritura en el espacio de trabajo sin red

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"

[permissions.project-edit.network]
enabled = false

Escritura en el espacio de trabajo con acceso a la web pública

default_permissions = "workspace-net"

[features]
network_proxy = true

[permissions.workspace-net.filesystem]
":minimal" = "read"

[permissions.workspace-net.filesystem.":workspace_roots"]
"." = "write"

[permissions.workspace-net.network]
enabled = true

[permissions.workspace-net.network.domains]
"*" = "allow"

Utiliza la regla de permiso global "*" solo cuando quieras permitir el acceso a la red pública. Las reglas de denegación pueden limitar una lista de permitidos amplia.