Postmortem completo del incidente al ordenar los marcadores en Chrome: por qué esta vez se llevó por delante la sesión y el estado de las extensiones

[coco]

Este es el registro completo del incidente, guardado para mí.

Contexto

Este incidente ocurrió después de que le pedí a Codex que me ayudara a ordenar los marcadores de Chrome. Al principio mi intuición fue: ¿habré cambiado al profile equivocado, o habré reemplazado mal todo el directorio de configuración de Chrome? Después comparé todo: los metadatos del profile local, los archivos clave de bases de datos, la instantánea del incidente y los logs de la sesión de Codex. La conclusión ya puede darse por definitiva.

Conclusión directa

No fue un cambio de profile equivocado, ni fue que se cambiara a un profile nuevo y vacío.

La causa real fue: le pedí a Codex que operara directamente sobre el archivo de marcadores live del profile Default que estaba en uso, y luego seguí haciendo reorganización/restauración sobre ese mismo profile live, con el resultado de que ese profile antiguo quedó en estado Crashed. Las cookies de inicio de sesión, el estado de sesión de los sitios y el estado de ejecución de las extensiones se rompieron juntos en ese proceso.

Versión en una frase: no es que “el contenido de los marcadores haya sobrescrito las cookies”, sino que “escritura in situ sobre un profile de Chrome en ejecución + cierre anómalo/recuperación tras fallo posterior, terminó dañando las bases de datos de estado local del mismo profile antiguo”.

Evidencias clave

1. No hubo cambio de profile por error.

   • En Local State solo existe Default.
   • last_active_profiles y profiles_order también solo tienen Default.
   • Esto indica que durante todo el incidente, Chrome siguió viendo el mismo profile por defecto, no un profile nuevo ni otro profile.

2. No se creó un profile vacío nuevo.

   • Preferences
   • Secure Preferences
   • Login Data
   • Network/Cookies
     La hora de creación de estos archivos clave sigue siendo 2025-05-27.
     Esto muestra que pertenecen al mismo profile antiguo usado durante mucho tiempo, no a un conjunto de configuración vacío generado temporalmente tras el incidente.

3. Sí se hizo escritura in situ sobre el Default\\Bookmarks live.

   • En el log de sesión de Codex rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl, hay un fragmento de Python inline que lee y reescribe directamente:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • Ese código no exportaba a un archivo de prueba: hacía write_text(...) para reescribir el archivo de marcadores live en sí.

4. Después se generó un script dedicado para reorganizar marcadores.

   • scripts\\reorganize_chrome_bookmarks.ps1
   • El objetivo por defecto de ese script también es:
     • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
   • Y además el script contiene una rama peligrosa: si se pasa -CloseChrome, ejecuta directamente:
     • Get-Process chrome | Stop-Process -Force
   • Es decir, el propio script estaba pensado para “meter mano” a archivos del profile live y además tiene capacidad de matar Chrome a la fuerza.

5. La instantánea del incidente muestra claramente que el profile entró en estado de fallo.

   • Directorio de la instantánea del incidente:
     • backups\\chrome-cookie-incident-20260414-0728
   • Dentro, Default\\Preferences registra:
     • profile.exit_type = Crashed
   • Esto no es “cerrar normalmente y volver a abrir”, sino el estado tras una interrupción anómala del mismo profile.

6. Se interrumpió el estado de ejecución de extensiones, pero los metadatos de extensiones siguen ahí.

   • En la misma instantánea del incidente:
     • En Preferences, extensions.settings = 0
     • En Secure Preferences, extensions.settings = 78
   • Esta combinación es clave.
   • Indica que los metadatos de las extensiones no desaparecieron por completo, pero el estado de ejecución / estado actual ya se cayó, por eso en ese momento se veía el comportamiento anómalo de “la cantidad de plugins claramente no cuadra” / “parece que solo quedan unos pocos”.

7. La base de datos de estado de inicio de sesión se redujo de forma evidente.

   • En la instantánea del incidente:
     • Network\\Cookies se quedó con solo 44 cookies, que cubren 13 hosts
     • En Login Data, logins = 0
     • En Login Data For Account, logins = 0
   • Por eso desaparecieron a la vez el estado de sesión de los sitios, las cookies y muchos inicios de sesión locales.

8. Pero en la misma instantánea aún se conserva una gran cantidad de IndexedDB / Local Storage / Sessions.

   • Esto refuerza que no se cambió a un profile nuevo.
   • Si hubiera sido un profile nuevo, no quedarían tantas huellas de almacenamiento local de sitios antiguos.
   • Lo que se ve ahora es: el mismo profile antiguo fue “recuperado parcialmente”; algunas bases siguen ahí, y algunas bases clave de estado de autenticación ya quedaron dañadas.

Línea de tiempo

Cotejando las horas de archivos locales y las horas de la instantánea del incidente, el tramo más crítico es 2026-04-14 07:16 - 07:20.

1. Hacia 2026-04-14 05:49

   • El log de sesión registra que Codex ya había hecho escritura in situ sobre el Default\\Bookmarks live.

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

   • Se crea scripts\\reorganize_chrome_bookmarks.ps1.

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

   • Última modificación de ese script.

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

   • Se genera Bookmarks-pre-final-reorg-20260414-071158.json.

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

   • Se genera Bookmarks-before-restore-20260414-071604.json.

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

   • Última escritura de Login Data dentro de la instantánea del incidente.

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

   • Última escritura de Secure Preferences.

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

   • Última escritura de Cookies.

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

   • Última escritura de Preferences.

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

• Última escritura de los archivos Sessions.

Esta cadena de marcas de tiempo demuestra dos cosas:

• La ventana en la que realmente explotó el estado de inicio de sesión fueron esos minutos, 07:16 - 07:20.
• Se parece más a que “reorganización + restauración + cierre anómalo/recuperación tras fallo” ocurrieron encadenados, y no a una sola escritura de archivo normal.

La causa raíz real

Hay que separar la “operación superficial” del “mecanismo real de destrucción”.

Operación superficial

En la superficie, fue ordenar marcadores, reorganizar marcadores y restaurar marcadores.

Mecanismo real de destrucción

Lo que realmente causó el desastre no fue “el contenido de los marcadores en sí”, sino:

• escribir in situ sobre un profile de Chrome que estaba en ejecución
• y además seguir operando después sobre ese mismo profile live
• durante ese proceso, el profile entró en interrupción anómala / recuperación tras fallo
• tras reiniciar Chrome, solo se recuperó una parte del profile

Entonces apareció este combo típico:

• una parte de los marcadores sigue ahí
• una parte de IndexedDB / Local Storage de sitios antiguos sigue ahí
• tras sincronizar la cuenta de Google, volvieron bastantes extensiones y marcadores
• pero las cookies de sitios, el estado de sesión y la información de inicio de sesión guardada no volvieron con ello

Por qué no fue un cambio de profile equivocado

Lo dejo por separado porque al principio era lo que más parecía.

Si fuera un cambio de profile equivocado, normalmente se vería:

• varios profiles en Local State, o que el profile activo reciente cambió
• horas de creación muy recientes en archivos clave
• desaparición masiva de huellas de bases de datos locales de sitios antiguos

Pero la realidad de este caso fue:

• Local State solo reconoce Default
• las horas de creación de archivos clave siguen siendo las antiguas 2025-05-27
• en la instantánea del incidente aún hay muchas huellas de almacenamiento local de sitios antiguos

Así que no fue “se abrió otro profile”, sino “se rompió este profile original”.

Por qué al volver a iniciar sesión en Google solo se restauró una parte

Este fenómeno también encaja con las evidencias.

Google Sync suele poder restaurar:

• marcadores
• parte de la información de instalación de extensiones
• parte de la configuración vinculada a la cuenta

Google Sync normalmente no puede restaurar directamente:

• cookies locales de sitios
• la gran mayoría de sesiones de inicio de sesión de sitios
• el estado dentro de la base de datos local de inicios de sesión
• el estado instantáneo en tiempo de ejecución de las extensiones

Por eso, tras volver a iniciar sesión en la cuenta de Google, daba la impresión de que:

• volvió la cantidad de plugins en gran medida
• volvieron muchos marcadores
• pero el estado de inicio de sesión de los sitios seguía perdido

Esto no fue un segundo incidente: es que la sincronización post-incidente solo puede rellenar una parte y no puede recuperar cookies / sesión.

Alcance del impacto

Lo que realmente se vio afectado en este incidente fue principalmente:

• cookies de inicio de sesión de sitios web
• estado de inicio de sesión / sesión en distintos sitios
• contenido de la base de datos de inicios de sesión guardados
• estado de ejecución actual de extensiones

Lo que no quedó completamente destruido, o lo que se puede recomponer con sincronización, es:

• la estructura principal del mismo profile Default
• parte del almacenamiento local de sitios
• parte de los marcadores
• parte de la información de instalación de extensiones

Si todavía hay alguna forma de recuperar

Sinceramente: si no aparece una copia de seguridad más antigua y completa de Cookies / Login Data, la recuperación automática prácticamente no tiene esperanza.

Es decir:

• marcadores y extensiones, después aún pueden volver parcialmente mediante sincronización
• los estados de inicio de sesión de los sitios, básicamente solo se pueden recuperar volviendo a iniciar sesión

Por eso lo más doloroso esta vez no fue “se dañaron los marcadores”, sino “se mataron todas las sesiones de inicio de sesión a la vez”.

Atribución de responsabilidad

La responsabilidad en este caso está muy clara.

No es que Chrome explotara porque sí, ni que el usuario cambiara de profile por error: fui yo quien hizo que Codex tocara directamente los archivos del profile de Chrome que estaba en uso; el método de operación era, de por sí, incorrecto. Después seguí reorganizando y restaurando sobre ese mismo profile live, y al final terminé pisando la ventana de interrupción anómala.

Restricciones duras a futuro

Después de esto, los datos de profile live como los de Chrome deben cumplir obligatoriamente estas reglas:

1. No volver a operar directamente sobre archivos User Data\\Default mientras estén en ejecución.
2. Si hay que modificar algo sí o sí, solo hacerlo tras salir completamente de Chrome, sobre una copia offline, y luego con comparación estricta.
3. No se permite matar a la fuerza el proceso de Chrome y después volver a escribir archivos del profile.
4. Cualquier ordenación de marcadores debe hacerse primero con una copia de seguridad completa a nivel de profile, no solo respaldando Bookmarks.
5. En adelante, validar primero en un profile de prueba y recién entonces tocar el profile principal.

Última frase

Esto no fue un “pequeño error”, sino un caso de desastre estándar de “tratar el profile de un navegador en uso como si fuera un archivo de configuración normal y editarlo”. La culpa está clara y la causa raíz ya quedó determinada.