Codex CLI ставит демон в фоне по умолчанию — что с Claude Code и Cursor

Что за процесс стартует у Codex CLI в фоне

Если ты поставил Codex CLI через npm install -g @openai/codex и просто открыл интерактивную сессию, начиная с версии 0.157.0 в фоне у тебя стартует отдельный процесс — демон app-server. Команда codex app-server --managed-daemon запускается без TTY, в своей сессии, и переживает закрытие окна: процесс перепривязывается к PID 1 и продолжает работать до команды codex app-server daemon stop или перезагрузки.

Баг-репорт с этим описанием собрал десятки реакций от пользователей Linux (WSL2), Windows и Arch — люди находили демон случайно, через менеджер процессов, а не из документации. Получил метки enhancement, CLI, app-server — то есть разработчики сразу отнесли его не к мелкой придирке, а к архитектуре протокола app-server. Сам автор формулирует ожидание так: для обычного CLI естественно, что сервер живёт и умирает вместе с окном, выполняется из того бинарника, что ты поставил, и не обновляется сам в фоне — общий самообновляющийся демон имеет смысл для Remote Control или десктопного приложения, но не как дефолт для интерактивной сессии.

При первом старте демон не запускает тот бинарник, что ты поставил через npm. Он копирует весь платформенный пакет — codex, codex-code-mode-host, бинарники bwrap и zsh, rg — в ~/.codex/packages/app-server-daemon/releases/<version>/ и работает из этой копии. С этого момента версия демона живёт отдельно от версии CLI, которую видит твой пакетный менеджер.

Зачем демону обновляться каждый час и что при этом рвётся

Вместе с демоном стартует отдельный процесс обновлений — codex app-server daemon pid-update-loop. Он проверяет новые релизы через 5 минут после старта, а дальше каждый час; найдя обновление, скачивает его и перезапускает backend.

Перезапуск не ждёт, пока ты закончишь текущий запрос. Активным ходам дают 60 секунд на завершение, после чего их останавливают силой. Разработчики ссылаются на это поведение в отдельном issue — там же написано, что отключить принудительное прерывание нельзя в принципе, только весь автостарт демона целиком.

Что это меняет для прокси, хуков и обычной сессии

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

В режиме --remote хуки получают рабочую папку демона, а не той сессии, из которой их вызвали. В баг-трекере это связали с двумя отдельными репортами о хуках, которые не видят нужный терминал — похоже, у обоих одна и та же причина.

Баг при выключении и как на него ответили разработчики

Автор репорта проверил и обратный путь. Команда codex app-server daemon stop гасит app-server, но не трогает pid-update-loop — обновляющий процесс оставался живым ещё 70 секунд после того, как его должны были остановить, и пришлось убивать вручную. С выключенным флагом daemon_auto_start новая TUI-сессия демона не поднимает вовсе.

На Windows история была хуже: когда демону не хватало прав на старт, ломался весь ввод в CLI, и единственным рабочим выходом оказался тот же daemon_auto_start = false в config.toml.

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

28 сентября в репозиторий ушёл коммит, отключающий автостарт демона по умолчанию. Дальше чинили смежное: 7 октября — патч песочницы для nix-user-chroot в 0.160.1, 10 октября — сборка CLI из официальных релизных бинарников, 13 октября — ещё один фикс, чтобы Codex не поднимал самообновляющийся демон. Один из пользователей сообщил, что на Raspberry Pi в версии 0.160.0 фоновых процессов уже не видно.

Что проверить у себя, если фоновые процессы — красная линия

Вопрос «codex cli vs claude code» в контексте фоновых процессов закономерный, но разбора такого масштаба — с логами, номерами issue и подтверждением от разработчиков — про другие ИИ-кодеры в терминале пока не было. Это не значит, что там ничего не крутится в фоне. Значит, что никто не собрал это в один публичный тред, как в случае с Codex.

Если фоновые процессы ИИ-агентов на компьютере для тебя принципиальны, проверка одна и та же для любого инструмента. После установки открой диспетчер процессов — ps aux на Linux и macOS, Task Manager на Windows — и посмотри, что остаётся живым после закрытия окна CLI. Отдельно стоит прочитать раздел про автообновление в документации конкретного инструмента и его настройки прокси и сети: именно там у Codex спрятались и decoupled-версия демона, и привязка к чужому HTTPS_PROXY. У каждого ИИ-кодера своя папка конфигурации и свои флаги автозапуска, но принцип проверки один: что стартует само, что переживает закрытие окна и чем оно обновляется.

Вопросы и ответы

Что за фоновый процесс ставит codex cli

С версии 0.157.0 Codex CLI после открытия интерактивной сессии поднимал демон app-server --managed-daemon без TTY, который переживал закрытие окна и держался до команды stop или перезагрузки. С 28 сентября автостарт этого демона выключен по умолчанию.

Как отключить демон codex cli

До фикса рабочим обходным путём было поставить daemon_auto_start = false в config.toml — тогда новая сессия демон не поднимала. Учти и баг: команда codex app-server daemon stop гасит сам сервер, но может оставить живым процесс обновлений pid-update-loop ещё на десятки секунд.

Безопасно ли это для обычного разработчика

Риск не в самом демоне, а в побочных эффектах: он копирует пакет и обновляет backend отдельно от версии, которую ставил пакетный менеджер, принудительно прерывает активные запросы через 60 секунд после обновления и наследует переменные окружения — включая прокси — той сессии, что подняла его первой. Разработчики признали проблему и выпустили серию фиксов между 28 сентября и 13 октября.

Источники

• Codex CLI installs a persistent, self-updating background daemon by default