CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: uso e auditoria

Não defina CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS em máquinas de desenvolvimento nem em executores de CI compartilhados. No Claude Code v2.1.311+, ela remove uma confirmação específica de exclusão somente quando a sessão usa bypassPermissions. Reserve seu uso para ambientes descartáveis e isolados, nos quais seja aceitável perder qualquer arquivo com permissão de escrita.

Em 2026-10-28, a documentação da Anthropic descreve essa exceção como uma configuração do ambiente de inicialização. Ela não ativa o modo bypassPermissions nem desativa todos os outros controles de permissão.

Por que --dangerously-skip-permissions ainda bloqueia rm -rf ~?

O Claude Code verifica os destinos reconhecidos de rm e rmdir separadamente das aprovações comuns de ferramentas. A opção --dangerously-skip-permissions seleciona bypassPermissions, mas esse modo mantém a verificação de caminhos críticos enquanto a nova exceção não entra em vigor.

Uma regra allow não pode aprovar uma exclusão reconhecida como direcionada a um caminho crítico. Um hook PreToolUse que retorna allow também não pode. Por padrão, o terminal pede aprovação com uma contagem regressiva de dois minutos.

Em uma execução com -p, uma ferramenta de permissões, um callback do SDK ou um hook PermissionRequest que autorize a ação pode decidir a operação. Sem um desses mecanismos, a operação é negada por padrão.

A definição de caminhos críticos inclui:

• A raiz do sistema de arquivos, como /.
• Os diretórios imediatamente abaixo da raiz, incluindo /usr, /etc e /data.
• Seu diretório pessoal, incluindo o nome curto no formato Windows 8.3, como C:\Users\LONGNA~1.
• As raízes de unidades do Windows e seus diretórios de primeiro nível, como C:\ e C:\Windows. Formas alternativas como \\?\C:\ e \\localhost\C$ também contam.
• Seu diretório de trabalho e os diretórios acima dele.
• Os diretórios de trabalho adicionais e seus diretórios superiores, especificamente quando o destino é um padrão glob abaixo deles, como rm -rf <dir>/*.

Excluir o próprio diretório adicional com rm -rf <dir> não aciona essa verificação específica. Outra regra ainda pode se aplicar, por exemplo, se o diretório também estiver diretamente abaixo da raiz.

Essa verificação cobre os comandos que o Claude Code reconhece. Um comando não detectado não recebe proteção especial, e outros programas autorizados também podem excluir arquivos. O Remove-Item do PowerShell e os comandos de exclusão do cmd têm verificações próprias.

Configure a variável para uma sessão isolada no terminal

Defina a variável no ambiente que inicia claude e selecione bypassPermissions explicitamente. Um uso adequado seria uma tarefa automatizada que precisa esvaziar intencionalmente um diretório de trabalho descartável.

Use uma CLI funcional e autenticada na versão v2.1.311 ou posterior. Execute estas verificações no Bash, em macOS, Linux ou WSL:

claude --version
claude auth status --text

Se a autenticação falhar, use claude auth login com a configuração de conta aprovada pela sua equipe. Se o executável errado for iniciado, siga as verificações de instalação e PATH do Claude Code. Atualize uma instalação antiga antes de continuar.

Inicie a sessão desejada com uma atribuição temporária no Bash:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

A atribuição vale para esse comando e seus processos filhos. Ela não permanece no shell que iniciou o comando. Você pode substituir --permission-mode bypassPermissions por --dangerously-skip-permissions.

Use um usuário sem privilégios de root no ambiente isolado. No Linux e no macOS, o modo bypassPermissions normalmente recusa execuções como root ou com sudo, exceto em sandboxes reconhecidos.

Não coloque essa variável no bloco env de ~/.claude/settings.json, .claude/settings.json ou .claude/settings.local.json. A referência de variáveis de ambiente confirma que o Claude Code a ignora nesses locais. Movê-la entre escopos de configuração não resolve isso.

A exceção só se aplica enquanto a sessão está efetivamente em bypassPermissions, e não em plan. Ela afeta a verificação de caminhos críticos das ferramentas Bash e Monitor, incluindo comandos que essa verificação não consegue interpretar por completo.

Para remover uma configuração já exportada, saia da sessão afetada e remova a atribuição da origem usada na inicialização. Execute unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS no shell e inicie uma nova sessão.

Confira o aviso de inicialização sem excluir arquivos

Leia o aviso de inicialização do Claude Code para saber se a exceção pode entrar em vigor. Uma resposta bem-sucedida do modelo, por si só, não comprova o estado das permissões.

Para um diagnóstico simples no ambiente isolado, execute no Bash:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

As opções da CLI removem as ferramentas integradas e bloqueiam as ferramentas MCP nesse diagnóstico. Elas restringem as ferramentas que o modelo pode chamar; os hooks de inicialização e as extensões continuam sendo carregados.

O comando solicita uma resposta READY em stdout. Ele salva o stderr da inicialização em claude-startup.log, sem solicitar nenhuma exclusão.

Os avisos documentados contêm uma destas três frases:

Trecho do aviso	Significado
is set, so dangerous rm commands can run without a prompt	A exceção pode se aplicar depois que as configurações gerenciadas e os hooks de plugins forem carregados. Regras ou hooks relevantes ainda podem impedi-la.
has no effect in this session	A confirmação ou negação habitual permanece durante toda a sessão. Corrija a causa e reinicie.
has no effect while the Windows registry cannot be read for managed settings	As verificações habituais permanecem enquanto a consulta ao Registro falha. Uma consulta posterior bem-sucedida pode ativar a exceção sem reiniciar.

Em um aplicativo que usa o Agent SDK, forneça a opção stderr para receber o aviso. A ausência de saída não comprova que a confirmação para caminhos críticos continua ativa. Verifique se a sessão herdou a variável de inicialização, qual modo de permissão está ativo e se a sessão foi iniciada indiretamente.

Se o diagnóstico terminar antes de exibir um aviso, examine primeiro o erro de inicialização. Uma falha de autenticação ou configuração é um problema separado dessa opção de permissão.

Nove motivos para a variável não ter efeito

Confira a versão, o ambiente de inicialização e o modo ativo antes de alterar qualquer outra configuração. Depois, identifique qual das exceções documentadas corresponde ao seu caso.

Estas são causas alternativas. Mantenha as proteções que a equipe configurou intencionalmente.

Causa	O que verificar e como agir
1. Outro componente trata as solicitações de permissão	Procure --permission-prompt-tool ou um callback canUseTool do SDK sem --permission-prompts none. Confira também qualquer hook PermissionRequest, independentemente do critério de correspondência, ou um mod que trate esse evento. Remova um componente configurado por engano e reinicie.
2. A sessão roda em um painel gráfico de chat	O painel de chat da extensão do VS Code e o aplicativo Desktop não aplicam essa exceção. Inicie a CLI no seu próprio terminal, inclusive no terminal integrado de uma IDE.
3. Uma regra deny ou ask se aplica a Bash, Edit ou Read	Qualquer regra desse tipo desativa a exceção, mesmo sem relação com exclusões. Depois de lida, ela impede a exceção até o fim da sessão, mesmo que seja removida. Uma alteração autorizada da regra exige reinício. Para omitir uma ferramenta, use --tools em vez de uma regra deny.
4. Leituras fora dos diretórios de trabalho estão bloqueadas	Verifique permissions.blockReadsOutsideWorkingDirectories. Se a intenção for desativar essa proteção, remova todas as configurações que a definem como true e reinicie.
5. O Claude Code foi iniciado dentro de outra sessão	A inicialização pela ferramenta Bash ou por um hook de outra sessão mantém as verificações habituais, mesmo com a variável na linha de comando. Inicie pelo seu próprio shell. Essa restrição de sessões aninhadas não é uma barreira de segurança.
6. Um hook PreToolUse retorna ask	Examine a decisão do hook para a exclusão. Corrija uma resposta ask não intencional; uma resposta allow, sozinha, não contorna a verificação normal de caminhos críticos.
7. O próprio Claude Code criou a sessão	O Claude Code inicia suas sessões em segundo plano sem a variável. Isso também ocorre com sessões de agentes de uma equipe em painéis divididos e sessões criadas por um servidor Remote Control. Quando precisar da exceção, use uma sessão iniciada diretamente no terminal.
8. As configurações gerenciadas não foram carregadas	Peça ao administrador que corrija a origem de configurações com falha. Use claude doctor para investigar falhas na obtenção de configurações gerenciadas pelo servidor. Falhas na consulta ao Registro têm o comportamento específico descrito abaixo.
9. A consulta ao Registro do Windows falha	Isso se aplica ao Windows e ao WSL, mesmo quando o WSL não usa configurações do Registro. As causas incluem interoperabilidade desativada, Windows em idioma diferente do inglês ou um contêiner sobre um kernel WSL2. Só reative a interoperabilidade se isso for permitido; caso contrário, faça a limpeza pretendida manualmente.

Após uma alteração autorizada, repita a verificação do aviso de inicialização. Se um hook do Windows se comportar de forma inesperada, siga as verificações do executável ativo e dos hooks do Windows antes de alterar a política de permissões.

Audite as origens da variável e aplique a política da equipe

Audite tanto os arquivos de configuração quanto o ambiente do processo que inicia o Claude Code. Uma busca sem resultados no repositório não exclui variáveis injetadas pelo serviço de CI hospedado.

Encontre configurações persistentes e rejeite a variável no CI

Pesquise no repositório e nos perfis comuns de shell sem imprimir o conteúdo dos arquivos. O exemplo abaixo usa Bash, exige ripgrep e imprime os nomes dos arquivos com ocorrências:

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

Revise as ocorrências antes de alterá-las; uma menção em um documento não equivale a uma variável exportada. Amplie a busca para arquivos carregados pelos perfis, scripts de inicialização, definições de contêineres e arquivos de ambiente.

Inspecione também as variáveis de CI nos escopos da organização, do repositório, do ambiente e do job. Revise o ambiente do serviço executor e qualquer etapa que altere variáveis antes de iniciar o Claude Code. Não registre o ambiente completo nos logs.

Coloque esta verificação Bash imediatamente antes da chamada ao Claude Code em um script de inicialização controlado pelo CI:

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

A verificação rejeita qualquer presença da variável, inclusive um valor vazio ou 0. Essa é uma política conservadora do script; não significa que todo valor ative o recurso. Ela protege apenas as chamadas que realmente passam pela verificação.

Desative o modo bypass por meio de configurações gerenciadas

Bloqueie o modo bypassPermissions quando a equipe não precisar dele. Como a exceção exige esse modo, o bloqueio elimina seu pré-requisito. Um bloco env nas configurações gerenciadas não neutraliza essa variável exclusiva do ambiente de inicialização.

Adicione este controle às configurações gerenciadas ativas da organização, preservando as demais opções:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Para distribuição por arquivo, use:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux e WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Reinicie o Claude Code e consulte /status. Confirme que Setting sources lista a origem gerenciada esperada. Uma nova tentativa de entrar em bypassPermissions deve ser rejeitada.

Confira a origem selecionada antes da implantação: uma origem gerenciada de maior prioridade pode substituir o arquivo distribuído. Proteja a política pela administração das máquinas; quem tiver acesso de administrador local poderá editar uma política baseada em arquivo.

Qual proteção é mais confiável: regras deny ou sandbox?

Use o isolamento do sistema operacional para limitar o acesso ao sistema de arquivos. As regras de permissão controlam chamadas individuais de ferramentas. A confirmação para caminhos críticos é uma verificação adicional, não uma proteção completa do sistema de arquivos.

Mantenha as regras deny úteis. Porém, as regras de Bash comparam o texto do comando: Bash(rm *) não cobre todas as formas de chamada nem outros programas que excluem arquivos. Revise também os hooks e mods instalados, pois extensões podem afetar as decisões de permissão.

Em instalações compatíveis de macOS, Linux e WSL2, adicione estas configurações de sandbox à política gerenciada:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Essa configuração impede a inicialização quando o sandbox não está disponível e desativa novas tentativas fora dele. O Windows nativo não oferece suporte a esse sandbox; portanto, essa política impediria a inicialização nele.

Consulte /sandbox para verificar a configuração efetiva e as dependências. Audite excludedCommands e os caminhos com permissão de escrita. O modo estrito ainda permite essas exceções, e as configurações de usuário ou --settings podem ampliar algumas listas.

Comandos executados no sandbox ainda podem excluir dados do projeto com permissão de escrita. O isolamento integrado também não abrange todos os hooks, servidores MCP iniciados localmente ou ferramentas de arquivos. Para tarefas sem supervisão que precisem dessa proteção mais ampla, isole todo o processo do Claude Code em um contêiner, VM ou ambiente de execução isolado. Não monte caminhos valiosos da máquina hospedeira com permissão de escrita e mantenha uma cópia de trabalho que possa ser recriada.