Codex CLI 0.157.0 оставляет демон работать после выхода

Вы закрываете последнее окно Codex, а процесс codex app-server --managed-daemon продолжает работать: его подхватывает PID 1, и живёт он до команды codex app-server daemon stop или до перезагрузки. Так ведёт себя Codex CLI 0.157.0 по словам автора issue на GitHub, который просит не включать фоновый демон по умолчанию.

Если вы не следили: по данным Codex Knowledge Base, раньше Codex CLI работал как процесс на один сеанс. Вы запускали его, работали и выходили, а фоновый сервер оставался опцией для опытных пользователей. Там же пишут, что автозапуск демона появился в v0.156.0 от 22 сентября 2026 года как опция, а в v0.157.0, вышедшей 25 сентября 2026 года, стал поведением по умолчанию.

Демон запускается из собственной копии пакета на 374 МБ

Автор работает на Linux под WSL2 и поставил Codex CLI 0.157.0 через npm install -g @openai/codex. При первом интерактивном сеансе демон копирует весь пакет платформы, около 374 МБ, в ~/.codex/packages/app-server-daemon/releases/<version>/. Внутри лежат codex, codex-code-mode-host и встроенные bwrap, zsh и rg, байт в байт то же, что npm только что поставил.

Дальше демон работает из этой копии, и версия бэкенда отрывается от версии CLI, которую вы ставили менеджером пакетов. Автор ссылается на соседние жалобы: в #46468 после npm update app-server остаётся на старой версии, а в #48050 Codex 0.157.0 из пакета Arch Linux вообще не стартует без флага --no-daemon. Поддержку внешне управляемых исполняемых файлов демона просят в #41188.

Обновления проверяются через 5 минут после старта и потом каждый час

Вместе с демоном запускается отдельный отвязанный процесс обновлений, codex app-server daemon pid-update-loop. Через 5 минут после старта он проверяет релизы, затем повторяет проверку раз в час, скачивает новые версии и перезапускает бэкенд.

Перезапуск может оборвать задачи, которые Codex в этот момент выполняет. Автор ссылается на issue #40969: при автообновлении демон даёт активным ходам 60 секунд на завершение, потом убивает их принудительно, и отключить такое поведение нельзя. Для CLI, пишет автор, меньше всего сюрпризов дало бы другое умолчание: бэкенд живёт и умирает вместе с окном, запускает установленный бинарник и сам в фоне не обновляется.

Прокси и рабочий каталог демон берёт у сеанса, который его запустил

Демон работает в собственной сессии без TTY и фиксирует окружение того сеанса, который случайно его поднял. Автор запускает Codex через обёртку, выставляющую свою переменную HTTPS_PROXY на каждый вызов. Демон запоминает прокси первого сеанса, и все его исходящие соединения идут через этот прокси, с какими бы настройками ни стартовали следующие сеансы.

Автор подозревает, что у ещё двух жалоб тот же корень. В #42457 хуки в режиме --remote получают рабочий каталог демона вместо каталога сеанса. В #37537 хуки, запущенные демоном, не могут определить терминал клиента, и ломаются хуки, которые адресуются конкретному терминалу.

Выключить демон удаётся четырьмя командами, одну из которых пришлось добавить из-за ошибки

Автор предлагает оставить общий самообновляемый демон для Remote Control и десктопного приложения или для явного запуска через codex app-server daemon start или bootstrap. Если умолчание сохранят, он просит хотя бы гасить автоматически запущенный демон после отключения последнего клиента и не копировать и не обновлять пакет, поставленный через npm, brew или pacman, а запускать установленный бинарник.

Свой обходной путь он описывает так: codex features disable daemon_auto_start, затем codex app-server daemon stop, затем pkill -f 'app-server daemon pid-update-loop' и удаление ~/.codex/packages/app-server-daemon. Команда pkill нужна из-за ошибки: daemon stop останавливает app-server, но процесс обновлений у автора был жив и через 70 секунд. С выключенным флагом новый сеанс TUI демон не поднимает.

Общий сервер подключает все окна Codex к одному бэкенду

Логику схемы описывает Codex Knowledge Base. По её данным, при первом запуске Codex поднимает фоновый сервер, и TUI подключается к нему, вместо того чтобы работать внутри окна. Следующие запуски находят готовый сервер и цепляются к нему, поэтому сервер переживает отдельные сеансы. Подготовка песочницы, согласование соединения с моделью и индексация рабочей области делаются один раз при старте сервера, чтобы ускорить холодный старт.

Представьте кухню ресторана, где плиту не гасят между заказами: следующий клиент не ждёт розжига. Codex Knowledge Base добавляет, что фоновый агент продолжает работу после закрытия терминала, вкладки делят один сервер и общую картину очереди, а на общем сервере держится шорткат f, который форкает разговор из другого приложения вместе с черновиками и отложенными промптами.

Там же описан конфликт настроек. Если сеанс стартует с другой моделью, профилем песочницы или сетевой политикой, Codex предлагает три варианта: остаться на текущем сервере и проигнорировать настройки сеанса, перезапустить сервер и прервать идущие задачи или выйти. По данным Codex Knowledge Base, отсюда и перенос конфигурации первого сеанса на следующие.

Вся история держится на одном подробном отчёте пользователя с WSL2 и установкой через npm, и насколько массово воспроизводятся сбои с прокси и обновлениями, из него не понять. Исправление в 0.162.1 от 9 октября 2026 года, по данным Updatify, касается падений при старте из-за расхождения настроек функций у сервера и умолчаний CLI. На наш взгляд, спорнее всего здесь копия пакета на 374 МБ: решать, какая версия у вас реально работает, перестаёт ваш менеджер пакетов.

Судьба флага daemon_auto_start

Станет ли daemon_auto_start выключенным по умолчанию, пока неизвестно. Релизы выходят часто: по данным PPCBasic.com, между v0.157.0 (2026-09-25) и v0.162.1 (2026-10-09) вышли v0.157.1, v0.158.0, v0.159.0–v0.159.3, v0.160.0, v0.160.1, v0.161.0 и v0.162.0. Исправлена ли ошибка с процессом обновлений после daemon stop, в источниках не сказано, так что pkill из обходного пути автора стоит держать под рукой.