הדימון שנפתח אוטומטית ב-Codex CLI 0.157.0 מעורר תסכול אצל משתמשים

מה השתנה ב-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).

תלונות משתמשים ופתרון עקיף

ב-25 בספטמבר 2026 נפתח 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 הופך ללא תקין, ו-daemon_auto_start = false ב-config.toml פותר את הבעיה. משתמש אחד מצא עדכון רקע של 1.3 GB ימים לאחר ההתקנה. התגובה הייתה חריפית שלילית: רבים כינו את ההתנהגות "דומה לתוכנה זדונית", וחלקם אמרו שיחזירו את רישיונות המקומות של Codex.

פתרון עקיף ושאלות פתוחות

commit של אריזת 28 בספטמבר (b51c036, ב-nixvital/ml-pkgs) מכבה את ההפעלה האוטומטית של הדימון בחבילת Nix זו, אך שינוי רשמי בברירת המחדל מצד OpenAI אינו נראה בביקורת. דגל הכיבוי אינו קיים גם במסמך התצורה הרשמי, והערה של 0.157.0 תיארה את הפונקציה במשפט אחד, ללא אזכור של תהליך קבוע, עותק חבילה מנוהלת ועדכון שעתי.

ביקורת נוספת נוגעת ביורכיה: CLI מעתיק את עצמו לתיקיית המהדורות המנוהלות, ועדכון רקע עלול להחליף עותק זה, ולכן סבב הבא עלול שלא לשרת את הארטיפקט שהמשתמש התקין. אחד המגיבים הציע מפתח בדיקה לחיבור כל לקוח: גרסת CLI של הלקוח, חתימה בינארית של הדימון, דור הדימון, מצב העדכון ודור מורשת של סביבה, כדי שהלקוח יקבע איזה דימון הוא הסמכותי. issues #40969, #41188, #46468 ו-#48050 פתוחים.

מקורות: GitHub