Verificando acesso...

MÓDULO 4.3

⚡ Modo YOLO

"YOLO" não é nome oficial da Anthropic. Por trás do termo existem duas coisas distintas: --dangerously-skip-permissions (sem proteção) e Auto Mode (mar/2026, classifiers ML com backstop). Este módulo separa as duas e mostra quando cada uma vive.

6
Tópicos
20
Minutos
Avançado
Nível
Segurança
Tipo
1

--dangerously-skip-permissions

Flag do Claude Code que desliga TODOS os prompts de permissão. Claude executa Bash, Write, Edit, qualquer ferramenta — sem perguntar. O nome carrega o aviso embutido: dangerously.

⚠️ O que essa flag faz

claude --dangerously-skip-permissions
  • • Zero prompt de permissão pra qualquer ferramenta
  • • Bash rodando comandos arbitrários sem aprovação
  • • Write/Edit sobrescrevendo qualquer arquivo
  • • Apaga sem confirmar

💡 Dica prática

A Anthropic nomeou a flag assim de propósito. Se você precisa digitar "dangerously" toda vez, é difícil esquecer. Use só em ambientes que você está disposto a perder.

2

🤖 Auto Mode (mar/2026)

Alternativa muito mais segura ao --dangerously. Auto Mode usa classifiers de ML que analisam cada ação proposta. Posicionado entre prompts manuais e sem guardrails — usuários aprovam 93% dos prompts manualmente; Auto Mode automatiza esses casos seguros.

🧠 Como o Auto Mode funciona

  • Classifier ML analisa cada ação proposta antes de executar
  • 93% dos casos que humanos aprovariam manualmente viram automáticos
  • Backstop: 3 negações consecutivas OU 20 negações totais na sessão param e escalam pra humano
  • Multi-agent handoff guard: classifiers rodam nos dois lados do handoff entre subagentes — saída e retorno — pra detectar prompt injection
  • Resultados suspeitos recebem aviso de segurança prepended, não são descartados em silêncio

Por que Auto Mode é o caminho recomendado

Velocidade quase idêntica ao --dangerously, mas com um ML treinado pra parar nas 7% das ações que valem inspeção humana. É o sweet spot entre produtividade e segurança.

3

⚠️ Riscos reais

Quem nunca pagou o preço subestima. Listar os 5 desastres possíveis evita o sexto.

1

rm -rf indevido

Claude decide "limpar build artifacts" e remove pasta crítica. Sem prompt = sem chance de cancelar.

2

git push em main

Commit + push em main com código quebrado, deploy automático dispara.

3

Vazamento de secret

Claude lê .env, inclui no commit por engano, push pra repo público. Segredo na história do git pra sempre.

4

Comando em DB de prod

psql ou kubectl apontado pra produção — TRUNCATE acidental.

5

Prompt injection

README malicioso ou issue do GitHub injeta instrução; Claude executa sem ninguém ver.

4

🟢 Quando ligar (sandbox seguro)

Velocidade absoluta vale quando "perder tudo" é OK. Demo cinemática sai dali.

✓ Ambientes ok pra --dangerously

  • Container Docker descartável
  • VM efêmera (gitpod, codespace)
  • Devcontainer isolado
  • Repo throwaway novo
  • Sandbox de aprendizado

🤖 Onde Auto Mode é o melhor caminho

  • Repo de trabalho com backup
  • Refatorações grandes
  • Setup de projeto novo
  • Loop autônomo de testes
  • Workflows agênticos longos

💡 Dica prática

Em demo "wow", devcontainer + --dangerously dá um efeito incrível: Claude trabalha 10 minutos sem interrupção, sala vê o output rolando. Mas faça isso só dentro do devcontainer.

5

🔴 Quando NUNCA ligar

A regra inegociável. Se a sala estiver em laptop corporativo, recomende Auto Mode — não --dangerously.

🚫 Lista de ambientes proibidos

  • • Repo principal da empresa (mesmo com branch nova)
  • • Máquina com SSH key carregada
  • • Ambiente com kubectl apontado pra prod
  • • Qualquer máquina com .env contendo secrets reais
  • • Servidor de prod, jamais
  • • Máquina compartilhada (work, cliente)
  • • Repo com histórico crítico (Loss of trust + perda de produção)

📋 Checklist antes de digitar --dangerously

  • ☐ Estou em container ou VM efêmera?
  • ☐ Existe backup recente de tudo que importa?
  • ☐ Esta máquina tem SSH key ou .env crítico?
  • ☐ kubectl/aws/gcloud apontados pra prod?
  • ☐ Posso destruir esse ambiente agora e seguir em paz?
  • ☐ Se a resposta de qualquer um for "não" — use Auto Mode
6

↔️ YOLO vs auto-accept

Auto-accept (VS Code extension) é granular: aceita edits sem perguntar, mas mantém Bash sob prompt. --dangerously desliga TUDO. Configurável no VS Code via claudeCode.initialPermissionMode.

📊 Tabela comparativa

MODO                     | Edit | Bash | Web | Risco
-------------------------|------|------|-----|------
Manual (default)         |  ?   |  ?   |  ?  | baixo
Auto-accept edits (VSC)  |  ✓   |  ?   |  ?  | médio
Auto Mode (classifiers)  | ML   | ML   | ML  | médio
--dangerously            |  ✓   |  ✓   |  ✓  | ALTO

✓ Combinação recomendada

  • Default: prompt manual
  • Sessão longa: Auto Mode
  • Sandbox: --dangerously
  • VS Code rapid edits: auto-accept

✗ Confusões comuns

  • "Auto-accept = YOLO" — não, é só edits
  • "--dangerously sem backup"
  • "Auto Mode aceita TUDO" — não, tem ML

📋 Resumo do Módulo

--dangerously desliga TUDO — sem guardrail, sem proteção
Auto Mode (mar/2026) é ML + backstop — 93% automatizado, 3 negações param
5 desastres clássicos — rm, push, secret, DB, prompt injection
Sandbox seguro = ok pra --dangerously — Docker, VM, throwaway
Prod, secrets, máquina compartilhada = NUNCA — regra inegociável
Auto-accept ≠ YOLO — auto-accept é só edits

Próximo Módulo:

4.4 — 📜 Instructions (system prompt do projeto)