Como Parei de Ter Medo do Claude Code e Aprendi a Amar os Guard Hooks

Imagine a seguinte situação: você está tranquilamente acomodado em sua poltrona, tomando um café, enquanto seu agente de IA favorito (seja Claude Code, Cursor ou GitHub Copilot CLI) alegremente informa que completou uma tarefa de refatoração. De repente, rm -rf ou, ainda mais engraçado, sudo rm -rf / aparece no terminal. O café fica preso em sua garganta, e horas de trabalho não remunerado — aquelas alterações que você ainda não commitou — evaporam na oblivion digital.

Essa sensação familiar de impotência diante das "alucinações" de redes neurais? Na minha prática, esses momentos aconteceram algumas vezes, e cada vez foi uma lição dolorosa. É por isso que o projeto destructive_command_guard (ou simplesmente dcg) imediatamente chamou minha atenção. Não é uma "plataforma revolucionária", apenas um guarda-costas muito rápido e corajoso para o seu terminal.

O que é essa criatura

Em resumo, dcg é um hook de alto desempenho escrito em Rust. Ele intercepta o processo de comunicação entre você (ou seu agente de IA) e a linha de comando. Sua única tarefa é interceptar um comando destrutivo antes que ele tenha chance de quebrar algo.

A ferramenta suporta praticamente tudo que está em alta no mundo do desenvolvimento com IA: Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor IDE, Grok e até opções mais exóticas como Hermes Agent. O utilitário funciona no Linux, macOS e Windows (via WSL ou nativamente via PowerShell).

Por que um grep comum não vai te salvar

Pode parecer: por que criar um projeto Rust inteiro quando você pode escrever um simples script em Bash ou Python? O autor do projeto, Jeffrey Emanuel, seguiu esse caminho: a primeira versão era em Python. Mas rapidamente ficou claro que as tarefas modernas exigem uma abordagem mais refinada.

O contexto é tudo

dcg não apenas procura a string rm -rf. Ele analisa o contexto. Se um agente escreve "não use rm -rf /" na documentação, o hook vai entender que isso é dado e não vai bloquear a escrita do arquivo. Mas assim que se trata de realmente executar o comando — o bloqueio entra em ação.

Para isso, é usado um sistema de verificação em três níveis:

1. Busca rápida de substring (Quick Reject) via instruções SIMD. Isso leva microssegundos.
2. Normalização de comandos (espaços extras são removidos, caminhos absolutos são substituídos por relativos).
3. Verificação contra padrões complexos usando expressões regulares.

Proteção contra ameaças "ocultas"

Um recurso interessante — escaneamento de Heredocs e scripts inline. Se um agente decidir chamar rm -rf, um simples filtro de linha de comando vai deixar passar. dcg investiga dentro dessas construções, analisa usando AST (Abstract Syntax Trees) e encontra chamadas de funções suspeitas.

O que exatamente ele bloqueia

Fora da caixa, mesmo que você não tenha configurado nada, dcg protege contra as coisas mais assustadoras:

• rm -rf, sudo rm -rf /, dd if=/dev/zero.
• git push --force fora de pastas temporárias.
• Formatação de disco, exclusão de partições e outras delícias do sistema.

Mas a melhor parte são os "packs" (pacotes de segurança). Existem mais de 50 deles no repositório. Você pode ativar a proteção para tecnologias específicas no seu dcg.toml:

[packs]
enabled = [
    "database.postgresql",    # Заблокирует DROP TABLE
    "kubernetes.kubectl",     # Не даст удалить namespace по ошибке
    "cloud.aws",              # Спасет от случайного terminate-instances
    "containers.docker",      # Ограничит docker system prune
]

Como fica na prática

Digamos que seu agente decidiu perder a cabeça e resetar todas as alterações. Você verá algo assim no terminal:

════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes

Command: git reset --hard HEAD~5

Tip: Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════════════

O bloqueio vem com conselhos úteis. Na maioria dos casos, o agente, tendo recebido essa rejeição, percebe o erro e sugere um caminho mais seguro, por exemplo, usando git stash.

Bordas técnicas e performance

O que me conquistou foi a abordagem de performance. O autor afirma latência sub-milissegundos. Para quem gosta de detalhes:

• Rust + SIMD: instruções vetoriais do processador são usadas para busca de palavras-chave extremamente rápida.
• Motor Regex Duplo: padrões simples são tratados por um motor rápido com tempo de execução linear, enquanto os complexos (onde lookaheads/lookbehinds são necessários) são processados por um regex mais poderoso, porém mais lento.
• Zero-alocação: em caminhos críticos, o programa tenta não alocar memória heap, o que é crítico quando o hook é chamado a cada tecla pressionada ou comando do agente.

A propósito, o projeto implementa uma filosofia fail-open. Se dcg não tiver tempo de analisar o comando dentro do orçamento de tempo alocado (200ms por padrão), ele deixa passar. Isso é feito para que a ferramenta nunca se torne um "freio" que atrapalhe o trabalho normal. Na minha visão, um compromisso razoável entre segurança e conveniência.

Como integrar ao seu fluxo de trabalho

A forma mais fácil de experimentar é executar o script de instalação do README. Ele vai detectar seu SO, baixar o binário correto e configurar as definições nos configs dos agentes de IA.

Para Claude Code, fica assim adicionar uma seção ao claude_desktop_config.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "dcg" }]
      }
    ]
  }
}

E se você trabalha em equipe e quer ter certeza de que ninguém commitou um git push --force destrutivo ou um pipeline de CI quebrado, existe um modo de scan:

dcg scan --staged

Você pode conectá-lo a um pre-commit hook, e ele vai verificar todos os arquivos que você está tentando enviar para o Git.

Algumas palavras sobre as desvantagens

Não existem ferramentas perfeitas. O que pode dar errado?

1. Falsos positivos: Apesar da análise avançada, às vezes dcg pode bloquear comandos perfeitamente legítimos. Para esse caso, existe uma "saída de emergência" via variável de ambiente DCG_BYPASS ou sistema DCG_UNLOCK_CODE.
2. Complexidade de configuração: Se você precisa de algo específico, terá que mergulhar nos configs TOML.
3. Rust Nightly: Se você quiser compilar o projeto do zero, precisará da versão nightly do Rust, já que recursos da edição de 2024 são usados.

Quem precisa disso

Se você usa agentes de IA mais de uma vez por semana e confia neles para executar comandos no terminal — instale sem hesitar. É um seguro barato. Isso é especialmente relevante para iniciantes que podem não perceber imediatamente que o comando de "limpeza de cache" sugerido pela rede neural na verdade apaga metade do sistema.

Para desenvolvedores experientes, é mais uma forma de economizar nervos. Todos sabemos como é fácil pressionar Ctrl+C no piloto automático, e depois ficar desesperado lembrando quando foi o último backup.

dcg é aquela ferramenta que roda silenciosamente em segundo plano e "não pede comida" até chegar um momento crítico. Não faz mágica, apenas analisa bem strings e sabe como são os comandos ruins. Em um mundo onde estamos cada vez mais delegando a escrita e execução de código para máquinas, esses "fusíveis digitais" estão se tornando um atributo obrigatório do ambiente de trabalho.

Vale a pena experimentar pelo menos para ver como software moderno em Rust é rápido. E você já confiou na sua IA para deletar arquivos? Como isso terminou?