Codex от OpenAI убивает SSD за считанные месяцы из-за скрытой записи терабайтов служебных данных

Инструмент Codex от OpenAI создаёт колоссальную нагрузку на накопители пользователей через систему журналирования. За 21 день работы программа записала на SSD одного из инженеров около 37 ТБ данных, что при сохранении такого режима грозит исчерпать ресурс диска за период менее 12 месяцев.

Обнаружил проблему разработчик, который заметил подозрительно быстрый износ накопителя на рабочем ноутбуке. Внешне ничего не предвещало беды, машина использовалась под стандартные задачи написания и проверки кода. Никаких ресурсоёмких процессов фоном не запускалось, тяжёлые рендеры или базы данных на устройстве не крутились.

Источником постоянной записи оказался ИИ-ассистент Codex от OpenAI, а конкретно его внутренняя подсистема логирования. Программа без остановки сбрасывала служебную информацию в локальную базу SQLite, размещённую прямо на системном диске. Звучит безобидно, ведь почти любое приложение пишет логи для отладки и поиска багов.

Но масштабы записи в случае Codex выбивались из любой адекватной нормы. Объёмы вышли на промышленный уровень при том, что задача-то у инструмента совершенно другая. Накопитель за три недели получил такую нагрузку, какую обычные пользовательские SSD должны выдерживать годами.

Стоит обратить внимание, что многие потребительские накопители рассчитаны на общий ресурс записи около 600 ТБ за весь срок службы.

Получается забавная арифметика. При экстраполяции выявленной нагрузки на год эксплуатации программа способна сгенерировать порядка 640 ТБ записи. То есть один-единственный ИИ-помощник без ведома пользователя выжигает гарантийный ресурс диска быстрее, чем заканчивается срок самой гарантии.

Самым странным оказалось соотношение размера базы и количества операций. На диске SQLite-файл занимал чуть больше 1 ГБ и содержал примерно 500 тыс. строк. А внутренний счётчик идентификаторов записей уже перевалил за 5,5 млрд.

Цифры расходятся в десять тысяч раз, и объясняется это просто. Codex без остановки создавал новые строки и тут же их удалял, освобождая место под следующую порцию. Для пользователя это выглядело как маленькая локальная база, для контроллера накопителя — как непрерывный поток операций перезаписи.

Каждый цикл создания и удаления физически фиксировался на флеш-памяти. Ячейки изнашивались, ресурс таял, а на экране всё оставалось тихо и спокойно. Никаких индикаторов, никаких предупреждений системы, ничего.

Копаться в причинах долго не пришлось. Виновником оказались настройки самой системы журналирования внутри клиента. Разработчики выкрутили уровень детализации логов почти на максимум практически для всех модулей приложения.

В файлы попадало буквально всё подряд, и львиную долю объёма генерировали несколько источников:

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

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

После того как результаты расследования стали публичными, команда OpenAI отреагировала довольно оперативно. Уже через несколько дней вышли два обновления, нацеленные на снижение паразитной нагрузки. Первый патч урезал объём данных, связанных с сетевыми соединениями и сериализацией трафика между клиентом и сервером. Второй патч отрубил запись большинства технических событий, которые в реальной диагностике практически не пригождались.

Автор исследования прикинул эффект от изменений и получил снижение лишних операций записи примерно на 85%. Цифра внушительная, но осадок остался. Пользователи, которые работали с Codex с момента релиза и до выхода патчей, могли потерять заметный кусок ресурса своих накопителей.

Что особенно показательно в этой ситуации, проблема не лежала на поверхности. Износ SSD идёт незаметно для конечного пользователя, занятое место на диске почти не меняется, приложение функционирует штатно. Узнать о происходящем без специальных утилит мониторинга и сравнения SMART-показателей невозможно.

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

Российских пользователей этот сюжет тоже касается напрямую. Разработчики из РФ активно работают с ИИ-помощниками для генерации кода, а накопители здесь стоят денег и не всегда заменяются по первому требованию. Перспектива выжечь ресурс SSD за полгода работы инструмента, который должен был экономить время, мало кого обрадует.

Несколько практических выводов из этой ситуации:

• стоит периодически проверять SMART-показатели накопителей через CrystalDiskInfo или аналоги;
• полезно отслеживать, какие процессы пишут на диск больше всего, через resmon на Windows или iotop на Linux;
• имеет смысл выносить рабочие папки ИИ-инструментов на отдельный накопитель;
• регулярные бэкапы критичных проектов сокращают риски при неожиданном отказе диска;
• обновления клиентов ИИ-сервисов лучше ставить сразу, поскольку патчи закрывают подобные проблемы.

Производители SSD пока никак публично не комментировали ситуацию. Хотя случай явно даёт повод задуматься о том, что современные потребительские накопители живут в принципиально новой реальности нагрузок. Гарантийные показатели TBW рассчитывались в эпоху, когда никто не предполагал, что фоновое приложение будет писать терабайты в неделю.

Ранее сообщалось, что OpenAI представила специализированную модель GPT-5.5-Cyber для доверенных специалистов по информационной безопасности в рамках программы Daybreak. Одновременно компания анонсировала обновлённый плагин Codex Security и инициативу Patch the Planet, ориентированную на поддержку разработчиков открытого программного обеспечения. В OpenAI позиционировали GPT-5.5-Cyber как наиболее мощный на тот момент инструмент для поиска, анализа и устранения уязвимостей в программном обеспечении, отмечая, что для отрасли всё более важной проблемой становится не обнаружение ошибок, а скорость их исправления.

Эксперты редакции CISOCLUB уверены, что инцидент с Codex обнажил системную проблему всей индустрии ИИ-инструментов. Производители софта закладывают избыточную телеметрию по умолчанию, перекладывая стоимость своей диагностики на железо конечных пользователей. Подобные практики недопустимы и требуют жёсткого аудита со стороны независимых исследователей. Пользователям пора требовать от разработчиков прозрачных настроек логирования и возможности отключать сбор данных без потери функциональности продукта. Без этого каждый новый ИИ-сервис будет нести скрытые риски для оборудования, о которых никто заранее не предупреждает.