يفيد أحد المستخدمين بأنه منذ إصدار 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، وإنهاء المُحدِّث يدويًا، وحذف مجلد الحزم المخزنة مؤقتًا.
المصدر: Hacker News · لخّصه HeadlinesBriefing