Баг Codex: ИИ-агент писал на SSD до 640 ТБ в год - разбор 2026

Проверить диск: за 10 минут · Сэкономит: ресурс SSD ценой до 31 000 ₽ на Mac · Уровень: средний · Чтение: ~28 минут · Данные актуальны на 09.07.2026

Что узнаешь:

• Что за баг openai/codex #28224: 37 ТБ записано на SSD за 21 день и как из этого выходит 640 ТБ в год
• Почему логи весят терабайты, а сам файл всего 1,2 ГиБ: TRACE по умолчанию, WAL и разрыв в 10 000 раз
• Много ли 640 ТБ: таблица TBW трёх SSD и расчёт, что ресурс диска на 1 ТБ сгорает за ~11 месяцев
• Команды проверки диска на 10 минут: smartctl для Linux и macOS, CrystalDiskInfo для Windows
• 4 шага защиты: обновить до 0.143.0, прогнать VACUUM, поставить SQLite-триггер, увести файл в tmpfs
• Похожая история у Claude Code: 42 ГБ логов за неделю в issue #16093 - и что это значит для агентов

Главное. ИИ-агент Codex (в рунете его ищут как «кодекс ии») писал локальный лог в SQLite на уровне TRACE, игнорируя настройки: за 21 день - около 37 ТБ записи на SSD при размере самой базы 1,2 ГиБ. В пересчёте на год - до 640 ТБ, ресурс потребительского диска на 1 ТБ примерно за 11 месяцев. Баг жил с марта по июнь 2026, к концу июня его срезали на 85% тремя патчами.

Ты дал агенту задачу, он написал код, отрапортовал «готово». А между делом, пока ты пил кофе и правил его правки, он тихо записал на твой SSD десятки терабайт служебных логов. Ты этого не видел. В диспетчере ничего не мигало, файл на диске так и остался в районе гигабайта. Но счётчик записи на контроллере диска накрутился так, будто ты месяцами гонял торренты в две стороны.

Ресурс записи у SSD конечный, а на ноутбуках Apple с 2018 года диск впаян в плату - замена выйдет в десятки тысяч рублей, точные цифры ниже. То есть баг в бесплатной обёртке ИИ для кода способен превратиться в счёт за ремонт размером с бюджетный ноутбук. Подписку на этот инструмент из России и так напрямую не купить. А сами агенты никуда не деваются: тысячи пользователей и команд каждый день работают с теми же моделями через единый API provod.ai, и дисковый след у агентов там такой же. Следить придётся в любом случае.

Разберу по порядку: что именно случилось, откуда терабайты, много ли это для твоего диска, как проверить свой SSD прямо сейчас, как починить и что делать владельцу Mac. И заодно - один ли Codex такой.

Что за баг: как Codex записал 37 ТБ на SSD за три недели?

Главное. 14 июня 2026 разработчик под ником 1996fanrui открыл в репозитории openai/codex issue #28224. За 21 день непрерывной работы Codex CLI записал на его SSD около 37 ТБ, хотя файл лога ~/.codex/logs_2.sqlite весил всего 1,2 ГиБ. В пересчёте на год выходит ~640 ТБ. На Hacker News тред к 9 июля 2026 собрал 510 голосов и 271 комментарий.

Первоисточник тут технический - баг-репорт с приложенными замерами и снапшотами базы. Заголовок issue дословно: «Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance» (логи обратной связи Codex в SQLite могут писать ~640 ТБ в год и быстро расходовать ресурс SSD). Открыл его 14 июня 2026 разработчик 1996fanrui; все цифры ниже я перепроверил по самой странице issue.

Голая арифметика такая. За 21 день аптайма Codex CLI - консольный вайбкодинг-агент OpenAI, тот самый «кодекс ии» из поисковых подсказок, который правит код у тебя на машине, - на диск ушло около 37 ТБ. Сам файл базы logs_2.sqlite при этом занимал 1,2 ГиБ и не рос. Рядом с ним лежали спутники WAL и SHM (-wal, -shm) - служебные файлы того же SQLite. Экстраполяция автора звучит так:

«On a 1 TB SSD, that is about 640 full-drive writes per year» - для SSD на 1 ТБ это примерно 640 полных перезаписей диска в год.

• 1996fanrui, автор issue openai/codex #28224, 14 июня 2026, перевод с английского.

640 полных перезаписей за год. Не 640 ТБ «где-то в облаке», а 640 раз переписанный от корки до корки твой личный диск. Тред на Hacker News под заголовком «Codex logging bug may write TBs to local SSDs» (баг логирования Codex может писать терабайты на локальные SSD) к 9 июля 2026 набрал 510 голосов и 271 комментарий - для узкотехнической темы это много.

Русскоязычные IT-СМИ разобрали новость за неделю: Хабр, SecurityLab, 3DNews, 4PDA и ещё десяток площадок. Но по запросу «кодекс ии» выдача так и состоит из коротких рерайтов GitHub-issue на 400-800 слов. Что реально происходит внутри базы и почему при терабайтах записи файл не пухнет - объясняю ниже.

Почему логов на терабайты, а файл весит гигабайт?

Главное. Codex писал логи в SQLite по схеме insert-and-prune: строки постоянно вставлялись и тут же удалялись, файл держался около гигабайта, а физическая запись копилась на диске. За 15 секунд в базу влетало 36 211 строк, а число хранимых оставалось прежним. Корень - глобальный уровень логирования TRACE по умолчанию, из-за которого 70,7% записанных байт были самым подробным трейсом.

Разгадка парадокса «терабайты записи при гигабайтном файле» - в том, как работает эта база. Codex складывал логи в SQLite в режиме WAL (write-ahead log, журнал упреждающей записи). Строки логов вставлялись потоком, старые тут же вычищались, чтобы файл не разрастался. Схема называется insert-and-prune - «вставил и подрезал». Файл на диске остаётся маленьким, а вот контроллер SSD исправно считает каждую вставку и каждую вычистку как физическую запись. На языке SSD это называется write amplification - усиление записи.

Масштаб разрыва видно по цифрам из issue. На момент снапшота в базе хранилось 506 149 строк. А общее число выданных идентификаторов строк - 5 543 677 486. Больше пяти с половиной миллиардов. Разрыв примерно в десять тысяч раз: на каждую строку, которая реально лежит в базе, приходятся тысячи вставленных и уже удалённых. Автор замерил и скорость:

«About 36,211 rows were inserted in 15 seconds, while retained row count stayed flat» - около 36 211 строк вставлено за 15 секунд, при этом число хранимых строк не менялось.

• 1996fanrui, issue openai/codex #28224, июнь 2026, перевод с английского.

36 тысяч строк за 15 секунд - и все в мусорную корзину. Теперь откуда столько логов. Автор разложил второй снапшот на 681 774 строки по уровням логирования:

• TRACE - 732,5 МиБ, это 70,7% всех байт;
• INFO - 266,5 МиБ (25,7%);
• DEBUG - 30,6 МиБ (3,0%);
• WARN - 5,9 МиБ (0,6%).

Больше двух третей объёма - уровень TRACE, самый подробный и болтливый режим, который в нормальной жизни включают только при отладке. Главный источник - трейс вебсокет-эндпоинта: codex_api::endpoint::responses_websocket дал 527,4 МиБ в одиночку. А две OpenTelemetry-цели codex_otel.log_only и codex_otel.trace_safe вместе занимали примерно 96% хранимых байт лога.

Корневая причина в issue названа прямо: синк лога был поднят с глобальным дефолтом TRACE.

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

Эта строчка ставит уровень TRACE по умолчанию для всего. Из-за неё логгер игнорировал переменную окружения RUST_LOG, которой обычно приглушают вывод. То есть даже если ты явно просил писать пожиже, синк тебя не слушал.

Русскоязычные комментаторы на Хабре поставили диагноз без академизмов. Пользователь endpoints написал в комментариях на Хабре в июне 2026: «Но там банально забыли перевести режим на инфу, или на варн». Ровно так: забыли снять TRACE. Дальше - вопрос, много ли это для железа.

640 ТБ в год - это много? Сравниваем с ресурсом SSD

Главное. У потребительских SSD ресурс записи (TBW) указан в паспорте: у топовых дисков на 1 ТБ это около 600 терабайт записи. 640 ТБ в год превышают этот ресурс - диск на 1 ТБ вырабатывает гарантийный лимит примерно за 11 месяцев, на 2 ТБ - за 22,5 месяца. Мгновенно диск не умрёт, но заметный кусок его жизни сгорает на служебных логах.

У каждого SSD есть паспортный ресурс записи - TBW, terabytes written, сколько терабайт можно записать до конца гарантии. Число печатают в даташите. Взял три ходовые модели по официальным спецификациям вендоров.

Ёмкость	Samsung 990 Pro, TBW	WD Black SN850X, TBW	Crucial T500, TBW	За сколько сгорит при 640 ТБ/год
500 ГБ	-	-	300	~5,6 месяца
1 ТБ	600	600	600	~11 месяцев
2 ТБ	1200	1200	1200	~22,5 месяца
4 ТБ	2400	2400	-	~45 месяцев

Данные TBW: даташиты Samsung (download.semiconductor.samsung.com), WD/SanDisk (documents.sandisk.com), Crucial (crucial.com), гарантия у всех - 5 лет или выработка TBW, что наступит раньше. У WD Black SN850X есть и модель на 8 ТБ с ресурсом 4800 TBW.

Расчёт простой: 640 ТБ в год делим на 600 TBW - получаем 0,94 года, около 11,25 месяца. Диск на 1 ТБ, рассчитанный производителем на пять лет, при таком фоне вырабатывает весь гарантийный ресурс меньше чем за год. На 2 ТБ - вдвое дольше, 22,5 месяца, но и это против заявленных пяти лет выглядит грустно. Механику, откуда берётся столько записи, разобрали выше - тут важно следствие: служебный лог съедает ресурс, за который ты заплатил.

Теперь честно про пределы этой оценки. 640 ТБ - экстраполяция с 21 дня непрерывной работы на целый год. Мало кто держит агента запущенным круглосуточно 365 дней. На Хабре пользователь Metotron0 в июне 2026 подметил это с иронией: «640 - это если он кодит без выходных и отпусков». Справедливо.

Реальный годовой износ у большинства будет ниже - пропорционально тому, сколько часов агент реально крутился. Но даже треть от 640 ТБ - это 210 ТБ в год на пустых трейсах, треть ресурса годового диска на 1 ТБ. И превышение над паспортом само по себе не значит, что диск умрёт ровно на 601-м терабайте: TBW - консервативная гарантийная оценка, реальный ресурс NAND обычно выше.

Спорить о точной дате смерти диска можно долго, суть не в ней: фоновый процесс жёг ресурс, которого ты ему не давал.

Codex из России: как получить доступ. Codex включён в подписки ChatGPT - Plus за $20/мес, Pro от $100/мес - либо работает по API-ключу OpenAI. Из РФ ни то ни другое напрямую не оплатить: карта отлетает на процессинге из-за санкций к банковскому сектору, а с российского IP страница часто не грузится вовсе (об этом две отдельные статьи на vc.ru, март и май 2026). Мало того что баг ест ресурс SSD - так ещё и инструмент, который его ест, картой РФ не купишь. Если строишь собственных агентов на API, те же модели - GPT-5.5, Claude, Gemini - доступны через provod.ai по API в рублях, интерфейс OpenAI- и Anthropic-совместимый, цены 1:1 с официалом. Ключ и baseURL меняешь в конфиге, код не трогаешь: подключить модели по API в рублях.

Кого задел баг и во сколько он обошёлся?

Главное. Баг жил с марта по июнь 2026, всё это время писал у всех, кто гонял свежий Codex CLI. The Register оценил суммарный ущерб в «младшие» миллионы долларов сожжённого ресурса SSD. Один пользователь посчитал свой личный убыток в $38,64 на Samsung 990 на 2 ТБ. На Mac с впаянным диском замена обходится в 27 000-31 000 ₽ по прайсам сервисов РФ на июль 2026.

Окно проблемы - март-июнь 2026. Всё это время подробное логирование работало по умолчанию у всех, кто пользовался актуальными на тот момент версиями Codex CLI. То есть под раздачу разом попала масса пользователей агента. Издание The Register (автор Thomas Claburn, 23 июня 2026) прикинуло агрегированный ущерб:

«This regression plausibly burned low-single-digit millions of dollars of SSD endurance across users during the March-June window» - этот регресс, по правдоподобной оценке, сжёг ресурса SSD на "младшие" миллионы долларов у пользователей за окно с марта по июнь.

• The Register, Thomas Claburn, 23 июня 2026, перевод с английского.

Считаешь просто: объём записи умножаешь на цену диска и делишь на его ресурс TBW - получаешь, на сколько денег стёрся диск. Один пользователь так и сделал для своего накопителя, его цитирует The Register: «this bug cost me $38.64 in drive value of my Samsung 990 2 TB NVMe» (этот баг стоил мне $38,64 в стоимости диска, моего Samsung 990 на 2 ТБ NVMe). 3DNews в переводе того же материала приводит диапазон $12,33-$38,64 на пользователя.

Официальная реакция OpenAI была скупой. The Register пишет, что представитель компании подтвердил: инженеры знают о проблеме и работают над исправлением. Развёрнутого поста в блоге или заявления не было - только эта фраза и правки в коде. В самом issue #28224 подробных комментариев мейнтейнеров тоже нет: все три патча выкатил один разработчик, jif-oai.

Теперь про боль, которой нет в англоязычных разборах, - Mac. Начиная с MacBook 2018 года (чип T2 и все Apple Silicon - M1, M2, M3, M4) SSD физически впаян в материнскую плату. Штатно его не поменять и не апгрейдить, только перепайка на уровне микросхем в сервисе.

Реальные цены РФ на июль 2026: переустановка впаянного накопителя - около 27 000 ₽ за 1 ТБ и 31 000 ₽ за 2 ТБ, срок два-три дня (по прайсам сервисов вроде iRepair). Полная замена материнской платы - от 20 000 до 25 000 ₽ (по прайсам Orange-Apple).

На Хабре под июньской новостью arinatitova зло сформулировала суть претензии: «Инструмент для программистов сам содержит баг уровня первый курс». Если этот баг «уровня первый курс» реально доест диск на MacBook Air - счёт будет сопоставим с ценой нового ноутбука. Поэтому первый практический вопрос - проверить, что с твоим диском.

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

Главное. Накопленную запись показывает SMART-статистика диска. На Linux и macOS её читает smartctl из пакета smartmontools, на Windows проще всего CrystalDiskInfo. Смотришь параметр Data Units Written (NVMe) или Total Host Writes и сравниваешь с паспортным TBW. Занимает пять-десять минут, ничего в системе не ломает - только чтение.

Диск сам ведёт счётчик того, сколько на него записали за всю жизнь. Лежит он в SMART - служебной телеметрии накопителя. Достать его можно на любой ОС. Пройди по шагам под свою систему.

Linux, NVMe-диск (1-4):

1. Поставь smartmontools, если его нет: sudo apt install smartmontools (Debian/Ubuntu) или аналог для твоего дистрибутива.
2. Найди диск - обычно это /dev/nvme0. Список: lsblk или nvme list.
3. Прочитай SMART:

sudo smartctl -a /dev/nvme0

1. В выводе найди строку Data Units Written. Одна единица тут равна 512 000 байт (по man smartctl(8), первое значение соответствует 1000 единиц по 512 байт). Умножаешь число единиц на 512 000, делишь на 1 000 000 000 000 - получаешь записанные терабайты. Сравниваешь с TBW из таблицы выше.

Linux, SATA-диск: смотри атрибут 241 Total_LBAs_Written в том же выводе smartctl -a. Умножаешь на размер сектора (обычно 512 байт). Оговорка: атрибут vendor-specific начиная с ATA/ATAPI-4, у некоторых накопителей единицы могут отличаться - сверяйся с даташитом своего диска.

macOS (1-3):

1. Поставь smartmontools через Homebrew: brew install smartmontools.
2. Узнай имя диска: diskutil list - системный обычно disk0.
3. Прочитай SMART:

sudo smartctl -a disk0

Дальше как на Linux - ищешь Data Units Written. Важно: команда iostat покажет только скорость записи прямо сейчас, а не накопленный за всю жизнь объём. Для оценки износа нужен именно SMART-счётчик.

Windows: ставишь CrystalDiskInfo (бесплатная утилита с crystalmark.info), запускаешь - она сразу показывает по каждому диску параметр Total Host Writes в гигабайтах или терабайтах, а также «здоровье» в процентах. Сравниваешь Total Host Writes с паспортным TBW своей модели.

Что делать с числом. Если диску год-два, а записано уже под сотню-другую терабайт при паспорте 600 - повод насторожиться и посмотреть, кто пишет. Отдельно проверь размер логов Codex: файл ~/.codex/logs_2.sqlite и его спутники -wal, -shm. Если lsof или проводник показывают, что база живёт и растёт, а рядом крутится агент, - переходи к защите. Она ниже.

Починили ли баг - и насколько?

Главное. Да, но не полностью. К 22-23 июня 2026 разработчик jif-oai выкатил три патча (#29432, #29457, #29599), они вошли в релизы 0.142.0 и 0.143.0. Автор issue оценил эффект в «примерно 85% логов» и закрыл тикет. Осадок остаётся: похожий репорт про избыточную запись на macOS #29876 открыт 24 июня и на 9 июля 2026 всё ещё висит открытым.

Чинил баг один человек - jif-oai, автор всех трёх пул-реквестов. Вот они по порядку.

PR	Что делает	Мерж	Релиз
#29432	Перестал логировать каждое событие Responses WebSocket	22.06.2026	0.142.0
#29457	Отфильтровал шумные цели из постоянных логов	22.06.2026	0.142.0
#29599	Перестал сохранять bridged-события лога	23.06.2026	0.143.0

Логика правок такая. #29432 убил главный источник: каждое успешное вебсокет-событие рождало три записи (payload на TRACE плюс две OpenTelemetry), и партиция на 1000 строк заполнялась за секунды. #29457 отфильтровал шумные логи зависимостей и OTel-зеркало. #29599 закрыл дыру, через которую bridged-записи проскакивали фильтр под своим оригинальным именем цели - их отсекли в самом синке.

Итог автор issue подвёл сам, когда закрывал тикет 23 июня: «the following 3 PRs are merged, it could avoid 85% logs (feedback from my codex), so let me close this issue» (эти три пул-реквеста слиты, они могли бы срезать 85% логов - по отзыву моего codex, так что закрываю issue). 85%, не 100%. Пятнадцать процентов лишней записи по его же оценке остаётся.

Актуальные версии на 9 июля 2026: стабильный релиз rust-v0.143.0 вышел 8 июля, есть и предрелиз 0.144.0-alpha.4 от 9 июля. То есть если у тебя Codex старше 0.142.0 - ты всё ещё на баганой версии, обновляйся в первую очередь.

Радоваться рано и по другой причине. 24 июня 2026, уже после патчей, разработчик Ko7ov-Konstantin открыл issue #29876 «Excessive disk writes / SSD wear concern on macOS Codex app and JetBrains ACP». Замеры там свежие: около 207 МБ записи в минуту в простое, порядка 1,05 ГБ за две минуты активной работы, кэш com.openai.codex.code_sign_clone разросся до 12 ГБ, а logs_2.sqlite снова 166 МБ плюс 31 МБ WAL. На 9 июля 2026 этот тикет открыт. Так что «починили» - с оговоркой: главный пожар потушили, тлеющие углы остались. Пока ждёшь официальный фикс - защищай ресурс руками: четыре шага ниже.

Как обезопаситься: 4 шага, если работаешь с Codex

Главное. Порядок такой: обновись до 0.143.0 или свежее, потом прогони VACUUM, чтобы вернуть уже занятое место, при желании поставь SQLite-триггер, блокирующий вставки в лог, а самым продвинутым - уведи файл базы в tmpfs (запись в ОЗУ вместо диска). Первые два шага безопасны почти всем. Триггер и симлинк - на свой страх: они ломают штатное логирование и не работают на Windows.

Четыре меры от простого к рискованному. Начинай сверху.

Способ	Что делает	Платформа	Риск
Обновить Codex	Ставит версию с патчами, режет запись на ~85%	Все	Нет, делай первым
VACUUM	Ужимает раздувшийся файл базы, возвращает место	Все	Низкий, только переупаковка
SQLite-триггер	Блокирует вставки в таблицу логов	Linux, macOS	Средний, ломает диагностику
Симлинк в tmpfs	Уводит запись в ОЗУ, диск не трогается	Linux, macOS	Высокий, данные летучие

Шаг 1. Обновись. Поставь Codex 0.143.0 или новее - три патча уже внутри, и они снимают львиную долю записи. Проверь текущую версию и обнови из своего пакетного менеджера. Если сидишь на чём-то из марта-мая - ты всё ещё жжёшь диск.

Шаг 2. Прогони VACUUM. Обновление останавливает новую запись, но уже раздувшийся файл базы место не вернёт. Команда VACUUM переупаковывает SQLite-файл и отдаёт незанятое обратно. Эффект пользователи наблюдали внушительный:

«I found that running VACUUM FULL on the sqlite file on my laptop shrunk it from 27GB to a mere 73MB» - я запустил VACUUM FULL на этом sqlite-файле, и он ужался с 27 ГБ до жалких 73 МБ.

• woadwarrior01, Hacker News, обсуждение бага Codex, июнь 2026, перевод с английского.

27 гигабайт превратились в 73 мегабайта. (VACUUM FULL - нестандартный для SQLite синтаксис, тут команда называется просто VACUUM - её и запускай.) Сделать так:

sqlite3 ~/.codex/logs_2.sqlite "VACUUM;"

Шаг 3. Поставь триггер (Linux/macOS). Если хочешь заглушить вставки в лог руками, не дожидаясь идеального фикса, вешаешь на таблицу триггер, который тихо игнорирует любые INSERT. Тот же woadwarrior01 привёл разошедшийся по X и Threads воркэраунд:

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

Предупреждение честное: ты вырубаешь штатную диагностику Codex. Если потом что-то сломается и тебя попросят собрать логи - их не будет. Обратимо (триггер можно удалить), но помни, что сделал.

Шаг 4. Уведи файл в tmpfs (для продвинутых, Linux/macOS). Радикальный вариант - сделать так, чтобы база вообще не касалась SSD, а жила в оперативке. На Хабре пользователь zakker так и поступил ещё до фикса, в июне 2026: «Отвел 8 гигабайт под ramdrive и всю телеметрию перенаправил туда». Механика - подменить файл симлинком на tmpfs (файловую систему в ОЗУ). Но риск реальный: tmpfs летучая, при перезагрузке содержимое пропадёт, а если под ramdisk отвести мало памяти - упрёшься в переполнение. Делай, только если понимаешь, что творишь.

⚠️ Внимание. Триггер глушит штатную диагностику Codex, а tmpfs летучая: перезагрузка стирает содержимое, нехватка ОЗУ оборачивается переполнением. Оба приёма - костыли до официального фикса. Применяй, только если понимаешь последствия и умеешь откатить.

Отдельно про Windows: шаги 3 и 4 там в таком виде не работают - остаются обновление и очистка файла.

Чего эти шаги не решают. Уже сожжённый ресурс не возвращается - счётчик записи назад не крутится. Патчи срезают ~85% логов, не все: остаток и открытый тикет #29876 никуда не делись. А SMART показывает суммарную запись без разбивки по виновникам - кто именно писал, вычисляешь по логам и кэшам сам.

Codex один такой? Claude Code тоже пишет гигабайты

Главное. Нет, не один. У Claude Code есть подтверждённый баг #16093: бесконечный цикл логирования раздул отладочные файлы до 200+ ГБ, у автора набежало 42 ГБ за 7 дней против 232 МБ у коллеги - разница почти в 180 раз. Механизм другой - текстовые логи с петлёй самозаписи вместо SQLite, - но класс проблемы тот же: фоновый лог агента незаметно съедает диск.

Болячка общая для всего класса агентских инструментов: на диск они пишут куда больше, чем ты думаешь. Разверну на прямом аналоге.

В репозитории anthropics/claude-code разработчик EthanJStark 2 января 2026 открыл issue #16093 «[BUG] Infinite logging loop in debug files causes 200GB+ disk usage» (бесконечный цикл логирования в отладочных файлах приводит к использованию 200+ ГБ диска). Механику он описал изящно и жутко: система мониторинга производительности логирует операции дольше 75 мс. Когда отладочный файл распухает настолько, что дописать в него самому становится дольше 75 мс, логгер логирует эту медленную дозапись - и получается бесконечная петля, которая кормит сама себя.

Цифры: 42 ГБ за 7 дней на 481 разговоре, тогда как у коллеги при похожем использовании набежало 232 МБ. Разрыв - около 180 раз. Тикет закрыли как «not planned» (не запланировано к исправлению). Кладу два кейса рядом.

Параметр	Codex #28224	Claude Code #16093
Объём	~37 ТБ записи за 21 день	42 ГБ файла за 7 дней (200+ ГБ в пределе)
Механика	insert-and-prune в SQLite, TRACE по умолчанию	текстовый лог + петля самозаписи медленных операций
Файл	~/.codex/logs_2.sqlite (+wal, +shm)	отладочные лог-файлы
Статус	закрыт, ~85% срезано патчами	закрыт как not planned

Claude Code (в рунете его ищут как «клод код») и Codex - топовые ИИ-агенты для кода, и оба споткнулись на логировании. А ведь есть ещё жалобы на прожорливость по другим ресурсам. На Hacker News пользователь jorl17 в сердцах написал: «Claude code (desktop) and Codex (desktop) are both absolutely dogshit pieces of software... The other day Codex (desktop) was eating up 70GB of RAM on my machine» (десктопные Claude Code и Codex - оба абсолютно паршивый софт... На днях десктопный Codex сожрал 70 ГБ оперативки на моей машине).

Диск, память, а по другим репортам и процессор - агентские приложения молодые и сырые. Отсюда правило: любой такой инструмент держи под наблюдением - режим «поставил и забыл» тут выходит боком.

Что это меняет для вайбкодинга?

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

Вайбкодинг продал идею: опиши задачу словами, агент сделает остальное, а ты не думай о деталях. Баг Codex показал изнанку этой сделки. Пока ты не думал о деталях, деталь в виде глобального TRACE молча стирала твой диск. Ошибаются все. Но тут цена ошибки легла на твоё физическое железо - на диск, о котором ты даже не вспоминал, пока агент рапортовал «готово».

На Hacker News это сформулировал applfanboysbgon - заметная реплика в треде:

«I have never written a bug that has destroyed my users' hardware» - я ни разу не писал баг, который уничтожал бы железо моих пользователей.

• applfanboysbgon, Hacker News, обсуждение бага Codex, июнь 2026, перевод с английского.

Его мысль шире одной колкости. Человек, допустивший такую ошибку однажды, запомнит её на всю жизнь и больше не повторит. Языковая модель из своих багов не учится - она сгенерирует похожий код завтра, если её об этом попросят.

Отсюда сарказм cedws в том же треде: «Moreover why isn't the bug fixed already? I thought programmers were obsolete now» (и вообще, почему баг до сих пор не починили? Я думал, программисты теперь не нужны). Инструмент, который продают как замену программисту, неделю не мог закрыть баг «уровня первый курс».

В рунете это легло на давнюю тревогу. На Хабре целый кластер статей про издержки вайбкодинга - от «когнитивной деградации» до утечек данных, и они собирают по 40-75 комментариев. Теперь к рискам «атрофии навыков» и «слива в прод» добавился третий, самый осязаемый - угроза железу.

Агентов бросать незачем. Просто перестань считать их волшебной коробкой и начни относиться как к обычному фоновому процессу: смотри, что он пишет, сколько ест, куда лезет. Дисциплина скучная, но именно она отделяет спокойную работу с ИИ для кода от сюрприза в SMART-статистике.

5 ошибок дисковой гигиены при работе с ИИ-агентами

Главное. Диск под ИИ-агентом убивает привычка не смотреть, что происходит, - один баг лишь повод. Пять типичных промахов: держать агента на старой версии, ни разу не читать SMART, игнорировать логи и кэши, гонять всё на впаянном диске Mac без оглядки и вслепую применять костыли из интернета. Ниже пары «должно / не должно» под каждый.

Ошибка 1. Сидеть на старой версии инструмента

Баг Codex срезали патчами за неделю, но патч работает только у того, кто обновился. Старая версия жжёт диск так же, как жгла в марте.
Не должно: месяцами не обновлять CLI-агента, «работает же».
Должно: держать инструмент на свежем стабильном релизе, читать changelog на предмет фиксов записи.

Ошибка 2. Никогда не смотреть SMART

Накопленная запись копится тихо. Пока не откроешь smartctl или CrystalDiskInfo, ты не знаешь, сколько уже стёр твой диск и кто это сделал.
Не должно: ждать чужой статьи про баг, чтобы узнать про износ своего диска.
Должно: раз в пару месяцев глядеть в Data Units Written или Total Host Writes и сравнивать с TBW.

Ошибка 3. Не замечать логи и кэши агента

logs_2.sqlite, отладочные файлы, кэши вроде code_sign_clone на 12 ГБ - всё это растёт молча. Файл может выглядеть маленьким, а записи копиться (привет insert-and-prune).
Не должно: считать, что маленький файл на диске означает малую запись.
Должно: знать, где агент держит логи и кэш, и периодически туда заглядывать.

Ошибка 4. Гонять агента на впаянном диске Mac без оглядки

На Apple Silicon SSD не поменять за 3000 ₽ - ремонт стоит те же 27-31 тысячу рублей из раздела про Mac. Цена невнимательности тут кратно выше, чем на ПК со сменным диском.
Не должно: относиться к диску MacBook как к расходнику, который легко заменить.
Должно: на впаянном диске проверять запись чаще и приглушать болтливые логи агрессивнее.

Ошибка 5. Вслепую применять костыли из интернета

Триггер на таблицу, симлинк в tmpfs, ramdisk - рабочие приёмы, но каждый ломает что-то штатное. Симлинк в летучую память без запаса ОЗУ - путь к переполнению.
Не должно: копировать команду с форума в свою систему, не поняв, что она делает.
Должно: сначала разобраться в последствиях (потеря логов, летучесть tmpfs), потом применять и уметь откатить.

Что дальше: следи за агентом как за любым процессом

Главное. Сделай три вещи прямо сейчас: обнови Codex до 0.143.0 или свежее, проверь Data Units Written своего диска через smartctl или CrystalDiskInfo, при раздутом logs_2.sqlite прогони VACUUM. Дальше держи ИИ-агента под тем же присмотром, что и любой фоновый процесс. А если строишь собственных агентов - выбирай доступ к моделям, который не отвалится на оплате из РФ.

Сделай прямо сейчас. Три шага, десять минут:

1. Проверь версию Codex и обнови до 0.143.0 или новее - патчи уже внутри.
2. Прочитай SMART своего диска и сравни запись с паспортным TBW:

sudo smartctl -a /dev/nvme0   # Linux, ищи Data Units Written

На Windows то же покажет CrystalDiskInfo (Total Host Writes), на macOS - smartctl -a disk0 после brew install smartmontools.

1. Если ~/.codex/logs_2.sqlite раздут - ужми его: sqlite3 ~/.codex/logs_2.sqlite "VACUUM;".

Дальше - привычка. Агент для системы - такой же демон, как и все остальные: раз в пару месяцев заглядывай в его логи, кэш и SMART-счётчик диска.

И последнее - про доступ. Codex требует подписку ChatGPT или API-ключ OpenAI, а из России оплата напрямую не проходит: карта отлетает на процессинге, с российского IP страница не грузится. Если ты строишь собственных агентов или гоняешь инструменты поверх API, есть путь без VPN и зарубежных карт. provod.ai - российский аналог OpenRouter: все флагманы (Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek v4) в одном чате и через единый API, OpenAI- и Anthropic-совместимый. Твой код, Cursor или n8n переезжают сменой baseURL и ключа - сам проект не трогаешь. Оплата по факту за токены в рублях, картой РФ, через СБП или по счёту с закрывающими документами для юрлица. Цены 1:1 с официалом, без наценки посредников, свежие модели сразу и без недельных лимитов подписок. Подключить модели по API в рублях.

Была полезна статья? Да / Нет

Источники

1. GitHub, openai/codex, issue #28224 «Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance» (автор 1996fanrui: 37 ТБ за 21 день, 640 ТБ/год, распределение TRACE/INFO/DEBUG/WARN, insert-and-prune, TRACE по умолчанию) - открыт 14 июня 2026, закрыт 23 июня 2026
2. GitHub, openai/codex, PR #29432, #29457, #29599 (jif-oai) и релизы rust-v0.142.0, rust-v0.143.0 - 22 июня - 8 июля 2026
3. GitHub, openai/codex, issue #29876 «Excessive disk writes / SSD wear concern on macOS Codex app and JetBrains ACP» (Ko7ov-Konstantin: 207 МБ/мин в простое, кэш 12 ГБ) - открыт 24 июня 2026, открыт на 9 июля 2026
4. GitHub, anthropics/claude-code, issue #16093 «[BUG] Infinite logging loop in debug files causes 200GB+ disk usage» (EthanJStark: 42 ГБ за 7 дней, петля самозаписи операций >75 мс) - открыт 2 января 2026, закрыт как not planned
5. Hacker News, обсуждение «Codex logging bug may write TBs to local SSDs» (510 голосов, 271 комментарий; цитаты woadwarrior01, applfanboysbgon, cedws, jorl17) - июнь 2026
6. The Register, Thomas Claburn, «OpenAI Codex bombards SSDs with needless write operations» (оценка ущерба в "младшие" миллионы $, $38,64 на Samsung 990 2 ТБ, комментарий представителя OpenAI) - 23 июня 2026
7. Даташиты Samsung 990 Pro, WD Black SN850X, Crucial T500 (рейтинги TBW, гарантия 5 лет) - download.semiconductor.samsung.com, documents.sandisk.com, crucial.com
8. man smartctl(8) (smartmontools), crystalmark.info (команды проверки записи: Data Units Written, Total Host Writes) - проверено 9 июля 2026
9. Хабр, комментарии к новости про баг Codex (Metotron0, zakker, arinatitova, endpoints - боли аудитории) - июнь 2026
10. Прайсы сервисов ремонта Mac в РФ (замена впаянного SSD 27 000-31 000 ₽, замена платы 20 000-25 000 ₽) - iRepair, Orange-Apple, июль 2026
11. vc.ru, статьи об оплате Codex из России (карта РФ не проходит на процессинге, требуется зарубежный IP) - 20 марта и 5 мая 2026

Баг Codex - частный случай общей истории: за аппетитами агентских инструментов приходится следить самому. А если строишь собственных агентов на API, доступ к моделям без осечек на оплате из РФ - через единый OpenAI- и Anthropic-совместимый API на provod.ai, по ценам 1:1 с официалом в рублях.

---

provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.

Try: provod.ai · model catalog · docs