أدوات سطر الأوامر لا يجب أن تثبّت خدمات خلفية افتراضياً

يشغّل مطور الأمر npm install -g @openai/codex لتجربة مساعد برمجي بالذكاء الاصطناعي، فينتهي به الأمر بعملية خلفية دائمة تحدّث نفسها بنفسها لم يطلبها أبداً. هذا ما حدث مؤخراً حين اكتشف مستخدمو Codex CLI من OpenAI أن الأداة تشغّل عملية خلفية تلقائياً، وتكتب ملفات pid وlock داخل ~/.codex، وتحتفظ بنسخ قديمة من الملفات التنفيذية على القرص (أبلغ أحد المستخدمين عن نحو 12 غيغابايت منها)، وتحدّث نفسها دون أن تسأل. هذه ليست قصة خلل في شركة واحدة، بل قصة عن نموذج ثقة اعتمدت عليه أدوات المطورين لعقود، وكيف يُتخلى عنه بهدوء.

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

الخرافة الأولى: «إنه مجرد أداة تحديث، والمتصفحات تفعل الشيء نفسه»

هذا أكثر الدفاعات شيوعاً، ويبدو معقولاً. كروم وفايرفوكس يحدّثان أنفسهما باستمرار، وكذلك VS Code وSlack. فلماذا لا يحق ذلك لأداة سطر أوامر؟

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

أداة سطر الأوامر المثبتة عبر npm تحمل عقداً ضمنياً مختلفاً. يتوقع المطورون أن تعمل عند استدعائها وأن تتوقف عند انتهائها، وهذا التوقع ليس حنيناً للماضي بل عنصر أساسي تقوم عليه الأنظمة. خطوط CI والحاويات وخوادم البناء المشتركة ومراجعات الأمان كلها تفترض أن npm i -g some-tool يمنحك ملفاً تنفيذياً يعمل عند الطلب. عملية خلفية تبقى بعد تسجيل الخروج، وتعيد تشغيل نفسها، وتستبدل ملفها التنفيذي تنتهك كل هذه الافتراضات. شاركت شخصياً في مكالمات حوادث تحوّل فيها سؤال «لماذا توجد عملية لا نستطيع تفسيرها؟» تنبيهاً روتينياً إلى تحقيق جنائي استمر ثلاث ساعات. فالاستمرارية غير المفسَّرة لا تختلف عن الاختراق حتى يثبت العكس.

هناك أيضاً فرق عملي في حجم الضرر المحتمل. المتصفح يعرض صفحات الويب داخل بيئة معزولة (sandbox). أما مساعد البرمجة بالذكاء الاصطناعي فيشغّل أوامر الصدفة، ويقرأ شجرة الشيفرة المصدرية، وغالباً ما يحتفظ بمفاتيح API وبيانات اعتماد السحابة في بيئته. إضافة مكوّن يعدّل نفسه ويعمل دائماً لهذه الأداة مخاطرة أكبر بكثير من تحديث متصفح.

الخرافة الثانية: «يستطيع المستخدمون إيقافه بعلامة إعداد»

صحيح من الناحية النظرية، وبلا معنى عملياً. نعم، توجد علامة ميزة:

# ~/.codex/config.toml
[features]
daemon_auto_start = false

المشكلة أنها كانت غير موثّقة حين بحث عنها المستخدمون. خيار إلغاء لا يعرفه أحد ليس موافقة، بل فخ. ولاحظ أيضاً خطة الاحتياط التي اقترحها المجتمع: حذف ملفات pid وlock، وربطها رمزياً بـ /dev/null، وجعلها غير قابلة للتعديل عبر chattr +i بحيث تتعطل العملية عند بدء التشغيل إذا اختفت العلامة يوماً ما. حين يضطر مستخدموك إلى تفخيخ مجلداتهم الشخصية للدفاع ضد برمجيتك، فأنت لم تبنِ نظام إعدادات، بل بنيت علاقة عدائية.

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

الحل سهل جداً وكان دائماً كذلك: اسأل مرة واحدة عند أول تشغيل. Codex runs a background service to keep itself updated. Enable it? [y/N] وأدوات مثل apt وHomebrew ومعظم خدمات لينكس تعمل على أساس التفعيل الصريح منذ عقود. وجود systemctl enable هو تحديداً لأن تشغيل شيء عند الإقلاع يُفترض أن يكون فعلاً متعمداً.

الخرافة الثالثة: «السرعة في التطوير تتطلب تحديثاً صامتاً»

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

لكن «نحن نحتاج إلى تحديثات» لا تعني «نحتاج إلى عملية خلفية دائمة تحدّث نفسها بينما أنت لا تنتبه». هناك مساحة واسعة بين الخيارين:

• الفحص عند الاستدعاء. قارن الإصدارات عند بدء تشغيل الأداة، واعرض إشعاراً، وحدّث في التشغيل التالي. يفعل Homebrew وgh وكثير غيرهما ذلك.
• التحديث عبر مدير الحزم. ثبّتَّ الأداة عبر npm، فحدّثها عبر npm. لدى المستخدم أصلاً آلية يفهمها ويستطيع تثبيتها وتدقيقها وتقييدها.
• عملية خلفية اختيارية ومعطّلة افتراضياً. للمستخدمين الذين يريدون حداثة بلا أي احتكاك، قدّم العملية الخلفية كخيار موثّق.
• تنظيف الإصدارات القديمة. الاحتفاظ بكل ملف تنفيذي سابق حتى يستهلك 12 غيغابايت من قرص أحدهم ليس استراتيجية تحديث، بل تسريب.

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

الخرافة الرابعة: «إنه مفتوح المصدر، يمكنك قراءة الشيفرة»

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

هناك مشكلة ثانية أدق، وهي تشابك الحالة مع الإعدادات. وجد مستخدمون يحاولون إدارة Codex بشكل تصريحي (وصف أحدهم فشله في ذلك ضمن nix-darwin) أن الأداة تخلط الإعدادات مع حالة التشغيل المتغيرة في المجلد نفسه، وهذا يجعل تثبيت الإصدارات أو مقارنتها أو تدقيق ما تغيّر أمراً مستحيلاً. وقد عرفت أدوات يونكس الجيدة ذلك منذ زمن طويل: الإعدادات في ~/.config، والحالة في ~/.local/state، والذاكرة المؤقتة في ~/.cache، ولا تسمح الأداة أبداً بتعديل إعداداتها بنفسها. وإذا أردت فهم سبب أهمية المسار الخاضع للتدقيق، فالفجوة بين المواصفة والتنفيذ هي بالضبط المكان الذي تعيش فيه هذه المفاجآت.

إذا أردت أن تتحقق الآن مما يعمل فعلاً على جهازك، فالأمر يستغرق ثلاثين ثانية:

# What AI-tool daemons are alive right now?
ps auxww | grep -Ei 'codex|claude' | grep -v grep
# What's been accumulating on disk?
du -sh ~/.codex ~/.local/share/claude 2>/dev/null
# What launchd/systemd units did tools register?
ls ~/Library/LaunchAgents 2>/dev/null   # macOS
systemctl --user list-units --type=service | grep -Ei 'codex|claude'  # Linux

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

الخرافة الخامسة: «الجميع يفعل ذلك، إذن لا بد أنه سليم»

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

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

ومعيار الجودة مهم أيضاً. أبلغ المستخدمون أن عملية Codex الخلفية كانت تُفسد الصلاحيات أثناء التحديث الذاتي، فتترك مجلدات .git للقراءة فقط وتعطّل مستودعات العمل. العملية المعيبة لا تكتفي بالبقاء ساكنة، بل تكسر الأشياء فعلياً بصلاحيات لم تمنحها عن وعي. «الجميع يفعل ذلك» مع «إنها معيبة» ليست طمأنة، بل توقّعٌ بما سيحدث.

كيف تبدو آلية تحديث تحترم الموافقة

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

1. لا استمرارية افتراضياً. تعمل الأداة عند استدعائها وتخرج عند انتهائها. أي مكوّن خلفي يكون اختيارياً، ويُطلب صراحةً عند أول تشغيل.
2. مفاتيح إيقاف موثّقة ومستقرة. علامة إعداد ومتغير بيئة (مثل CODEX_NO_DAEMON=1) موثّقان ومختبران، ولا يختفيان بصمت.
3. التحديث عبر قناة التثبيت. الأدوات المثبتة عبر npm تُحدَّث عبر npm. تُشعر المستخدم عند الاستدعاء، ولا تُعدّل ملفها التنفيذي من تحت قدميه أبداً.
4. إصدارات موقّعة ومُرقَّمة مع سجل تغييرات. إذا شحنت مُحدِّثاً، فوقّع الملفات، ودع المستخدمين يثبّتون الإصدارات ويدقّقون ما تغيّر.
5. مساحة قرص محدودة وفصل واضح للحالة. احتفظ بنسخة سابقة واحدة كحد أقصى، وافصل الإعدادات عن الحالة، والتزم بأعراف XDG.
6. احترم نموذج التوزيعات. كما قال أحد المعلّقين، وُجدت حزم التوزيعات لكي يختبر المشرفون البرمجيات ويزيلوا الحيل قبل أن تصل إلى المستخدمين. لا تحاربها، بل انشر عبرها.

لا شيء من هذا يبطئ فريقاً سريع الحركة بأي شكل ملموس. إنه فقط ينقل الموافقة إلى بداية التفاعل، وهذا مكانها الصحيح.

الخلاصة

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

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