Codex тащит в кэше целый LibreOffice: зачем ИИ-ассистенту скрытые гигабайты и стоит ли переживать

title: "Codex тащит в кэше целый LibreOffice: зачем ИИ-ассистенту скрытые гигабайты и стоит ли переживать" slug: "codex-libreoffice-skrytyy-kesh-ii-assistenta" date: "2026-09-10" description: "Саймон Виллисон нашёл 1,7 ГБ кэша с LibreOffice, Python и Node.js внутри ИИ-ассистента Codex. Разбираю, зачем агенту эти бинарники, чем грозит непрозрачный кэш и сколько весит кэш моего Claude Code." tags: ["ии агенты", "разработка с ai", "нейросети для программирования"]

Полез тут в свой ~/.cache почистить место на диске - и вспомнил историю недельной давности, которая мне всю малину испортила. Саймон Виллисон, разработчик и автор блога simonwillison.net про AI-тулинг, ковырялся в кэше десктопного Codex (это ChatGPT-приложение, бывший OpenAI Codex) и нашёл там 1,7 ГБ скрытых бинарников. В прямом смысле - целый LibreOffice.

Что нашёл Виллисон в кэше Codex

В папке ~/.cache/codex-runtimes/codex-primary-runtime на маке у Виллисона лежало 1,7 ГБ: LibreOffice headless на 429,7 МБ, Poppler на 187,9 МБ, git на 148,1 МБ, а рядом - полноценные инсталляции Node.js (446,4 МБ) и Python (440,6 МБ). Нашёл он это не через доку и не через анонс, а случайно - гонял OmniDiskSweeper в поисках, куда делось место на диске (пост от 1 сентября 2026, simonwillison.net). В самом посте Виллисон ни словом не упоминает официальный анонс или документацию от OpenAI об этом кэше - похоже, тихая рабочая деталь под капотом, а не фича, которую выносят в чейнджлог.

Зачем ИИ-ассистенту для кода целый офисный пакет

Ответ лежит рядом, в папке plugins/documents - там навыки (skills), которые объясняют агенту, как находить и вызывать эти бинарники. LibreOffice headless умеет конвертировать .docx/.xlsx в текст без Word и Excel, Poppler - выдирать текст и картинки из PDF, git - работать с репозиториями напрямую, а не через обёртки. Логика понятная: пользователь кинул агенту счёт в PDF или техзадание в .docx, и вместо того чтобы попросить поставить внешний конвертер вручную, разработчики Codex зашили нужные инструменты прямо в кэш - открылось само, без диалогов и разрешений. Агент должен уметь работать с любым файлом, который ему прислали, а не только с текстом и кодом - отсюда и офисный пакет, и PDF-парсер, и отдельный git в комплекте на случай, если системный недоступен или не той версии. Дёшево по разработке, дорого по прозрачности.

Похожий трюк, к слову, не только у Codex - курсор нейросеть (Cursor) и другие ИИ-ассистенты для кода тоже таскают в раздачах не только модельные веса, а целые рантаймы под капотом. Разница в том, что Виллисон об этом рассказал, а остальные - нет, пока кто-то не поймает за руку.

Почему бинарники зашиты в кэш, а не берутся из системы

Логичный вопрос: зачем тащить свой LibreOffice, если на маке или в Linux можно вызвать системный, а на винде поставить через инсталлятор. Ответ - в контроле версий и переносимости. Если агент рассчитывает на системный LibreOffice, у одного пользователя это будет версия 24.х, у другого 26.2.3, а у третьего его вообще не будет - и агенту придётся либо гадать, какой API доступен, либо просить установить пакет руками, а это обрыв автономности на самом интересном месте. Замороженная версия внутри кэша решает проблему разработчика: поведение одинаковое у всех, тестировать одну версию вместо десяти. Для пользователя это оборачивается ровно противоположным - у него на диске висит бинарник, который никогда не обновится через apt, brew или центр обновлений, потому что менеджеры пакетов о нём просто не знают. Он живёт своей отдельной жизнью в кэше, пока разработчик Codex сам не решит его пересобрать.

Чем грозит непрозрачный кэш агентского CLI

Сам факт "нашёл лишний гигабайт" - не катастрофа, диски дешёвые. Проблема в другом: если пользователь не знает, что у него в кэше, он не может это ни проверить, ни контролировать. А у coding-агентов уже есть послужной список именно с кэшами и логами, которые расползаются без спроса.

По тому же Codex CLI есть открытый баг (issue #34061, версии 0.142.4-0.144.6): одна дочерняя сессия сгенерировала 483,7 МБ лога в 353 255 JSONL-записях за 3 минуты 19 секунд, а суммарно с 2393 дочерних сессий каталог ~/.codex разросся до 760 ГиБ - это забило том на 1,8 ТиБ до 99-100% (разбор на braindetox.kr, 21 июля 2026). И это не только чужая беда: в том же материале приводят случаи с Claude Code, где файл вывода фоновой задачи разросся до 324 ГБ за 16 минут, а на маке был кейс на 472 ГБ в одном файле. Я тоже чинил у себя протечку через веб-доступ Claude Code - и это тоже была история "агент делает что-то невидимое, пока не присмотришься".

И версия, замороженная в кэше навсегда, - отдельная головная боль. У Poppler и LibreOffice, как и у любого парсера сложных бинарных форматов, есть история уязвимостей именно в разборе документов: CVE-2026-10118 - целочисленное переполнение в бэкенде Splash у Poppler, которое эксплуатируется через специально собранный PDF и может привести к выполнению кода при открытии файла; CVE-2026-4430 - переполнение буфера в LibreOffice при обработке OOXML-документов с несовпадающими параметрами соли шифрования, закрыто в версиях 26.2.3 и 25.8.7 (разборы на sentinelone.com и здесь же по LibreOffice). Я не знаю, какая именно версия Poppler и LibreOffice зашита в кэш Codex у Виллисона - он это не публиковал. Но сама механика уязвима по конструкции: если агентский CLI парсит документы этими бинарниками, а пользователь понятия не имеет, что они там вообще есть, он не проверит версию, не узнает про патч и не обновится - обновление придёт только тогда, когда компания-разработчик агента сама пересоберёт рантайм и раскатит новый релиз приложения. Это отдельный, невидимый снаружи слой зависимостей, который живёт вне обычного цикла патчей ОС.

Вывод простой: чем автономнее агент, тем меньше у него стимула отчитываться о побочных эффектах - месте на диске, версиях зашитых библиотек, сетевых запросах, файлах, которые он тихо плодит. И это отдельная категория риска рядом с более очевидными вещами вроде утечки email в User-Agent, с которой я разбирался у Claude Code - там хоть было что смотреть в трафике, а тут нужно руками лезть в файловую систему.

Сколько кэширует мой собственный агентский пайплайн

Раз уж такое дело - проверил у себя. Мой агентский пайплайн живёт на сервере (агенты у меня давно не на ноутбуке, а на VPS), и там же гоняется Claude Code. Результат du -sh:

• ~/.claude - 205 МБ;
• ~/.cache/claude-cli-nodejs - 392 КБ.

Негусто - раз в десять меньше, чем у Codex с его LibreOffice. Но по-настоящему толстые кэши на том же сервере оказались у совсем других инструментов: ~/.cache/ms-playwright - 799 МБ, ~/.cache/go-build - 703 МБ, ~/.cache/pip - 276 МБ, ~/.npm - 411 МБ. То есть сам Claude Code у меня скромный, а вот тестовый браузер для QA-агентов и обычные пакетные менеджеры несут на диск больше гигабайта суммарно - и я об этом узнал только когда специально пошёл смотреть, а не потому что кто-то предупредил.

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

Разница между моим кэшем Claude Code и кэшем Codex у Виллисона не в том, что один агент "хороший", а другой "плохой" - просто у меня Claude Code почти не занимается парсингом сторонних офисных документов, ему это в моём пайплайне не нужно, а сам инструмент явно не тащит с собой запасной рантайм под каждую возможную задачу. Как только агенту дают более широкий список навыков - разбирать PDF, конвертировать таблицы, работать с чужими репозиториями - кэш неизбежно растёт, и вопрос уже не в том, вырастет ли он, а в том, скажут ли пользователю, из чего он состоит.

Как проверить кэш своего coding-агента

Ничего экзотического, минут на пять раз в месяц:

• du -sh ~/.cache/* | sort -rh - топ по размеру, сразу видно, кто жрёт;
• ncdu ~/.cache - интерактивно покопаться, если что-то непонятное вылезло;
• отдельно проверить папку своего CLI-агента (~/.codex, ~/.claude, ~/.cursor - у кого что стоит) - не разрослась ли она за последний месяц без видимой причины;
• если нашёл незнакомую папку с бинарниками - погуглить имя папки и версию инструмента, баг может быть уже описан и обсуждается на GitHub;
• нашёл сам бинарник (libreoffice, pdftotext от Poppler и подобные) - вызвать его с флагом версии напрямую и свериться со страницей security-advisories производителя: если версия старше последнего патча из CVE-базы, это стоит хотя бы знать, даже если сделать с этим напрямую нечего кроме как ждать релиза от разработчика агента.

Регулярная политика чистки (logrotate или ручной du раз в месяц) на самом деле не про то, чтобы сэкономить место - диск дешёвый. Она про то, чтобы вообще заметить момент, когда агент начал вести себя не так, как раньше: тащить новый бинарник, писать логи в десять раз быстрее обычного, разрастаться без видимой причины. LibreOffice в кэше Codex сам по себе безобиден. А вот привычка не проверять, что у твоего ИИ-ассистента лежит под капотом - уже не очень.