Permisos
Configura los perfiles de permisos beta de Codex para el acceso al sistema de archivos y a la red
Los perfiles de permisos 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 acceder los comandos.
Usa perfiles para proporcionar a Codex el acceso suficiente para el chat actual sin concederle 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 permisos de escritura puede limitar las modificaciones 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 obtener información y advertencias específicas de cada plataforma.
Para conocer la configuración de red de Codex cloud, consulta Acceso a Internet.
Definir y seleccionar un perfil
Codex incluye tres perfiles de permisos integrados:
:read-onlymantiene la ejecución de comandos locales en modo de solo lectura.:workspacepermite escribir dentro de las raíces activas del espacio de trabajo y los directorios temporales del sistema.:danger-full-accesselimina las restricciones del aislamiento local y debe utilizarse solo cuando se pretenda conceder ese acceso amplio.
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 el nombre de un 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, se deniegan los perfiles omitidos,
incluidos los perfiles integrados omitidos y los que se agreguen en versiones futuras de Codex. Consulta
Controlar los perfiles de permisos disponibles
para conocer la configuración administrada recomendada.
Los perfiles personalizados utilizan dos conceptos relacionados:
[permissions.<name>.workspace_roots]agrega directorios concretos que deben considerarse 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 agregar o reemplazar entradas bajo el mismo nombre de perfil sin volver a especificar el perfil completo.
Por ejemplo, una configuración de nivel organizativo y una configuración de 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" = trueCuando server está activo, ambas raíces del espacio de trabajo forman parte del perfil
efectivo.
default_permissions = "project-edit"
[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 las opciones próximas al IDE, como
.devcontainer/, en cada raíz. - Deniega los archivos de entorno coincidentes mediante una regla de patrón 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 aunque una ruta más general
se pueda leer o escribir. Por ejemplo, un perfil puede permitir la escritura en las raíces del espacio de trabajo
y, al mismo tiempo, establecer una ruta .env coincidente en deny.
Ampliar un perfil
Usa extends cuando un perfil sea casi igual que uno integrado u otro perfil con
nombre. Es preferible ampliar un perfil integrado en lugar de empezar desde cero para
conservar las protecciones de referencia. Por ejemplo, al ampliar :workspace se mantiene
en modo de solo lectura el directorio .codex de la raíz del espacio de trabajo, a menos que lo
sobrescribas explícitamente. Establece el perfil principal una vez y, después, agrega o sobrescribe solo las reglas que
sean diferentes.
default_permissions = "project-edit"
[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 coincidan con .env y
permite las 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 de cadena | Ninguno | Especifica el perfil de permisos que Codex aplica de forma predeterminada. Debe coincidir con un perfil definido en [permissions] o con uno integrado, como :workspace. Defínalo 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 valor 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; otras opciones de configuración de 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 principal mediante extends. |
permissions.<name>.extends |
Nombre de perfil de cadena | Ninguno | Inicia este perfil a partir de otro perfil con nombre o del perfil integrado :read-only o :workspace. Codex rechaza :danger-full-access, los perfiles principales desconocidos y los ciclos de herencia. |
[permissions.<name>.workspace_roots] |
Tabla | Ninguno | Agrega raíces del espacio de trabajo definidas por el perfil que reciben reglas del sistema de archivos :workspace_roots junto con las raíces del espacio de trabajo en tiempo de ejecución de la sesión actual. |
permissions.<name>.workspace_roots."<path>" |
Booleano | false |
Agrega la ruta al conjunto de raíces del espacio de trabajo del perfil cuando es true. Las entradas establecidas en false permanecen inactivas. |
[permissions.<name>.filesystem] |
Tabla | Ninguno | Asigna rutas del sistema de archivos a valores de acceso o a mapas de subrutas con ámbito. 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 crea una instantánea de las coincidencias antes de iniciar el entorno aislado. Los valores mayores pueden aumentar el trabajo de análisis durante el inicio. Use 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 puede aplicar. |
[permissions.<name>.filesystem."<path>"]."<subpath>" |
read, write o deny |
Ninguno | Concede acceso a un descendiente de <path>. Use . para la ruta base. Las demás subrutas deben ser descendientes relativos y no pueden contener componentes . ni ... |
[permissions.<name>.network] |
Tabla | Ninguno | Configura el proxy del entorno aislado de red y la política de red del entorno aislado para el perfil. |
permissions.<name>.network.enabled |
Booleano | false |
Habilita el acceso a la red para los comandos ejecutados en el entorno aislado del perfil. Esto cambia la política de red del entorno aislado; no inicia por sí solo el proxy de red. |
[permissions.<name>.network.domains] |
Tabla | Ninguno | Asigna patrones de host a allow o deny. Si no hay entradas allow, las solicitudes de dominio se bloquean. Las entradas de denegación prevalecen sobre las entradas de permiso. |
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 de permiso. Los patrones de host se normalizan eliminando los espacios de los extremos, convirtiéndolos a minúsculas, quitando el punto final y eliminando puertos simples o corchetes. |
[permissions.<name>.network.unix_sockets] |
Tabla | Ninguno | Asigna excepciones a la lista de permitidos de sockets Unix. Úselo solo para integraciones locales como Docker. |
permissions.<name>.network.unix_sockets."<path>" |
allow o deny |
Ninguno | Agrega una ruta absoluta de socket Unix a la lista de permitidos efectiva con allow o la rechaza con deny. Las entradas denegadas se omiten de la lista de permitidos efectiva. |
permissions.<name>.network.proxy_url |
Cadena de URL | http://127.0.0.1:3128 |
Agente de escucha del proxy HTTP usado para HTTP_PROXY, HTTPS_PROXY, las variables del proxy websocket y las variables de entorno relacionadas con el proxy de herramientas. |
permissions.<name>.network.enable_socks5 |
Booleano | true |
Habilita el agente de escucha SOCKS5 usado para ALL_PROXY y las variables del proxy FTP. |
permissions.<name>.network.socks_url |
Cadena de URL | http://127.0.0.1:8081 |
Dirección del agente de escucha SOCKS5. |
permissions.<name>.network.enable_socks5_udp |
Booleano | true |
Habilita la compatibilidad con UDP de SOCKS5 cuando el agente de escucha SOCKS5 está habilitado. |
permissions.<name>.network.allow_upstream_proxy |
Booleano | true |
Permite que el proxy del entorno aislado de red respete las opciones de configuración ascendentes HTTP(S)_PROXY y ALL_PROXY para las solicitudes salientes. |
permissions.<name>.network.allow_local_binding |
Booleano | false |
Deshabilita la protección de la red local/privada cuando es true. Cuando 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 resuelven en direcciones IP locales o privadas permanecen bloqueados. |
permissions.<name>.network.dangerously_allow_non_loopback_proxy |
Booleano | false |
Permite que los agentes de escucha del proxy se vinculen a direcciones que no sean de bucle invertido. Déjelo sin definir para el desarrollo local habitual. |
permissions.<name>.network.dangerously_allow_all_unix_sockets |
Booleano | false |
Omite la lista de permitidos de sockets Unix cuando se admite el uso de proxy para sockets Unix. Esta es una vía de escape local de amplio alcance. |
Permisos del sistema de archivos
Las entradas del sistema de archivos usan 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, renombrar ni eliminar archivos allí. |
write |
Permite que los comandos lean y modifiquen archivos bajo la ruta, lo que incluye crear, renombrar y eliminar archivos cuando el SO lo permite. |
deny |
Deniega tanto la lectura como la escritura bajo la ruta. Úselo 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 generales. Cuando dos entradas apuntan a la
misma ruta, deny tiene prioridad sobre write, y write tiene prioridad
sobre read.
Esta precedencia permite que un perfil describa primero un área de trabajo amplia y luego excluya los archivos o directorios que deban 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 en el entorno aislado.
Una ruta más específica también puede volver a abrir un subárbol más reducido 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 alcance limitado |
|---|---|---|
:root |
La raíz del sistema de archivos | Solo . |
:minimal |
Rutas de la plataforma y del entorno de ejecución necesarias para herramientas comunes | Solo . |
:workspace_roots |
Las raíces del espacio de trabajo de la sesión actual más cualquier raíz del espacio de trabajo habilitada y definida por el perfil | Sí |
:tmpdir |
La ubicación de $TMPDIR, cuando hay 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 principal del usuario actual | Sí |
En Windows nativo, las rutas relativas al directorio principal también pueden usar barras inversas, como
~\work.
Use :root solo cuando un perfil necesite intencionadamente una amplia cobertura de lectura:
[permissions.audit.filesystem]
":root" = "read"Use entradas anidadas bajo :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 directoryLas subrutas anidadas deben permanecer dentro de su raíz del espacio de trabajo. Se rechaza el recorrido al directorio superior, como
../other-repo.
Denegar lecturas mediante rutas exactas o patrones glob
Use 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 patrón glob se encuentra bajo :workspace_roots, Codex lo interpreta en relación con cada
raíz efectiva del espacio de trabajo. Por ejemplo:
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"Esta regla deniega la lectura de los archivos .env coincidentes que se encuentren bajo cada raíz del espacio de trabajo
del entorno de ejecución o definida por el perfil. Úsela cuando quiera conservar las escrituras normales
en el espacio de trabajo y, a la vez, mantener ilegibles los archivos de entorno, los secretos generados u otros
archivos similares que contengan credenciales.
Los patrones glob deny son compatibles como reglas para denegar la lectura. Los patrones glob read o write
son menos portátiles en el aislamiento de Linux, WSL y Windows nativo, por lo que debe preferir rutas
exactas o reglas de subárbol como "docs/**" = "read" cuando sea posible.
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. Establezca glob_scan_max_depth cuando
use 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 al menos 1. Los valores más altos exploran a mayor profundidad antes
del inicio del entorno aislado, lo que puede añadir trabajo de inicio en Linux, WSL y Windows nativo.
Si prefiere no usar la expansión acotada, enumere profundidades explícitas como
*.env, */*.env y */*/*.env.
Añada raíces reutilizables del espacio de trabajo al perfil cuando las mismas reglas deban aplicarse a más ubicaciones además de la raíz de la sesión actual:
[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = trueCuando este perfil está activo, Codex aplica las reglas :workspace_roots a las
raíces del espacio de trabajo del entorno 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
Establezca enabled = true para permitir el acceso a la red en el perfil seleccionado:
[permissions.project-edit.network]
enabled = trueCuando el acceso a la red está habilitado, Codex usa de forma predeterminada el comportamiento de red completo. La mayoría de los perfiles también deben definir reglas de dominio:
[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 allowEl proxy del entorno aislado de red se enlaza de forma predeterminada con 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 = trueMantenga estos ajustes de los agentes de escucha en sus valores predeterminados, salvo que esté realizando una integración con
un entorno de ejecución específico. Las claves de red dangerously_* son vías de escape para
entornos especializados y no deben usarse para el desarrollo local habitual.
Redes locales y privadas
Codex aplica de forma predeterminada una protección para redes locales y privadas como defensa contra la revinculación de DNS y el acceso accidental a servicios locales. Para permitir intencionadamente un destino local literal, añada a la lista de permitidos el host exacto o el literal de IP:
[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"Establezca allow_local_binding = true solo cuando el perfil deba acceder 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 un proxy para sockets Unix es una vía de escape local para herramientas como Docker. Úselo con moderación:
[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"Use 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, mantenga los agentes de escucha del proxy enlazados a direcciones de bucle invertido.
Migrar desde ajustes de aislamiento anteriores
Los perfiles de permisos sustituyen la combinación anterior de sandbox_mode y
sandbox_workspace_write cuando quiera que un único perfil reutilizable describa tanto el
comportamiento del sistema de archivos como el de la red. Use un sistema u otro para cada sesión, no
ambos.
Puntos de partida sugeridos:
- Para un flujo de trabajo de solo lectura, use el perfil integrado
:read-onlyo defina un perfil personalizado con acceso de lectura únicamente donde sea necesario. - Para editar el espacio de trabajo, use el perfil integrado
:workspaceo defina un perfil personalizado que escriba mediante:workspace_rootsy añada solo las rutas temporales o de caché adicionales que necesite el flujo de trabajo. - Para una ejecución local sin restricciones, use
:danger-full-accesssolo cuando quiera intencionadamente 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 todavía pueden añadir restricciones que la configuración del usuario no debe ampliar. Consulte Configuración administrada para conocer las restricciones del sistema de archivos y de la red impuestas por administradores.
Alcance y aplicación
Los perfiles de permisos definen los límites para la ejecución local de comandos en el entorno aislado. Úselos junto con las políticas de aprobación y los controles independientes para conectores, servidores MCP, el navegador integrado, Computer Use y Codex cloud.
Qué controlan los perfiles
- Ejecución local de comandos: Los perfiles de permisos rigen los comandos en el entorno aislado que se ejecutan en su equipo. Los conectores, los servidores MCP, las superficies de navegador o Computer Use, los ajustes del entorno de Codex cloud y los escalamientos aprobados usan sus propios controles.
- Escrituras en el sistema de archivos: Un perfil con capacidad de escritura puede crear cambios persistentes. Considere confidenciales las escrituras en scripts, pasos de compilación, enlaces de gestores de paquetes, archivos de inicio del shell y directorios compartidos, ya que otras herramientas o usuarios pueden ejecutar esos archivos posteriormente fuera del contexto del entorno aislado original.
- Destinos salientes: Las reglas de dominios de red restringen los destinos a los que puede dirigirse el tráfico de los comandos en el entorno aislado mediante el proxy de red. No determinan si un destino permitido es de confianza, y las reglas de permiso con comodines siguen siendo amplias.
- Servicios locales: Los destinos de redes locales y privadas están bloqueados de forma predeterminada.
Añadir a la lista de permitidos
localhost, direcciones IP privadas o sockets Unix, o establecerallow_local_binding = trueabre explícitamente el acceso a servicios locales.
Cómo funciona la aplicación
- En macOS, Codex usa perfiles de aislamiento Seatbelt. Si la política seleccionada no puede aplicarse mediante el entorno aislado de la plataforma, Codex se niega a ejecutar el comando en lugar de ejecutarlo silenciosamente sin aislamiento.
- En Linux y WSL, Codex usa bubblewrap y seccomp, con Landlock disponible para las rutas de compatibilidad alternativas. La ruta de aplicación más sólida depende de los espacios de nombres de usuario y de la compatibilidad del kernel; los hosts de contenedores restringidos pueden forzar rutas de compatibilidad, y las políticas divididas no compatibles se rechazan.
- En Windows nativo, el aislamiento
elevatedes el más sólido porque puede usar usuarios de aislamiento dedicados con menos privilegios, límites de permisos del sistema de archivos y reglas de firewall. El aislamientounelevatedes una alternativa con un aislamiento de red más débil y no puede aplicar todas las exclusiones divididas de lectura y escritura, por lo que las políticas no compatibles se rechazan. Use WSL cuando necesite el modelo de aislamiento de Linux.
Orientación operativa
Elija el perfil más restrictivo que permita completar la tarea, especialmente cuando conceda acceso de escritura o de red saliente. Mantenga la política de aprobación, el manejo de secretos y las reglas de permiso en consonancia con ese nivel de acceso.
Perfiles comunes
Solo lectura con lista de permitidos de red
default_permissions = "readonly-net"
[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 su espacio de trabajo y, al mismo tiempo, denegará la lectura del resto del sistema de archivos (con excepciones limitadas, según lo determine :minimal).
default_permissions = "workspace-only"
[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# subfolders such as .codex/ and .git/ 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 = falseEscritura en el espacio de trabajo con acceso a la web pública
default_permissions = "workspace-net"
[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"Use la regla global de permiso "*" solo cuando pretenda permitir el acceso a la red
pública. Las reglas de denegación pueden restringir una lista de permitidos amplia.