Codex и SSD-износ: что баг с логами говорит о рисках AI-агентов

По состоянию на 23 июня 2026 года история с Codex SSD износом выглядит так: пользователь GitHub сообщил о 37 ТБ записи на SSD за 21 день работы Codex, связал это с локальными SQLite-логами и экстраполировал нагрузку примерно до 640 ТБ в год. Это пользовательская оценка из issue, а не официальное заявление OpenAI.

Главная деталь не в страшной формулировке «Codex убивает SSD». Гораздо важнее механизм: локальный AI-агент ведет себя как часть инфраструктуры разработчика. Если у него без лимитов работают TRACE-логи, SQLite WAL и постоянная телеметрия, он может незаметно создавать нагрузку на диск, хотя сам файл базы выглядит небольшим.

OpenAI уже закрыла первичный issue после двух PR от 22 июня. Но 23 июня появился follow-up по Windows Codex Desktop, где пользователь пишет, что похожий churn логов все еще воспроизводится. Поэтому правильный вывод для разработчиков осторожнее: не паниковать, но проверить I/O и обновления, если Codex или похожий AI-агент постоянно запущен локально.

Что произошло с Codex и SSD-износом

Первичный отчет появился в GitHub issue openai/codex#28224, открытом 14 июня 2026 года. Автор указал, что Codex постоянно пишет в локальную SQLite-базу обратной связи: ~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal и ~/.codex/logs_2.sqlite-shm.

По его замерам, за 21 день uptime основной SSD получил около 37 ТБ записи, а проверки на уровне процесса и файлов показали Codex SQLite logs как главный постоянный источник. Экстраполяция дала примерно 640 ТБ в год. Для контекста автор сравнил это с потребительским SSD на 1 ТБ и рейтингом порядка 600 TBW, но такую оценку нельзя автоматически переносить на все диски, версии Codex и сценарии работы.

Эта история попала в русскоязычные пересказы как сюжет «Codex может убить SSD». Для Toolarium интереснее другой слой: проблема возникла не из-за reasoning-модели, не из-за промптов и не из-за «магии ИИ», а из-за обычной инженерии логирования. Агент для кода становится локальным сервисом, а сервис без лимитов на запись способен тратить ресурс машины.

Почему маленький файл может дать большую запись

Файл logs_2.sqlite сам по себе не обязан раздуваться до десятков терабайт. В issue описан другой паттерн: строки активно вставляются, индексируются, уходят в WAL, затем обрезаются или ротируются, а счетчик SQLite продолжает расти. Снаружи база может выглядеть около гигабайта, но накопитель уже видел намного больше операций записи.

В одном снимке автор указал: текущий размер logs_2.sqlite - 1,2 GiB, сохраненных строк - 506 149, а общий счетчик выделенных row id ушел за 5,54 млрд. В другом срезе retained log content оценивался в 1 035,6 MiB, при этом TRACE занимал 70,7% байтов, INFO - 25,7%, DEBUG - 3,0%, WARN - 0,6%.

Это объясняет, почему смотреть только на размер файла недостаточно. Важны WAL, частота вставки и удаления, индексы, checkpoints, page rewrites и write amplification на уровне файловой системы и устройства. В апрельском issue openai/codex#17320 похожая проблема описывалась через streaming: app-server писал около 5 MiB/s в logs_2.sqlite-wal, хотя процесс был запущен с RUST_LOG=warn.

Что OpenAI уже исправила

22 июня 2026 года issue #28224 был закрыт после двух merged PR. В #29432 OpenAI остановила запись каждого успешного Responses WebSocket event в persistent logs. В описании PR сказано, что каждый такой event раньше порождал три локальные записи: полный payload на TRACE, OpenTelemetry log event и OpenTelemetry trace event.

Второй PR, #29457, отфильтровал шумные targets в SQLite sink: bridged target=log events и два зеркальных codex_otel-target. Автор первичного issue после этого написал, что на его установке объем логов должен сократиться примерно на 85%, и закрыл issue.

Это важная поправка к громким заголовкам. Нельзя писать, что OpenAI ничего не сделала: два исправления уже в main. При этом нельзя и объявлять проблему полностью закрытой для всех пользователей, потому что один закрытый issue не равен проверке всех платформ, сборок и режимов Codex Desktop.

Почему история не закрыта полностью

23 июня появился follow-up openai/codex#29556. В нем пользователь Windows 11 пишет, что после #29432 и #29457 все еще воспроизводит persistent SQLite log churn в новом пакете Codex Desktop. По его словам, logs_2.sqlite и WAL продолжают писаться во время обычного использования, а сохраненные строки по-прежнему доминируются TRACE targets.

Это не доказывает, что каждый пользователь Codex продолжит терять сотни терабайт записи в год. Это показывает, что класс проблемы шире одного шумного WebSocket target. Локальный агент может иметь несколько каналов логирования: приложение, app-server, CLI, OpenTelemetry mirror events, сетевые библиотеки и платформенные адаптеры. Исправить один источник полезно, но инженерный риск остается, пока нет понятных лимитов, ротации, метрик и безопасных настроек по умолчанию.

Что это говорит о локальных AI-агентах

Codex постепенно выходит за рамки «чат-бота для кода». В соседнем материале про Codex Record & Replay мы разбирали, как OpenAI учит агента повторять рабочие сценарии. В статье про покупку Ona обсуждали другой вектор: постоянную облачную среду для Codex-задач. История с SSD показывает локальную сторону той же трансформации.

AI-агент теперь живет рядом с git, IDE, shell, файловой системой, локальными базами и телеметрией. Он не только генерирует код, но и читает проект, запускает инструменты, хранит состояние, пишет логи и иногда висит фоном часами. Поэтому к нему надо применять те же вопросы, что к любому локальному сервису: сколько он пишет на диск, куда складывает временные данные, как ограничивается логирование, что происходит при ошибке и как это увидеть до инцидента.

Похожий урок был в материале про Claude Code и git reset --hard: риски AI-coding tools не всегда выглядят как «модель ошиблась в рассуждении». Иногда инструмент ломает рабочую среду обычным техническим действием: перезаписывает файлы, меняет git-состояние или бесконтрольно пишет диагностические данные.

Что проверить разработчику

Если Codex или другой AI-агент постоянно запущен локально, начните с наблюдения, а не с опасных workaround. Проверьте версию Codex и наличие обновлений после 22 июня. Затем сравните дисковую активность с агентом и без него: системные счетчики записи, SMART/NVMe TBW, активность процесса и частоту изменения SQLite/WAL-файлов скажут больше, чем размер одного .sqlite.

• Проверьте, растут ли ~/.codex/logs_2.sqlite, .sqlite-wal и .sqlite-shm во время обычной работы.
• Смотрите не только размер базы, но и запись на уровне устройства: WAL может активно churn-иться при стабильном размере основного файла.
• Сравните I/O до и после обновления Codex; если нагрузка осталась, зафиксируйте версию, платформу и сценарий.
• Не переносите SQLite-файлы в tmpfs и не ставьте SQLite triggers как универсальное решение. Это временные обходы для тех, кто понимает последствия для логов, диагностики и восстановления.
• Для корпоративной среды добавьте AI-coding agents в обычный SRE-чеклист: лимиты логов, ротация, мониторинг I/O, дефолтный уровень логирования и политика telemetry sink.

Самый полезный вывод из этой новости простой: локальный AI-агент нельзя оценивать только по качеству ответа. Он стал программой, которая потребляет CPU, память, сеть и ресурс SSD. Значит, безопасные настройки по умолчанию и наблюдаемость важны не меньше, чем очередной прирост в benchmark.

FAQ

Codex действительно убивает SSD?

Нет подтверждения, что Codex гарантированно «убивает SSD» у всех пользователей. Есть пользовательский отчет в GitHub issue #28224: 37 ТБ записи за 21 день и оценка около 640 ТБ в год на одной установке. Это серьезный сигнал, но он зависит от версии Codex, платформы, времени работы и сценария использования.

Почему файл logs_2.sqlite может быть маленьким, а запись на диск огромной?

SQLite может активно вставлять и удалять строки, писать WAL, обновлять индексы и выполнять checkpoints. Основной файл базы при этом остается сравнительно небольшим, но накопитель видит все промежуточные записи. Поэтому для диагностики нужны счетчики записи и наблюдение за WAL, а не только размер .sqlite.

Что делать, если Codex постоянно пишет на диск?

Сначала обновите Codex и измерьте I/O повторно. Если нагрузка сохраняется, соберите факты: версия, платформа, активный процесс, изменение WAL, счетчики TBW и сценарий воспроизведения. После этого имеет смысл смотреть открытые issues или заводить новый отчет. Обходы вроде tmpfs стоит применять только временно и осознанно.

Источники и проверка фактов

Факты проверены 23 июня 2026 года. Состояние GitHub issues, PR и поведение Codex Desktop может измениться после этой даты.

• GitHub openai/codex#28224: Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance.
• GitHub openai/codex#29432: Stop logging every Responses WebSocket event, merged 22 июня 2026 года.
• GitHub openai/codex#29457: Filter noisy targets from persistent logs, merged 22 июня 2026 года.
• GitHub openai/codex#29556: Persistent SQLite TRACE log churn still reproducible on Windows after #29432/#29457, opened 23 июня 2026 года.
• GitHub openai/codex#17320: Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG, opened 10 апреля 2026 года.