خيار «Don't Ask Again» في Claude Code سرّب كلمات مرور إلى 1122 ملفًا عامًا على GitHub

لقد ضغطتم على «Don't Ask Again» مئة مرة كي يتوقف الوكيل عن مقاطعتكم عند كل أمر. إنها ميزة مريحة. لكن باحثي Apiiro أظهروا أن لهذه الراحة ثمنًا: فقد عُثر في GitHub العام على 1122 ملفًا تحتوي على كلمات مرور تسرّبت تحديدًا عبر أذونات Claude Code من هذا النوع.

تنبيه: لا يتوافر لدينا سوى العنوان والإشارة الواردة من Hacker News، حيث حصد المنشور 114 نقطة و85 تعليقًا، وليس النص الكامل للتقرير. لذلك تُعرض الآلية أدناه بوصفها التفسير الأرجح، وينبغي التحقق من التفاصيل بالرجوع إلى المصدر الأصلي.

كيف تصل كلمة المرور إلى GitHub

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

ولكي تتذكر الأداة اختياركم، تكتب قاعدة الإذن في ملف إعدادات المشروع. وإذا كانت القاعدة مرتبطة بأمر محدد، فقد يُحفظ الأمر كاملًا في الملف، بما في ذلك السر. ثم تسير الأمور كالمعتاد: git add ثم commit ثم push. يكون ملف الإعدادات داخل المستودع بجوار الشفرة، وإذا كان المستودع عامًا تصبح كلمة المرور متاحة للجميع.

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

لماذا يُعد هذا أخطر من تسريب عادي

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

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

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

ما الذي ينبغي فعله الآن

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

ثانيًا، افصلوا الإعدادات المشتركة عن المحلية. يجب أن تكون القواعد التي يريد الفريق مشاركتها منفصلة عن الأذونات الشخصية، وأن يُضاف الملف المحلي إلى .gitignore.

ثالثًا، أضيفوا ماسحًا للأسرار إلى pre-commit وCI، وأدرجوا صراحة ملفات إعدادات أدوات الذكاء الاصطناعي في نطاق الفحص. إنها وسيلة حماية زهيدة التكلفة.

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

الخلاصة لفرق المنتجات والمؤسسين

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