Documentation Index
Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
Use this file to discover all available pages before exploring further.
As configurações para toda a equipe permitem que os admins do Enterprise controlem o uso do Devin CLI em toda a organização.
- Admins do Devin Enterprise podem gerenciar essas configurações no dashboard do Devin voltado ao cliente, em Configurações → Enterprise → Windsurf (
app.devin.ai/org/{orgName}/settings/windsurf). Esse é um recurso de autoatendimento para admins com acesso às configurações do Enterprise.
- Admins do Windsurf Enterprise podem gerenciar essas configurações no dashboard do Windsurf em https://windsurf.com/team/cli-settings.
Apenas as configurações específicas do Devin CLI nessas páginas se aplicam ao Devin CLI. As Configurações da equipe do Windsurf se aplicam ao Windsurf e não necessariamente ao Devin CLI, a menos que também estejam listadas na página de configurações do Devin CLI. Configurações disponíveis
- Permitir modelos específicos — Restringir os usuários a uma lista selecionada de modelos aprovados
- Permitir todos os modelos — Dar aos usuários acesso a todos os modelos disponíveis
Clique em Configure para gerenciar o acesso aos modelos em cada categoria.
Você também pode fixar um modelo padrão para toda a equipe que o Devin CLI usará em novas sessões. Essa é a mesma configuração que o Windsurf usa como modelo padrão, então basta configurá-la uma vez para que ela seja aplicada em ambas as interfaces.
- Se nenhum modelo padrão da equipe estiver definido, o Devin CLI usará o modelo padrão interno.
- Se o modelo padrão fixado não estiver presente na lista de modelos permitidos acima, o Devin CLI voltará ao modelo padrão interno — a lista de permissões sempre tem precedência.
- Usuários individuais ainda podem trocar de modelo durante uma sessão; essa configuração controla apenas o modelo inicial de novas sessões.
Admins do Enterprise podem configurar o modelo padrão na página Configurações da equipe do Windsurf, na página Devin CLI Settings ou na página de configurações do Devin Enterprise voltada para o cliente em app.devin.ai/org/{orgName}/settings/windsurf.
Permite que o agente da CLI do Devin faça pesquisas na web na Internet aberta. Isso não afeta a capacidade do agente de ler URLs específicas, o que é feito localmente na máquina do usuário. Esta ferramenta fica desativada por padrão para equipes Enterprise.
Defina se seus usuários podem usar ferramentas MCP (Model Context Protocol).
- Ativar/desativar — Ative ou desative completamente o uso de servidores MCP
- Servidores MCP na lista de permissões — Especifique a quais servidores MCP os usuários podem se conectar. Se nenhum servidor for adicionado, todos os servidores entrarão na lista de permissões por padrão. Clique em Adicionar servidor para restringir o acesso a servidores específicos.
Configure regras de permissão aplicadas pela equipe para o uso do Devin CLI. Essas regras têm a precedência mais alta e não podem ser sobrescritas pelas configurações locais ou de projeto de usuários individuais.
Clique em Configure para abrir o editor de permissões. A configuração requer um objeto JSON com três campos:
{
"deny": [
"exec"
],
"ask": [],
"allow": [
"Read(~/my-repository/**)"
]
}
deny — Ações totalmente bloqueadas (tem a prioridade mais alta)ask — Ações que sempre solicitam aprovação do usuárioallow — Ações aprovadas automaticamente, sem solicitação
As permissões podem ser baseadas em escopo ou baseadas em ferramenta:
| Tipo | Formato | Exemplo |
|---|
| Leitura de arquivo | Read(/path) | Read(~/sensitive/**) |
| Escrita de arquivo | Write(/path) | Write(.env*) |
| Execução de comando | Exec(cmd) | Exec(rm), Exec(sudo) |
| Busca HTTP | Fetch(url) | Fetch(https://internal.api/*) |
| Baseado em ferramenta | Nome da ferramenta | read, edit, exec |
Use regras de negação impostas pela equipe para impedir ações em toda a organização, como bloquear o acesso a diretórios sensíveis ou a comandos perigosos, como rm -rf ou sudo.
Modo de imposição do sandbox
--sandbox em toda a sua organização:
- Opcional (padrão) — Os usuários decidem se querem usar
--sandbox. Não há imposição.
- Obrigatório — A flag
--sandbox é aplicada a todos os usuários, mesmo que eles não a informem na linha de comando. Todas as sessões da CLI são executadas com sandboxing do sistema de arquivos em nível de SO, que aplica escopos de permissão de leitura/gravação.
Um futuro modo Estrito poderá bloquear completamente a configuração do sandbox, impedindo que os usuários modifiquem as configurações do sandbox.
Quando o sandbox está ativo:
- Os caminhos graváveis são derivados dos escopos de permissão
Write(...) concedidos, além do diretório do workspace
- Os caminhos legíveis são derivados dos escopos
Read(...) concedidos (padrões da plataforma, como /usr/bin, são sempre legíveis)
- Escopos concedidos durante a sessão expandem dinamicamente o sandbox para os comandos subsequentes
Se a resolução do sandbox falhar (por exemplo, se as ferramentas de sandboxing não estiverem disponíveis na plataforma do usuário), a CLI se recusará a iniciar em vez de ser executada sem sandbox. Esse comportamento de falha fechada se aplica tanto quando o sandbox foi ativado por essa configuração da equipe quanto quando o usuário informa --sandbox diretamente, garantindo que a intenção de segurança nunca seja ignorada em silêncio.Quando imposto pelo Enterprise, os usuários verão um erro orientando-os a entrar em contato com o administrador da equipe. Quando iniciado pelo usuário, o erro sugere executar sem --sandbox para prosseguir sem isolamento em nível de SO.Causas comuns de falha na resolução do sandbox:
- Windows: o sandboxing em nível de SO não é compatível com Windows no momento. As sessões no Windows falharão imediatamente quando
--sandbox for informado ou quando a imposição do sandbox for Obrigatória, inclusive quando a CLI for executada como um servidor ACP dentro de uma IDE (por exemplo, Windsurf).
- Linux: o sandboxing exige que
bubblewrap (bwrap) e socat estejam instalados. As sessões falham imediatamente com instruções de instalação quando eles não estão presentes.
- Erros de escopo de permissão: caminhos inválidos em escopos de permissão que não podem ser resolvidos.
Certifique-se de que todas as máquinas de destino estejam provisionadas antes de definir o modo de imposição do sandbox como Obrigatório em toda a sua organização. Se houver usuários no Windows, eles não conseguirão executar a CLI até que o sandboxing em nível de SO seja compatível com Windows ou que a política seja flexibilizada para Opcional.
-
Lista de permissões de domínios — Quando definida, somente os domínios desta lista podem ser acessados pelo proxy de rede do sandbox. Esta lista é definitiva: ela substitui completamente qualquer
allowed_domains configurado pelo usuário em sua configuração do sandbox. Os usuários não podem adicionar domínios extras para contornar as restrições do admin.
-
Lista de bloqueio de domínios — Domínios que são sempre bloqueados. Os domínios negados do Enterprise são aditivos: eles são combinados com o
denied_domains local do usuário, tornando a lista resultante mais restritiva.
Consulte a referência da configuração do sandbox para a sintaxe dos padrões de domínio (por exemplo, *.example.com, **.example.com).
Como as listas de domínios do Enterprise e do usuário interagem:
| Cenário | Configuração do Enterprise | Configuração do usuário | Resultado efetivo |
|---|
| Admin define lista de permissões | allowed_domains: ["github.com"] | allowed_domains: ["npmjs.org"] | Somente github.com é permitido (o Enterprise substitui a lista do usuário) |
| Admin define lista de bloqueio | denied_domains: ["evil.com"] | denied_domains: ["risky.io"] | Tanto evil.com quanto risky.io são bloqueados (combinados) |
| Sem lista de permissões do admin | allowed_domains: [] | allowed_domains: ["github.com"] | A lista de permissões do usuário é usada |
Como o denied_domains local do usuário é preservado e combinado de forma aditiva, um usuário pode negar um domínio que aparece na lista de permissões do Enterprise. Isso é intencional: o efeito combinado é sempre mais restritivo, nunca menos. Se isso causar problemas de acesso, o usuário deverá remover a entrada conflitante da sua configuração local.
Combine a imposição do sandbox com regras de negação de permissão da equipe (por exemplo, Write(/etc)) para impedir que agentes modifiquem diretórios sensíveis tanto no nível de permissão quanto no nível do sistema operacional. As regras de negação de permissão impedem que o agente sequer tente executar a ação, enquanto o sandbox fornece uma segunda camada de proteção no nível do sistema operacional.
Mostrar “Install Devin CLI” na Paleta de Comandos do Windsurf
Cmd+Shift+P no macOS ou Ctrl+Shift+P no Windows/Linux) e executar Install Devin CLI para adicionar o binário devin ao PATH.
Esta configuração está disponível nos planos Windsurf Enterprise e Devin Enterprise e fica desativada por padrão.
