У пользователей OpenAI Codex обнаружился довольно дорогой побочный эффект: локальные логи инструмента могут записывать на диск объемы, которые больше похожи на стресс-тест, чем на обычную телеметрию. Речь идет не о процентах производительности, а о вполне материальной истории про износ SSD: один из разработчиков насчитал 37 ТБ записи всего за 21 день работы машины.
О проблеме износа SSD у пользователей Codex сообщает The Register. Поводом стал баг-репорт в GitHub, который на прошлой неделе открыл разработчик Rui Fan, участник project management committee Apache Flink. По его словам, после примерно трех недель аптайма основной SSD на его компьютере получил около 37 ТБ записи, а проверка на уровне процессов и файлов показала, что главным постоянным источником записи были SQLite-логи Codex. Если экстраполировать эту нагрузку на год, получается около 640 ТБ записи. Для потребительского SSD емкостью 1 ТБ это уже сопоставимо с полным паспортным ресурсом: The Register приводит для примера Samsung 9100 PRO 1 TB с заявленными 600 TBW.
Здесь важно не путать две разные вещи. OpenAI еще в декабре 2025 года говорила о планах включить телеметрию по умолчанию в Codex CLI, кроме юрисдикций, где это ограничено законом. Но в нынешней истории речь идет не о передаче данных в облако, а о локальной диагностике, которая тоже включена по умолчанию и появилась примерно вместе с запуском приложения в прошлом году. Формально эти логи остаются на устройстве пользователя, если он сам не приложит их к отчету об ошибке. Практически же вышло так, что диагностический механизм стал фоновой машиной по перетиранию ресурса накопителя. Для ноутбука разработчика это уже не мелочь из серии «потом починим».
Финансовая оценка в этой истории тоже не взялась с потолка, хотя к ней стоит относиться как к оценке, а не к счету от бухгалтерии. Еще один участник обсуждения написал, что баг якобы уже «съел» у него около 38,64 доллара стоимости SSD Samsung 990 на 2 ТБ. Дальше в треде появился и более широкий расчет: за период с марта по июнь этот регресс мог стоить пользователям «несколько миллионов долларов» в суммарно потраченном ресурсе накопителей. Логика расчета такая: стоимость одного терабайта записи оценивают через формулу цена SSD / TBW. The Register отдельно замечает, что конкретная цифра зависит от модели диска: чем выше паспортный ресурс и чем больше объем, тем дешевле обходится лишний терабайт записи. Но сам вывод от этого не меняется: даже если спорить о долларах, сам ресурс флеш-памяти все равно уходит в никуда.
Проблема неприятна еще и потому, что сигналы были давно. По данным The Register, жалобы на чрезмерные операции записи в репозитории Codex появлялись уже несколько месяцев. OpenAI подтвердила изданию, что инженеры знают о баге и работают над исправлением; это видно и по недавним pull request, которые должны снизить нагрузку. По словам компании, логи нужны для диагностики сбоев, а причина инцидента в том, что большие объемы данных стали сохраняться способом, который вызвал куда больше дисковой активности, чем предполагалось. Переводя с корпоративного на обычный язык: хотели удобнее дебажить, а получили локальный DDoS по собственному SSD.
Есть и деталь с легким привкусом жанра. The Register связывает корень проблемы с февральскими изменениями, когда для логов app-server в SQLite включили уровень TRACE, то есть максимально многословный режим. Забавнее другое: эту серию коммитов, по данным издания, проверял сам Codex, предположительно на модели GPT-5.3. Это, конечно, не доказательство того, что ИИ «проспал» баг, но символика сильная. Инструмент для написания кода помог пропустить реализацию, которая затем начала методично изнашивать диски у разработчиков. Хорошая иллюстрация того, что code review с участием ИИ не отменяет скучного человеческого вопроса: а сколько это вообще пишет на диск, в сеть и в память при реальной нагрузке?
Для русскоязычной IT-аудитории в этой истории важен не столько сам Codex, сколько класс ошибки. Почти любой современный AI-инструмент для разработки живет на стыке локального клиента, фонового сервиса, телеметрии, кэша, индексации и логирования. На бумаге каждый слой выглядит безобидно, но в сумме легко получается система, которая незаметно жрет I/O, батарею, RAM и срок жизни накопителя. Для разработчиков это аргумент внимательнее смотреть на фоновые процессы и размеры логов, особенно на рабочих ноутбуках. Для тимлидов и IT-директоров это уже вопрос эксплуатации парка устройств: если агент для кодинга по умолчанию пишет сотни терабайт в год, история быстро выходит из категории «ошибка в клиенте» в категорию «скрытая стоимость владения». А для вендоров AI-инструментов это напоминание, что настройка уровня логирования по умолчанию может стоить дороже, чем любая экономия на support-инфраструктуре.
OpenAI, судя по всему, баг исправит. Но после этой истории рынок вряд ли будет так же беззаботно смотреть на «локальные диагностические данные по умолчанию». Чем больше AI-ассистенты становятся частью повседневной разработки, тем важнее не только качество ответов модели, но и банальная инженерная гигиена клиента: сколько он пишет, что хранит и во что обходится его невидимая активность. Проверить детали исходной публикации можно в .