Когда AI-агент начинает убивать SSD: разбор инцидента с Codex и 640 ТБ логов в год

В июне 2026 года в репозитории OpenAI Codex появился баг-репорт, который быстро стал одним из самых обсуждаемых. Пользователь обнаружил, что Codex непрерывно пишет огромный объем диагностических логов в локальную SQLite-базу и потенциально способен записывать до 640 ТБ данных в год на SSD. Через неделю проблема была признана и исправлена двумя PR.

Что произошло

Автор заметил аномально высокий износ диска:

• за 21 день SSD записал около 37 ТБ данных;

• основным источником записи оказался Codex;

• логи сохранялись в SQLite-файлы:

  • logs_2.sqlite

  • logs_2.sqlite-wal

  • logs_2.sqlite-shm

Если экстраполировать эти цифры на год, получается около 640 ТБ записи, что сопоставимо или даже превышает ресурс многих потребительских SSD на 1 ТБ.

Самая интересная находка

Размер базы составлял всего около 1.2 ГБ, однако счетчик записей SQLite показывал более 5.5 миллиардов вставок. При этом реально в базе оставалось лишь около 500 тысяч строк.

Это означает, что система постоянно:

1. записывала новые логи;

2. записывала новые логи;

3. индексировала их;

4. писала данные в WAL;

5. удаляла старые записи;

6. снова записывала новые.

То есть происходило классическое write amplification — огромный объем физической записи ради относительно небольшого количества сохраняемых данных.

Что именно генерировало трафик

Анализ логов показал довольно типичную проблему инженерии observability:

Основными виновниками стали:

• логирование WebSocket-сообщений;

• SSE-события;

• внутренние сообщения tokio;

• inotify-события файловой системы;

• OpenTelemetry-трейсы;

• сетевой транспортный слой.

Фактически в SQLite сохранялось почти всё подряд на уровне TRACE.

Корневая причина

Проблема оказалась удивительно простой. Для SQLite-логирования был установлен глобальный уровень:

Targets::new().with_default(Level::TRACE)

То есть система сохраняла практически любые внутренние события, включая низкоуровневые сообщения библиотек и сетевых протоколов. Это хороший пример того, как настройки, полезные для отладки, случайно попадают в production и начинают создавать огромные накладные расходы.

Почему это важно не только для Codex

Сам инцидент гораздо интереснее конкретного бага. Он показывает типичную проблему современных AI-агентов:

1. Агент — это не просто LLM

Сегодняшний агент состоит из множества подсистем:

• модель;

• терминал;

• файловая система;

• телеметрия;

• логи;

• контекст;

• память;

• WebSocket-коммуникации;

• плагины и инструменты.

Большая часть инженерных проблем возникает именно вокруг этих компонентов, а не вокруг самой модели. Это подтверждают и исследования багов AI-агентов: более трети проблем связаны с интеграциями, инфраструктурой и конфигурацией, а не с качеством генерации кода. (arXiv)

2. AI-инструменты создают новые классы багов

В комментариях сообщества обсуждались последствия:

• быстрый износ SSD;

• переполнение дисков;

• деградация производительности;

• ошибки при долгих сессиях;

• проблемы с памятью;

• зависания интерфейса. (Reddit)

Причем многие связанные issue в Codex касаются именно:

• контекст-компактации;

• логирования;

• WAL-файлов;

• фоновых процессов;

• утечек ресурсов.

3. Чем сложнее агент — тем важнее классическая инженерия

На фоне хайпа вокруг вайб-кодинга этот кейс выглядит особенно показательным. LLM прекрасно пишет код, но:

• кто-то должен проектировать телеметрию;

• кто-то должен ограничивать логирование;

• кто-то должен контролировать потребление ресурсов;

• кто-то должен понимать работу SQLite, WAL и файловой системы.

Именно поэтому востребованными остаются инженеры, а не просто пользователи AI.

Чем всё закончилось

22 июня автор закрыл issue. Команда OpenAI оперативно внесла два изменения:

1. отключила логирование каждого WebSocket-события;

2. отфильтровала наиболее шумные источники логов.

По словам автора, это позволило сократить объем логирования примерно на 85%.

Вывод

История с Issue #28224 — не просто баг про SQLite. Это хороший пример того, что основные проблемы AI-агентов сегодня лежат не в области генерации кода, а в области классической software engineering:

• управление ресурсами;

• наблюдаемость;

• телеметрия;

• производительность;

• работа с диском и памятью.

Чем мощнее становятся AI-агенты, тем важнее становятся инженеры, которые понимают, как работают системы под капотом. И этот кейс отлично показывает, почему эпоха «просто попросил ИИ написать приложение» пока не отменяет необходимость разбираться в технологиях.