Критический баг в Codex: лог пишет сотни терабайт в год и убивает SSD

Ключевые факты

• Codex пишет ~640 ТБ/год в SQLite логи, что исчерпывает TBW типичного SSD за 1 год вместо 5, 10
• Корень проблемы: глобальный TRACE уровень логирования по умолчанию сохраняет шум от зависимостей и WebSocket трафика
• TRACE логи составляют 70% объема, OpenTelemetry зеркала еще 25%, вместе это 96% лишних данных
• Write amplification: 36k строк вставляются за 15 секунд, затем удаляются, создавая цикл записи без останова
• Решение: сузить фильтр TRACE, исключить полные payload'ы, добавить глобальный cap на размер БД логов

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

Почему это важно

SSD имеют ограниченный ресурс по количеству записей (TBW). Большинство потребительских SSD рассчитаны на 600 ТБ записей, что дает примерно 5, 10 лет при обычной работе. Codex в текущем виде может исчерпать весь ресурс за год, превратив дорогой накопитель в яблочное пюре. Для компаний это означает ускоренный выход из строя серверов и локальных машин разработчиков.

Ред. Красивая метафора про яблочное пюре скрывает скучную правду: ресурс убивает не модель за миллиарды параметров, а забытый флаг уровня логирования. Самое дорогое в стеке гробит самое дешёвое.

Кому это важно

Пользователи Codex (редактор от OpenAI, встраивается в VS Code и другие IDE), особенно те, кто активно работает в нем по 8+ часов в день. Компании, которые развертывают Codex на корпоративных машинах разработчиков. DevOps и системные администраторы, которые должны заменять SSD чаще, чем планировалось. Все, кто полагается на стабильность локального диска.

Ред. Список «кому важно» сводится к одному пункту: всем, кто запустил Codex и не открыл диспетчер записи. DevOps тут не жертвы, а единственные, кто вообще заметит, пока гарантия не кончится.

Как это применить

Пока OpenAI не исправит баг: 1) отключить Codex логирование через переменную окружения или конфиг, если доступно. 2) Мониторить размер ~/.codex/logs_2.sqlite вручную, периодически чистить старые логи. 3) Хранить Codex кэш и логи на отдельном диске, чтобы изнашивание не затрагивало системный SSD. 4) Отключить полный TRACE логирование, если есть опции конфигурации. Предложенное решение (узкие фильтры TRACE, отключение сырых payload'ов, глобальный cap) должно быть применено в следующих версиях Codex.

Ред. Четыре пункта обхода, и все они про то, чтобы руками чистить за чужим дефолтом; мониторить размер sqlite это работа, которую софт должен был не создавать. Совет «отключить, если есть опция» намекает, что опции может и не быть.

Можно ли доверять

Отчет основан на конкретных данных из запущенной системы: замеры за 21 день, статистика по БД (уровни логирования, размеры записей), примеры частых записей с указанием количеств. Расчет экстраполяции (37 ТБ за 21 дней = 640 ТБ/год) математически верен. Предложенные решения логичны и опираются на анализ состава логов (TRACE 70%, OpenTelemetry 25%). Таким образом, это технически обоснованный отчет разработчика, а не спекуляция.

Ред. Цифрам верить можно, арифметика 37 ТБ за 21 день в год экстраполируется честно. Открытый вопрос в другом: репорт от одного разработчика на одной машине, и пока нет данных, у скольких ещё диск тихо стачивается прямо сейчас.

Риски и подводные камни

Отключение логирования полностью может усложнить отладку проблем в Codex. Требуется аккуратный баланс между детализацией и производительностью. OpenAI может долго не торопиться с исправлением, если это нечасто поступающая жалоба. На машинах с быстрыми SSD (например, PCIe 5.0) изнашивание будет менее заметно, но все равно значительно. Пользователи Windows WSL2 сообщают похожие проблемы с I/O, что указывает на системную природу проблемы. Также есть риск того, что исправление может нарушить функционал сбора feedback для улучшения модели.

Ред. Самый честный риск спрятан в конце: чинить, возможно, не торопятся, потому что эти же логи кормят улучшение модели. То есть ваш SSD это плата за чужой датасет, и баланс «детализация против железа» OpenAI будет считать не в вашу пользу.

«На моей машине после примерно 21 дня работы основной SSD записал около 37 ТБ. На SSD объемом 1 ТБ это означает около 640 полных записей диска в год. Некоторые потребительские SSD рассчитаны примерно на 600 TBW, поэтому это может исчерпать весь гарантированный ресурс за менее чем год.»

— Автор issue на GitHub, разработчик, использующий Codex