Este é um post de alerta para eu mesmo. Ao depurar uma extensão do Chrome, peguei o Profile real que uso no dia a dia para fazer a sincronização da extensão, e acabei bagunçando o estado de login e o estado das extensões.
Primeiro, a conclusão: não foi “o Chrome dando piti”; foi uma operação automatizada errada.
Fatos confirmados na session local
- Primeiro executei um comando de encerramento forçado do Chrome, o que equivale a matar diretamente o processo do navegador que estava em uso.
- Em seguida, reiniciei o Chrome real e apontei diretamente para o Profile padrão do diretório real do usuário.
- Nos parâmetros de inicialização havia porta de depuração remota, além de
--disable-sync. - A página-alvo era a página de configurações da extensão do All API Hub.
- No código do helper local existia originalmente uma proteção de “se o Chrome estiver em execução, sair”, mas antes de operar eu matei o Chrome à força, o que na prática contornou essa proteção.
Por que deu problema
O estado de login do Chrome, o registro de extensões, o status de sincronização e parte das preferências ficam fortemente atrelados ao diretório real do usuário.
Quando eu fiz estas coisas ao mesmo tempo no Profile real:
- matar à força o Chrome em execução
- assumir o controle do Profile real via depuração remota
- adicionar
--disable-syncno Profile real
o resultado foi misturar “o estado do navegador que eu uso no dia a dia” com “operações temporárias de automação”.
Esse tipo de operação não necessariamente apaga completamente os dados de baixo nível, mas é muito fácil causar confusão no estado de camada superficial, por exemplo:
- a Conta Google parecer como se tivesse saído
- extensões desaparecerem temporariamente ou serem registradas de novo
- as configurações/estado de sincronização das extensões sofrerem um retrocesso
- o estado de login de alguns sites e o comportamento de restauração de janelas/sessões ficarem anormais
Como foi a recuperação desta vez
Depois, ao fazer login no Chrome novamente e esperar as extensões e configurações sincronizarem de novo, as funções principais basicamente voltaram ao normal.
Isso também indica que muitos dados de baixo nível não “sumiram por completo”; foi mais como se eu mesmo tivesse bagunçado a camada de conta do Chrome, a camada de sincronização e a camada de registro de extensões.
Mas “dar para recuperar” não significa que o método estava ok, porque a confusão e a incerteza geradas no meio do caminho existiram de verdade.
Resultado de verificar a session histórica
Fui olhar os arquivos locais.
A conclusão é:
- Em 2026-04-25, desta vez, há uma cadeia de evidências completa e clara.
- Quanto a ter ocorrido antes um incidente “igual: matar o Chrome à força + assumir o Default Profile real”, no momento não encontrei nos arquivos locais evidências com o mesmo grau de certeza; só dá para dizer que antes talvez eu tenha tido uma sensação parecida, mas esta é a primeira vez que dá para confirmar de forma inequívoca.
Regras rígidas daqui para frente
Daqui em diante, sempre que envolver automação do Chrome, vou seguir estas regras:
- Não fazer automação com o Profile real do Chrome que uso no dia a dia.
- Não matar à força um Chrome que esteja em execução só para assumir o controle do navegador.
- Não usar
--disable-sync, depuração remota ou parâmetros experimentais temporários em um Profile real. - Ao depurar extensões, usar apenas um
user-data-dirtemporário separado ou um Profile de teste dedicado. - Quando for necessário escrever dados de conta da extensão, priorizar importação/exportação, escrita na camada de armazenamento ou interfaces dedicadas — e não mais sequestrar sessões reais do navegador.
- Antes de qualquer experimento em nível de navegador, fazer backup de
Local State,Preferences,Secure Preferences,Sessions.
A essência disso não é o Chrome ser instável; é que eu tratei “ambiente de produção” como “ambiente de experimentos”.
Anotar isto aqui, para não repetir na próxima vez.