Permissões - Devin Docs

O sistema de permissões controla quais ações o agente pode executar sem pedir sua aprovação. Você pode aprovar previamente ações seguras, bloquear ações perigosas e sempre exigir confirmação para operações sensíveis.

Comportamento padrão das permissões

O Devin CLI usa um sistema de permissões em níveis para equilibrar flexibilidade e segurança. O comportamento padrão depende do modo atual:

Tipo de ferramenta	Exemplo	Normal	Accept Edits	Bypass	Autonomous (sandbox)
Somente leitura	Leitura de arquivos, grep, glob	Não	Não	Não	Não
Fetch	Requisições HTTP	Sim	Sim	Não	Não
Comandos Bash	Execução no shell	Sim	Sim	Não	Não
Edições de arquivo via `edit`/`write`	Editar/gravar arquivos	Sim	Não (no workspace)	Não	Sim

No modo Normal (o padrão), operações somente leitura são aprovadas automaticamente, enquanto gravações em arquivos e comandos de shell exigem sua aprovação explícita. Cada vez que você aprova uma ação, pode escolher permiti-la uma vez, durante a sessão ou permanentemente para o projeto. No modo Accept Edits, edições de arquivo dentro do workspace são aprovadas automaticamente, mas comandos de shell e gravações fora do workspace ainda exigem confirmação. No modo Bypass, todas as chamadas de ferramenta são aprovadas automaticamente sem pedir confirmação. No modo Autonomous, comandos de shell e requisições de rede são aprovados automaticamente porque o sandbox no nível do sistema operacional restringe o que eles podem acessar. Edições diretas de arquivo pelas ferramentas edit/write ainda exigem confirmação, porque essas ferramentas operam fora do sandbox. Autonomous só está disponível quando o sandbox no nível do sistema operacional está ativo.

Os modos Bypass e Autonomous não substituem permissões em nível de organização. Regras de bloqueio e solicitação de aprovação impostas por admins, configuradas em Configurações da equipe, permanecem ativas independentemente do modo de permissão do usuário. Consulte Precedência para mais detalhes.

Modo Autonomous

Autonomous é o modo de permissão usado com a flag --sandbox. Em termos conceituais, ele equivale mais ou menos a “Aceitar edições no workspace atual” mais a capacidade de executar qualquer comando de shell, com ambos os comportamentos contidos pela sandbox em nível de sistema operacional. Quando a sandbox está ativa:

É o único modo de permissão disponível. Os modos Normal, Accept Edits e Bypass ficam ocultos em sessões com sandbox. O modo Plan continua disponível.
Comandos de shell e fetches são aprovados automaticamente em vez de pedir confirmação, porque a sandbox impõe limites ao que eles podem ler, escrever e acessar pela rede.
Edições diretas de arquivos com as ferramentas edit e write ainda pedem confirmação. Essas ferramentas são executadas dentro do processo da CLI, e não dentro da sandbox, então não podem ser delimitadas por ela. Conceder um escopo Write(...) no prompt expande dinamicamente a sandbox para que os comandos de shell subsequentes possam escrever nesse local.
Escopos concedidos no meio da sessão expandem dinamicamente a sandbox para os comandos subsequentes.

devin --sandbox --permission-mode autonomous

Use Bypass quando quiser execução irrestrita, sem isolamento no nível do sistema operacional; use --sandbox (que seleciona Autonomous) quando quiser execução sem supervisão, com limites de acesso ao sistema de arquivos e à rede impostos pelo sistema operacional. Consulte a referência de configuração do sandbox para mais detalhes sobre diretórios raiz graváveis/legíveis e filtragem de domínios, e Configurações da equipe → Aplicação do sandbox para controles do Enterprise.

Como as permissões funcionam

Quando o agente usa uma ferramenta, o sistema de permissões verifica suas regras em ordem de prioridade:

Regras de negação — Verificadas primeiro. Se houver correspondência, a ação é bloqueada imediatamente.
Regras de solicitação — Verificadas em segundo lugar. Se houver correspondência, você sempre precisará confirmar (faz override de qualquer regra de permissão).
Regras de permissão — Verificadas por último. Se houver correspondência, a ação prossegue sem pedir confirmação.
Padrão — Se nenhuma regra corresponder, sua aprovação será solicitada.

Como a negação é verificada antes da solicitação, e a solicitação é verificada antes da permissão, uma regra de negação sempre prevalece. Se o mesmo escopo corresponder tanto a uma regra de negação quanto a uma regra de solicitação, a regra de negação prevalecerá.

Configuração

Adicione permissões à seção permissions do seu arquivo de configuração:

No Windows, o caminho do arquivo de configuração do usuário é %APPDATA%\devin\config.json (geralmente C:\Users\<you>\AppData\Roaming\devin\config.json) em vez de ~/.config/devin/config.json. Consulte Arquivo de configuração para mais detalhes.

Configuração do projeto
Configuração do usuário
Override local

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .devin/config.local.json
{
  "permissions": {
    "allow": [
      "Exec(docker compose)"
    ]
  }
}

Sintaxe de permissão

Há dois tipos de correspondência de permissão: baseada em escopo (que controlam quais caminhos/comandos/URLs podem ser acessados) e baseada em ferramenta (que controlam quais ferramentas podem ser usadas).

Permissões baseadas em escopo

Read(glob)

Controla o acesso de leitura a arquivos. O padrão glob corresponde aos caminhos dos arquivos.

"allow": [
  "Read(src/**)",           // Todos os arquivos em src/
  "Read(~/.config/**)",     // Arquivos de configuração do diretório home
  "Read(/tmp/**)"           // Diretório temporário
]

Caminhos de diretório correspondem automaticamente a todos os arquivos dentro deles.

Write(glob)

Controla o acesso de gravação/edição de arquivos.

"allow": [
  "Write(src/**)",          // Pode gravar em qualquer lugar de src/
  "Write(tests/**)"         // Pode gravar arquivos de teste
],
"deny": [
  "Write(*.lock)",          // Não pode modificar arquivos .lock
  "Write(.env*)"            // Não pode modificar arquivos .env
]

Exec(prefix)

Controla a execução de comandos de shell. Corresponde a comandos que começam com o prefixo fornecido.

"allow": [
  "Exec(git)",              // git, git status, git commit...
  "Exec(npm run)",          // npm run test, npm run build...
  "Exec(python)"            // python, python script.py...
],
"deny": [
  "Exec(rm)",               // Bloqueia rm, rm -rf etc.
  "Exec(sudo)"              // Bloqueia comandos sudo
]

Exec(git) corresponde a “git”, “git status”, “git commit -m ‘msg’”, mas NÃO a “gitk” nem “github-cli”. O prefixo deve corresponder a uma palavra completa.

Fetch(pattern)

Controla o acesso a fetch HTTP usando padrões de URL.

"allow": [
  "Fetch(https://api.github.com/*)",    // API do GitHub
  "Fetch(https://*.example.com/*)",     // Todos os subdomínios de example.com
  "Fetch(domain:npmjs.org)"             // Qualquer URL em npmjs.org
]

Os padrões de URL seguem o padrão WHATWG URL Pattern. A forma abreviada domain: corresponde a qualquer caminho no domínio exato.

Permissões por ferramenta

Use o nome da ferramenta para controlar ferramentas inteiras:

{
  "permissions": {
    "deny": [
      "edit",       // Bloquear todas as edições de arquivo
      "exec"        // Bloquear toda execução de comandos
    ],
    "allow": [
      "read",       // Permitir todas as leituras de arquivo
      "grep",       // Permitir todas as buscas
      "glob"        // Permitir toda localização de arquivos
    ]
  }
}

Nomes de ferramentas disponíveis: read, edit, grep, glob, exec

Permissões das ferramentas do MCP

Controle o acesso às ferramentas do servidor MCP:

{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Ferramenta específica em servidor específico
      "mcp__github__*",               // Todas as ferramentas no servidor github
      "mcp__*"                        // Todas as ferramentas MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Bloquear ferramenta perigosa específica
    ]
  }
}

Pattern	Corresponde a
`mcp__server__tool`	Uma ferramenta específica
`mcp__server__*`	Todas as ferramentas de um servidor
`mcp__*`	Todas as ferramentas MCP em qualquer lugar

Padrões de caminho

Os padrões glob em Read() e Write() aceitam:

Padrão	Significado
`*`	Quaisquer caracteres em um único segmento de caminho
`**`	Quaisquer caracteres em vários segmentos de caminho (recursivo)
`~`	Expansão do diretório home

Exemplos:

"allow": [
  "Read(**)",                    // Todos os arquivos em qualquer lugar
  "Read(src/**/*.ts)",           // Todos os arquivos TypeScript em src/
  "Write(~/projects/myapp/**)"   // Escrever em projeto específico
]

Use um prefixo de caminho absoluto (por exemplo, Read(/**)) quando quiser corresponder a todos os arquivos do sistema. Um Read(**) sem uma / inicial é resolvido em relação ao diretório de trabalho atual, então corresponde apenas aos arquivos nesse diretório — não aos arquivos acessados por caminhos absolutos em outros locais.

Opções de persistência

Quando o agente solicitar permissão durante uma sessão, você poderá escolher como salvar sua decisão:

Opção	Onde fica salvo	Compartilhado com a equipe?
Permitir uma vez	Não é salvo	Não
Permitir durante a sessão	Apenas na memória	Não
Permitir para o projeto	`.devin/config.json`	Sim
Permitir para o projeto (local)	`.devin/config.local.json`	Não
Permitir globalmente	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` no Windows)	Não

Permissões no nível do servidor MCP

Quando for solicitada permissão para uma ferramenta MCP específica (por exemplo, list_issues no servidor Figma), o prompt de permissão também oferece opções mais amplas no nível do servidor:

Opção	Efeito
Permitir esta ferramenta (nesta sessão)	Concede acesso à ferramenta específica na sessão atual
Sempre permitir esta ferramenta	Salva a permissão da ferramenta específica na configuração
Permitir todas as ferramentas neste servidor (nesta sessão)	Concede acesso a todas as ferramentas do servidor nesta sessão
Sempre permitir ferramentas neste servidor	Salva o acesso a todo o servidor na configuração

Isso permite conceder rapidamente acesso amplo a um servidor MCP confiável sem precisar aprovar cada ferramenta individualmente.

Precedência

Quando várias fontes de permissão definem regras, elas são combinadas seguindo esta ordem de precedência (da mais alta para a mais baixa):

Configurações da organização/equipe (se Enterprise)
Permissões concedidas no nível da sessão (aprovações interativas)
Configuração local do projeto (.devin/config.local.json)
Configuração do projeto (.devin/config.json)
Configuração do usuário (~/.config/devin/config.json; %APPDATA%\devin\config.json no Windows)

Permissões negadas no nível da organização não podem ser substituídas por configurações de projeto ou de usuário. Isso garante que as políticas do Enterprise sejam aplicadas.

Exemplos

Configuração mínima de desenvolvimento

Permita operações comuns somente de leitura e solicite confirmação para todo o restante:

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}

Confiança total em um projeto

Aprove automaticamente a maioria das operações no projeto:

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}

Enterprise com restrições rígidas

Restrinja a operações seguras específicas e sempre solicite confirmação para operações de escrita:

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}

Neste exemplo, gravações em .env* são negadas de imediato, todas as outras gravações sempre solicitam confirmação ao usuário, e apenas alguns comandos somente leitura são aprovados automaticamente. Como deny é verificado antes de ask, a negação de .env* tem prioridade sobre a regra Write(**) de ask.

Documentation Index

​Comportamento padrão das permissões

​Modo Autonomous

​Como as permissões funcionam

​Configuração

​Sintaxe de permissão

​Permissões baseadas em escopo

​Permissões por ferramenta

​Permissões das ferramentas do MCP

​Padrões de caminho

​Opções de persistência

​Permissões no nível do servidor MCP

​Precedência

​Exemplos

​Configuração mínima de desenvolvimento

​Confiança total em um projeto

​Enterprise com restrições rígidas

Comportamento padrão das permissões

Modo Autonomous

Como as permissões funcionam

Configuração

Sintaxe de permissão

Permissões baseadas em escopo

Permissões por ferramenta

Permissões das ferramentas do MCP

Padrões de caminho

Opções de persistência

Permissões no nível do servidor MCP

Precedência

Exemplos

Configuração mínima de desenvolvimento

Confiança total em um projeto

Enterprise com restrições rígidas