Codex CLI डिफ़ॉल्ट रूप से एक स्थायी, स्वयं-अपडेट होने वाला बैकग्राउंड डेमन इंस्टॉल करता है
OpenAI का Codex CLI अब डिफ़ॉल्ट रूप से एक स्थायी, स्वयं-अपडेट होने वाला बैकग्राउंड डेमन इंस्टॉल करता है, जिससे user control, छिपे हुए resource usage, और पुराने संस्करणों द्वारा घिरी गई बड़ी disk space खपत को लेकर चिंताएँ उठी हैं। टिप्पणीकार तर्क देते हैं कि पेशेवर टूल्स को auto-update नहीं करना चाहिए या उपयोगकर्ता के स्पष्ट नियंत्रण के बाहर लंबे समय तक चलने वाली processes नहीं चलानी चाहिए, खासकर जब वे पहले से ही buggy हों और workflows को तोड़ने की प्रवृत्ति रखते हों। कई लोग इस व्यवहार की तुलना पारंपरिक OS package managers और हल्के third-party “harnesses” से करते हैं, और Codex तथा इसी तरह के AI tooling (जैसे Claude Code) को जल्दबाज़ी में किए गए, LLM-चालित विकास के प्रतीक के रूप में देखते हैं जो स्थिरता, पारदर्शिता, और platform conventions की कीमत पर तेज़ feature growth को प्राथमिकता देता है।
ऑटो-अपडेट होने वाले डेमन का व्यवहार
- Codex CLI अब एक स्थायी बैकग्राउंड डेमन इंस्टॉल करता है जो अपने-आप अपडेट होता है और पुराने संस्करणों को रखता है।
- कई लोग इसे उपयोगकर्ता-विरोधी मानते हैं: CLI के बाहर निकलने के बाद भी यह बना रहता है, उपयोगकर्ताओं को चौंका सकता है, और इसे नियंत्रित करना कठिन है।
- अन्य लोग तर्क देते हैं कि तेज़ी से बदलने वाले AI टूलिंग को ऑटो-अपडेट की “ज़रूरत” है, और इसकी तुलना ब्राउज़र तथा डेस्कटॉप ऐप्स से करते हैं।
- कई पोस्ट करने वाले ज़ोर देते हैं कि यह केवल स्पष्ट ऑप्ट-इन के रूप में स्वीकार्य हो सकता है, डिफ़ॉल्ट के रूप में नहीं, खासकर पेशेवर टूल्स के लिए।
डिस्क स्पेस, प्रदर्शन, और अव्यवस्था
- उपयोगकर्ता कई बड़े बाइनरीज़ और बहुत-से पुराने संस्करणों के जमा होने की रिपोर्ट करते हैं (कई GB से लेकर दर्जनों GB तक)।
- Cursor, Claude Code, VS Code सेटअप जैसे अन्य harnesses के बारे में भी इसी तरह की शिकायतें की जाती हैं, जो सिस्टम में हर जगह logs, temp dirs, और caches छोड़ देते हैं।
- कुछ लोग scripts, snapshots, या यहाँ तक कि LLM का उपयोग करके “garbage” फ़ाइलों की पहचान करने के जरिए नियमित सफाई करते हैं।
विश्वसनीयता और सॉफ़्टवेयर गुणवत्ता
- Codex CLI, Codex VS Code extension, Claude Code, और अन्य harnesses को नाज़ुक, अपडेट्स पर अक्सर regress होने वाला, और बुनियादी UX (scrolling, copy/paste, subagents, login flows) को तोड़ने वाला बताया गया है।
- कई लोग इसका कारण “vibe coding” और भारी मात्रा में LLM-जनित कोड को मानते हैं: फीचर्स का आसान बढ़ना, खराब architecture, और बहुत कम manual testing।
- अन्य लोग नोट करते हैं कि buggy flagship harnesses LLM-चालित विकास की वर्तमान स्थिति का ईमानदार प्रतिबिंब हैं।
नियंत्रण, सुरक्षा, और sandboxing
- चिंता है कि persistent daemons और auto-updates user control को कमज़ोर करते हैं और backdoors जैसे दिखते हैं।
- कई उपयोगकर्ता harnesses को containers, VMs, microVMs, या bubblewrap जैसे tools में isolate करते हैं, या उन्हें host पर install ही नहीं करते।
- कुछ लोग रिपोर्ट करते हैं कि agents पहले की तुलना में credentials पढ़ रहे हैं या shell commands अधिक आक्रामक ढंग से चला रहे हैं, बिना स्पष्ट चेतावनियों के।
कॉन्फ़िगरेशन, flags, और workaround
- एक hidden/undocumented feature flag (
daemon_auto_start = false) और--no-daemonको डेमन को निष्क्रिय करने के तरीकों के रूप में साझा किया गया है। - चिंता है कि defaults और flags समय के साथ बदल सकते हैं, जिससे लगातार सतर्क रहना पड़ेगा।
- package-manager और Nix उपयोगकर्ता patched builds को पसंद करते हैं जो self-updating व्यवहार को हटा देते हैं।
विकल्प और प्राथमिकताएँ
- हल्के, “minimal” harnesses (जैसे hax, Pi, अन्य) को अक्सर XDG का सम्मान करने, daemons से बचने, और सामान्य CLI tools की तरह व्यवहार करने के लिए सराहा जाता है।
- कुछ उपयोगकर्ता इन बदलावों के जवाब में manual API उपयोग या web UIs पर लौट जाते हैं, या Codex को unsubscribe/delete कर देते हैं।