Автор admin 
Користувачі ШІ-агента Codex від OpenAI зіткнулися з проблемою, яка може коштувати їм заміни SSD-накопичувача раніше терміну. Codex записує надлишковий обсяг діагностичних даних на локальні SSD, що, за оцінками розробників, здатне вичерпати весь гарантійний ресурс диска менш ніж за рік активного використання. Про це пише The Register.
Читайте также: До Чого Сниться Сніг: Толкования и Значение Сновидения
37 ТБ за 21 день — і це лише початок
Розробник Руй Фань, учасник комітету управління проєктом Apache Flink, повідомив на GitHub, що за 21 день безперервної роботи Codex його основний SSD-накопичувач записав близько 37 ТБ даних. У перерахунку на рік це дає приблизно 640 ТБ записів.
Для порівняння: типовий споживчий SSD об’ємом 1 ТБ розрахований приблизно на 600 ТБ записаних даних (TBW) за весь гарантійний термін служби. Тобто Codex, працюючи у фоновому режимі, теоретично здатний вичерпати весь ресурс диска швидше, ніж за 12 місяців — і це без жодної реальної користі для користувача. Після перевищення показника TBW різко зростає ризик деградації накопичувача та його повної відмови.
Подібна закономірність підтверджується й іншими користувачами: за даними звіту на GitHub (issue #28224), за 15-секундний інтервал система здійснювала близько 36 211 операцій запису рядків у базу, тоді як кількість фактично збережених записів залишалася на рівні приблизно 680 тисяч — тобто диск безперервно перезаписувався, хоча розмір файлу логів зовні залишався стабільним і не викликав підозр у звичних інструментах моніторингу.
У чому причина: TRACE-логування, яке неможливо вимкнути
Проблема пов’язана з локальними логами Codex у форматі SQLite (файл ~/.codex/logs_2.sqlite), які призначені для діагностики технічних проблем і за замовчуванням увімкненими на пристрої користувача. Ситуація різко погіршилась після оновлення в лютому, коли частина логів почала записуватися на рівні TRACE — найбільш «галасливому» режимі логування, який фіксує буквально все, від сирих WebSocket-пакетів до рутинних подій файлової системи.
Особливо неприємний нюанс: за повідомленнями розробників, цей механізм логування ігнорує стандартну змінну середовища RUST_LOG, тобто навіть явне налаштування рівня логування (наприклад, на warn) не знижує обсяг записів — стандартний спосіб «приглушити» діагностику просто не працює.
Ситуацію додатково ускладнює так зване посилення запису (write amplification): база даних SQLite не просто накопичує дані, а постійно виконує цикли вставки й видалення записів. Це означає, що фізичний обсяг записаних на диск даних суттєво перевищує те, що показує розмір самого файлу логів — і, відповідно, реальне зношування накопичувача значно вище, ніж може здатися на перший погляд.
Читайте также: Пріоритет для Цукерберга. Meta готує застосунок для прогнозів і ставок на події
Це не нова проблема — і вона досі не вирішена повністю
Перші повідомлення про подібну поведінку Codex з’являлися в репозиторії проєкту на GitHub ще в квітні 2026 року (issue #17320) — тоді йшлося про швидкість запису на рівні 5–16 МБ/с під час стримінгу. Тобто проблема існує вже кілька місяців, але набула масштабного резонансу лише зараз, коли хтось нарешті перевів обсяги записів у конкретну річну цифру у терабайтах.
OpenAI підтвердила, що логи потрібні інженерам компанії для пошуку технічних збоїв, але визнала: великий обсяг даних зберігався способом, який створював значно більше дискової активності, ніж очікувалося. Представник компанії заявив, що фахівці вже працюють над виправленням і кілька відповідних змін уже потрапили до коду. Проте користувачі продовжують повідомляти про надмірний запис даних навіть після цих правок.
Що робити користувачам прямо зараз
Поки повноцінного офіційного патчу немає, спільнота розробників пропонує тимчасові обхідні рішення:
- Для Linux і macOS — створити символічне посилання, що перенаправляє файл ~/.codex/logs_2.sqlite у директорію /tmp/, де запис відбувається в оперативну пам’ять, а не на фізичний накопичувач.
- Моніторинг здоров’я диска — для Windows варто використовувати CrystalDiskInfo, для Linux/WSL — smartctl, щоб відстежувати реальний обсяг записаних даних (TBW) та вчасно помітити прискорене зношування.
- Для користувачів Windows зручного обхідного рішення наразі немає — їм залишається лише слідкувати за станом накопичувача й чекати на офіційне виправлення від OpenAI.
Якщо тенденція збережеться, частина активних користувачів Codex CLI може зіткнутися з необхідністю заміни SSD значно раніше запланованого терміну служби — особливо це стосується власників бюджетних накопичувачів із низьким показником TBW, які найбільш чутливі до подібного навантаження.
Нагадаємо, кілька днів тому Codex навчили створювати «навички» з відеозапису екрана — без жодних інструкцій.
Читайте также: Кого це стосується. Anthropic запроваджує перевірку віку в Claude через документи
Підписуйтесь на нас у соцмережах: Telegram | Facebook | LinkedIn