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

A user reports that since Codex CLI version 0.157.0, simply opening an interactive codex session starts a persistent background daemon that keeps running after the window is closed. The daemon copies the full platform package, roughly 374 MB, into a local releases folder and runs from that copy. This decouples the backend version from the version installed through npm, and a detached updater checks for new releases shortly after start and then hourly, restarting the backend in the process.

The user also says the daemon pins the environment of the session that launched it. Because they use a wrapper that sets HTTPS_PROXY per invocation, the daemon keeps the first session's proxy variables, and its outbound connections route through that proxy regardless of later sessions. Related issues about working directory and terminal inheritance appear to share the same root cause.

The request is to make daemon_auto_start opt-in, defaulting to false, for the CLI, or at least to ask before enabling it. The user argues that a shared, self-updating daemon suits Remote Control and the desktop app, but a CLI should have a backend that lives and dies with the window and runs the binary the user installed. If the default stays on, the user suggests exiting auto-started daemons when their last client disconnects and skipping self-copying and self-updating when the CLI came from a package manager such as npm, Homebrew, or pacman.

The user also found a bug: codex app-server daemon stop halts the app server but leaves the pid-update-loop updater running. Their current workaround is to disable the feature flag, stop the daemon, kill the updater manually, and remove the cached packages folder.

يفيد أحد المستخدمين بأنه منذ إصدار Codex CLI 0.157.0، يكفي فتح جلسة codex تفاعلية حتى يبدأ تشغيل daemon خلفي دائم يستمر في العمل بعد إغلاق النافذة. يقوم الـ daemon بنسخ حزمة المنصة الكاملة، وحجمها نحو 374 ميغابايت، إلى مجلد releases محلي، ويعمل من تلك النسخة. وهذا يفصل إصدار الواجهة الخلفية عن الإصدار المثبت عبر npm، كما يتحقق مُحدِّث منفصل من الإصدارات الجديدة بعد وقت قصير من البدء ثم كل ساعة، ويعيد تشغيل الواجهة الخلفية في هذه العملية.

ويقول المستخدم أيضًا إن الـ daemon يثبّت بيئة الجلسة التي شغّلته. ولأنه يستخدم غلافًا يضبط HTTPS_PROXY مع كل استدعاء، يحتفظ الـ daemon بمتغيرات البروكسي الخاصة بالجلسة الأولى، وتُوجَّه اتصالاته الصادرة عبر ذلك البروكسي بغض النظر عن الجلسات اللاحقة. ويبدو أن مشكلات متصلة بمجلد العمل ووراثة الطرفية تشترك في السبب الجذري نفسه.

ويطلب المستخدم جعل daemon_auto_start اختياريًا في واجهة سطر الأوامر، بقيمة افتراضية false، أو على الأقل السؤال قبل تفعيله. ويرى أن daemon مشترك ذاتي التحديث يناسب Remote Control وتطبيق سطح المكتب، لكن واجهة سطر الأوامر ينبغي أن تملك خلفية تبدأ وتنتهي مع النافذة وتشغّل الملف التنفيذي الذي ثبّته المستخدم. وإن بقي الخيار مفعّلًا افتراضيًا، فيقترح إنهاء الـ daemons التي بدأت تلقائيًا عند انفصال آخر عميل، وتخطي النسخ الذاتي والتحديث الذاتي إذا جاءت واجهة سطر الأوامر من مدير حزم مثل npm أو Homebrew أو pacman.

وقد وجد المستخدم أيضًا خللًا: الأمر codex app-server daemon stop يوقف خادم التطبيق، لكنه يترك المُحدِّث pid-update-loop يعمل. وحلّه المؤقت الحالي هو تعطيل مفتاح الميزة، وإيقاف الـ daemon، وإنهاء المُحدِّث يدويًا، وحذف مجلد الحزم المخزنة مؤقتًا.

একজন ব্যবহারকারী জানাচ্ছেন যে Codex CLI সংস্করণ 0.157.0 থেকে, একটি interactive codex সেশন খুললেই একটি স্থায়ী background daemon চালু হয়, যা উইন্ডো বন্ধ হওয়ার পরেও চলতে থাকে। daemon সম্পূর্ণ প্ল্যাটফর্ম প্যাকেজ, প্রায় 374 MB, একটি স্থানীয় releases ফোল্ডারে কপি করে এবং সেই কপি থেকে চলে। এর ফলে backend-এর সংস্করণ npm দিয়ে ইনস্টল করা সংস্করণ থেকে আলাদা হয়ে যায়। একটি আলাদা updater শুরুর কিছু পরে এবং তারপর প্রতি ঘণ্টায় নতুন রিলিজ খোঁজে, এবং এই প্রক্রিয়ায় backend পুনরায় চালু করে।

ব্যবহারকারী আরও বলেন, daemon যে সেশন একে চালু করেছিল তার environment আটকে রাখে। তিনি এমন একটি wrapper ব্যবহার করেন যা প্রতিটি invocation-এ HTTPS_PROXY সেট করে, তাই daemon প্রথম সেশনের proxy variables ধরে রাখে এবং এর outbound connections পরের সেশন যাই হোক না কেন সেই proxy দিয়েই যায়। working directory ও terminal inheritance-সংক্রান্ত অন্যান্য সমস্যাও একই মূল কারণের সঙ্গে সম্পর্কিত বলে মনে হচ্ছে।

অনুরোধ হলো CLI-এর জন্য daemon_auto_start-কে opt-in করা, ডিফল্ট মান false, অথবা অন্তত চালু করার আগে জিজ্ঞাসা করা। ব্যবহারকারীর যুক্তি, শেয়ার্ড ও স্বয়ংক্রিয়ভাবে আপডেট হওয়া daemon Remote Control ও desktop app-এর জন্য উপযুক্ত, কিন্তু CLI-এর এমন একটি backend থাকা উচিত যা উইন্ডোর সঙ্গে জন্মায় ও মরে এবং ব্যবহারকারীর ইনস্টল করা binary চালায়। ডিফল্ট চালু রাখা হলে তিনি প্রস্তাব করেন, শেষ client সংযোগ বিচ্ছিন্ন হলে স্বয়ংক্রিয়ভাবে শুরু হওয়া daemon বন্ধ হোক, এবং CLI যদি npm, Homebrew বা pacman-এর মতো package manager থেকে আসে তবে নিজেকে কপি ও আপডেট করা বাদ যাক।

ব্যবহারকারী একটি বাগও পেয়েছেন: codex app-server daemon stop app server বন্ধ করে, কিন্তু pid-update-loop updater চালু থাকে। তার বর্তমান সমাধান হলো feature flag বন্ধ করা, daemon থামানো, updater নিজে হাতে বন্ধ করা এবং cached packages ফোল্ডার মুছে ফেলা।

Ein Nutzer berichtet, dass seit Codex CLI Version 0.157.0 bereits das Öffnen einer interaktiven codex-Sitzung einen dauerhaften Hintergrunddienst startet, der auch nach dem Schließen des Fensters weiterläuft. Der Dienst kopiert das vollständige Plattformpaket, etwa 374 MB, in einen lokalen releases-Ordner und läuft von dieser Kopie aus. Dadurch wird die Version des Backends von der über npm installierten Version entkoppelt. Ein separater Updater prüft kurz nach dem Start und danach stündlich auf neue Releases und startet dabei das Backend neu.

Der Nutzer erklärt außerdem, dass der Dienst die Umgebung der Sitzung festschreibt, die ihn gestartet hat. Da er einen Wrapper verwendet, der bei jedem Aufruf HTTPS_PROXY setzt, behält der Dienst die Proxy-Variablen der ersten Sitzung bei, und seine ausgehenden Verbindungen laufen unabhängig von späteren Sitzungen über diesen Proxy. Verwandte Probleme mit dem Arbeitsverzeichnis und der Vererbung des Terminals scheinen dieselbe Ursache zu haben.

Die Forderung lautet, daemon_auto_start für die CLI optional zu machen, mit dem Standardwert false, oder zumindest vor der Aktivierung nachzufragen. Der Nutzer argumentiert, dass ein gemeinsam genutzter, sich selbst aktualisierender Dienst für Remote Control und die Desktop-App passt, eine CLI aber ein Backend haben sollte, das mit dem Fenster entsteht und endet und das vom Nutzer installierte Binary ausführt. Bleibt die Standardeinstellung aktiv, schlägt er vor, automatisch gestartete Dienste zu beenden, sobald der letzte Client getrennt wird, und das Selbstkopieren und Selbstaktualisieren zu überspringen, wenn die CLI aus einem Paketmanager wie npm, Homebrew oder pacman stammt.

Der Nutzer hat außerdem einen Fehler gefunden: codex app-server daemon stop beendet den App-Server, lässt aber den Updater pid-update-loop weiterlaufen. Seine aktuelle Umgehungslösung besteht darin, das Feature-Flag zu deaktivieren, den Dienst zu stoppen, den Updater manuell zu beenden und den zwischengespeicherten packages-Ordner zu entfernen.

Un usuario informa de que, desde la versión 0.157.0 de Codex CLI, basta con abrir una sesión interactiva de codex para que se inicie un demonio persistente en segundo plano que sigue ejecutándose después de cerrar la ventana. El demonio copia el paquete completo de la plataforma, de unos 374 MB, en una carpeta local de versiones y se ejecuta desde esa copia. Esto desvincula la versión del backend de la versión instalada mediante npm, y un actualizador independiente busca nuevas versiones poco después de iniciarse y luego cada hora, reiniciando el backend en el proceso.

El usuario también afirma que el demonio fija el entorno de la sesión que lo lanzó. Como utiliza un contenedor que establece HTTPS_PROXY en cada invocación, el demonio conserva las variables de proxy de la primera sesión, y sus conexiones salientes se enrutan a través de ese proxy independientemente de las sesiones posteriores. Otros problemas relacionados con el directorio de trabajo y la herencia del terminal parecen tener la misma causa raíz.

La solicitud consiste en que daemon_auto_start sea opcional para la CLI, con valor predeterminado false, o al menos que se pida confirmación antes de activarlo. El usuario sostiene que un demonio compartido y de autoactualización encaja con Remote Control y la aplicación de escritorio, pero que la CLI debería tener un backend que nazca y muera con la ventana y ejecute el binario instalado por el usuario. Si la opción predeterminada se mantiene activada, el usuario sugiere cerrar los demonios iniciados automáticamente cuando se desconecte su último cliente, y omitir la autocopia y la autoactualización cuando la CLI proviene de un gestor de paquetes como npm, Homebrew o pacman.

El usuario también descubrió un error: codex app-server daemon stop detiene el servidor de aplicaciones, pero deja en ejecución el actualizador pid-update-loop. Su solución temporal consiste en desactivar la marca de función, detener el demonio, terminar manualmente el actualizador y eliminar la carpeta de paquetes en caché.

Un utilisateur signale que, depuis la version 0.157.0 de Codex CLI, il suffit d’ouvrir une session codex interactive pour qu’un démon d’arrière-plan persistant se lance et continue de tourner après la fermeture de la fenêtre. Le démon copie le package complet de la plateforme, soit environ 374 Mo, dans un dossier local de versions et s’exécute à partir de cette copie. Cela découple la version du backend de celle installée via npm. Un programme de mise à jour distinct vérifie les nouvelles versions peu après le démarrage, puis toutes les heures, en redémarrant le backend au passage.

L’utilisateur affirme également que le démon fige l’environnement de la session qui l’a lancé. Comme il utilise un wrapper qui définit HTTPS_PROXY à chaque invocation, le démon conserve les variables de proxy de la première session, et ses connexions sortantes passent par ce proxy quelles que soient les sessions suivantes. Des problèmes liés au répertoire de travail et à l’héritage du terminal semblent partager la même cause profonde.

La demande consiste à rendre daemon_auto_start optionnel pour la CLI, avec la valeur par défaut false, ou au minimum à demander confirmation avant de l’activer. L’utilisateur estime qu’un démon partagé et auto-mis à jour convient à Remote Control et à l’application de bureau, mais qu’une CLI devrait disposer d’un backend qui naît et meurt avec la fenêtre et exécute le binaire installé par l’utilisateur. Si l’option reste activée par défaut, il suggère d’arrêter les démons lancés automatiquement lorsque le dernier client se déconnecte, et d’omettre l’auto-copie et l’auto-mise à jour lorsque la CLI provient d’un gestionnaire de paquets tel que npm, Homebrew ou pacman.

L’utilisateur a aussi relevé un bogue : codex app-server daemon stop arrête le serveur d’application mais laisse tourner le programme de mise à jour pid-update-loop. Son contournement actuel consiste à désactiver le drapeau de fonctionnalité, arrêter le démon, tuer manuellement le programme de mise à jour et supprimer le dossier des paquets en cache.

एक उपयोगकर्ता की रिपोर्ट है कि Codex CLI संस्करण 0.157.0 से, केवल एक interactive codex सत्र खोलने पर एक लगातार चलने वाला background daemon शुरू हो जाता है, जो विंडो बंद होने के बाद भी चलता रहता है। daemon पूरे platform package, लगभग 374 MB, को एक स्थानीय releases फ़ोल्डर में कॉपी करता है और उसी कॉपी से चलता है। इससे backend का संस्करण npm के माध्यम से इंस्टॉल किए गए संस्करण से अलग हो जाता है, और एक अलग updater शुरू होने के थोड़ी देर बाद और फिर हर घंटे नए releases की जांच करता है, जिससे प्रक्रिया में backend फिर से शुरू होता है।

उपयोगकर्ता का यह भी कहना है कि daemon उस सत्र का environment पिन कर देता है जिसने उसे शुरू किया था। चूंकि वह एक wrapper का उपयोग करते हैं जो हर invocation के लिए HTTPS_PROXY सेट करता है, daemon पहले सत्र के proxy variables को रखता है, और उसके outbound connections बाद के सत्रों की परवाह किए बिना उसी proxy से होकर जाते हैं। working directory और terminal inheritance से जुड़ी अन्य समस्याएं भी इसी मूल कारण से जुड़ी लगती हैं।

अनुरोध यह है कि CLI के लिए daemon_auto_start को opt-in बनाया जाए, जिसका डिफ़ॉल्ट मान false हो, या कम से कम इसे सक्षम करने से पहले पूछा जाए। उपयोगकर्ता का तर्क है कि साझा, स्वयं-अपडेट होने वाला daemon Remote Control और desktop app के लिए उपयुक्त है, लेकिन CLI के लिए ऐसा backend होना चाहिए जो विंडो के साथ ही शुरू और बंद हो और उपयोगकर्ता द्वारा इंस्टॉल किए गए binary को चलाए। यदि डिफ़ॉल्ट रूप से चालू रहता है, तो उपयोगकर्ता सुझाव देता है कि अंतिम client के disconnect होने पर स्वचालित रूप से शुरू हुए daemons बंद हो जाएं, और जब CLI npm, Homebrew या pacman जैसे package manager से आया हो तो self-copying और self-updating छोड़ दी जाए।

उपयोगकर्ता को एक बग भी मिला: codex app-server daemon stop app server को रोक देता है, लेकिन pid-update-loop updater चलता रहता है। उनका अस्थायी समाधान है कि feature flag बंद करें, daemon रोकें, updater को मैन्युअली बंद करें, और cached packages फ़ोल्डर हटा दें।

Seorang pengguna melaporkan bahwa sejak Codex CLI versi 0.157.0, cukup dengan membuka sesi codex interaktif, sebuah daemon latar belakang persisten akan dijalankan dan terus berjalan setelah jendela ditutup. Daemon menyalin seluruh paket platform, sekitar 374 MB, ke folder releases lokal dan berjalan dari salinan tersebut. Hal ini memisahkan versi backend dari versi yang dipasang melalui npm. Sebuah updater terpisah memeriksa rilis baru tak lama setelah dijalankan, lalu setiap jam, dan dalam prosesnya me-restart backend.

Pengguna juga menyatakan bahwa daemon mengunci lingkungan sesi yang menjalankannya. Karena pengguna memakai wrapper yang mengatur HTTPS_PROXY pada setiap pemanggilan, daemon mempertahankan variabel proxy dari sesi pertama, dan koneksi keluarnya tetap melewati proxy tersebut terlepas dari sesi berikutnya. Masalah terkait direktori kerja dan pewarisan terminal tampaknya berasal dari akar penyebab yang sama.

Permintaannya adalah menjadikan daemon_auto_start sebagai opt-in untuk CLI, dengan nilai default false, atau setidaknya meminta konfirmasi sebelum mengaktifkannya. Pengguna berpendapat bahwa daemon bersama yang memperbarui diri sendiri cocok untuk Remote Control dan aplikasi desktop, tetapi CLI seharusnya memiliki backend yang hidup dan mati bersama jendelanya serta menjalankan binary yang dipasang pengguna. Jika default tetap aktif, ia menyarankan agar daemon yang dijalankan otomatis dihentikan saat klien terakhir terputus, dan agar penyalinan dan pembaruan mandiri dilewati jika CLI berasal dari pengelola paket seperti npm, Homebrew, atau pacman.

Pengguna juga menemukan bug: codex app-server daemon stop menghentikan app server, tetapi membiarkan updater pid-update-loop tetap berjalan. Solusi sementaranya adalah menonaktifkan feature flag, menghentikan daemon, mematikan updater secara manual, dan menghapus folder paket yang di-cache.

あるユーザーの報告によると、Codex CLI バージョン 0.157.0 以降、対話型の codex セッションを開くだけで常駐のバックグラウンドデーモンが起動し、ウィンドウを閉じた後も動き続けるといいます。デーモンはプラットフォーム全体のパッケージ（約 374 MB）をローカルの releases フォルダーにコピーし、そのコピーから実行します。これにより、バックエンドのバージョンが npm でインストールされたバージョンから切り離されます。さらに、独立したアップデーターが起動直後と、その後は毎時間新しいリリースを確認し、その過程でバックエンドを再起動します。

ユーザーはまた、デーモンが起動元のセッションの環境を固定してしまうとも述べています。呼び出しごとに HTTPS_PROXY を設定するラッパーを使っているため、デーモンは最初のセッションのプロキシ変数を保持し、その後のセッションに関係なく、外向きの接続はそのプロキシ経由になります。作業ディレクトリやターミナルの継承に関する関連問題も、同じ根本原因に由来するようです。

要望は、CLI の daemon_auto_start をオプトインにして既定値を false にすること、少なくとも有効化する前に確認を求めることです。ユーザーは、共有で自己更新するデーモンは Remote Control やデスクトップアプリには適しているものの、CLI では、ウィンドウと共に起動・終了し、ユーザーがインストールしたバイナリを実行するバックエンドが望ましいと主張しています。既定で有効のままにする場合は、最後のクライアントが切断したときに自動起動したデーモンを終了させること、そして CLI が npm、Homebrew、pacman などのパッケージマネージャーから来ている場合は自己コピーと自己更新を省くことを提案しています。

ユーザーはバグも見つけました。codex app-server daemon stop はアプリサーバーを停止しますが、pid-update-loop のアップデーターは動いたままになります。現在の回避策は、機能フラグを無効にし、デーモンを停止し、アップデーターを手動で終了させ、キャッシュされたパッケージフォルダーを削除することです。

Um usuário relata que, desde a versão 0.157.0 do Codex CLI, basta abrir uma sessão interativa do codex para iniciar um daemon persistente em segundo plano, que continua em execução depois que a janela é fechada. O daemon copia o pacote completo da plataforma, de cerca de 374 MB, para uma pasta local de releases e executa a partir dessa cópia. Isso desvincula a versão do backend da versão instalada via npm. Além disso, um atualizador separado verifica novas versões pouco depois de iniciar e depois a cada hora, reiniciando o backend nesse processo.

O usuário também afirma que o daemon fixa o ambiente da sessão que o iniciou. Como ele usa um wrapper que define HTTPS_PROXY a cada invocação, o daemon mantém as variáveis de proxy da primeira sessão, e suas conexões de saída passam por esse proxy independentemente das sessões seguintes. Outros problemas relacionados ao diretório de trabalho e à herança do terminal parecem ter a mesma causa raiz.

O pedido é tornar daemon_auto_start opcional para a CLI, com valor padrão false, ou pelo menos pedir confirmação antes de ativá-lo. O usuário argumenta que um daemon compartilhado e com autoatualização serve ao Remote Control e ao aplicativo de desktop, mas uma CLI deveria ter um backend que nasce e morre com a janela e executa o binário instalado pelo usuário. Se o padrão continuar ativado, ele sugere encerrar os daemons iniciados automaticamente quando o último cliente se desconectar, e pular a autocópia e a autoatualização quando a CLI vier de um gerenciador de pacotes como npm, Homebrew ou pacman.

O usuário também encontrou um bug: codex app-server daemon stop interrompe o servidor de aplicativo, mas deixa o atualizador pid-update-loop em execução. Seu contorno atual é desativar a flag de recurso, parar o daemon, encerrar manualmente o atualizador e remover a pasta de pacotes em cache.

Пользователь сообщает, что начиная с версии Codex CLI 0.157.0 достаточно открыть интерактивную сессию codex, чтобы запустился постоянный фоновый демон, который продолжает работать после закрытия окна. Демон копирует весь пакет для платформы, примерно 374 МБ, в локальную папку releases и работает из этой копии. Это отделяет версию backend от версии, установленной через npm. Отдельный модуль обновления проверяет наличие новых релизов вскоре после запуска, а затем каждый час, перезапуская backend в ходе этой проверки.

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

Запрос состоит в том, чтобы сделать daemon_auto_start для CLI необязательным, со значением по умолчанию false, или хотя бы спрашивать перед включением. Пользователь считает, что общий самообновляющийся демон подходит для Remote Control и настольного приложения, но у CLI должен быть backend, который запускается и завершается вместе с окном и работает с установленным пользователем бинарным файлом. Если значение по умолчанию оставят включённым, он предлагает завершать автоматически запущенные демоны, когда отключается последний клиент, и пропускать самокопирование и самообновление, если CLI установлен через менеджер пакетов, например npm, Homebrew или pacman.

Пользователь также обнаружил ошибку: команда codex app-server daemon stop останавливает сервер приложения, но оставляет работать модуль обновления pid-update-loop. Его текущий обходной путь: отключить флаг функции, остановить демон, вручную завершить модуль обновления и удалить папку с кэшированными пакетами.

一位用户报告称，自 Codex CLI 0.157.0 版本起，只要打开一个交互式 codex 会话，就会启动一个持久的后台守护进程，即使窗口关闭后它仍会继续运行。该守护进程会将完整的平台安装包（约 374 MB）复制到本地 releases 文件夹中，并从该副本运行。这使后端版本与通过 npm 安装的版本脱钩。此外，一个独立的更新程序会在启动后不久以及之后每小时检查一次新版本，并在此过程中重启后端。

该用户还表示，守护进程会固定启动它的那个会话的环境变量。由于其使用的包装脚本会为每次调用设置 HTTPS_PROXY，守护进程会保留第一个会话的代理变量，其对外连接将始终经由该代理，而不受之后会话的影响。与工作目录和终端继承相关的其他问题似乎也源于同一根本原因。

该请求是希望将 CLI 的 daemon_auto_start 改为可选开启，默认值为 false；或者至少在启用前先询问用户。用户认为，共享且自动更新的守护进程适用于 Remote Control 和桌面应用，但 CLI 应当使用随窗口启停、并运行用户所安装二进制文件的后端。若保留默认开启，用户建议在最后一个客户端断开时退出自动启动的守护进程，并在 CLI 来自 npm、Homebrew 或 pacman 等包管理器时，跳过自我复制和自我更新。

用户还发现一个缺陷：执行 codex app-server daemon stop 会停止应用服务器，但会让 pid-update-loop 更新程序继续运行。其目前的变通方法是禁用功能开关、停止守护进程、手动终止更新程序，并删除缓存的 packages 文件夹。