
Codex CLI 0.157.0-ის ავტომატურად გაშვებული დემონი მომხმარებლების უკმაყოფილებას იწვევს
მომხმარებლები ამბობენ, რომ Codex CLI 0.157.0 ინტერაქტიულ სესიაზე ჩუმად რთავს მუდმივ, თვითგანახლებად ფონურ დემონს. განხილვაში მოცემული გვერდის ავლის ხერხი მას feature flag-ით თიშავს, პრობლემა კი კვლავ ღიაა.
რა შეიცვალა Codex CLI 0.157.0-ში
0.157.0-დან ინტერაქტიული Codex CLI სესია ავტომატურად რთავს მუდმივ ფონურ დემონს (codex app-server --managed-daemon). ის საკუთარ სესიაში, TTY-ს გარეშე მუშაობს, ფანჯრების დახურვის შემდეგ PID 1-ზე მიმაგრებით რჩება და გრძელდება მანამ, სანამ codex app-server daemon stop არ შესრულდება ან მოწყობილობა არ გადაიტვირთება.
დემონი მთლიან პლატფორმის პაკეტს, დაახლოებით 374 MB-ს, codex, codex-code-mode-host, bwrap, zsh და rg-ის ჩათვლით, ~/.codex/packages/app-server-daemon/releases/<version>/-ში აკოპირებს და იქიდან მუშაობს. ამიტომ backend-ის ვერსია CLI-ის ვერსიას აღარ არის მიბმული. განცალკევებული განახლების პროცესი (codex app-server daemon pid-update-loop) ხუთ წუთში, შემდეგ ყოველ საათში ამოწმებს განახლებებს, ჩამოტვირთავს ახალ გამოშვებებს და backend-ს თავიდან უშვებს, რამაც აქტიური ტურები შეიძლება შეწყვიტოს (issue #40969).
მომხმარებლების საჩივრები და გვერდის ავლა
2026 წლის 25 სექტემბერს გახსნილი issue #48195 ამბობს, რომ მუდმივი, თვითგანახლებადი დემონი CLI-სთვის ნაგულისხმევი არ უნდა იყოს. ის ამაგრებს დამწყები სესიის გარემოს, ამიტომ გამოძახებისას დაყენებული proxy ცვლადები შემდეგ სესიებში იგნორირდება, ხოლო --remote რეჟიმში hooks-ები დემონის სამუშაო დირექტორიას იღებენ, არა სესიისას (issues #42457, #37537). ხარვეზია ისიც, რომ codex app-server daemon stop app-server-ს აჩერებს, pid-update-loop-ს კი არა, ამიტომ საჭიროა ხელით მოკვლა.
დოკუმენტირებული გამოსავალია codex features disable daemon_auto_start, დემონის გაჩერება, განახლების პროცესის მოკვლა და ~/.codex/packages/app-server-daemon-ის წაშლა. დროშის გამორთვით ახალი TUI სესიები დემონს აღარ ქმნიან. Windows 10 LTSC-ზე CLI არასამუშაო ხდება, config.toml-ში daemon_auto_start = false კი პრობლემას წყვეტს. ერთმა მომხმარებელმა ინსტალაციიდან დღეების შემდეგ 1,3 GB ფონური განახლება იპოვა. რეაქცია მკვეთრად უარყოფითი იყო: ბევრმა ქცევას „მავნე პროგრამის მსგავსი“ უწოდა, ზოგმა თქვა, რომ Codex-ის ადგილების ლიცენზიებს უკან დააბრუნებდა.
გვერდის ავლა და დარჩენილი კითხვები
28 სექტემბრის პაკეტირების commit-ი (b51c036, nixvital/ml-pkgs-ში) ამ Nix პაკეტში დემონის ავტომატურ გაშვებას თიშავს, OpenAI-ს მხრიდან ნაგულისხმევის ოფიციალური ცვლილება კი განხილვაში არ ჩანს. გამორთვის დროშა ოფიციალურ კონფიგურაციის ცნობარშიც არ არის, 0.157.0-ის შენიშვნა კი ფუნქციას ერთი წინადადებით აღწერდა, მუდმივი პროცესის, მართული პაკეტის ასლისა და საათობრივი განახლების დასახელების გარეშე.
შემდგომი განხილვა წარმომავლობას ეხება: CLI თავს მართულ გამოშვების საქაღალდეში აკოპირებს, ფონურ განახლებას კი ეს ასლი შეუძლია ჩაანაცვლოს, ამიტომ შემდეგ ტურს შესაძლოა ის არტეფაქტი აღარ ემსახუროს, რომელიც მომხმარებელმა დააყენა. ერთმა კომენტატორმა შესთავაზა შესრულების ქვითარი თითო კლიენტის მიმაგრებისთვის: კლიენტის CLI ვერსია, დემონის ბინარული დაჯესტი, დემონის თაობა, განახლების მდგომარეობა და გარემოს მემკვიდრეობითი თაობა, რომ კლიენტმა დაადგინოს, რომელი დემონია ავტორიტეტული. დაკავშირებული issues #40969, #41188, #46468 და #48050 ღიაა.
წყაროები: GitHub
SiTech — AI-გაძლიერებული ვებ დეველოპმენტი
ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.