Codex CLI 0.157.0 по умолчанию запускает фоновый демон с автообновлением: жалоба на GitHub

В репозитории openai/codex на GitHub открыт issue №48195 с просьбой сделать функцию daemon_auto_start опциональной (по умолчанию выключенной) для Codex CLI или хотя бы один раз спрашивать пользователя перед её включением. Автор issue использует CLI версии 0.157.0, установленный через npm на Linux (WSL2). По его описанию, начиная с 0.157.0 одно лишь открытие интерактивной сессии codex приводит к следующему.

Во-первых, запускается постоянный фоновый демон (codex app-server --managed-daemon). Он работает в собственной сессии без TTY и продолжает жить после закрытия всех окон Codex (переходит под PID 1), пока его не остановят командой codex app-server daemon stop или не перезагрузят машину.

Во-вторых, CLI копирует весь платформенный пакет (около 374 МБ: codex, codex-code-mode-host, а также bwrap, zsh и rg из комплекта) в каталог ~/.codex/packages/app-server-daemon/releases/<версия>/. По словам автора, копия побайтно совпадает с тем, что только что поставил npm, а демон запускается уже из неё, поэтому версия бэкенда отрывается от версии CLI, установленной менеджером пакетов.

В-третьих, стартует отдельный фоновый обновлятор (codex app-server daemon pid-update-loop): он проверяет обновления через 5 минут после старта, затем ежечасно, скачивает новые релизы и перезапускает бэкенд. Это может прерывать активные запросы; автор ссылается на открытый issue №40969, где говорится об автообновлении, которое принудительно завершает активные ходы после 60-секундного окна на «слив».

В-четвёртых, демон закрепляет окружение той сессии, которая его запустила. Автор запускает Codex через обёртку, задающую HTTPS_PROXY для каждого запуска, но демон сохраняет прокси-переменные первой сессии, и его исходящие соединения идут через этот прокси, какие бы параметры ни были у последующих сессий. Те же корни, по мнению автора, у issue №42457 и №37537: хуки в режиме --remote получают рабочий каталог демона, а не сессии.

Автор формулирует принцип: для CLI наименее неожиданно, когда бэкенд живёт и умирает вместе с окном, запускает установленный бинарник и не обновляется сам. Общий самообновляющийся демон, по его мнению, имеет смысл для Remote Control и десктопного приложения, а также при явном запуске codex app-server daemon start или bootstrap. Если по умолчанию оставят включённым, он просит как минимум завершать автозапущенный демон, когда отключается последний клиент, и не копировать/не обновлять сам себя, если CLI установлен менеджером пакетов (npm, brew, pacman).

Отдельно автор нашёл ошибку: codex app-server daemon stop останавливает app-server, но не трогает обновлятор pid-update-loop, который был ещё жив спустя 70 секунд, и его пришлось убивать вручную.

В обсуждении к issue присоединились другие пользователи. Одни пишут, что сталкивались с тем же и что стартовать процессы без предупреждения при небольшом повышении версии не должно; другие называют CLI непригодным до исправления. Один комментатор подтвердил проблему на Windows 10 LTSC с Codex CLI 0.157.0 и сообщил, что daemon_auto_start = false в config.toml её снимает; он предложил автоматически переходить в локальный режим, когда запуск демона блокируется из-за повышения прав, вместо требования флага --no-daemon. Часть комментаторов сравнивает поведение с вредоносным ПО и считает, что это сделано не случайно; в тексте это именно мнения, доказательств вредоносных действий демона не приводится. Последний комментатор пишет, что в официальном справочнике по конфигурации поддерживаемый способ отключения не отражён (нет строк про daemon_auto_start), а примечание к релизу 0.157.0 описывает изменение одним предложением, не называя ни постоянный процесс, ни копию пакета, ни ежечасное обновление.

Ключевые факты

По словам автора issue №48195 в openai/codex, с Codex CLI 0.157.0 открытие интерактивной сессии запускает постоянный фоновый демон, который живёт после закрытия всех окон, пока его не остановят командой или перезагрузкой.
CLI копирует пакет около 374 МБ в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускает демон из копии, из-за чего версия бэкенда отрывается от версии, установленной через npm; отдельный обновлятор проверяет релизы через 5 минут после старта и затем ежечасно.
Демон закрепляет окружение первой сессии: прокси-переменные из неё сохраняются для последующих запусков, а команда daemon stop оставляет обновлятор работать.
Обходной путь автора: codex features disable daemon_auto_start, затем codex app-server daemon stop, pkill -f 'app-server daemon pid-update-loop' и удаление ~/.codex/packages/app-server-daemon.
Проблему подтверждают другие пользователи, в том числе на Windows 10 LTSC; в тексте обсуждения нет ответа мейнтейнеров OpenAI.

Почему это важно

Это спор о границах поведения терминального инструмента. По описанию автора issue, CLI, который пользователь установил менеджером пакетов, начинает вести себя как самостоятельный сервис: запускает фоновый процесс, копирует в домашний каталог собственную версию бинарников и обновляет её по расписанию. В 0.157.0, как цитирует комментатор примечание к релизу, включён «автоматический запуск фонового сервера для подходящих интерактивных сессий». Пользователи жалуются, что о таком изменении не предупреждали, а сама функция не отражена в справочнике по конфигурации. Судя по тому, как много реакций набрали комментарии, тема затронула заметное число людей.

Кому это важно

Прежде всего тем, кто ставит Codex CLI через npm, brew или pacman и хочет, чтобы запускался именно установленный бинарник: по описанию автора, демон запускается из собственной копии. Важно тем, кто запускает Codex через обёртки с разными прокси-переменными по запуску, а также тем, кто использует хуки в режиме --remote. Автор issue работает в WSL2, а среди откликнувшихся есть пользователь Windows 10 LTSC; Arch Linux упомянут лишь в названии связанного issue №48050 о том, что 0.157.0 не стартует с пакетом Arch без --no-daemon. Отдельный комментатор пишет, что в его компании откатывает лицензии на Codex.

Как это применить

Если вы не хотите фонового демона, автор issue предлагает такой порядок: выполнить codex features disable daemon_auto_start, затем codex app-server daemon stop, потом pkill -f 'app-server daemon pid-update-loop' (команда stop этот процесс не останавливает) и удалить каталог ~/.codex/packages/app-server-daemon. По словам автора, с выключенным флагом новая TUI-сессия демон больше не создаёт. Комментатор на Windows пишет, что ему помогла строка daemon_auto_start = false в config.toml. Другой путь, упомянутый в связанных обсуждениях, запуск с флагом --no-daemon. Стоит проверить ps и каталог ~/.codex после обновления до 0.157.0.

Можно ли доверять

Источник, пользовательский issue и комментарии, а не заявление OpenAI. Описание подробное, с командами и путями, и совпадает с отчётами других пользователей в треде, но все технические детали (размер около 374 МБ, пути, расписание обновлений, поведение stop) измерены автором на его установке Linux (WSL2); размеры на других платформах не приводятся. Примечание к релизу 0.157.0 процитировано только из вторых рук. Ответа или исправления от мейнтейнеров OpenAI в тексте нет, не сказано и то, открыт ли issue и стала ли функция опциональной. Сравнения с вредоносным ПО и ботнетом, мнения комментаторов, подтверждений вредоносных действий (например, отправки данных) в обсуждении нет. Один комментатор пишет, что в v0.160.0 на Raspberry Pi демонов не видно, но изменилось ли значение по умолчанию, из текста не следует.

Риски и подводные камни

По описанию автора, обновлятор перезапускает бэкенд, и это может прервать активные запросы; связанный issue №40969 говорит о принудительном завершении после 60-секундного окна. Версия бэкенда расходится с установленной через менеджер пакетов, из-за чего неочевидно, какой бинарник реально обслуживает запрос. Закрепление окружения означает, что настройки первой сессии, например прокси, могут тихо применяться к последующим. Остановка демона не останавливает обновлятор, а лишняя копия пакета занимает около 374 МБ на диске в ~/.codex. Один из комментаторов предложил для демона «квитанцию исполнения»: показывать клиенту версию CLI, дайджест бинарника демона, поколение демона, состояние обновлятора и поколение унаследованного окружения, чтобы было видно, что именно обслуживает ход. Пока это только предложение в обсуждении.

«Для CLI наименее неожиданное поведение по умолчанию, когда бэкенд живёт и умирает вместе с окном, запускает установленный мной бинарник и не обновляется сам в фоне.»

— автор issue №48195 в репозитории openai/codex