Codex CLI يترك عملية خلفية تحدّث نفسها: هل تحتاج أدوات المطورين إلى إذنك أولاً؟

في الأسبوع الماضي انتشر بلاغ على GitHub يطرح سؤالاً بسيطاً يلامس كل مطوّر يستخدم أدوات الذكاء الاصطناعي في الطرفية: هل يحق لأداة سطر أوامر أن تترك عملية خلفية تعمل بعد إغلاقها، وتحدّث نفسها كل ساعة، دون أن تسألك؟ البلاغ يخصّ Codex CLI من OpenAI، وقد فتح نقاشاً أوسع من الأداة نفسها حول معنى «الموافقة» في أدوات المطورين الوكيلية.

ما الذي حدث بالضبط؟

وفق البلاغ رقم 48195 في مستودع openai/codex، بدأ سلوك جديد منذ الإصدار 0.157.0: فتح جلسة تفاعلية يطلق عملية خلفية دائمة (daemon) تعمل بوضع الخادم المُدار. هذه العملية بلا طرفية، وتبقى حيّة بعد إغلاق كل نوافذ Codex، حتى إيقافها يدوياً أو إعادة تشغيل الجهاز.

تفاصيل البلاغ التي تكررت في النقاشات:

• نسخ الحزمة كاملة: يُنسخ نحو 374 ميغابايت إلى مجلد الإصدارات داخل ~/.codex/packages، وتُشغَّل العملية من تلك النسخة.
• مُحدِّث منفصل: يبدأ بعد نحو خمس دقائق من التشغيل، ثم يفحص كل ساعة، وقد ينزّل إصداراً جديداً ويعيد تشغيل الخلفية حتى لو كانت هناك مهمة جارية.
• تثبيت البيئة: تحتفظ العملية ببيئة أول جلسة أطلقتها (مثل متغيرات الوكيل Proxy)، فترث الجلسات اللاحقة إعدادات قديمة.

بلاغ آخر، رقم 51961، يذكر أن الأداة أطلقت خادماً ومُحدِّثاً دون أن يضبط صاحب البلاغ شيئاً صراحةً، ويطلب مراجعة الإعدادات الافتراضية للتحديث. وحتى 13 أكتوبر 2026 كانت البلاغات المتصلة مفتوحة بلا ردّ رسمي حسب ما نُقل في التغطيات.

لماذا يغضب هذا المطوّرين؟

المسألة ليست أن العملية الخلفية فكرة سيئة، فهي شائعة في محررات الأكواد وخوادم اللغة وأدوات البناء. الاعتراض على ثلاثة أمور مجتمعة.

1. الافتراضي بلا سؤال

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

2. التحديث الذاتي المستمر

التحديث التلقائي مفيد أمنياً عموماً، لكنه حين يجري في عملية دائمة وبلا إشعار يعني أن الشيفرة المنفَّذة على جهازك تتغير دون أن تراجعها. في بيئات الشركات هذا يتعارض غالباً مع سياسات إدارة التغيير.

3. الموارد وتقاليد النظام

أشار معلّقون إلى تضخّم القرص بسبب نسخ الحزمة، وإلى تجاهل أعراف مثل مجلدات XDG. وهي تفاصيل صغيرة لكنها تتراكم حين تثبّت أدوات كثيرة بالطريقة نفسها.

الثقة في أداة وكيلية لا تُبنى على قدراتها وحدها، بل على أنها تفعل ما توقعتَ أن تفعله وتخبرك بما عداه.

كيف يتصل هذا بأمان الوكلاء؟

ربطت بعض التغطيات بين العملية الدائمة وبين نتيجة نسبتها إلى باحثي Cymulate، مفادها أن Codex CLI يخزّن رموز OAuth نصاً صريحاً في ~/.codex/auth.json. اجتماع أمرين، رموز دخول غير مشفّرة وعملية دائمة تحدّث نفسها، يوسّع سطح الهجوم نظرياً. ينبغي التعامل بحذر هنا: هذا ما ورد في التقارير، ولم نختبره بأنفسنا، والتأثير الفعلي يعتمد على إعداد كل جهاز وعلى من يستطيع الوصول إليه.

لكن الدرس عملي حتى مع هذا التحفظ: كل أداة تعمل بصلاحياتك الكاملة، وتحتفظ بمفاتيحك، وتبقى حيّة في الخلفية، تستحق المراجعة نفسها التي تجريها على أي خدمة تثبّتها على خادم.

ماذا تفعل اليوم؟

الحلول المتداولة في النقاش على Hacker News وفي البلاغات تعتمد على ملف الإعداد وأوامر الإيقاف. تحقّق من توثيق إصدارك قبل تطبيقها لأن الأسماء قد تتغير.

الإجراء	الغرض
ضبط daemon_auto_start = false تحت [features] في ~/.codex/config.toml	منع الإطلاق التلقائي مستقبلاً
codex features disable daemon_auto_start	الأثر نفسه عبر سطر الأوامر
codex app-server daemon stop	إيقاف الخادم المُدار الجاري
إنهاء عملية المُحدِّث يدوياً عند بقائها	في البلاغ 51961 ظلّ المُحدِّث يعمل بعد الإيقاف

وبعد ذلك راجع ما يجري على جهازك:

1. اعرض العمليات الجارية وابحث عن أي عملية باسم الأداة بعد إغلاق الجلسة.
2. افحص حجم مجلد الحزم داخل مجلد إعدادات الأداة.
3. راجع صلاحيات ملفات الاعتماد، وتأكد أنها مقروءة لحسابك وحده.
4. إن كنت في فريق، ضع قاعدة واضحة: أي أداة وكيلية تُثبَّت يجب أن يُعرف سلوكها الخلفي قبل اعتمادها.

ما الذي يمكن أن تتعلمه فرق المنتجات؟

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

كيف يبدو نموذج الموافقة الجيد؟

يمكن تلخيص ما يطلبه المعلّقون في أربعة عناصر عملية، وهي نفسها ما يستحق أن تتوقعه من أي أداة وكيلية:

• سؤال صريح عند أول تشغيل: يشرح ما الذي سيبقى حيّاً بعد الإغلاق، ولماذا، وكم يستهلك من القرص والذاكرة.
• مفتاح إيقاف واضح: خيار في ملف الإعداد وأمر واحد يوقف كل ما يتعلق بالخلفية، بما فيه المُحدِّث، لا أمران يترك أحدهما عملية يتيمة.
• فصل التنزيل عن التطبيق: تُنزَّل التحديثات وتُعلَن، ولا تُطبَّق وسط مهمة جارية قد تُقتل بسبب إعادة التشغيل.
• احترام بيئة المستخدم: مسارات قياسية للبيانات والإعدادات، وعدم تثبيت بيئة جلسة قديمة على الجلسات اللاحقة.

هذه المتطلبات لا تعطّل ابتكار المنتج. هي ما يجعل المطوّر مرتاحاً لمنح الأداة صلاحيات أوسع كل مرة، وهذا ما تحتاجه الأدوات الوكيلية أصلاً كي تؤدي عملاً حقيقياً.

ما الذي ننتظره بعد ذلك؟

حتى كتابة هذه السطور لم تصدر OpenAI تعليقاً رسمياً على البلاغات المفتوحة. هناك ثلاثة سيناريوهات معقولة: أن يتحول التشغيل التلقائي إلى خيار اختياري بقيمة افتراضية معطّلة، أو أن يُبقى عليه مع سؤال عند أول استخدام، أو أن يُوثَّق بوضوح ويُترك كما هو. أيّاً كان القرار، فإن ما حدث يرفع سقف توقعات المستخدمين من كل أدوات الفئة، وسيُسأل عن سلوكها الخلفي كل مزوّد من الآن.

أسئلة شائعة

هل يعني هذا أن Codex CLI غير آمن؟

لا يمكن الجزم من البلاغات وحدها. الموثّق أن السلوك الافتراضي أُدخل دون سؤال ومع تحديث ذاتي، وأن الجدل يدور حول الموافقة والشفافية. أما الأثر الأمني الفعلي فيحتاج تقييماً لكل بيئة.

هل أحتاج إلى حذف الأداة؟

ليس بالضرورة. كثير من المستخدمين اكتفوا بتعطيل التشغيل التلقائي وإيقاف العملية الجارية. القرار يعتمد على سياسة جهة عملك ودرجة حساسية ما تعمل عليه.

هل تنطبق المشكلة على أدوات أخرى؟

الفكرة عامة: أي أداة وكيلية تعمل في الخلفية وتحدّث نفسها تستحق الفحص نفسه. افحص عملياتك الجارية بعد إغلاق أي أداة ذكاء اصطناعي طرفية، ولا تفترض أنها توقفت.

الخلاصة

بلاغ الـdaemon في Codex CLI ليس عن ثغرة مؤكدة بقدر ما هو عن مبدأ: الأدوات التي تعمل بصلاحياتك يجب ألا تغيّر حضورها على جهازك دون موافقتك. إلى أن تصدر OpenAI ردّاً رسمياً، عطّل التشغيل التلقائي إن لم تكن بحاجة إليه، وراجع العمليات والملفات التي تتركها أدواتك خلفها، واجعل هذه المراجعة جزءاً ثابتاً من اعتماد أي أداة وكيلية جديدة في فريقك.

المصادر: GitHub #48195، GitHub #51961، Hacker News، daily.dev