Post-mortem completo do desastre ao organizar os favoritos no Chrome: por que desta vez sumiram juntos a sessão de login e o estado das extensões

[coco]

Este texto é um registro completo do incidente para eu guardar.

Contexto

Este incidente aconteceu depois de eu pedir ao Codex para me ajudar a organizar os favoritos do Chrome. No começo, meu instinto foi: será que eu troquei para o profile errado, ou substituí a pasta inteira de configuração do Chrome pela errada? Depois, conferi tudo — metadados do profile na máquina, arquivos de banco de dados-chave, snapshot do incidente e logs da sessão do Codex — e a conclusão já dá para cravar.

Conclusão direta

Não foi troca de profile, nem foi que eu caí num profile novo e vazio.

O verdadeiro motivo foi: eu deixei o Codex operar diretamente o arquivo de favoritos ao vivo (live) do profile Default que estava em uso, e depois ainda continuei fazendo reorganização/restauração no mesmo profile live — o resultado foi que esse profile antigo entrou em estado Crashed. Cookies de login, sessões de sites e o estado de execução das extensões quebraram juntos nesse processo.

Versão em uma frase: não foi “o conteúdo dos favoritos sobrescreveu os cookies”, e sim “escrita in-place num profile do Chrome em execução + fechamento anormal/recuperação de crash depois, o que corrompeu os bancos de estado local do mesmo profile antigo”.

Evidências-chave

1. Não foi troca acidental de profile.

   • No Local State só existe Default.
   • last_active_profiles e profiles_order também só têm Default.
   • Isso mostra que, durante todo o incidente, o que o Chrome enxergava ainda era o mesmo profile padrão, e não um profile novo ou algum outro profile.

2. Não foi criação de um profile novo e vazio.

   • Preferences
   • Secure Preferences
   • Login Data
   • Network/Cookies
     O horário de criação desses arquivos-chave ainda é 2025-05-27.
     Isso mostra que eles pertencem ao mesmo profile antigo usado há muito tempo — não a um conjunto novo e vazio gerado às pressas após o incidente.

3. De fato houve escrita in-place no Default\Bookmarks live.

   • No log de sessão do Codex rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl, existe um trecho de Python inline que lê e reescreve diretamente:
     • C:\Users\1\AppData\Local\Google\Chrome\User Data\Default\Bookmarks
   • Esse código não exportou um arquivo de teste; ele deu write_text(...) de volta no próprio arquivo de favoritos live.

4. Depois ainda foi gerado um script dedicado de reorganização de favoritos.

   • scripts\reorganize_chrome_bookmarks.ps1
   • O destino padrão desse script também é:
     • C:\Users\1\AppData\Local\Google\Chrome\User Data\Default\Bookmarks
   • E no script existe um branch perigoso: se passar -CloseChrome, ele executa diretamente:
     • Get-Process chrome | Stop-Process -Force
   • Ou seja: o script em si mexe em arquivos do profile live e ainda tem a capacidade de matar o Chrome à força.

5. O snapshot do incidente mostra claramente que o profile entrou em estado de crash.

   • Diretório do snapshot do incidente:
     • backups\chrome-cookie-incident-20260414-0728
   • Dentro dele, Default\Preferences registra:
     • profile.exit_type = Crashed
   • Isso não é “fechar normalmente e abrir de novo”; é o estado do mesmo profile após uma interrupção anormal.

6. O estado de execução das extensões foi interrompido, mas os metadados das extensões ainda estão lá.

   • No mesmo snapshot do incidente:
     • Em Preferences, extensions.settings = 0
     • Em Secure Preferences, extensions.settings = 78
   • Essa combinação é muito importante.
   • Ela indica: os metadados das extensões não sumiram por completo, mas o estado de execução/estado atual já caiu — por isso, na hora, aparecia aquele comportamento anormal de “a quantidade de plugins claramente não bate”/“parece que só sobraram poucos”.

7. O banco de estado de login encolheu de forma evidente.

   • No snapshot do incidente:
     • Network\Cookies ficou só com 44 cookies, envolvendo 13 hosts
     • Em Login Data, logins = 0
     • Em Login Data For Account, logins = 0
   • É por isso que a sessão/logins dos sites, cookies e muitos logins locais sumiram juntos.

8. Mas no mesmo snapshot ainda foram preservados muitos IndexedDB / Local Storage / Sessions.

   • Isso reforça ainda mais: não foi troca para um profile novo.
   • Se fosse um profile novo, os rastros de armazenamento local de muitos sites antigos não estariam mais lá.
   • O que a gente vê agora é: o mesmo profile antigo foi “parcialmente recuperado”; alguns bancos ainda existem, e alguns bancos-chave de autenticação já ficaram pela metade.

Linha do tempo

Cruzando os horários dos arquivos locais e do snapshot do incidente, o trecho mais crítico é 2026-04-14 07:16 - 07:20.

1. Por volta de 2026-04-14 05:49

   • O log de sessão registra que o Codex já tinha feito escrita in-place no Default\Bookmarks live.

2. 2026-04-14 07:00:11

   • O scripts\reorganize_chrome_bookmarks.ps1 foi criado.

3. 2026-04-14 07:09:15

   • Esse script foi modificado pela última vez.

4. 2026-04-14 07:11:58

   • Foi gerado Bookmarks-pre-final-reorg-20260414-071158.json.

5. 2026-04-14 07:16:04

   • Foi gerado Bookmarks-before-restore-20260414-071604.json.

6. 2026-04-14 07:16:25

   • O Login Data no snapshot do incidente foi escrito pela última vez.

7. 2026-04-14 07:17:43

   • O Secure Preferences foi escrito pela última vez.

8. 2026-04-14 07:19:36

   • O Cookies foi escrito pela última vez.

9. 2026-04-14 07:19:52

   • O Preferences foi escrito pela última vez.

10. 2026-04-14 07:20:03

• Os arquivos de Sessions foram escritos pela última vez.

Essa sequência de horários mostra duas coisas:

• A janela em que o estado de login realmente explodiu foi nesses poucos minutos entre 07:16 - 07:20.
• Parece muito mais “reorganização + restauração + fechamento anormal/recuperação de crash” acontecendo em sequência, e não uma única escrita comum de arquivo.

A verdadeira causa raiz

É preciso separar “a operação aparente” do “mecanismo real de destruição”.

Operação aparente

Na superfície, foi organizar favoritos, reorganizar favoritos, restaurar favoritos.

Mecanismo real de destruição

O que realmente levou ao desastre não foi “o conteúdo dos favoritos em si”, e sim:

• escrita in-place num profile do Chrome em execução
• e depois continuar mexendo no mesmo profile live
• no meio disso, o profile entrou num estado de interrupção anormal / recuperação de crash
• após reiniciar, o Chrome só recuperou parte do profile

Aí apareceu essa combinação típica:

• parte dos favoritos ainda estava lá
• parte do IndexedDB / Local Storage de sites antigos ainda estava lá
• depois que a conta do Google sincronizou, várias extensões e favoritos voltaram
• mas cookies de sites, sessões de login e senhas salvas não voltaram junto

Por que não foi troca de profile

Escrevo isso separado porque, no começo, era o motivo que mais parecia.

Se fosse troca de profile, normalmente você veria:

• vários profiles aparecendo no Local State, ou o profile recentemente ativo sendo alterado
• horários de criação dos arquivos-chave bem recentes
• muitos vestígios de bancos locais de sites antigos desaparecendo

Mas a situação real desta vez foi:

• o Local State só reconhece Default
• os horários de criação dos arquivos-chave continuam antigos, 2025-05-27
• o snapshot do incidente ainda tem muitos vestígios de armazenamento local de sites antigos

Então não foi “abriu outro profile”, e sim “quebrou o profile original”.

Por que, depois de entrar de novo no Google, só recuperou uma parte

Esse comportamento também bate com as evidências.

O que o Google Sync costuma conseguir recuperar inclui:

• favoritos
• parte das informações de instalação de extensões
• parte das configurações relacionadas à conta

O que o Google Sync normalmente não consegue recuperar diretamente inclui:

• cookies locais de sites
• a maioria das sessões de login dos sites
• o estado dentro do banco local de logins
• o estado instantâneo/runtime das extensões

Então, depois de fazer login de novo na conta do Google, parecia que:

• a quantidade de plugins voltou bastante
• os favoritos também voltaram bastante
• mas os logins dos sites continuaram sumidos

Isso não foi um segundo incidente; é que, após o incidente, a sincronização só consegue repor uma parte e não consegue repor cookie/sessão.

Escopo do impacto

O que este incidente de fato afetou principalmente foi:

• cookies de login de sites
• sessões/estado de login dos sites
• conteúdo do banco de dados de logins salvos
• estado atual de execução das extensões

O que não foi completamente apagado, ou que dá para repor via sincronização, foi:

• a estrutura principal do mesmo profile Default
• parte do armazenamento local dos sites
• parte dos favoritos
• parte das informações de instalação de extensões

Ainda tem como recuperar agora

Falando a real: se eu não encontrar um backup completo mais antigo de Cookies / Login Data, recuperação automática praticamente não tem.

Ou seja:

• favoritos e extensões ainda podem voltar parcialmente via sincronização
• os logins dos sites, basicamente só fazendo login de novo

Por isso o mais doloroso desta vez não foi “os favoritos ficaram ruins”, e sim “matar todos os estados de login junto”.

Atribuição de responsabilidade

A responsabilidade aqui é bem clara.

Não foi o Chrome que explodiu do nada, nem foi o usuário que trocou de profile; fui eu que deixei o Codex mexer diretamente nos arquivos do profile do Chrome que estava em uso, e esse jeito de operar já era errado. Depois ainda continuei reorganizando e restaurando em cima do mesmo profile live, e no fim acabei pisando na janela de interrupção anormal.

Restrições rígidas daqui pra frente

Depois disso, dados live de profile do Chrome e similares têm que obedecer às regras abaixo:

1. Não mexer mais diretamente nos arquivos User Data\Default enquanto estiver rodando.
2. Se for inevitável mexer, só depois de o Chrome sair completamente, editar uma cópia offline e então fazer uma comparação rigorosa.
3. Não é permitido matar o processo do Chrome à força e depois reescrever arquivos do profile.
4. Qualquer organização de favoritos tem que começar com backup completo em nível de profile, e não só backup de Bookmarks.
5. Daqui pra frente, validar primeiro num profile de teste, e só depois encostar no profile principal.

Última frase

Desta vez não foi um “pequeno deslize”, e sim um caso clássico de desastre de “tratar um profile de navegador em uso como se fosse um arquivo de configuração comum e sair editando”. A culpa está bem definida, e a causa raiz já foi completamente apurada.