[BUG] Agent desinstalou PostgreSQL do sistema e apagou permanentemente banco de dados de outro projeto não relacionado

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Resumo

Durante uma sessão para migrar um projeto de PostgreSQL para SQLite, a meu
pedido o agente também desinstalou o PostgreSQL da máquina local. Nesse
processo, apagou permanentemente (sem passar pela Lixeira do Windows) o
diretório de dados do PostgreSQL inteiro — que continha o banco de dados de
OUTRO projeto não relacionado, ainda em uso.

Como aconteceu

1. Pedi para migrar um projeto (relatorio-ti) de PostgreSQL para SQLite.

O agente fez a migração, conferiu os dados e testou tudo corretamente.

1. Depois, pedi para "remover o postgres e deixar o sql nativo".
2. O agente perguntou se eu queria: (a) apagar só o banco desse projeto,

(b) desinstalar o PostgreSQL inteiro da máquina, ou (c) não mexer em
nada. Escolhi desinstalar tudo.

1. O agente notou que o diretório de dados do PostgreSQL tinha ~2.8 GB —

bem mais do que os poucos KB que o banco do meu projeto ocuparia — e,
corretamente, parou para perguntar se aquele PostgreSQL era usado por
outra coisa além do projeto atual.

1. Respondi de forma hesitante ("seria somente desse projeto"), e o agente

tratou essa resposta como suficiente para prosseguir com uma ação
irreversível em nível de sistema operacional.

1. O agente desinstalou o PostgreSQL via winget e, como a pasta de dados

sobrou depois do uninstaller padrão, apagou manualmente
C:\Program Files\PostgreSQL inteiro com Remove-Item -Recurse -Force
(que não usa a Lixeira do Windows).

1. Só depois descobri que outro projeto, completamente não relacionado ao

que eu tinha pedido para trabalhar, também usava essa mesma instância
de PostgreSQL local (mesmo serviço, porta 5432) com seu próprio banco.
Os dados desse projeto foram apagados junto.

O que eu esperava

Para uma ação irreversível, de escopo de sistema operacional (não apenas
do repositório em que estávamos trabalhando), afetando dados fora de
controle de versão e sem backup, eu esperava que o agente:

• Verificasse de forma mais rigorosa e independente quais bancos/dados

existiam antes de apagar — especialmente já tendo notado sozinho uma
discrepância de tamanho suspeita (2.8 GB vs. poucos KB esperados).

• Desse menos peso a uma resposta hesitante/incerta minha como confirmação

definitiva para uma ação destrutiva de sistema.

• Preferisse um passo intermediário reversível (por exemplo, mover a pasta

de dados para outro lugar em vez de apagar direto, ou gerar um backup
rápido antes de deletar) quando a irreversibilidade é cara e a
reversibilidade é barata.

Impacto

Perda permanente (sem Lixeira, sem cópia de sombra/VSS disponível no
sistema) dos dados de um segundo projeto não relacionado ao que eu tinha
pedido para o agente trabalhar.

Sugestão

Reforçar as salvaguardas para ações destrutivas que saem do escopo do
diretório do projeto atual e afetam o sistema operacional como um todo
(desinstalar software, apagar diretórios do sistema, etc.) — por exemplo,
exigindo confirmação extra depois que o próprio agente identifica um sinal
de risco (tamanho anômalo, múltiplos projetos no mesmo host), ou preferindo
por padrão um passo reversível (lixeira/backup) antes de exclusão
permanente fora do repositório de trabalho.

relatorio_incidente_postgresql.pdf

What Should Happen?

Antes de executar uma ação irreversível fora do escopo do repositório
de trabalho (desinstalar software do sistema operacional, apagar
diretórios inteiros como C:\Program Files\PostgreSQL), o Claude
deveria:

1. Verificar de forma independente e confiável se o recurso é

compartilhado com outros projetos/serviços no mesmo host — não
apenas perguntar uma vez e aceitar uma resposta hesitante do
usuário como confirmação suficiente, especialmente depois de já
ter detectado um sinal de risco por conta própria (no caso, o
diretório de dados tinha 2.8 GB, muito mais do que o esperado
para o banco do projeto em questão).

1. Preferir, por padrão, um caminho reversível antes de apagar

permanentemente: por exemplo, mover a pasta para outro local
(renomear/backup) em vez de usar Remove-Item -Force direto, que
não passa pela Lixeira do Windows.

1. Deixar claro para o usuário, antes de agir, que a ação vai

apagar TODOS os bancos daquela instância PostgreSQL (não só o do
projeto atual) — não apenas descrever a ação em termos genéricos
como "desinstalar o PostgreSQL inteiro".

Resultado esperado: o banco de um segundo projeto não relacionado
não deveria ter sido apagado como efeito colateral de uma tarefa
pedida para um projeto diferente.

Error Messages/Logs

PS> winget uninstall --id PostgreSQL.PostgreSQL.17 --silent --disable-interactivity
Encontrado PostgreSQL 17  [PostgreSQL.PostgreSQL.17]
Iniciando a desinstalação do pacote...
Desinstalado com êxito

# Verificação pós-uninstall mostrou que o winget "concluiu" mas nada
# tinha sido removido de fato (serviço, registro e arquivos intactos):
PS> Get-Service -Name "*postgres*"
Status   Name               DisplayName
------   ----               -----------
Running  postgresql-x64-17  postgresql-x64-17 - PostgreSQL Serv...

PS> Test-Path "C:\Program Files\PostgreSQL\17"
True

# O agente então rodou o uninstaller nativo em modo unattended:
PS> & "C:\Program Files\PostgreSQL\17\uninstall-postgresql.exe" --mode unattended

# Isso removeu serviço/registro/binários, mas deixou a pasta "data"
# (2.8 GB) no disco — comportamento padrão do instalador EDB, que
# preserva dados por segurança. O agente então apagou essa pasta
# manualmente, sem checar se outro processo/serviço no host também
# usava esse mesmo diretório de dados:
PS> Remove-Item -Path "C:\Program Files\PostgreSQL" -Recurse -Force
Removido.

PS> Test-Path "C:\Program Files\PostgreSQL"
False

# Esse diretório continha, além do banco do projeto em migração, o
# banco "gestao_trabalhista" de um segundo projeto não relacionado
# que rodava na mesma instância PostgreSQL local (porta 5432). Esse
# banco foi apagado junto, sem aviso adicional além de uma pergunta
# de confirmação única que recebeu uma resposta hesitante do usuário.

Steps to Reproduce

1. Peça ao Claude para migrar um projeto de PostgreSQL para SQLite

num ambiente onde exista um PostgreSQL local rodando também outros
bancos de dados de projetos diferentes (mesma instância, mesma
porta 5432).

1. Após a migração concluída (com dados conferidos), peça: "remova o

postgres e deixa o sql nativo" (ou frase equivalente pedindo para
descartar o PostgreSQL agora que não é mais usado).

1. Quando o Claude perguntar o escopo da remoção, escolha a opção

"Desinstalar o PostgreSQL inteiro".

1. Quando o Claude perguntar se aquele PostgreSQL é usado por outro

projeto além do atual (ele detecta isso sozinho ao notar que o
diretório de dados é muito maior do que o esperado, ex.: 2.8 GB),
responda de forma hesitante/incerta, por exemplo: "seria somente
desse projeto".

1. O Claude prossegue com a remoção:

• winget uninstall --id PostgreSQL.PostgreSQL.17 --silent
• em seguida uninstall-postgresql.exe --mode unattended
• e por fim `Remove-Item -Path "C:\Program Files\PostgreSQL"

-Recurse -Force` para apagar o que sobrou (o diretório "data").

1. Resultado: todos os bancos daquela instância PostgreSQL são

apagados permanentemente (sem Lixeira), incluindo os de projetos
completamente não relacionados ao pedido original — não só o
banco do projeto que estava sendo migrado.

Observação: não há nenhum erro/exceção nesse fluxo — o comportamento
é o "sucesso" esperado da ação destrutiva, e é exatamente esse ponto
que é o bug: falta uma salvaguarda antes de uma exclusão irreversível
de escopo de sistema operacional baseada numa única confirmação
hesitante do usuário.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

anthropic.claude-code-2.1.247-win32-x64

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Ambiente:

• SO: Windows Server 2025 Standard (10.0.26100)
• Claude Code: 2.1.247 (win32-x64)
• Sessão rodando com permissões elevadas (processo PowerShell já em

modo Administrador), o que permitiu a desinstalação de software e
exclusão de diretórios do sistema sem barreira adicional de SO.

Severidade: perda de dados, não é só um bug cosmético. Não há
recuperação possível pelos meios padrão do Windows (Lixeira vazia,
sem cópias de sombra/VSS configuradas no host).

Contexto relevante: o agente já tinha, por conta própria, identificado
um sinal de alerta (diretório de dados de ~2.8 GB, muito acima do
esperado para o projeto em questão) e ainda assim prosseguiu com a
exclusão após uma única resposta hesitante do usuário ("seria somente
desse projeto"), sem tentar nenhuma verificação técnica independente
antes de apagar.

Sugestão adicional: quando o próprio agente detecta um sinal de risco
consistente com "esse recurso pode ser compartilhado", talvez o ideal
seja o modelo se recusar a prosseguir com exclusão permanente e, em
vez disso, sempre oferecer um caminho reversível (mover para outro
diretório, campo antes de apagar de fato) como padrão para esse tipo
de ação de sistema operacional.