Полный разбор инцидента с наведением порядка в закладках Chrome: почему на этот раз вместе исчезли и сессия входа, и состояние расширений

Универсальный
,
1

Это полный отчёт об инциденте для собственного архива.

Предыстория

Инцидент произошёл после того, как я попросил Codex помочь мне упорядочить закладки Chrome. Сначала интуитивно казалось: не туда ли я переключил профиль, или не тем ли образом заменил весь каталог конфигурации Chrome. Потом я полностью сверил метаданные профиля на этой машине, ключевые файлы баз данных, снимок инцидента и логи сессии Codex — вывод уже можно считать окончательным.

Прямой вывод

Это не ошибка переключения профиля и не переход на новый пустой профиль.

Реальная причина в том, что я позволил Codex напрямую работать с live-файлом закладок активного профиля Default, а затем продолжил реорганизацию/восстановление поверх того же live-профиля — в итоге этот старый профиль оказался в состоянии Crashed. Логин-cookie, состояния входа на сайты и состояние работы расширений сломались вместе с этим процессом.

Версия в одну фразу: дело не в том, что «содержимое закладок перезаписало cookie», а в том, что «запись на месте в работающий Chrome profile + последующее нештатное закрытие/восстановление после падения повредили локальные базы состояния одного и того же старого профиля».

Ключевые доказательства

  1. Это не ошибочная смена профиля.

    • В Local State есть только Default.
    • last_active_profiles и profiles_order тоже содержат только Default.
    • Это означает, что на протяжении всего инцидента Chrome видел один и тот же профиль по умолчанию, а не новый или какой-то другой.

  2. Это не новый пустой профиль.

    • Preferences
    • Secure Preferences
    • Login Data
    • Network/Cookies
      Время создания этих ключевых файлов всё ещё 2025-05-27.
      Это означает, что они принадлежат одному и тому же давно используемому старому профилю, а не являются «пустым набором», временно сгенерированным после инцидента.

  3. Действительно была выполнена запись на месте в live Default\\Bookmarks.

    • В логе сессии Codex rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl есть фрагмент встроенного Python, который напрямую читает и перезаписывает:
      • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
    • Этот код не экспортирует тестовый файл, а напрямую делает write_text(...) и переписывает сам live-файл закладок.

  4. Далее был сгенерирован отдельный скрипт для реорганизации закладок.

    • scripts\\reorganize_chrome_bookmarks.ps1
    • Целевой путь по умолчанию в этом скрипте такой же:
      • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
    • И в скрипте есть опасная ветка: если передать -CloseChrome, он напрямую выполнит:
      • Get-Process chrome | Stop-Process -Force
    • То есть сам по себе этот скрипт — вмешательство в live-файлы профиля, плюс у него есть возможность жёстко убить Chrome.

  5. Снимок инцидента явно показывает, что профиль перешёл в состояние падения.

    • Каталог снимка инцидента:
      • backups\\chrome-cookie-incident-20260414-0728
    • Внутри Default\\Preferences записано:
      • profile.exit_type = Crashed
    • Это не «нормально закрыл и снова открыл», а состояние после нештатного прерывания того же профиля.

  6. Состояние работы расширений прервано, но метаданные расширений на месте.

    • В том же снимке инцидента:
      • в Preferences значение extensions.settings = 0
      • в Secure Preferences значение extensions.settings = 78
    • Эта комбинация очень показательная.
    • Она означает: метаданные расширений не исчезли полностью, но runtime / текущее состояние уже сорвалось — поэтому тогда и наблюдалось «расширений явно меньше» / «как будто осталось всего несколько».

  7. База данных логинов заметно “усохла”.

    • В снимке инцидента:
      • в Network\\Cookies осталось всего 44 cookie, по 13 host
      • в Login Data logins = 0
      • в Login Data For Account logins = 0
    • Поэтому и пропали состояния входа на сайты, cookie и множество локальных логинов.

  8. Но в том же снимке всё ещё сохранены большие объёмы IndexedDB / Local Storage / Sessions.

    • Это дополнительно доказывает: это не переключение на новый профиль.
    • Если бы это был новый профиль, следов локального хранения со старых сайтов почти не осталось бы.
    • А тут видно: один и тот же старый профиль был «частично восстановлен» — какие-то хранилища остались, а ключевые хранилища аутентификации уже повреждены.

Таймлайн

По времени файлов на машине и времени снимка инцидента самая критичная часть — 2026-04-14 07:16 - 07:20.

  1. Около 2026-04-14 05:49

    • Лог сессии фиксирует, что Codex уже выполнял запись на месте в live Default\\Bookmarks.

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

    • Создан scripts\\reorganize_chrome_bookmarks.ps1.

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

    • Последняя модификация этого скрипта.

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

    • Сгенерирован Bookmarks-pre-final-reorg-20260414-071158.json.

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

    • Сгенерирован Bookmarks-before-restore-20260414-071604.json。

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

    • Последняя запись в Login Data (по снимку инцидента).

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

    • Последняя запись в Secure Preferences.

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

    • Последняя запись в Cookies.

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

    • Последняя запись в Preferences.

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

  • Последняя запись в файлы Sessions.

Эта цепочка временных точек показывает две вещи:

  • Окно, в которое реально «взорвалось» состояние логинов, — это как раз несколько минут 07:16 - 07:20.
  • Больше похоже на связку «реорганизация + восстановление + нештатное закрытие/восстановление после падения», а не на один обычный акт записи файла.

Реальная первопричина

Нужно разделять «поверхностное действие» и «реальный механизм повреждения».

Поверхностное действие

На поверхности это выглядит как сортировка закладок, реорганизация закладок, восстановление закладок.

Реальный механизм повреждения

К катастрофе привело не «содержимое закладок само по себе», а то, что:

  • выполнялась запись на месте в работающий профиль Chrome
  • и затем операции продолжались поверх того же live-профиля
  • в процессе профиль попал в нештатное прерывание / восстановление после падения
  • после перезапуска Chrome восстановил только часть профиля

Из-за этого получилась типичная комбинация:

  • часть закладок осталась
  • часть IndexedDB / Local Storage со старых сайтов осталась
  • после синхронизации с Google расширения и закладки вернулись ещё в заметной степени
  • но cookie сайтов, состояния входа и сохранённые логины не вернулись вместе с ними

Почему это не ошибочная смена профиля

Я отдельно фиксирую это, потому что сначала именно это казалось самым вероятным.

Если бы это была ошибка переключения профиля, обычно видно:

  • в Local State появляется несколько профилей или меняется список недавно активных
  • время создания ключевых файлов баз очень свежее
  • массово пропадают следы локальных баз со старых сайтов

Но фактически в этот раз:

  • Local State признаёт только Default
  • время создания ключевых файлов всё ещё старое — 2025-05-27
  • в снимке инцидента есть много следов локального хранения со старых сайтов

Значит, это не «открыл другой профиль», а «сломал исходный профиль».

Почему после повторного входа в Google восстановилась только часть

Это явление также соответствует доказательствам.

Google Sync обычно может восстановить:

  • закладки
  • часть информации об установленных расширениях
  • часть настроек, связанных с аккаунтом

Google Sync обычно не может напрямую восстановить:

  • локальные cookie сайтов
  • большинство сессий входа на сайты
  • состояние в локальной базе логинов
  • мгновенное runtime-состояние расширений

Поэтому после повторного входа в Google-аккаунт выглядит так:

  • расширений снова стало заметно больше
  • закладок тоже вернулось много
  • но состояния входа на сайтах всё равно пропали

Это не «второй инцидент» — просто синхронизация после инцидента умеет вернуть лишь часть и не возвращает cookie / session.

Область влияния

Фактически сильнее всего пострадали:

  • cookie авторизации сайтов
  • состояния входа / сессии на сайтах
  • содержимое базы сохранённых логинов
  • текущее runtime-состояние расширений

Относительно не было уничтожено полностью или можно было частично вернуть синхронизацией:

  • основная структура того же профиля Default
  • часть локального хранилища сайтов
  • часть закладок
  • часть информации об установленных расширениях

Есть ли сейчас способ восстановить

Честно — если не найдено более ранней полной резервной копии Cookies / Login Data, автоматического восстановления почти нет.

То есть:

  • закладки и расширения потом ещё частично вернутся через синхронизацию
  • логины на сайтах почти наверняка придётся вводить заново

Поэтому больнее всего здесь не «сломанные закладки», а «убитые все состояния входа одновременно».

Разбор ответственности

Ответственность здесь предельно ясна.

Это не Chrome сам по себе «ни с того ни с сего взорвался», и не пользователь ошибся профилем — это я позволил Codex напрямую трогать файлы активно используемого профиля Chrome, а сам способ действий был неверным. Потом я продолжил реорганизацию и восстановление на том же live-профиле и в итоге наступил на окно нештатного прерывания.

Жёсткие правила на будущее

После этого случая данные live-профиля вроде Chrome должны всегда подчиняться правилам ниже:

  1. Больше не трогать напрямую файлы User Data\\Default, пока Chrome запущен.
  2. Если уж нужно менять — только после полного выхода из Chrome, редактируя офлайн-копию, и затем делать строгую сверку.
  3. Нельзя жёстко убивать процесс Chrome и потом продолжать обратную запись файлов профиля.
  4. Любая сортировка закладок должна начинаться с полного бэкапа профиля, а не только Bookmarks.
  5. Сначала проверять на тестовом профиле, и только потом трогать основной.

Последняя фраза

Это не «маленькая ошибка», а классический кейс катастрофы из серии «взяли профиль работающего браузера и правили как обычный конфиг-файл». Вина очевидна, первопричина уже установлена.