Codex записал 37 ТБ логов за 3 недели: главные проблемы AI агентов не в модели

В июне 2026 года в репозитории OpenAI Codex (облачный ИИ-агент для написания кода) появился баг-репорт под номером 28224. Пользователь заметил, что за 21 день его SSD записал около 37 терабайт данных, и основным источником записи оказался именно Codex. Проблему признали, и команда OpenAI закрыла её двумя исправлениями 22 июня. Но сам инцидент оказался показательнее любого бенчмарка: он наглядно продемонстрировал, где именно ломаются ИИ-агенты на практике.

Что записывало 37 терабайт и почему база весила всего гигабайт?

Самая любопытная деталь: файл базы данных весил около 1,2 гигабайта, но счётчик записей SQLite показывал больше 5,5 миллиарда вставок. Реально в базе оставалось лишь около 500 тысяч строк.

Происходило то, что инженеры называют write amplification (усиление записи, когда ради хранения небольшого объёма данных диск физически записывает в десятки раз больше):

• Codex непрерывно записывал новые логи в SQLite
• Индексировал их
• Писал данные в WAL-файл (журнал упреждающей записи, промежуточный буфер SQLite)
• Удалял старые записи
• И тут же записывал новые

Корневая причина оказалась до обидного простой. Для SQLite-логирования был выставлен глобальный уровень TRACE, самый подробный из возможных. В базу попадало буквально всё: каждое сообщение WebSocket (протокол постоянного соединения с сервером), каждое SSE-событие (потоковая передача данных от сервера), внутренние сообщения библиотеки tokio, события файловой системы, трейсы OpenTelemetry (система наблюдаемости) и данные сетевого транспортного слоя.

Отладочная настройка, полезная на стенде разработчика, случайно попала в рабочую версию продукта.

Почему это касается не только программистов?

Любой, кто разворачивает ИИ-агентов на своём компьютере или сервере, сталкивается с той же архитектурой. Современный ИИ-агент состоит не из одной языковой модели. Вокруг неё работают:

• Терминал и файловая система
• Телеметрия (наблюдаемость, сбор данных о поведении программы) и логи
• Контекст и память
• WebSocket-соединения
• Плагины и внешние инструменты

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

В обсуждении на Reddit пользователи перечисляли последствия, с которыми столкнулись:

• Быстрый износ SSD
• Переполнение дисков
• Деградация производительности
• Ошибки при долгих сессиях
• Зависания интерфейса

Связанные баг-репорты в Codex касались тех же инфраструктурных проблем: компактация контекста, WAL-файлы, фоновые процессы, утечки ресурсов. Это типичная картина проблем ИИ-агентов, которая повторяется от продукта к продукту.

Как исправили и что проверить у себя?

Команда OpenAI внесла два изменения:

• Отключила логирование каждого WebSocket-события
• Отфильтровала наиболее «шумные» источники логов

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

Как проверить свой диск прямо сейчас

1. Посмотрите статистику записи SSD. На Windows откройте CrystalDiskInfo (бесплатная утилита), на macOS используйте smartctl из Homebrew. Ищите параметр Total Bytes Written: если цифра растёт на терабайты в неделю, что-то пишет слишком много
2. Найдите крупные SQLite-файлы. Поищите файлы с расширениями .sqlite, .sqlite-wal, .sqlite-shm в папках ИИ-инструментов. Если WAL-файл весит гигабайты, логирование, скорее всего, избыточное
3. Ограничьте уровень логирования. Если вы разработчик и настраиваете агентное решение, никогда не оставляйте TRACE в рабочей среде. Уровень INFO или WARN достаточен для продакшена

При чём тут российские ИИ-инструменты?

Из доступных в РФ агентных решений ближе всего к сценарию Codex стоят GigaCode от Сбера и интеграции YandexGPT с IDE. По моим наблюдениям, оба инструмента пока работают преимущественно через облачные API и не ведут локальное логирование такого масштаба. Но если вы разворачиваете любую агентную систему локально, с открытыми моделями через Ollama или LM Studio, проблема избыточных логов воспроизводится один в один: SQLite, WAL, усиление записи. Язык модели и производитель значения не имеют, имеет значение конфигурация инфраструктуры.

Частые вопросы

Мой SSD уже повреждён, если я пользовался Codex?

Не обязательно. Проверьте параметр Total Bytes Written в CrystalDiskInfo или аналогичной утилите и сравните с заявленным ресурсом диска (обычно 300-600 терабайт для потребительских SSD на 1 терабайт). Если использовали Codex недолго, износ, скорее всего, в пределах нормы. После исправления бага объём записи снизился примерно на 85%.

Это проблема только Codex или других ИИ-инструментов тоже?

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

Зачем вообще ИИ-агентам столько логов?

Логи нужны для наблюдаемости (observability): разработчики отслеживают, что делает агент, какие инструменты вызывает, где ошибается. Проблема возникает, когда уровень детализации, подходящий для отладки на тестовом стенде, случайно остаётся в рабочей версии. Решение не отключать логи совсем, а выставить разумный уровень: INFO или WARN вместо TRACE.

Случай с Issue #28224 лучше любой презентации объясняет, почему эпоха «просто попросил ИИ написать приложение» не отменяет необходимость разбираться в том, как работают системы под капотом. Чем мощнее становятся ИИ-агенты, тем важнее люди, которые понимают, что происходит на уровне диска, памяти и конфигурации.