يستطيع وكيل البرمجة تشغيل أوامر على حاسوبكم. علينا أن نقرّر ما الذي يُسمح له بفعله وحده، وأيّ الإجراءات يجب أن تنتظر موافقتنا. سنبدأ بطلب الإذن، ثم ننظر في أوضاع الصلاحيات والقواعد الدائمة. وسنميّز أيضًا بين الموافقات وحدود الوصول، ونرى كيف تساعدكم نقاط الحفظ والعزل على تقليل المقاطعات حين يسهل احتواء الأخطاء والتعافي منها.
لنبدأ بطلب الإذن هذا. لنفترض أنكم طلبتم من الوكيل تنظيف مُخرَجات البناء وإعادة نشر المشروع.
ولتنفيذ ذلك، يقرّر الوكيل تشغيل أمر shell. هذا الأمر يحذف المجلد dist، ثم يشغّل سكربت النشر.
الأمر المعروض يحتاج إلى موافقة قبل أن يُنفَّذ. يمكنكم السماح به مرة واحدة، أو رفضه، أو حفظ قاعدة لأوامر مشابهة إن عُرض هذا الخيار. اقرؤوا ما يشمله خيار السماح الدائم قبل أن تختاروه.
الوكيل يطلب تنفيذ الأمر على حاسوبكم. حذف مجلد البناء وتشغيل سكربت النشر سيُحدثان آثارًا حقيقية إن وافقتم عليهما. استغلّوا هذا التوقّف لقراءة الأمر، وقرّروا هل تطابق هذه الآثار ما طلبتموه.
يتيح لكم طلب الإذن مراجعة الإجراء قبل أن يُنفَّذ. اقرؤوا الإجراء المطلوب قبل الموافقة عليه. قد يصعب التراجع عن حذف الملفات، أو يستحيل، والنشر قد يغيّر خدمة قيد التشغيل. يمنحكم طلب الإذن فرصة لاكتشاف إجراء غير مرغوب فيه قبل أن يُنفَّذ.
يتيح لكم Claude Code ضبط سياسات للإجراءات المتكرّرة. كما رأينا في الأسبوع الأول، يتيح Shift+Tab التنقّل بين أوضاع الصلاحيات المتاحة. ومنها: اليدوي، وقبول التعديلات، والتخطيط، والتلقائي إن كان متاحًا. تحقّقوا من الوضع الظاهر في جلستكم، لأن الأوضاع المتاحة تعتمد على الإعداد. يحدّد الوضع سلوك الموافقة العام في الجلسة. تتيح لكم القواعد الدائمة أن تحسموا الحالات المتكرّرة مسبقًا، وأن تحفظوا هذه القرارات للجلسات التي يشملها ملف الإعدادات المعنيّ.
تُحفظ القواعد الدائمة في ملف الإعدادات. قاعدة السماح (allow) تسمح بالأوامر المطابقة دون طلب الإذن المعتاد. والمثالان هنا npm test و git status. قبل السماح بـ npm test، تحقّقوا مما يشغّله سكربت الاختبار في المشروع، لأن اسم الأمر وحده لا يجعل السكربت آمنًا. قاعدة المنع (deny) تحجب الأوامر المطابقة، مثل صيغتَي الحذف العودي والـ push القسري الظاهرتين هنا. تسري القواعد في النطاق الذي تحفظونها فيه، مثل مشروع واحد أو إعدادات المستخدم الخاصة بكم. وهي تطابق صيغ أوامر محدّدة، لذا فإن قاعدة قصيرة كهذا المثال ليست حظرًا كاملًا لكل طرق حذف الملفات أو إعادة كتابة السجلّ.
يفحص Claude Code قواعد الصلاحيات بالترتيب: المنع، ثم طلب الإذن (ask)، ثم السماح. قاعدة المنع المطابقة تحجب الأمر حتى لو طابقته أيضًا قاعدة طلب إذن أو قاعدة سماح. إن لم تطابقه قاعدة منع وطابقته قاعدة طلب إذن، ظهر طلب الإذن. وإن لم تطابقه أيٌّ منهما وطابقته قاعدة سماح، سُمح بالأمر. وحين لا تطابقه أي قاعدة، يحدّد وضع الصلاحيات وفحوصات أخرى ما يحدث. الأمر الذي لا تغطّيه القواعد لا يستدعي بالضرورة طلب إذن.
المنع يتقدّم على طلب الإذن، وطلب الإذن يتقدّم على السماح. وهذا يتيح لكم إبقاء أمر مطابق محجوبًا حتى عندما تطابقه أيضًا قاعدة سماح أوسع. لكن يجب أن تطابق القاعدة الأمر فعلًا، فراجعوا نطاقها، واستخدموا قيود الوصول أيضًا حين تحتاجون إلى احتواء الضرر.
هنا قراران يسهل الخلط بينهما: ما الذي يمكن أن يصل إليه الإجراء، وهل يحتاج إلى موافقة قبل أن يُنفَّذ. الأول هو الوصول. إعداد القراءة فقط يتيح للوكيل فحص الملفات دون تغييرها. وإعداد محصور في المشروع قد يسمح بالتعديل داخل المشروع فقط. أما الإعداد الأوسع بكثير فقد يصل إلى كل ما يسمح به حساب نظام التشغيل وبيانات الاعتماد المتاحة، وربما في أنحاء الحاسوب كله.
الثاني هو الإشراف: متى يتوقّف الوكيل ليسأل. قد تشترطون موافقات متكرّرة، أو تسمحون بالعمل الروتيني داخل حدود الوصول، مع السؤال قبل تجاوزها، أو تُعِدّون تشغيلًا بلا أي موافقات تفاعلية. هذه سياسات موافقة، لا مقدار الوصول المتاح للعملية.
يمكنكم الجمع بين وصول واسع وطلبات إذن متكرّرة، أو بين وصول مقيَّد وحرية التصرّف داخل الحدود. الأول يعتمد على أن تكتشفوا أنتم الإجراء الضار. والثاني يقيّد ما يمكن أن يؤثّر فيه الإجراء المسموح به. أوضاع الصلاحيات وقواعدها في Claude Code تتولّى الموافقات. وإعدادات البيئة المعزولة (sandbox) يمكنها تقييد وصول الأوامر إلى الملفات والشبكة. قد تعرض أدوات أخرى هذه الضوابط بطريقة مختلفة، لكن من المفيد طرح السؤالين كلٍّ على حدة.
في Claude Code خيار اسمه --dangerously-skip-permissions. وهو يفعّل وضعًا يتجاوز طلبات الإذن والفحوصات المعتادة.
حين يكون هذا الخيار مفعّلًا، يمكن أن تُنفَّذ الأوامر العادية دون موافقتكم، بما فيها الأوامر المدمِّرة. لا تعتمدوا على طلب إذن لكشف أمر سيئ قبل تنفيذه. هذا الخيار لا يمنحكم بيئة معزولة. إن أردتم تقييد ما يمكن أن يصل إليه الوكيل، فعليكم إعداد ذلك بشكل منفصل. قد يأتي الأمر غير المرغوب فيه من تخمين خاطئ من النموذج، أو من حقن الـ prompt، أي تعليمات مدسوسة في شيء يقرؤه، كما رأينا في المقدّمة. ومن دون طلب إذن يعترض طريقه، قد يُنفَّذ ذلك الأمر قبل أن تنتبهوا له.
لا تستخدموا هذا الخيار إلا في بيئة معزولة يمكن التخلّص منها، ولا يصل فيها أمر خاطئ إلى ملفات مهمة أو مفاتيح أو خدمات. يمكن لحاوية أو آلة افتراضية أن توفّر هذا الفصل، ما دمتم لم تتيحوا لها مجلدات حساسة من الجهاز المضيف أو بيانات اعتماد. أبقوا ضوابط الموافقة المعتادة مفعّلة حين تعملون مباشرة على حاسوبكم المحمول. الاستغناء عن بضعة طلبات إذن ليس مبرّرًا لتمكين أمر غير مفحوص من الوصول إلى ملفاتكم اليومية.
ابدؤوا بصلاحيات صارمة، واقرؤوا طلبات الإذن. وقبل تخفيفها من أجل مهمة ما، جهّزوا طريقة للتعافي من أنواع الأخطاء التي قد تُحدثها تلك المهمة. قبل أن يعدّل الوكيل المشروع، راجعوا النسخة العاملة التي تريدون الحفاظ عليها وسجّلوها في commit. وكما في درس Git الأول، اختاروا نُسَخ الملفات التي تدخل في ذلك الـ commit، وتحقّقوا من أن الملفات اللازمة مشمولة. احتفظوا بمُعرِّف الـ commit، لتقارنوا التغييرات اللاحقة بنقطة البداية هذه.
ومع حفظ هذه النسخة، اسمحوا بمزيد من العمل الروتيني حين يمكنكم التعافي من الأخطاء. قد تستخدمون وضع قبول التعديلات للتغييرات داخل المشروع، أو تمنحون صلاحيات الوصول إلى مجلد إضافي واحد تحتاجه المهمة. أجروا التغيير حيث يكون الضرر المحتمل محدودًا، واستمرّوا في مراجعة النتيجة.
اضغطوا Esc لإيقاف الردّ الحالي، ثم افحصوا التغييرات. إيقاف الوكيل لا يتراجع عن تعديلاته. يمكن بالأمر /rewind استعادة تعديلات أدوات الملفات التي احتفظ بها Claude Code، كما رأينا في درس الجلسة. وفي درس Git، استعدنا ملفًا متتبَّعًا من نقطة حفظ، بعد أن تحقّقنا من التعديلات التي سنتخلّى عنها. وفي حالة استعادة مختلفة، حدّدوا النسخة والعمل الذي تريدون الإبقاء عليه، ثم اطلبوا من الوكيل أن يشرح العملية المناسبة قبل تشغيلها.
أدوات الاستعادة هذه لا تتراجع عن كل أمر shell أو كل أثر خارجي. حتى الآن تناولنا ملفات سجّلها Git، ويمكن استعادتها ما دامت النسخ المحفوظة متاحة. لكن الوكيل ذا الوصول الأوسع قد يُتلف آلية الاستعادة نفسها. فقد يعيد كتابة سجلّ Git أو يحذفه، أو يُجري push لتغييرات ضارّة إلى الـ remote إن سمحت بيانات اعتماده، أو يحذف المشروع كله. يعتمد الضرر المحتمل على الملفات والخدمات وبيانات الاعتماد التي تصل إليها أدواته.
فكّروا فيما هو أبعد من استعادة المشروع الحالي. لو مُسح الحاسوب بالكامل، لاحتجتم إلى نسخة أخرى من كل بياناتكم المهمة. احتفظوا بنسخ احتياطية في مكان لا يستطيع الوكيل تعديله أو حذفه. وهذه ممارسة جيدة على أي حال، لأن البرمجيات الخبيثة وبرمجيات الفدية قد تمسح الحاسوب تمامًا كما قد يفعل وكيل مهمل. لاحقًا في المساق سنرى كيف نُعِدّ للوكيل جهازًا معزولًا لا يحوي إلا القليل، وهذا يسهّل المهمة كثيرًا، وسنعود إلى موضوع الأمان بتعمّق أكبر.
قابلية الاستعادة هي ما يمنحكم السرعة. خفّفوا القيود بقدر سهولة التراجع عن الخطأ. وهذا يصلح للتعديلات التي سجّلها Git. أبقوا رقابة أشدّ على الإجراءات التي لا يستطيع commit محلي التراجع عنها، مثل نشر شيء ما، أو حذف بيانات موجودة في مكان آخر. يساعد Git على استعادة الملفات المسجَّلة، بينما تحدّ البيئة المعزولة مما يمكن أن يصل إليه الأمر. واستخدام الاثنين معًا قد يقلّل المخاطر، ويتيح للعمل الروتيني أن يمضي بمقاطعات أقل.
يصوّر هذا المخطط مقدار الموافقة الذي تشترطونه على هيئة مقبض دوّار يمكنكم ضبطه. في الطرف الأيسر، تراجعون الإجراءات كثيرًا قبل تنفيذها. طلبات الإذن المتكرّرة تمنحكم فرصًا أكثر لاكتشاف الخطأ، لكنها تستهلك وقتكم. وهي لا تضمن الأمان، لأنكم قد توافقون على أمر ضار رغم ذلك.
في الطرف الأيمن، تُنفَّذ الإجراءات دون انتظار موافقتكم. هذا يقلّل المقاطعات، لكن الخطأ قد يتقدّم أكثر قبل أن تلاحظوه. ويبقى مقدار الضرر الممكن مرهونًا بما يصل إليه الوكيل.
يمكنكم اختيار موضع بين الطرفين وتغييره كلما تغيّرت المهمة. ابدؤوا بإعداد صارم ما دمتم تتعلّمون ما يطلبه الوكيل.
قلّلوا طلبات الإذن في الأعمال التي جعلتم التعافي منها سهلًا أو قيّدتم فيها وصول الوكيل. الـ commit النظيف ينفع في تعديلات الملفات المتتبَّعة، بينما يمكن لحاوية أو بيئة معزولة مُعدّة جيدًا أن تحدّ مما تصل إليه الأوامر. عودوا إلى موافقات أشدّ مع الكود غير المألوف ومع الإجراءات التي لا يسهل التراجع عنها. افحصوا تلك الإجراءات قبل أن تُنفَّذ.
لاختيار الموضع، اسألوا: ما الذي يمكن أن يُتلفه الوكيل بوصوله الحالي، وما الذي يتطلّبه التعافي من هذا الضرر؟ قد تكون استعادة ملف مسجَّل أمرًا بسيطًا. أما كشف معلومة سرّية أو تغيير خدمة بعيدة فقد لا يمكن التراجع عنه. العزل يقلّص ما يستطيع الوكيل الوصول إليه، فكلما زاد ما يفعله دون سؤال، وجب عليكم أن تحدّوا الضرر المحتمل بعناية أكبر.
لا يوجد إعداد واحد يناسب كل مهمة. ابدؤوا بموافقات صارمة، ثم خفّفوها لأعمال محدّدة تفهمون آثارها وتستطيعون احتواءها. واستمرّوا في فحص العمل وأنتم تفعلون ذلك. نجاح المهام السابقة لا يجعل الإجراء الذي لا رجعة فيه آمنًا، ونقطة الحفظ لا تساعد إلا في أنواع التغييرات التي تسجّلها.
كل ما سبق يفترض أنكم تستطيعون قراءة طلب الإذن والحكم عليه. لكن هذا يزداد صعوبة في الواقع. فكثيرًا ما يكتب الوكلاء أوامر طويلة تربط خطوات عديدة بـ &&، وتمرّر مُخرَجات برنامج إلى البرنامج التالي عبر الـ pipe. إليكم طلب إذن من هذا النوع. في سطر واحد، يثبّت الحزم، ويشغّل أداة فحص الأنواع ويصفّي مُخرَجاتها، ويفرغ مجلد البناء، ويبدّل الفرع، ثم يبني من جديد للإصدار.
وفي المنتصف خطوةٌ تستحق نظرة أدق. فهي تشغّل rm -rf على كل ما داخل المجلد الذي يحدّده المتغيّر BUILD_DIR. فإذا كان هذا المتغيّر فارغًا، يصبح المسار /*. عندها يحاول الأمر حذف كل ما يمكنه الوصول إليه من جذر القرص. اكتشاف ذلك يتطلّب قراءة متأنّية، والطلب يبدو تمامًا مثل الطلبات الكثيرة غير المؤذية التي سبقته.
عندما تكون الطلبات كلها تقريبًا غير مؤذية، يتوقّف الناس عن قراءتها بعناية. ويُسمّى هذا إرهاق الموافقات. تذكر Anthropic أن مستخدمي Claude Code يوافقون على 93% من طلبات الإذن. في دراسة نشرتها Anthropic في أغسطس 2026، في مهمة برمجة مدفوعة الأجر، حلّ محلّ أحد طلبات الإذن أمرٌ واضح الخطورة. ولم يحجبه سوى 13.6% من المختبِرين البالغ عددهم 1,053. في بداية الجلسة، اكتشفه نحو 17%. وبعد خمسين طلبًا سابقًا أو أكثر، لم يكتشفه سوى نحو 5%.
وهذا أحد أسباب إضافة Claude Code للوضع التلقائي، وهو الآن وضعه الافتراضي. في الوضع التلقائي، يراجع نموذج مصنِّف منفصل كل إجراء قبل تنفيذه، ويحجب ما يبدو منها خطيرًا. في الدراسة نفسها، حجب الوضع التلقائي 89% من الأوامر المستبدَلة. وهذا أفضل بكثير من أداء المختبِرين، لكنه ليس ضمانًا. ووجدت قياسات Anthropic نفسها أن المصنِّف أخفق في 17% من الحالات الحقيقية التي تجاوز فيها الوكيل ما طلبه المستخدم. فالاعتماد على الوضع التلقائي يعني الاعتماد على حكم نموذج آخر، وهذا الحكم قد يخطئ.
لذا تعاملوا مع النصائح في هذا الفيديو على أنها الحال الراهنة لمجال ناشئ. فالأدوات وإعداداتها الافتراضية والممارسات الموصى بها تتغيّر بسرعة، وتأمين وكلاء البرمجة لا يزال مشكلة مفتوحة. عندما يكون الأمر أطول من أن تتحقّقوا منه، يمكنكم أن ترفضوه، وأن تطلبوا من الوكيل تشغيل الخطوات واحدة تلو الأخرى أو شرح كل جزء. ما يصمد هو البنية التي استخدمناها. قيّدوا ما يستطيع الوكيل الوصول إليه، واحتفظوا بطريقة للاستعادة.
أنتم تقرّرون أمرين: الوصول والإشراف. الوصول هو ما يمكن أن يصل إليه الإجراء، والإشراف هو متى يحتاج الإجراء إلى موافقتكم. في Claude Code، استخدموا الأوضاع والقواعد للموافقات، وفكّروا في إعدادات البيئة المعزولة وفي البيئة المحيطة لتقييد الوصول.
ابدؤوا بإعداد صارم، وأنشئوا نقطة حفظ قبل السماح بمزيد من التعديل الروتيني. سجّلوا في commit النسخة التي تريدون الحفاظ عليها، ثم خفّفوا الموافقات فقط لعمل تستطيعون احتواء آثاره والتعافي منها.
عودوا إلى موافقات أشدّ حين تصل المهمة إلى كود غير مألوف أو بيانات حساسة، أو إلى إجراء يصعب التراجع عنه. النسخة المحفوظة من الكود لا تتراجع عن كل ما قد يفعله أمر ما. هذه الخيارات تتيح لكم منح الوكيل مساحة مفيدة للعمل مع إبقاء أخطائه المحتملة تحت السيطرة. في كل مرة تبدؤون فيها مهمة، تحقّقوا من أمرين: ما يستطيع الوكيل الوصول إليه، وما يستطيع فعله دون سؤال.