> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissões

> Controle o que o agente pode fazer com regras de permissão detalhadas

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.

***

<div id="default-permission-behavior">
  ## Comportamento padrão das permissões
</div>

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](/pt-BR/cli/essential-commands#modes) 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        | Bypass | Autonomous (sandbox) |
| ------------------------------------- | ------------------------------- | ------ | ------------------- | ------ | -------------------- |
| Somente leitura                       | Leitura de arquivos, grep, glob | Auto   | Auto                | Auto   | Auto                 |
| Fetch                                 | Requisições HTTP                | Prompt | Prompt              | Auto   | Auto                 |
| Comandos Bash                         | Execução no shell               | Prompt | Prompt              | Auto   | Auto                 |
| Edições de arquivo via `edit`/`write` | Editar/gravar arquivos          | Prompt | 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 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](#autonomous-mode) está ativo.

<Warning>
  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](/pt-BR/cli/enterprise/team-settings), permanecem ativas independentemente do modo de permissão do usuário. Consulte [Precedência](#precedence) para mais detalhes.
</Warning>

<div id="autonomous-mode">
  ### Modo Autonomous
</div>

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.

```bash theme={null}
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](/pt-BR/cli/reference/configuration/config-file#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](/pt-BR/cli/enterprise/team-settings#sandbox-enforcement) para controles do Enterprise.

***

<div id="how-permissions-work">
  ## Como as permissões funcionam
</div>

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

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

<Note>
  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á.
</Note>

***

<div id="configuration">
  ## Configuração
</div>

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

<Note>
  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](/pt-BR/cli/reference/configuration/config-file#file-locations) para mais detalhes.
</Note>

<Tabs>
  <Tab title="Configuração do projeto">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Configuração do usuário">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Override local">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## Sintaxe de permissão
</div>

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).

<div id="scope-based-permissions">
  ### Permissões baseadas em escopo
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    Controla o acesso de leitura a arquivos. O padrão glob corresponde aos caminhos dos arquivos.

    ```json theme={null}
    "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.
  </Accordion>

  <Accordion title="Write(glob)" icon="pen">
    Controla o acesso de gravação/edição de arquivos.

    ```json theme={null}
    "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
    ]
    ```
  </Accordion>

  <Accordion title="Exec(prefix)" icon="terminal">
    Controla a execução de comandos de shell. Corresponde a comandos que começam com o prefixo fornecido.

    ```json theme={null}
    "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
    ]
    ```

    <Note>
      `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.
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    Controla o acesso a fetch HTTP usando padrões de URL.

    ```json theme={null}
    "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](https://urlpattern.spec.whatwg.org/). A forma abreviada `domain:` corresponde a qualquer caminho no domínio exato.
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### Permissões por ferramenta
</div>

Use o nome da ferramenta para controlar ferramentas inteiras:

```json theme={null}
{
  "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`

<div id="mcp-tool-permissions">
  ### Permissões das ferramentas do MCP
</div>

Controle o acesso às ferramentas do servidor MCP:

```json theme={null}
{
  "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 |

***

<div id="path-patterns">
  ## Padrões de caminho
</div>

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:**

```json theme={null}
"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
]
```

<Note>
  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.
</Note>

***

<div id="persistence-options">
  ## Opções de persistência
</div>

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                         |

<div id="mcp-server-level-grants">
  ### Permissões no nível do servidor MCP
</div>

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.

***

<div id="precedence">
  ## Precedência
</div>

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):

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

<Warning>
  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.
</Warning>

***

<div id="examples">
  ## Exemplos
</div>

<div id="minimal-development-setup">
  ### Configuração mínima de desenvolvimento
</div>

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

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### Confiança total em um projeto
</div>

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

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

<div id="locked-down-enterprise">
  ### Enterprise com restrições rígidas
</div>

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

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

<Tip>
  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`.
</Tip>