Permissões do Devin CLI

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: Cada célula mostra se essa ferramenta é executada automaticamente (Auto, sem confirmação) ou espera sua aprovação (Prompt) nesse modo:

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

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 Smart, edições no workspace são aprovadas automaticamente como no modo Accept Edits, e todas as outras ações são avaliadas por um modelo rápido que só as executa automaticamente quando são claramente seguras. Todo o restante exige confirmação como de costume. Consulte o Modo Smart abaixo. 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 Smart, Bypass e Autonomous não substituem permissões em nível de organização. Regras de negação 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 Smart

O Smart fica entre Accept Edits e Bypass. As edições de arquivos no workspace são aprovadas automaticamente, exatamente como em Accept Edits. Para todas as outras ações — comandos de shell, requisições web, ferramentas MCP, gravações fora do workspace — um modelo rápido avalia se a ação pode ser executada com segurança sem supervisão. Se for claramente segura, a ação é executada sem prompt; caso contrário, ou se o modelo estiver incerto ou indisponível, você verá o prompt de aprovação normal.

/smart
# ou
/mode smart

Você também pode alternar para o modo Smart com Shift+Tab, selecioná-lo no seletor de modo ou iniciá-lo:

devin --permission-mode smart
# ou
DEVIN_PERMISSION_MODE=smart devin

O julgamento do modelo se limita ao trabalho rotineiro de desenvolvimento — criar, testar, executar lint, formatar e inspecionar o projeto. Algumas categorias nunca são aprovadas automaticamente no modo Smart, independentemente do que o modelo considere:

Instalações de pacotes (npm install, pip install, cargo install, brew install, …)
Operações de git que modificam dados (subcomandos somente de leitura, como git status, continuam elegíveis)
rm, sudo e outros comandos destrutivos ou de escalonamento de privilégios
kubectl delete e operações destrutivas em CLIs de nuvem (aws, gcloud, az, terraform, …)
Tudo que leia ou grave arquivos dotenv, material de chave, configurações do Git ou a própria configuração do agente

O Smart se diferencia dos modos adjacentes pelo que delega:

	Accept Edits	Smart	Bypass
Edições de arquivos do workspace	Auto	Auto	Auto
Comandos de shell e requisições	Sempre pedir	Auto somente quando o modelo os julgar seguros	Sempre auto
Comandos de alto risco (instalações, `rm`, `sudo`, `git` que modifica dados)	Sempre pedir	Sempre pedir	Sempre auto

Suas próprias regras continuam tendo prioridade. O julgamento do Smart só se aplica quando nenhuma regra já determina a decisão. Portanto, uma regra deny bloqueia a ação, e uma regra ask sempre solicita aprovação, exatamente como descrito em Como as permissões funcionam. As regras deny e ask no nível da organização também não são afetadas.

O modo Smart está sendo disponibilizado gradualmente, portanto talvez ainda não apareça no seletor de modo ou no ciclo de Shift+Tab.

Modo Autonomous

Autonomous é o modo de permissão usado com a flag --sandbox. Em termos conceituais, ele equivale mais ou menos a “Accept Edits 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, Smart e Bypass ficam ocultos em sessões com sandbox. O modo Plan continua disponível.
Comandos de shell e requisições 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 Write(...) concedidos no meio da sessão expandem dinamicamente a sandbox para os comandos subsequentes. Aprovações de Read(...) no meio da sessão afetam apenas as próprias ferramentas do agente; caminhos ocultos por regras de negação Read(...) permanecem ocultos durante toda a sessão.

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, regras de negação 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, as regras correspondentes no mesmo nível de configuração são resolvidas da seguinte forma:

Regras de negação — Se houver correspondência, a ação é bloqueada imediatamente.
Regras de solicitação — Se houver correspondência, você precisará confirmar, a menos que uma regra de permissão de comando ou de MCP igualmente ou mais específica também corresponda.
Regras de permissão — Se houver correspondência, a ação prossegue sem pedir confirmação.
Padrão — Se nenhuma regra corresponder, sua aprovação será solicitada.

Uma regra de negação sempre prevalece. Uma regra de permissão nunca faz override de uma negação correspondente, independentemente de quão específica seja a regra de permissão.

Regras de Permissão Específicas

No mesmo nível de configuração, uma permissão para um comando específico pode abrir uma exceção a um ask mais amplo. Por exemplo:

{
  "permissions": {
    "ask": ["exec"],
    "allow": ["Exec(git status)"]
  }
}

Com essa configuração, git status é executado sem solicitar aprovação, enquanto os demais comandos continuam solicitando. O mesmo vale quando as duas regras usam escopos de comando: um comando exato é mais específico que um prefix, e um prefix mais longo é mais específico que um mais curto. As regras de MCP seguem o mesmo princípio: um tool específico é mais específico que uma regra válida para todo o servidor, que por sua vez é mais específica que uma regra que abrange todas as ferramentas MCP. Essa exceção só vale dentro de um mesmo nível de configuração. Um allow de nível inferior não pode sobrepor um ask vindo de um nível de precedência maior, como as configurações da organização. Ela também não se aplica a globs de caminho em Read() ou Write(): se um caminho corresponder a uma regra ask, Devin solicita aprovação mesmo que um allow de caminho mais restrito também corresponda.

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

Os prompts de comando oferecem ambos os escopos explicitamente: “Sim, sempre permitir comandos <cmd> em <project>” salva a permissão para o projeto atual, e “Sim, sempre permitir comandos <cmd> em todos os projetos” a salva na sua configuração de usuário para que se aplique em todos os lugares. Os prompts de busca na web para uma URL ou domínio específico adicionam uma opção equivalente de “Sim, sempre permitir todas as buscas na web”, que inclui as buscas na lista de permissões em uma única etapa.

Editando um Command Antes de Aprovar

Os prompts de aprovação do Command não se limitam a sim ou não. Além das opções de aprovação, um prompt de comando oferece:

Opção	Efeito
Editar comando	Abre o comando proposto para edição inline, permitindo ajustá-lo antes de executá-lo
Descrever alteração no comando	Reescreve o comando com base em uma descrição em linguagem natural do que você quer que ele faça, para revisão antes da execuçã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)

As regras deny e ask no nível da organização não podem sofrer override 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 o comando específico permite fazer override do ask mais amplo de exec no mesmo nível de configuração. A negação de .env* continua tendo prioridade sobre a regra Write(**) de ask.

Primeiros passos

Integrações do Editor

Extensibilidade

Enterprise

Referência

Changelog

Permissões do Devin CLI

Comportamento padrão das permissões

Modo Smart

Modo Autonomous

Como as permissões funcionam

Regras de Permissão Específicas

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

Editando um Command Antes de Aprovar

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 Smart

​Modo Autonomous

​Como as permissões funcionam

​Regras de Permissão Específicas

​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

​Editando um Command Antes de Aprovar

​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 Smart

Modo Autonomous

Como as permissões funcionam

Regras de Permissão Específicas

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

Editando um Command Antes de Aprovar

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