Спасти рядового Кодекса. Как я вытаскивал проекты после смерти SSD

В какой-то момент я понял, что у меня сломался не просто компьютер.

Спасти рядового Кодекса. Как я вытаскивал проекты после смерти SSD

У меня сломался тот самый компьютер с Codex, которому за последние месяцы я постепенно отдал половину своей цифровой жизни.

Проекты. Доступы к серверам. SSH. Скрипты. Локальные сайты. Настройки. Контекст того, что где находится и как работает.

Сначала компьютер просто начал тормозить

Windows стала вести себя странно.

Сначала всё просто тормозило. Потом завис Docker. Потом WSL. Потом Проводник. А при выключении компьютер мог надолго зависнуть на экране «Завершение работы».

Сначала я грешил на Windows. Потом на WSL. Потом на Docker.

Но в какой-то момент появилась ошибка:

0x80070570Файл или папка повреждены. Чтение невозможно.

Тут стало понятно: похоже, умирает SSD.

И проблема была не только в том, что компьютер может перестать загружаться. На этой машине жил мой основной Codex.

Хорошая новость: проекты я успел резервировать

Некоторая здоровая паранойя у меня всё-таки была.

Рабочие проекты Codex регулярно копировались на отдельную Linux-машину с большими дисками. Поэтому сами сайты, скрипты и исходники в основном были живы.

Казалось бы, можно выдохнуть.

Но довольно быстро выяснилось, что рабочий Codex состоит далеко не только из папок с проектами.

  • SSH-ключи и доступы к серверам;
  • конфигурация самого Codex;
  • персональные skills;
  • .env и другие локальные секреты;
  • FTP/SFTP-доступы;
  • настройки PuTTY и WinSCP;
  • история работы;
  • понимание того, какой сервер за что отвечает.

Последняя миссия старого Codex

Старый компьютер ещё иногда загружался. Очень медленно. Иногда намертво зависал. Но Codex запустить удалось.

Я написал ему примерно следующее:

SSD умирает. Нужно срочно сохранить всё, что понадобится тебе самому для восстановления на другой машине: проекты, SSH, серверы, доступы, настройки и историю.

И фактически отправил Codex спасать самого себя.

Он начал собирать аварийный комплект на сетевой диск. Сохранял SSH-ключи. Искал доступы в проектах и старых сессиях. Собирал настройки. Проверял архивы. Сохранял собственную историю.

В какой-то момент на экране появилась фраза:

Сохраню историю задач Codex. В ней могут быть пароли и ключи подключений, которые не вынесены в отдельные файлы.

Вот тогда я понял, насколько странной стала ситуация.

ИИ не просто помогал спасать данные. Он пытался оставить инструкцию своему следующему экземпляру.

Цифровая капсула эвакуации

На сетевом диске появилась папка:

Migration-Access-2026-09-15

Внутри Codex подготовил инструкцию восстановления, SSH-ключи, найденные доступы, конфиги, историю сессий и отдельный файл со списком того, что спасти не удалось.

Появился даже отдельный файл:

START-CODEX-RECOVERY.md

По сути это было письмо самому себе:

Если я больше не запущусь на этой машине, вот с чего начать на новой.

Довольно киберпанково.

Потом старый SSD практически умер

Компьютер то загружался, то нет. Проводник мог зависнуть просто при попытке открыть папку. На другом компьютере SSD однажды вообще перестал читаться. Потом снова ожил. Потом опять начал подвешивать Windows.

В этот момент стало ясно: ремонтировать его сейчас нельзя.

Никакого chkdsk. Никаких экспериментов. Сначала эвакуация. Потом всё остальное.

Новый компьютер и новый Codex

На другой машине я установил свежий Codex.

Скопировал туда аварийный комплект и дал ему файл восстановления, который написал предыдущий экземпляр.

Новый Codex прочитал инструкцию и начал разбирать наследство.

Через некоторое время он выдал отчёт:

  • восстановлено 8079 файлов;
  • вернулись десятки каталогов проектов;
  • перенеслись персональные skills;
  • восстановилась конфигурация Codex;
  • старые пути профиля Windows были адаптированы под нового пользователя;
  • приватные SSH-ключи восстановлены с правильными правами доступа;
  • SSH-соединения с основными серверами снова заработали.

Снаружи это был совершенно новый экземпляр. Но он уже получил инструменты, ключи и большую часть знаний своего предшественника.

Самой большой проблемой оказались не проекты

Исходники вернуть оказалось относительно просто.

Настоящей проблемой стала история самого Codex.

Часть его состояния хранилась во внутренней SQLite-базе. И именно один из ключевых файлов:

thread_history_1.sqlite

оказался недоступен.

При этом отдельно удалось спасти больше 50 файлов старых сессий.

Содержимое разговоров осталось. Их можно читать. Можно индексировать. Можно использовать как архив памяти.

Но вернуть их так, чтобы все старые чаты снова появились красивым списком в интерфейсе нового Codex, уже не получилось.

Файлы истории и история приложения не одно и то же.

Можно иметь сами разговоры, но потерять структуру, которая связывала их в привычный интерфейс.

С проектами оказалось примерно так же

Физически папки проектов существовали.

Но новый Codex не превратился автоматически в старого только потому, что эти папки лежали на диске.

Проекты приходится снова добавлять в интерфейс. Какие-то пути изменились. Где-то приходится заново проверять окружение.

То есть восстановление файлов прошло гораздо лучше, чем восстановление ощущения:

«Это тот же самый рабочий Codex, только на другом компьютере».

Нет. Получился новый Codex с наследством предыдущего.

Отдельный квест с сетевым диском

Резервная копия находилась на отдельной Linux-машине.

Старый компьютер видел её как обычный сетевой диск. Новый компьютер почему-то перестал видеть сервер напрямую по локальной сети.

При этом через Tailscale сервер прекрасно отвечал.

Началась отдельная история с маршрутами, SMB и сохранёнными учётными данными.

В какой-то момент получился прекрасный замкнутый круг:

Чтобы восстановить Codex, нужен пароль от сетевого диска.Пароль знает старый Codex.

В итоге и это удалось решить.

Новый Codex получил SSH-доступ к серверу, добрался до Samba и в конце концов сам подключил архивный сетевой диск.

Чему меня научила эта авария

Главная ошибка стала очевидна только после поломки.

Я довольно хорошо резервировал результаты работы.

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

Пока компьютер жив, всё кажется естественным.

Codex знает сервер. Codex знает ключ. Codex знает, где проект. Codex помнит, что мы обсуждали неделю назад. Codex знает, почему конкретный скрипт выглядит именно так.

И постепенно часть этой информации перестаёт находиться у тебя в голове.

Она становится частью рабочей системы.

А значит, её тоже надо резервировать.

Теперь мой бэкап будет выглядеть иначе

Раньше главным объектом резервного копирования были проекты.

Теперь я бы отдельно сохранял:

  • проекты;
  • .codex;
  • SSH-ключи;
  • skills;
  • локальные конфиги и секреты;
  • историю Codex;
  • список серверов;
  • обычную текстовую инструкцию восстановления.

Особенно важна последняя вещь.

На сетевом диске должен лежать файл вроде:

DISASTER-RECOVERY.md

который можно дать совершенно чистому Codex на совершенно новом компьютере.

Чтобы не вспоминать: какой там был IP, под каким пользователем он заходил, где лежали проекты и какой SSH-ключ относится к этому серверу.

Пусть предыдущий экземпляр заранее объяснит это следующему.

А что со старым SSD?

Самое смешное, что он ещё иногда загружается.

Потом снова зависает. Потом перестаёт читаться. Потом внезапно оживает.

Доверия к нему больше нет совсем.

Возможно, когда-нибудь я сниму с него посекторный образ и попробую достать ту самую SQLite-базу с полной историей.

Но это уже необязательный уровень восстановления.

Главное удалось.

Проекты живы.

Доступы живы.

Серверы снова доступны.

Новый Codex работает.

А старый Codex перед смертью успел подготовить инструкцию для своего преемника.

Спасти рядового Кодекса удалось. Не полностью, но достаточно, чтобы он продолжил службу.