Permissões
Configure perfis de permissões beta do Codex para acesso ao sistema de ficheiros e à rede
Os perfis de permissões permitem aplicar limites de privilégio mínimo aos comandos locais que o Codex executa em seu nome. Um perfil é uma política com nome que combina regras do sistema de ficheiros, que definem o que os comandos podem ler ou escrever, com regras de rede, que definem os destinos aos quais os comandos podem aceder.
Utilize perfis para conceder ao Codex acesso suficiente para a conversa atual sem conceder acesso abrangente ao seu computador ou à rede. Por exemplo, um perfil só de leitura pode permitir que o Codex inspecione um projeto sem o editar, enquanto um perfil com capacidade de escrita pode limitar as edições às raízes da área de trabalho selecionadas.
Os perfis de permissões locais são suportados no macOS, Linux, WSL e Windows nativo. Consulte Âmbito e aplicação para obter detalhes e ressalvas específicos de cada plataforma.
Para conhecer as definições de rede do Codex cloud, consulte Acesso à Internet.
Definir e selecionar um perfil
O Codex inclui três perfis de permissões incorporados:
:read-onlymantém a execução local de comandos apenas para leitura.:workspacepermite escritas dentro das raízes ativas da área de trabalho e dos diretórios temporários do sistema.:danger-full-accessremove as restrições do isolamento local e deve ser utilizado apenas quando esse acesso abrangente for intencional.
Crie um perfil com nome em [permissions.<name>] e, em seguida, defina a chave de nível superior
default_permissions como o nome desse perfil ou como um dos perfis incorporados acima.
Neste exemplo, project-edit é um nome de perfil definido pelo utilizador, não um valor
incorporado.
Os administradores empresariais podem definir perfis e restringir os perfis que
os utilizadores podem selecionar através da definição gerida requirements.toml. Assim que
allowed_permission_profiles estiver presente, os perfis omitidos são recusados,
incluindo os perfis incorporados omitidos e os perfis adicionados em futuras versões do Codex. Consulte
Controlar os perfis de permissões disponíveis
para conhecer a configuração gerida recomendada.
Os perfis personalizados utilizam dois conceitos relacionados:
[permissions.<name>.workspace_roots]adiciona diretórios concretos que devem ser considerados raízes da área de trabalho para esse perfil.[permissions.<name>.filesystem.":workspace_roots"]define as regras do sistema de ficheiros que o Codex aplica dentro de cada raiz efetiva da área de trabalho: as raízes da área de trabalho em tempo de execução da sessão atual e as raízes definidas pelo perfil acima.
Os perfis também utilizam o modelo normal de camadas de configuração. As camadas de maior precedência podem adicionar ou substituir entradas no mesmo nome de perfil sem repetir todo o perfil.
Por exemplo, uma configuração ao nível da organização e uma configuração ao nível do utilizador podem ampliar o mesmo perfil de forma independente:
# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = trueQuando server está ativo, ambas as raízes da área de trabalho fazem parte do perfil
efetivo.
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:
- Lê os caminhos mínimos de tempo de execução de que as ferramentas comuns de programação necessitam.
- Aplica as mesmas regras de raiz da área de trabalho à sessão atual e às raízes definidas pelo perfil.
- Mantém apenas para leitura, em cada raiz, as definições associadas ao IDE, como
.devcontainer/. - Recusa ficheiros de ambiente correspondentes através de uma regra glob.
- Permite o acesso à rede apenas através da política de domínios configurada.
Num perfil ativo, as regras de recusa mais restritas permanecem em vigor mesmo quando um caminho mais
abrangente permite leitura ou escrita. Por exemplo, um perfil pode permitir a escrita nas raízes da área de
trabalho e, ainda assim, definir um caminho .env correspondente como deny.
Ampliar um perfil
Utilize extends quando um perfil for, na sua maioria, igual a um perfil incorporado ou a outro perfil com
nome. Prefira ampliar um perfil incorporado em vez de começar do zero, para que
as proteções de base sejam mantidas. Ampliar :workspace, por exemplo, mantém
o diretório .codex da raiz da área de trabalho apenas para leitura, a menos que o substitua
explicitamente. Defina o perfil principal uma vez e, em seguida, adicione ou substitua apenas as regras que
forem 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 começa com :workspace, mantém recusados os ficheiros correspondentes a .env e
permite pedidos para api.openai.com. Um perfil pode ampliar :read-only,
:workspace ou outro perfil com nome. Não pode ampliar
:danger-full-access; o Codex também rejeita perfis principais desconhecidos e ciclos de
herança.
Especificação da configuração
| Entrada | Tipo / valores | Predefinição | Detalhes |
|---|---|---|---|
default_permissions |
Nome de perfil em cadeia | Nenhuma | Indica o perfil de permissões que o Codex aplica por predefinição. Tem de corresponder a um perfil em [permissions] ou a um perfil incorporado, como :workspace. Defina-o explicitamente para obter um comportamento previsível; os requisitos geridos só podem omiti-lo quando :workspace e :read-only forem ambos explicitamente permitidos. O Codex utiliza as definições de sandbox mais antigas, a menos que allowed_permission_profiles gerido indique que devem ser utilizados perfis de permissões nesta configuração. |
[permissions.<name>] |
Tabela | Nenhuma | Define um perfil com nome. default_permissions seleciona um perfil como predefinido; outras definições de perfis de permissões também utilizam o nome do perfil. |
permissions.<name>.description |
Cadeia | Nenhuma | Fornece uma descrição legível por humanos para o perfil. Um perfil não herda a descrição do perfil principal através de extends. |
permissions.<name>.extends |
Nome de perfil em cadeia | Nenhuma | Cria este perfil a partir de outro perfil com nome ou do perfil incorporado :read-only ou :workspace. O Codex rejeita :danger-full-access, perfis principais desconhecidos e ciclos de herança. |
[permissions.<name>.workspace_roots] |
Tabela | Nenhuma | Adiciona raízes da área de trabalho definidas pelo perfil, que recebem regras de sistema de ficheiros :workspace_roots juntamente com as raízes da área de trabalho de execução da sessão atual. |
permissions.<name>.workspace_roots."<path>" |
Booleano | false |
Adiciona o caminho ao conjunto de raízes da área de trabalho do perfil quando true. As entradas definidas como false permanecem inativas. |
[permissions.<name>.filesystem] |
Tabela | Nenhuma | Associa caminhos do sistema de ficheiros a valores de acesso ou a mapas de subcaminhos com âmbito definido. Tabelas do sistema de ficheiros em falta ou vazias mantêm o acesso ao sistema de ficheiros restrito e emitem um aviso no arranque. |
permissions.<name>.filesystem.glob_scan_max_depth |
Número | Nenhuma | Limita a expansão de padrões glob de negação de leitura no Linux, WSL e Windows nativo quando o Codex cria um instantâneo das correspondências antes do arranque da sandbox. Valores superiores podem aumentar o trabalho de análise no arranque. Utilize um valor de, pelo menos, 1 quando um padrão ** ilimitado necessitar de uma pré-expansão limitada. |
[permissions.<name>.filesystem]."<path>" |
read, write ou deny |
Nenhuma | Concede acesso direto a um caminho suportado. deny nega o acesso e prevalece sobre entradas write ou read com o mesmo grau de especificidade. O Codex rejeita regras de escrita direta que o ambiente de execução ativo não consiga impor. |
[permissions.<name>.filesystem."<path>"]."<subpath>" |
read, write ou deny |
Nenhuma | Concede acesso a um descendente de <path>. Utilize . para o caminho base. Os restantes subcaminhos têm de ser descendentes relativos e não podem conter componentes . ou ... |
[permissions.<name>.network] |
Tabela | Nenhuma | Configura o proxy da sandbox de rede e a política de rede da sandbox para o perfil. |
permissions.<name>.network.enabled |
Booleano | false |
Ativa o acesso à rede para comandos executados na sandbox no perfil. Esta opção altera a política de rede da sandbox; por si só, não inicia o proxy de rede. |
[permissions.<name>.network.domains] |
Tabela | Nenhuma | Associa padrões de anfitrião a allow ou deny. Se não existirem entradas allow, os pedidos de domínio são bloqueados. As entradas de negação prevalecem sobre as entradas de permissão. |
permissions.<name>.network.domains."<pattern>" |
allow ou deny |
Nenhuma | Suporta anfitriões exatos, *.example.com para subdomínios, **.example.com para o domínio de topo e respetivos subdomínios e * como caráter universal global apenas de permissão. Os padrões de anfitrião são normalizados através da remoção de espaços, da conversão para minúsculas, da remoção de um ponto final e da remoção de portas simples ou parênteses retos. |
[permissions.<name>.network.unix_sockets] |
Tabela | Nenhuma | Associa substituições da lista de permissões de sockets Unix. Utilize apenas para integrações locais, como o Docker. |
permissions.<name>.network.unix_sockets."<path>" |
allow ou deny |
Nenhuma | Adiciona um caminho absoluto de socket Unix à lista de permissões efetiva com allow ou rejeita-o com deny. As entradas negadas são omitidas da lista de permissões efetiva. |
permissions.<name>.network.proxy_url |
Cadeia de URL | http://127.0.0.1:3128 |
Listener do proxy HTTP utilizado para HTTP_PROXY, HTTPS_PROXY, variáveis de proxy de websocket e variáveis de ambiente de proxy de ferramentas relacionadas. |
permissions.<name>.network.enable_socks5 |
Booleano | true |
Ativa o listener SOCKS5 utilizado para ALL_PROXY e variáveis de proxy FTP. |
permissions.<name>.network.socks_url |
Cadeia de URL | http://127.0.0.1:8081 |
Endereço do listener SOCKS5. |
permissions.<name>.network.enable_socks5_udp |
Booleano | true |
Ativa o suporte de UDP por SOCKS5 quando o listener SOCKS5 está ativo. |
permissions.<name>.network.allow_upstream_proxy |
Booleano | true |
Permite que o proxy da sandbox de rede respeite as definições HTTP(S)_PROXY e ALL_PROXY a montante para pedidos de saída. |
permissions.<name>.network.allow_local_binding |
Booleano | false |
Desativa a proteção da rede local/privada quando true. Quando false, literais locais exatos, como localhost ou 127.0.0.1, têm de ser explicitamente incluídos na lista de permissões, e os nomes de anfitrião que são resolvidos para IPs locais ou privados permanecem bloqueados. |
permissions.<name>.network.dangerously_allow_non_loopback_proxy |
Booleano | false |
Permite que os listeners do proxy sejam vinculados a endereços que não sejam de loopback. Deixe por definir para desenvolvimento local normal. |
permissions.<name>.network.dangerously_allow_all_unix_sockets |
Booleano | false |
Ignora a lista de permissões de sockets Unix nos locais onde é suportado o proxy de sockets Unix. Esta é uma opção de escape local abrangente. |
Permissões do sistema de ficheiros
As entradas do sistema de ficheiros utilizam read, write ou deny:
| Acesso | Significado |
|---|---|
read |
Permite que os comandos leiam ficheiros e listem diretórios no caminho. Os comandos não podem criar, modificar, mudar o nome nem eliminar ficheiros nesse local. |
write |
Permite que os comandos leiam e modifiquem ficheiros no caminho, incluindo criar, mudar o nome e eliminar ficheiros quando o SO o permite. |
deny |
Impede leituras e escritas no caminho. Utilize esta opção para excluir um subcaminho de uma concessão read ou write mais abrangente. |
As entradas mais específicas substituem as mais abrangentes. Quando duas entradas têm como destino o
mesmo caminho, deny tem precedência sobre write e write tem precedência
sobre read.
Esta precedência permite que um perfil descreva primeiro uma área de trabalho abrangente e, em seguida, exclua ficheiros ou diretórios que devam permanecer inacessíveis para leitura:
[permissions.project-edit.filesystem]
":minimal" = "read"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"Neste exemplo, a raiz do espaço de trabalho permanece gravável, .devcontainer/ permanece
legível sem se tornar gravável e os ficheiros de ambiente correspondentes continuam
indisponíveis para os comandos em sandbox.
Um caminho mais específico também pode reabrir uma subárvore mais restrita no interior de uma negação mais abrangente:
[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"Formas de caminho suportadas:
| Caminho | Significado | Subcaminhos abrangidos |
|---|---|---|
:root |
A raiz do sistema de ficheiros | Apenas . |
:minimal |
Caminhos da plataforma e do runtime necessários às ferramentas comuns | Apenas . |
:workspace_roots |
As raízes do espaço de trabalho da sessão atual, além de quaisquer raízes do espaço de trabalho ativadas e definidas pelo perfil | Sim |
:tmpdir |
A localização $TMPDIR, quando disponível |
Apenas . |
:slash_tmp |
A pasta /tmp, caso exista |
Apenas . |
/absolute/path |
Um caminho absoluto da plataforma, como /path no macOS/Linux/WSL ou C:\path no Windows nativo |
Sim |
~/path |
Um caminho no diretório pessoal do utilizador atual | Sim |
No Windows nativo, os caminhos relativos ao diretório pessoal também podem utilizar barras invertidas, como
~\work.
Utilize :root apenas quando um perfil precisar intencionalmente de uma cobertura de leitura abrangente:
[permissions.audit.filesystem]
":root" = "read"Utilize entradas aninhadas em :workspace_roots para limitar o acesso a subcaminhos relativos
à raiz do espaço de trabalho:
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write" # each workspace root
"docs" = "read" # each workspace-root docs directory
"generated" = "deny" # each workspace-root generated directoryOs subcaminhos aninhados têm de permanecer no interior da respetiva raiz do espaço de trabalho. A navegação para o diretório principal, como
../other-repo, é rejeitada.
Negar leituras com caminhos exatos ou globs
Utilize deny para ficheiros ou subárvores que o Codex não deve ler, mesmo quando uma regra
mais abrangente do perfil concede acesso nas proximidades. Os caminhos exatos são adequados para localizações estáveis,
como ~/.ssh. Os padrões glob são mais adequados quando um perfil precisa de abranger uma
família de ficheiros confidenciais cujas localizações exatas variam entre repositórios.
Quando um glob está em :workspace_roots, o Codex interpreta-o relativamente a cada
raiz efetiva do espaço de trabalho. Por exemplo:
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"Esta regra nega a leitura de ficheiros .env correspondentes encontrados sob cada raiz do espaço de trabalho
do runtime ou definida pelo perfil. Utilize-a quando pretender preservar as escritas normais no
espaço de trabalho, mantendo ilegíveis os ficheiros de ambiente, os segredos gerados ou ficheiros semelhantes
que contenham credenciais.
Os padrões glob deny são suportados como regras de negação de leitura. Os globs read ou write
são menos portáveis no sandboxing do Linux, WSL e Windows nativo, pelo que deve preferir caminhos
exatos ou regras de subárvore, como "docs/**" = "read", sempre que possível.
No Linux, WSL e Windows nativo, um padrão de negação de leitura ** não limitado pode exigir
uma pré-expansão limitada antes de o sandbox ser iniciado. Defina glob_scan_max_depth quando
utilizar um padrão não limitado, como "**/*.env" = "deny":
[permissions.project-edit.filesystem]
glob_scan_max_depth = 3
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"glob_scan_max_depth tem de ser, no mínimo, 1. Os valores mais elevados pesquisam a maior profundidade antes
do arranque do sandbox, o que pode acrescentar trabalho de arranque no Linux, WSL e Windows nativo.
Se preferir não utilizar a expansão limitada, enumere profundidades explícitas, como
*.env, */*.env e */*/*.env.
Adicione raízes reutilizáveis do espaço de trabalho ao perfil quando as mesmas regras devam ser aplicadas a mais do que a raiz da sessão atual:
[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = trueQuando este perfil está ativo, o Codex aplica as regras :workspace_roots às
raízes do espaço de trabalho do runtime da sessão atual e a cada raiz do espaço de trabalho
ativada e definida pelo perfil.
No Windows nativo, os caminhos com letra de unidade, como D:\work, e os caminhos UNC, como
\\server\share, são suportados como caminhos absolutos.
Permissões de rede
Defina enabled = true para permitir o acesso à rede no perfil selecionado:
[permissions.project-edit.network]
enabled = trueQuando o acesso à rede está ativado, o Codex utiliza por predefinição o comportamento de rede completo. A maioria dos perfis também deve definir regras de domínio:
[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 allowO proxy do sandbox de rede associa-se por predefinição a listeners locais:
[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 = trueMantenha estas definições dos listeners com os valores predefinidos, exceto se estiver a fazer a integração com
um runtime específico. As chaves de rede dangerously_* são mecanismos de recurso para
ambientes especializados e não devem ser utilizadas no desenvolvimento local comum.
Redes locais e privadas
Por predefinição, o Codex aplica uma proteção de rede local/privada como defesa contra a reassociação de DNS e o acesso acidental a serviços locais. Para permitir intencionalmente um destino local literal, adicione o anfitrião exato ou o literal de IP à lista de permissões:
[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"Defina allow_local_binding = true apenas quando o perfil precisar de aceder a nomes de anfitrião incluídos na lista de permissões
que sejam resolvidos para endereços locais ou privados:
[permissions.project-edit.network]
enabled = true
allow_local_binding = true
[permissions.project-edit.network.domains]
"localhost" = "allow"Sockets Unix
A utilização de um proxy para sockets Unix é um mecanismo de recurso local para ferramentas como o Docker. Utilize-o com moderação:
[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"Utilize deny para rejeitar um caminho de socket, incluindo uma entrada de permissão herdada. Os caminhos de
socket negados são omitidos da lista de permissões efetiva.
Quando os sockets Unix estiverem ativados, mantenha os listeners do proxy associados a endereços de loopback.
Migrar de definições de sandbox mais antigas
Os perfis de permissões substituem a combinação anterior de sandbox_mode e
sandbox_workspace_write quando pretende que um único perfil reutilizável descreva o comportamento
do sistema de ficheiros e da rede. Utilize um sistema ou o outro numa sessão, mas não
ambos.
Pontos de partida sugeridos:
- Para um fluxo de trabalho só de leitura, utilize o perfil incorporado
:read-onlyou defina um perfil personalizado com acesso de leitura apenas onde for necessário. - Para editar o espaço de trabalho, utilize o perfil incorporado
:workspaceou defina um perfil personalizado que efetue escritas através de:workspace_rootse adicione apenas os caminhos adicionais de ficheiros temporários ou de cache necessários ao fluxo de trabalho. - Para execução local sem restrições, utilize
:danger-full-accessapenas quando pretender intencionalmente o modelo de acesso local mais abrangente.
Os perfis descrevem a postura local predefinida de uma sessão. Os requisitos geridos pela organização podem ainda acrescentar restrições que a configuração do utilizador não deve alargar. Consulte Configuração gerida para conhecer as restrições de sistema de ficheiros e rede impostas pelo administrador.
Âmbito e aplicação
Os perfis de permissões definem os limites da execução local de comandos em sandbox. Utilize-os em conjunto com as políticas de aprovação e os controlos separados para conectores, servidores MCP, o browser incorporado, Computer Use e a cloud do Codex.
O que os perfis controlam
- Execução local de comandos: os perfis de permissões regulam os comandos em sandbox executados no seu computador. Os conectores, servidores MCP, superfícies de browser ou Computer Use, definições do ambiente da cloud do Codex e escalamentos aprovados utilizam os seus próprios controlos.
- Escritas no sistema de ficheiros: um perfil com capacidade de escrita pode criar alterações persistentes. Trate como confidenciais as escritas em scripts, etapas de compilação, hooks do gestor de pacotes, ficheiros de arranque da shell e diretórios partilhados, porque outras ferramentas ou utilizadores podem executar posteriormente esses ficheiros fora do contexto original do sandbox.
- Destinos de saída: as regras de domínio de rede limitam os destinos para os quais o tráfego de comandos em sandbox pode seguir através do proxy de rede. Não determinam se um destino permitido é fidedigno, e as regras de permissão com caracteres universais continuam a ser abrangentes.
- Serviços locais: os destinos de rede locais e privados são bloqueados por predefinição.
Incluir
localhost, IP privados ou sockets Unix na lista de permissões ou definir explicitamenteallow_local_binding = trueabre o acesso a serviços locais.
Como funciona a aplicação
- No macOS, o Codex utiliza perfis de sandbox Seatbelt. Se a política selecionada não puder ser aplicada pelo sandbox da plataforma, o Codex recusa-se a executar o comando, em vez de o executar silenciosamente sem sandbox.
- No Linux e WSL, o Codex utiliza bubblewrap e seccomp, com o Landlock disponível para caminhos de contingência de compatibilidade. O caminho de aplicação mais forte depende dos namespaces de utilizador e do suporte do kernel; os anfitriões de contentores restritos podem forçar caminhos de compatibilidade e as políticas divididas não suportadas são recusadas.
- No Windows nativo, o sandboxing
elevatedé mais forte, porque pode utilizar utilizadores de sandbox dedicados com menos privilégios, limites de permissões do sistema de ficheiros e regras de firewall. O sandboxingunelevatedé uma alternativa com isolamento de rede mais fraco e não consegue aplicar todas as exclusões de leitura/escrita divididas, pelo que as políticas não suportadas são recusadas. Utilize o WSL quando precisar do modelo de sandbox do Linux.
Orientações operacionais
Escolha o perfil mais restrito que ainda permita concluir a tarefa, especialmente quando conceder permissões de escrita ou acesso de saída à rede. Mantenha a política de aprovação, o tratamento de segredos e as regras de permissão alinhados com esse nível de acesso.
Perfis comuns
Só de leitura com lista de permissões de rede
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"Acesso a ficheiros limitado ao espaço de trabalho
Segue-se um exemplo de um perfil de permissões que torna as pastas do seu espaço de trabalho graváveis pelo Codex, ao mesmo tempo que nega a leitura do resto do sistema de ficheiros (com exceções limitadas, conforme determinado por :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"Escrita no espaço de trabalho sem rede
default_permissions = "project-edit"
[permissions.project-edit.filesystem]
":minimal" = "read"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
[permissions.project-edit.network]
enabled = falseEscrita no espaço de trabalho com acesso à 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"Utilize a regra de permissão global "*" apenas quando pretender permitir acesso à rede
pública. As regras de negação podem restringir uma lista de permissões abrangente.