Claude Code يتجاهل المحظورات في CLAUDE.md: ما الذي ينبغي نقله إلى الأذونات والـ hooks

كتبتم في CLAUDE.md «لا تحذف البيانات دون طلب»، ومع ذلك حذفها الوكيل. هذا ليس خللًا نادرًا: ففي الـ issue رقم 46779 يشتكي صاحبه من أن Claude Code كان يمحو البيانات مرارًا تتجاوز حدود المهمة، رغم أن المنع كان مكتوبًا صراحةً. ويقترح تحليل منشور على Habr طريقة واضحة للتفكير في الأمر: يجب أن تعيش القاعدة في المكان الذي تبرّر فيه كلفةُ انتهاكها ذلك.

لماذا لا يكفي النص

يُحمَّل CLAUDE.md في بداية كل جلسة، ويعيد Claude Code قراءته بعد ضغط المحادثة. يبدو إذن أن القاعدة حاضرة دائمًا في السياق. لكن المشكلة ليست في الذاكرة. ففي معيار StateTrack-Bench المعروض في EMNLP 2026 أرجع المؤلفون 88,6% من حالات الإخفاق في المحادثات الطويلة إلى انجراف السلوك: النموذج يتذكر القيد لكنه يتوقف عن اتباعه. وتضيف Microsoft Research خلفية عامة: فجودة أفضل النماذج في الحوار متعدد الأدوار أقل بنحو 39% في المتوسط منها في الحوار أحادي الدور.

وتكتب Anthropic في وثائقها بصراحة أن تعليمة من نوع «لا تفعل X أبدًا» تُنفَّذ في معظم الحالات، لكنها قد تُنتهك تحت الضغط، أو في جلسة طويلة، أو في موقف غامض، أو عند حدوث prompt injection. والمقصود بالـ prompt injection هنا تعليمة غريبة مدسوسة في ملف فتحه الوكيل لأداء مهمته.

تقسيم القواعد بحسب كلفة الخطأ

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

• permissions: القواعد allow وask وdeny تحدد ما يفعله الوكيل بنفسه، وما يسأل عنه، وما هو ممنوع عليه؛
• hooks: أوامر shell يشغّلها Claude Code عند حدث في الجلسة، مثل ما قبل كتابة ملف أو عند محاولة إنهاء الدور؛
• فحص بالشيفرة قبل التشغيل، مثل سكربت لا يبدأ العمل دون ملف يحتوي على خطة مؤكَّدة.

مثال من تجربة الكاتب: كان أمر في أداة متصفح يستهلك رصيدًا مدفوعًا. فأُغلق بقاعدة deny في .claude/settings.json بدل الاكتفاء برجاء مكتوب في النص. ويُنصح بإيداع ملف الإعدادات في git كي تصل القواعد إلى الفريق كله. وثمة تفصيل مهم من تعليق على الـ issue رقم 65563: الحماية التي تراقب أوامر Bash فقط لن ترى استدعاءً يمر عبر MCP. ففي هذا الـ issue طُلب من الوكيل التحقيق في خلل، فقام عبر أتمتة المتصفح بالضغط على الحذف ثم التأكيد على سجل حقيقي في قاعدة بيانات الإنتاج.

والأمر مشابه مع المفاتيح. فقاعدة deny على قراءة .env تغلق الملف، وhook الكتابة يرفض أي تعديل يحتوي على مفتاح، لكن طباعة سر من متغيرات البيئة لا تغطيها هاتان القاعدتان. والمفتاح المكشوف لا يمكن استرجاعه، لذلك لا تُحمى مثل هذه الحالات بالنص وحده.

الـ hook من نوع Stop ضد العمل غير المكتمل

لكي لا ينهي الوكيل دوره ما دام الفحص يفشل، يُعلَّق بحدث Stop سكربت يشغّل فحص المشروع (مثل make check) ويخرج برمز 2 عند الفشل. يمنع الرمز 2 إنهاء الدور، ويُرسَل stderr إلى الوكيل كرسالة خطأ. أما الرمز 1 دون أي مخرجات فلا يمنع الإجراء، وهذا ما تحققت منه Caprock على الإصدارين 2.1.289 و2.1.299. ومنذ الإصدار 2.1.295 صار الخيار onFailure: block يمنع الإجراء حتى عند تعطل الـ hook نفسه.

وهناك حد: بعد ثماني عمليات منع متتالية دون استدعاء أي أداة يُنهي Claude Code الدور على أي حال. ويرفع هذا الحد المتغير CLAUDE_CODE_STOP_HOOK_BLOCK_CAP، وفي المهام الطويلة ينبغي التأكد من أن الـ hook لا يصطدم به.

ما العمل

اعتبروا CLAUDE.md سجلًّا للإخفاقات لا إعلان نوايا. أضيفوا سطرًا بعد الخطأ المتكرر الثاني، وأبقوا الملف أقصر من 200 سطر، وعيّنوا مسؤولًا عنه، وراجعوا التعديلات كما تراجعون الشيفرة. فالسطر القديم يضر أكثر من غيابه.

حدود هذا النهج: الأمثلة في المقال توضيحية، ويجب مطابقة الصيغة الدقيقة مع صفحة Configure permissions في الوثائق. أما السؤال الرئيسي لمشروعكم فبسيط: ما القواعد الثلاث في ملفكم التي تكلّف مالًا أو أسرارًا؟ انقلوها أولًا إلى deny والـ hooks والفحوص بالشيفرة.