O Claude Code apagou os meus ficheiros? A camada que o impede

Se o Claude Code apagou os seus ficheiros, só recupera o que existe noutro sítio. Para impedir que o Claude Code volte a apagar ficheiros, faça push do seu trabalho e depois acrescente uma regra de negação e um hook. Este guia configura cada camada no Claude Code em cerca de 30 minutos e mostra o que cada uma deixa passar.

Usamos uma proteção contra eliminações em todas as sessões do Claude Code no nosso próprio repositório. Os exemplos usam a Marrowby Tiles, uma loja de azulejos fictícia; as regras e os padrões são iguais aos nossos.

O Claude Code apagou ficheiros: o que se recupera

O caminho de volta constrói-se antes da eliminação, nunca depois.

Acabou de perder ficheiros? Execute estes passos por ordem:

1. Procure na pasta _archive/ do projeto.
2. Execute git status para listar os ficheiros versionados em falta.
3. Tem commit mas não tem push? git restore --source=HEAD --staged --worktree <path> recupera-o a partir do seu último commit local.
4. Execute git fetch e depois git restore --source=origin/main <path> para recuperar um ficheiro tal como estava no último push (substitua pelo nome do seu branch).
5. Se foi um commit que removeu o ficheiro, git log --diff-filter=D -- <path> indica qual.

O que estes passos não apanharem desapareceu do disco.

Porque é que o Claude Code apaga ficheiros

Um pedido de aprovação protege quem está ao teclado. Não faz nada por uma execução às 3 da manhã.

Os agentes apagam por motivos banais: quando lhe pedem para «começar do zero», o Claude Code esvazia primeiro a pasta, e no nosso teste descartável escolheu find -delete por iniciativa própria. O Git também apaga: git reset --hard, git clean, git restore, git checkout -- e git stash drop deitam fora trabalho sem commit, e um simples git stash esconde-o até fazer pop.

O pedido de aprovação é a camada mais fraca. As pessoas aprovam o que leem na diagonal, e as nossas execuções agendadas de agentes usam --dangerously-skip-permissions, por isso não aparece pedido nenhum.

Veja como o ConvOps coloca um passo de aprovação antes de cada merge(abre num novo separador), para que uma eliminação feita durante uma execução sem supervisão nunca chegue ao main sem o sim de uma pessoa.

Que camada trava mesmo uma eliminação

A lista de negação é uma lomba. O hook é um muro com falhas conhecidas. O trabalho com push é o chão.

O que é uma regra de negação? Uma regra de negação (deny) é uma linha nas definições do Claude Code que recusa qualquer comando Bash cujo texto corresponda a um padrão, como Bash(rm *).

O que é um hook PreToolUse? Um hook PreToolUse é um script que o Claude Code executa antes de uma chamada a uma ferramenta; quando o script termina com o código 2, a chamada é bloqueada e o agente lê a mensagem do script.

Há quatro camadas entre a eliminação de um agente e os seus ficheiros, e só o pedido de aprovação é ignorado quando ninguém está a ver.

Nas nossas execuções de teste, tanto a regra de negação como o hook bloquearam sozinhos o rm. Nenhum dos dois travou tudo.

Cada camada, por si só, deixa passar alguma coisa: um find com delete passa pela regra de negação e um one-liner em Python passa pelo hook, e a camada seguinte cobre a falha.

Faça commit e push antes de um agente tocar em alguma coisa

O trabalho sem push morre com a pasta onde está.

Antes de iniciar o Claude Code, guarde tudo no remoto:

git status
git add src/ data/products.json
git commit -m "Save work before the agent run"
git push

Inicie o agente apenas numa árvore limpa e atualizada com o remoto. Os nossos fluxos de trabalho fazem push do resultado de cada passo antes de avançar, e um stop hook impede que uma sessão termine com trabalho sem push. Execute o trabalho arriscado numa git worktree, como ~/marrowby-shop-run-0412, ou numa execução isolada que parte do remoto.

Acrescente regras de negação ao Claude Code

As regras de negação comparam o texto do comando, não o que o comando faz.

Este bloco vai no .claude/settings.json do projeto:

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(git rm *)",
      "Bash(git clean *)",
      "Bash(git reset *)",
      "Bash(git restore *)",
      "Bash(git checkout -- *)",
      "Bash(git stash drop *)",
      "Bash(git stash clear *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ]
  }
}

Bash(rm *) e o formato mais antigo Bash(rm:*) comportaram-se da mesma forma na versão 2.1.295, mesmo com --dangerously-skip-permissions. A documentação dos modos de permissão(abre num novo separador) da Anthropic diz que as regras de negação «bloqueiam em todos os modos, incluindo bypassPermissions», e inclui o modo automático nesses modos. A documentação de permissões(abre num novo separador) diz também que uma regra de negação «não é uma fronteira de segurança em torno do programa». No nosso teste, find -delete, /bin/rm e um one-liner python3 -c apagaram o ficheiro; sh -c 'rm ...' foi travado.

Acrescente um hook que bloqueia e indica uma saída

Um bloqueio sem alternativa ensina o agente a contorná-lo.

O .claude/settings.json completo, com uma chave hooks ao lado de permissions (guia de hooks(abre num novo separador)):

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(git rm *)",
      "Bash(git clean *)",
      "Bash(git reset *)",
      "Bash(git restore *)",
      "Bash(git checkout -- *)",
      "Bash(git stash drop *)",
      "Bash(git stash clear *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3",
            "args": ["${CLAUDE_PROJECT_DIR}/.claude/hooks/delete-guard.py"],
            "timeout": 5
          }
        ]
      }
    ]
  }
}

${CLAUDE_PROJECT_DIR} aponta para a raiz do projeto, por isso o caminho continua válido depois de o agente mudar de pasta. Um caminho errado para o script faz o python3 terminar com 2, e todas as chamadas Bash ficam bloqueadas com um erro can't open file (não é possível abrir o ficheiro). Ou seja, falha pelo lado seguro, e o primeiro comando mostra-o logo.

E o script, .claude/hooks/delete-guard.py:

import json, re, sys

ARCHIVE = ("file deletion is denied, archive instead: move it to _archive/ "
           "in this project (mkdir -p _archive && mv <path> _archive/)")
PATTERNS = [
    (r"\brm\s+-rf\b", "rm -rf is irreversible recursive deletion, " + ARCHIVE),
    (r"(?<!-)\brm\b", ARCHIVE),
    (r"\brmdir\b", ARCHIVE),
    (r"\bfind\b.*\s-delete\b", ARCHIVE),
    (r"\bgit\s+checkout\s+--\s+", "git checkout -- reverts uncommitted work"),
    (r"\bgit\s+reset\b", "git reset can destroy commit history"),
    (r"\bgit\s+restore\b", "git restore reverts uncommitted work"),
    (r"\bgit\s+clean\b", "git clean deletes untracked files"),
    (r"\bgit\s+stash\b", "git stash can drop uncommitted work"),
    (r"\bgit\s+push\b.*\s(?:-f|--force)\b", "force push overwrites remote history"),
]
MESSAGE_ARG = re.compile(r"""(?:^|\s)(?:-m|--message)(?:=|\s+)(?:"[^"]*"|'[^']*'|\S+)""")

def main():
    try:
        command = json.load(sys.stdin)["tool_input"]["command"]
    except Exception:
        return 0
    scanned = MESSAGE_ARG.sub(" ", command)
    for pattern, reason in PATTERNS:
        if re.search(pattern, scanned):
            print(f"BLOCKED: Destructive command detected.\n  Reason: {reason}\n"
                  f"  Command: {command}", file=sys.stderr)
            return 2
    return 0

sys.exit(main())

Cada linha tem uma razão de ser:

• O código de saída 2 bloqueia a chamada; o agente lê o stderr.
• (?<!-)\brm\b apanha qualquer token rm, incluindo /bin/rm. O lookbehind mantém docker run --rm permitido.
• Uma entrada ilegível termina com 0: nunca bloqueia uma sessão, e passa sem verificação.
• Sem padrão para interpretadores. Os one-liners com os.remove e shutil.rmtree passam: o hook só bloqueia o que os seus padrões indicam.

Um hook corre em todas as chamadas Bash, seja o que for que tenham dito ao agente (graph engineering). É por isso que uma regra destas pertence a um hook e não a um CLAUDE.md que não para de crescer.

Teste o hook antes de confiar nele

Uma regex por testar é um palpite.

Passe um payload de exemplo ao script:

echo '{"tool_name":"Bash","tool_input":{"command":"find exports -mindepth 1 -delete"}}' \
  | python3 .claude/hooks/delete-guard.py; echo "exit $?"

Acrescente um caso de teste por formato, incluindo as falhas esperadas:

Termine com um bloqueio real: numa pasta de testes, peça ao Claude Code para apagar um ficheiro descartável.

Uma tentativa de eliminação, passo a passo

O melhor bloqueio é aquele de que o agente recupera sozinho.

O hook bloqueia o find com delete do agente com exit 2, a mensagem indica a pasta _archive/ do projeto, e o agente move para lá os ficheiros em vez de os apagar, por isso nada é eliminado.

1. Pedido. A Marrowby Tiles pede: «Gere de novo a exportação do feed de produtos, comece do zero.» O agente executa find exports -mindepth 1 -delete (marcador 1).
2. Bloqueio. O hook corresponde a \bfind\b.*\s-delete\b e termina com 2; a mensagem indica _archive/ neste projeto (marcador 2).
3. Desvio. O agente executa mkdir -p _archive && mv exports/* _archive/ (marcador 3).
4. Resultado. 2 itens movidos, 0 eliminados: _archive/product-feed.csv e _archive/old/ (marcador 4).

O que corre mal com uma proteção contra eliminações

Preferimos explicar um bloqueio indevido a restaurar uma pasta.

Uma pesquisa só de leitura por «rm -rf» é bloqueada porque o hook compara texto, e mantemos esse falso positivo de propósito: um bloqueio indevido é melhor do que uma eliminação que escapa.

Quatro falhas que tivemos, cada uma com a sua regra:

• Uma pesquisa foi bloqueada. Um grep -rn "rm -rf" scripts/ só de leitura correspondeu ao padrão. Regra: manter o falso positivo (falhar pelo lado seguro) e o respetivo caso de teste.
• As mensagens de commit ativavam o hook. «Never rm -rf exports» correspondia como se fosse um comando. Regra: retirar primeiro os argumentos -m e --message entre aspas.
• O caminho de arquivo saía do projeto. A nossa mensagem de bloqueio indicava uma pasta na raiz do nosso repositório, e um agente de teste noutro projeto moveu para lá os seus ficheiros. Regra: indicar _archive/ neste projeto.
• Um comando git apagou trabalho. Um git checkout -- em duas pastas apagou trabalho sem commit. Regra: aplicar também a negação e o hook aos comandos git que eliminam.

Quando ninguém está a ver

Os pedidos de aprovação não são um controlo para execuções sem supervisão. Os pontos de aprovação e o isolamento são.

As nossas execuções sem supervisão ignoram os pedidos por conceção. Há três controlos que as protegem:

Os nossos fluxos de trabalho param para uma aprovação onde está o risco (humano no circuito), e o nosso ciclo de reparação do site corre num ambiente isolado.

Copie hoje o bloco de negação e o hook. Depois, execute os seus trabalhos de agentes sem supervisão como tarefas do ConvOps(abre num novo separador), com um passo de aprovação antes do merge e uma execução isolada.

A mesma proteção no OpenCode e no Kimi Code CLI

Um formato de proteção, três ficheiros.

Testámos esta proteção em projetos de teste; a proteção que usamos no dia a dia corre no Claude Code.

A mesma verificação de eliminação antes da execução vive no ficheiro próprio de cada ferramenta: um hook PreToolUse no Claude Code, um plugin tool.execute.before no OpenCode e uma entrada hooks no Kimi Code CLI.

OpenCode 1.18.31

No OpenCode, as regras de negação em permission.bash travaram rm e find -delete, e o agente apagou então com um one-liner em Python. Um plugin, .opencode/plugins/delete-guard.js, verifica cada comando bash em tool.execute.before, com os.remove e shutil.rmtree entre os seus padrões, e lança uma mensagem que indica _archive/. Bloqueou os seis formatos que experimentámos, e o agente arquivou em vez de apagar. opencode run --pure ignora os plugins, incluindo a proteção.

Kimi Code CLI 0.31.1

O Kimi Code CLI (que corre modelos como o Kimi K3) aceita um hook PreToolUse em ~/.kimi-code/config.toml:

[[hooks]]
event = "PreToolUse"
matcher = "Bash"
command = "node ~/.kimi-code/hooks/delete-guard.mjs"

O script termina com o código 2 e a mesma mensagem e, em modo yolo, bloqueou os seis formatos. Os hooks vivem apenas na configuração do utilizador, nunca no projeto. A regra nativa Bash(rm *) nunca correspondeu a um caminho com barra; Bash(rm */**) corresponde.

Seja qual for a ferramenta, a ordem é a mesma: push, negação, hook, teste.