تهيئة الصلاحيات: ما مدى التساهل أو التقييد، القرار لك

📚 تنقل السلسلة: المقال السابق 19 إدارة السياق يعلمك كيفية إدارة "طاولة عمل" Claude بشكل جيد لتجنب امتلاء الذاكرة. هذا المقال ينتقل إلى بعد آخر - لا يتعلق بـ "كم يتذكر"، بل بـ "كم يجرؤ على التعديل": من سؤاله لك عن كل أمر إلى تركه يعمل بحرية كاملة، القرار لك في تحديد مدى إحكام قبضة الصلاحيات.

"كيف تجرؤ على تشغيل --dangerously-skip-permissions؟ الكلمة 'dangerous' مكتوبة بوضوح في الاسم."

"أنا في بيئة رملية (sandbox)، ما الداعي للخوف؟ حتى لو قام بحذف الدليل بالكامل عبر rm -rf، فإن ما سيحذفه هو مجرد حاوية مؤقتة، وسنقوم بإنشاء حاوية جديدة فوراً."

لقد وقفت بنفسي على كلا الجانبين في هذه المحادثة: عند تشغيل إعادة هيكلة برمجية (refactoring) جماعية داخل حاوية معزولة في السحاب، كنت أستخدم الوضع الخطير الأكثر تساهلاً طوال الوقت دون أي قلق من الحذف والبدء من جديد؛ ولكن بمجرد العودة إلى جهازي المحلي الذي يحتوي على الأكواد الفعلية للفريق، كنت أتردد لثانيتين حتى مع acceptEdits. باختصار، لا يوجد 'صواب أو خطأ' في موضوع الصلاحيات، بل يتعلق الأمر بـ 'أين تستخدمها'. نفس الوضع الخطير الأكثر تساهلاً يعد "أداة لتسريع العمل" في حاوية معزولة، بينما هو "قنبلة موقوتة" على جهازك الذي يحتوي على أكواد الإنتاج الخاصة بالشركة.

لقد جربنا ذلك بشكل سريع في المقال 07 - حيث يتوقف Claude ليسألك قبل تعديل الملفات. كانت تلك مجرد قمة جبل الجليد. اليوم سنكشف جبل الجليد بالكامل: ما هي أوضاع الصلاحيات المتاحة في Claude Code، وكيفية التبديل بينها بنقرة واحدة، وكيفية استخدام ملف التهيئة لتحديد ما هو مسموح وما هو ممنوع تماماً.

بعد قراءة هذا المقال، ستحصل على:

• جدول يوضح أوضاع الصلاحيات الستة ومتى يُنصح باستخدام كل منها.
• ذاكرة عضلية للتبديل بين الأوضاع باستخدام الاختصار Shift+Tab، وكيفية تحديد الوضع مباشرة عند بدء التشغيل.
• صيغة كتابة قواعد allow / ask / deny في ملف settings.json للتحكم الدقيق بالصلاحيات حسب الأداة والأمر.
• نموذجين جاهزين للتهيئة: "تساهل مع المشاريع الجانبية وتقييد مع مشاريع الإنتاج"، جاهزة للنسخ والاستخدام.
• متى يمكنك تفعيل --dangerously-skip-permissions وأين تكمن الخطوط الحمراء.

---

01 افهم أولاً: ماذا يدير نظام الصلاحيات؟

لنبدأ بالخلاصة: Claude Code هو في الأصل متدرب يعمل بمبدأ 'اسأل أولاً قبل التصرف'، وتهيئة الصلاحيات هي 'قواعد السلوك' التي تحددها لهذا المتدرب.

يقسم النظام جميع العمليات إلى ثلاث فئات، وتختلف المعاملة الافتراضية لكل منها. هذا الجدول من التوثيق الرسمي هو الأساس لفهم كل ما يلي:

نوع الأداة	مثال	هل يتطلب موافقة افتراضياً؟
القراءة فقط	قراءة الملفات، البحث بـ Grep	لا، يتم السماح مباشرة
أوامر Bash	تنفيذ أوامر shell	nعم
تعديل الملفات	تعديل الملفات عبر Edit / Write	نعم

تشبيه: هل يسألك المتدرب قبل البدء بالعمل؟ المتدرب الموثوق، عندما تطلب منه "إلقاء نظرة على هذا الكود" سيفعل ذلك مباشرة (قراءة فقط، صفر مخاطرة)؛ لكن عندما يريد "تعديل إعدادات الإنتاج" أو "تشغيل أمر حذف"، فمن الطبيعي أن يسألك أولاً "رئيسي، هل يمكنني تعديل هذا؟". Claude Code يعمل بهذه الطريقة افتراضياً - اقرأ كما تشاء، ولكن أبلغني قبل التعديل.

هناك نقطة إدراك أساسية وقعتُ فيها بنفسي سابقاً: يتم فرض الصلاحيات بواسطة برنامج Claude Code نفسه، وليس بالاعتماد على 'وعي النموذج'.

لقد كتبت ذات مرة في CLAUDE.md عبارة "لا تقم بتنفيذ git push" ظناً مني أن هذا سيمنعه تماماً، ولكن في إحدى المرات قام بعمل push بكل بساطة - لأن CLAUDE.md مجرد تلميح مرن (soft prompt) يؤثر على ما يرغب في فعله، بينما القيود الصارمة (hard constraints) يجب كتابتها في قواعد الصلاحيات. بعد أن نقلت هذا الأمر إلى قسم deny، التزم به. يذكر التوثيق الرسمي ذلك بوضوح:

يتم فرض قواعد الصلاحيات بواسطة Claude Code، وليس بواسطة النموذج. تؤثر التعليمات الموجودة في مطالباتك أو في ملف CLAUDE.md على الإجراءات التي يحاول Claude تنفيذها، لكنها لا تغير الإجراءات التي يسمح بها Claude Code.

تذكر هذه القاعدة لتحديد مكان بناء "خط الدفاع".

💡 خلاصة سريعة: السماح بالقراءة وطلب الإذن قبل التعديل هي القاعدة الافتراضية؛ إذا كنت تريد منع عملية معينة تماماً، يجب كتابة قاعدة صلاحيات، فالتوصيات في CLAUDE.md وحدها لا تكفي.

---

02 أوضاع الصلاحيات الستة: من "السؤال عن كل خطوة" إلى "الفتح الكامل"

تتحكم أوضاع الصلاحيات (permission mode) في أمر واحد: "معدل تكرار" توقف Claude ليسألك قبل اتخاذ أي إجراء. يتراوح هذا من "التوقف عند كل خطوة بانتظار موافقتك" إلى "التنفيذ المباشر دون أي سؤال".

تشبيه: بالعودة إلى المتدرب، فإن الوضع يمثل 'مستوى الصلاحية الممنوحة له'. في يومه الأول، يسأل عن كل شيء (default)؛ بعد أن يعتاد على العمل، يعدل الكود دون سؤال ولكن يسألك قبل حذف قاعدة البيانات (acceptEdits)؛ وعندما تسافر وتثق به تماماً، تتركه يتصرف بنفسه (bypassPermissions).

يوفر التوثيق الرسمي ستة أوضاع. قمنا بتنظيمها في جدول يوضح "ما يمكن عمله دون سؤال" و"سيناريو الاستخدام المناسب" - هذا الجدول هو الأهم في هذا المقال:

الوضع	العمليات المسموح بها دون سؤال	هل يسألك أولاً؟	السيناريو الأنسب
default	القراءة فقط فقط	تعديل الملفات وتشغيل الأوامر تتطلب سؤالاً	المبتدئون، المهام الحساسة
acceptEdits	القراءة فقط + تعديل الملفات + أوامر نظام الملفات الشائعة (mkdir، mv، cp وغيرها)	تعديل الملفات وأوامر نظام الملفات المذكورة لا تتطلب سؤالاً، بينما أوامر Bash الأخرى تتطلب سؤالاً	مراجعة وتعديل الأكواد الحالية
plan	القراءة فقط فقط (البحث والدراسة واقتراح الحلول دون تعديل الكود المصدري)	نفس قواعد التنبيه في وضع default	استكشاف المشروع ووضع الخطط قبل البدء بالتعديل
auto	جميع العمليات مع فاحص أمان خلفي	لا يسأل غالباً، ويقوم الفاحص بمنع التجاوزات	المهام الطويلة، تقليل المقاطعات (نسخة تجريبية)
dontAsk	الأدوات المعتمدة مسبقاً فقط	لا يسأل ولا يتوقف، ويتم رفض الأدوات غير المعتمدة مباشرة	بيئات CI البرمجية، النصوص المؤتمتة المغلقة
bypassPermissions	جميع العمليات مع تخطي كافة الفحوصات	لا يسأل على الإطلاق	الحاويات المعزولة والأجهزة الافتراضية فقط

لنوضح النقاط الأكثر إرباكاً للمبتدئين:

وضع plan (وضع التخطيط) ليس تساهلاً، بل هو الأكثر تقييداً. فهو يسمح لـ Claude بقراءة الملفات وتشغيل أوامر القراءة فقط لفهم حالة المشروع، ثم تقديم خطة بعنوان "أقترح التعديل بهذه الطريقة"، ولكنه لن يغير حرفاً واحداً في كودك المصدري. عند استلام أي مشروع جديد، يُنصح دائماً بالبدء بوضع plan ليدرسه أولاً، وهو أكثر أماناً من تركه يعدل مباشرة بشكل عشوائي.

وضع acceptEdits هو الخيار الأنسب للتطوير اليومي. فهو يوافق تلقائياً على تعديلات الملفات في دليل العمل وأوامر نظام الملفات الشائعة (mkdir، touch، rm، rmdir، mv، cp، sed)، ولكن أوامر shell الأخرى والكتابة خارج دليل العمل ستتطلب موافقتك. هذا يعني "عدل الأكواد دون الحجة للموافقة في كل مرة، مع الحفاظ على الحماية للعمليات الخطيرة".

يبدو وضع auto ووضع bypassPermissions متشابهين في 'عدم السؤال'، ولكن الأمان بينهما مختلف تماماً. وضع auto هو نسخة تجريبية يعتمد على نموذج تصنيف مستقل يفحص كل عملية قبل تشغيلها، ويمنع العمليات المتجاوزة (مثل curl | bash، أو الرفع إلى main، أو حذف التخزين السحابي)； أما وضع bypassPermissions فهو مكشوف تماماً ولا يحمي حتى من هجمات حقن التعليمات (prompt injection). يذكر التوثيق الرسمي بوضوح:

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

لذلك، إذا أردت "راحة البال مع الحفاظ على الأمان"، فاستخدم auto أولاً، ولا تذهب مباشرة إلى bypassPermissions.

💡 خلاصة سريعة: وضع default يسأل عن كل خطوة، acceptEdits يعدل الكود دون سؤال، plan يقرأ ولا يعدل، auto محمي بنموذج تصنيف، و bypassPermissions مكشوف تماماً - تذكر هذا التدرج من الأكثر صرامة إلى الأكثر تساهلاً واختر ما يناسبك.

توضح هذه الصورة ترتيب الأوضاع الستة على طيف "من الأكثر صرامة إلى الأكثر تساهلاً": المنطقة الخضراء على اليسار تمثل وضع plan / default (قراءة فقط، وسؤال عند كل خطوة، وهي الأكثر أماناً)، ثم نمر بـ acceptEdits (تعديل الكود دون سؤال) و auto (فاحص الأمان الخلفي)، وصولاً إلى المنطقة الحمراء على اليمين bypassPermissions (مكشوف تماماً) - كلما اتجهت يميناً زادت درجة اللون الأحمر لتنبيهك بضرورة الانتباه للمكان الذي تستخدم فيه هذا الوضع.

---

03 التبديل بين الأوضاع: Shift+Tab للتنقل الدائري بنقرة واحدة

بعد معرفة الأوضاع، كيف يتم التبديل؟ الاختصار الأكثر استخداماً هو: Shift+Tab.

بالضغط على Shift+Tab أثناء الجلسة، ستتنقل بين الأوضاع الثلاثة بشكل دائري:

default ← acceptEdits ← plan ← (اضغط مجدداً للعودة إلى default)

يمكنك معرفة الوضع الحالي من خلال شريط الحالة. على سبيل المثال، عند الانتقال إلى وضع acceptEdits، سيظهر في شريط الحالة ⏵⏵ accept edits on.

انتبه إلى تفصيل رسمي مهم حتى لا تبحث طويلاً عن الأوضاع الأخرى: التنقل الافتراضي يحتوي فقط على الأوضاع الثلاثة default / acceptEdits / plan. أما الأوضاع الثلاثة الأخرى فيتم الدخول إليها بطرق مختلفة: يظهر وضع auto في حلقة التنقل تلقائياً بعد استيفاء الحساب للشروط؛ ويتطلب وضع bypassPermissions بدء التشغيل باستخدام معلمات مثل --permission-mode bypassPermissions؛ بينما لا يظهر وضع dontAsk أبداً في حلقة التنقل، ويمكن تعيينه فقط عبر معلمة التشغيل --permission-mode dontAsk (سنشرح ذلك أدناه).

تشبيه: مفتاح كتم الصوت في الهاتف (رنين / اهتزاز / صامت). بالضغط على المفتاح الجانبي للهاتف، تتنقل بين هذه الأوضاع الثلاثة. اختصار Shift+Tab هو هذا المفتاح في Claude Code، ودورته هي "السؤال عن كل خطوة / التعديل دون سؤال / القراءة فقط".

إذا كنت لا تريد تغيير الوضع يدوياً في كل مرة، يمكنك تثبيته بطريقتين:

الطريقة الأولى: تحديد المعلمة عند بدء التشغيل (تطبق على الجلسة الحالية فقط):

claude --permission-mode plan

يمكنك استبدال plan بأي وضع آخر مثل acceptEdits أو dontAsk. وضع bypassPermissions يعتبر خاصاً - حيث تتكافأ الصيغتان --permission-mode bypassPermissions و --dangerously-skip-permissions، ولكن يُفضل استخدام الصيغة الثانية التي تحتوي على كلمة تحذيرية، وسنفصل ذلك في القسم 05.

الطريقة الثانية: كتابته كوضع افتراضي في settings.json (يطبق عند كل تشغيل). في ملف .claude/settings.json الخاص بمشروعك:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

⚠️ قيد رسمي مهم: عند تعيين defaultMode إلى "auto"، سيتم تجاهل الإعدادات الخاصة بالمشروع والإعدادات المحلية (لمنع المستودعات من تفعيل الوضع التلقائي سراً)، وتفعيل auto افتراضياً يتطلب كتابته في ملف الإعدادات على مستوى المستخدم ~/.claude/settings.json.

ممارسة موصى بها: عدم تثبيت الوضع داخل المشروع، والاعتماد على التبديل اليدوي باستخدام Shift+Tab. لأنه في نفس المشروع، قد ترغب أحياناً في تركه يعمل بحرية (وضع acceptEdits)، وأحياناً أخرى ترغب فقط في الحصول على خطة عمل (وضع plan)، وتثبيته قد يكون مزعجاً. يتم استخدام defaultMode عادة فقط عندما تريد فرض الصرامة كخيار افتراضي لحماية المشروع.

💡 خلاصة سريعة: الضغط على Shift+Tab في الجلسة ينقلك بين "السؤال عن كل خطوة / التعديل دون سؤال / القراءة فقط"، ويعرض شريط الحالة الوضع الحالي؛ وللتثبيت استخدم معلمة بدء التشغيل --permission-mode أو خيار defaultMode في ملف settings.json.

---

04 التحكم الدقيق بالصلاحيات: قواعد allow / ask / deny الثلاثة

الأوضاع تمثل "التحكم العام". أما التحكم الدقيق الذي يحدد "هذا الأمر مسموح والآخر ممنوع تماماً" فيعتمد على القواعد الثلاثة في ملف settings.json.

تؤدي كل قاعدة في النهاية إلى أحد الإجراءات الثلاثة التالية:

الإجراء	التأثير	الاستخدام النموذجي
allow	السماح التلقائي دون طلب موافقة	العمليات عالية التكرار ومنخفضة المخاطر، مثل git status أو npm run build
ask	إظهار تنبيه لطلب موافقتك	العمليات المتوسطة المخاطر التي تريد تأكيدها، مثل git push
deny	المنع المباشر دون تنفيذ أو تنبيه	العمليات الخطيرة التي تريد منعها تماماً، مثل rm -rf أو قراءة .env

الأولوية هي قاعدة حديدية: deny ← ask ← allow، حيث تفوز أول قاعدة مطابقة. لذلك فإن قواعد deny تتفوق دائماً على القواعد الأخرى - إذا كتبت نفس القاعدة في allow و deny، فستكون الكلمة لـ deny. هذا التصميم منطقي جداً: "المنع" يجب أن يكون له وزن أكبر من "السماح".

تُكتب القواعد بصيغة اسم_الأداة أو اسم_الأداة(المحدد). انظر إلى الأمثلة التالية لفهم ذلك:

القاعدة	ما تطابقه
Bash	جميع أوامر Bash
Bash(npm run build)	تطابق هذا الأمر الدقيق npm run build فقط
Bash(npm run *)	تطابق الأوامر التي تبدأ بـ npm run (مثل build و test...)
Read(./.env)	قراءة ملف .env في الدليل الحالي
WebFetch(domain:github.com)	جلب طلبات الشبكة الخاصة بموقع github.com

تحتوي علامة النجمة * على فخ للمبتدئين يتعلق بالمسافات الفارغة، وقد ركز عليه التوثيق الرسمي:

تطابق الصيغة Bash(ls *) الأمر ls -la ولكنها لا تطابق lsof، بينما تطابق الصيغة Bash(ls*) كلا الأمرين.

اختلاف وجود مسافة واحدة يغير المعنى تماماً. تتطلب الصيغة ls * (مع مسافة) وجود مسافة بعد ls، ولذا لم تطابق lsof؛ بينما الصيغة ls* (بدون مسافة) تطابق كلا الأمرين بما في ذلك lsof. إذا أردت الدقة، فاستخدم المسافات.

تبدو التهيئة الكاملة للملف كما يلي - السماح بـ npm و git commit، مع منع git push تماماً:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

نقطة أمان أخيرة يجب التركيز عليها: قواعد deny الخاصة بـ Read / Edit لا تمنع "القراءة والكتابة الملتوية" داخل العمليات الفرعية لـ Bash.

ماذا يعني ذلك؟ إذا كتبت deny: Read(./.env) لمنع Claude من قراءة ملف .env مباشرة، وقام بتشغيل كود Python مثل open('.env').read()، فلن تتمكن قاعدة deny من منعه - لأن هذه العملية تتم عبر عملية فرعية (sub-process) لقراءة الملف، ولا تمر عبر أدوات ملفات Claude المضمنة. يحذر التوثيق الرسمي من ذلك:

لا تنطبق هذه القواعد على العمليات الفرعية العشوائية التي تقرأ أو تكتب الملفات بشكل غير مباشر، مثل نصوص Python أو Node التي تفتح الملفات بنفسها. للحصول على منع على مستوى نظام التشغيل يمنع كافة العمليات من الوصول إلى المسارات، يرجى تفعيل البيئة الرملية (sandbox).

هذه النقطة قد تكون مفاجئة للبعض - حيث يعتقدون أن تعيين deny لملف .env كافٍ لحمايته. لذلك لحماية الملفات الحساسة بشكل كامل، يجب دمج قواعد الصلاحيات مع البيئة الرملية (Sandbox) لتوفير دفاع عميق (البيئة الرملية توفر عزلًا على مستوى نظام التشغيل، وسنفصل ذلك في المقال القادم "الأمان").

💡 خلاصة سريعة: تطبق الأولوية بترتيب deny ← ask ← allow وقواعد deny هي الأقوى؛ انتبه لوجود المسافة الفارغة في القواعد； وقواعد deny لا تمنع قراءة الملفات عبر البرمجيات النصية الملتوية، لذا يجب استخدام البيئة الرملية للملفات الحساسة.

---

05 تساهل مع المشاريع الجانبية وتقييد مع مشاريع الإنتاج: نموذجان جاهزان + الخط الأحمر لـ "الوضع الخطير"

بعد شرح الآليات، يمكن تلخيص التطبيق في جملة واحدة: كلما كان المشروع "جانبياً أو للتجربة" يمكنك التساهل، وكلما كان "للإنتاج" يجب التقييد.

إليك نموذجين جاهزين للتهيئة، اختر منهما ما يناسب طبيعة مشروعك.

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

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

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

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

تذكر عند كتابة قواعد deny هذه: كما ذكرنا في القسم السابق، فإن deny لا يمنع قراءة الملفات عبر البرمجيات النصية الملتوية، ولحماية بيئة الإنتاج بشكل كامل يجب إضافة البيئة الرملية (sandbox) بجانب هذه القواعد. لا تعتمد على قواعد deny وحدها كجدار حماية لا يمكن اختراقه.

أخيراً، نتحدث عن الخط الأحمر، وهو بطل المحادثة في البداية - معيار التشغيل --dangerously-skip-permissions (المكافئ لوضع bypassPermissions).

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

استخدم هذا الوضع فقط في البيئات المعزولة (مثل الحاويات، أو الأجهزة الافتراضية VM، أو حاويات التطوير dev containers الخالية من الوصول إلى الإنترنت) حيث لا يمكن لـ Claude Code إلحاق الضرر بنظامك المضيف.

يمكنك اعتماد هذه القواعد الحديدية مباشرة:

السيناريو	هل تجرؤ على تشغيل --dangerously-skip-permissions؟
حاوية معزولة / جهاز افتراضي VM / حاوية تطوير dev container	✅ نعم، لأن البيئة المحذوفة مؤقتة
بيئات CI لتشغيل المهام المؤقتة	✅ نعم، مع إضافة طبقة حماية باستخدام deny
جهازك المحلي للتطوير اليومي	❌ لا، يُفضل العمل ببطء مع وجود حماية
الأجهزة التي تحتوي على أكواد الإنتاج للشركة	❌ لا مطلقاً، فهذا خطر كبير

هناك ميزتا أمان صممهما النظام لزيادة الطمأنينة: الأولى هي أنه حتى في هذا الوضع، فإن العمليات مثل rm -rf / و rm -rf ~ التي تحذف دليل الجذر أو الدليل الرئيسي ستتطلب موافقتك كقاطع أمان ضد الأخطاء غير المقصودة؛ والثانية هي أن النظام يرفض العمل بصلاحيات root أو sudo عند تفعيل هذا الوضع على أنظمة Linux / macOS. ولكن لا تعتمد بالكامل على هذه الميزات - الأصل هو "تشغيل هذا الوضع فقط في البيئات المعزولة التي لا تخشى حذفها".

💡 خلاصة سريعة: استخدم acceptEdits لتسريع مشاريع التجربة، و default لمشاريع الإنتاج، والنموذجان جاهزان للنسخ؛ أما معيار --dangerously-skip-permissions فلا يتم تفعيله إلا في الحاويات المعزولة، ويُمنع تماماً على الأجهزة المحلية وأجهزة الإنتاج.

---

06 ابدأ العمل: 5 دقائق لإعداد أول قاعدة صلاحيات لك

التعلم بالعمل هو الأفضل. سنقوم الآن بإعداد قواعد صلاحيات لمشروع تجريبي، لتشاهد بنفسك كيف تؤثر قواعد allow و deny. لا يتطلب هذا الأمر أي بيئات معقدة.

الخطوة الأولى: إنشاء مشروع تجريبي وملف التهيئة (على أنظمة Mac / Linux / Windows)

mkdir perm-demo
cd perm-demo
mkdir .claude

النتيجة المتوقعة: وجود دليل باسم perm-demo ويحتوي على دليل فرعي فارغ باسم .claude. عند كتابة ls -a أو dir ستلاحظ وجود .claude.

الخطوة الثانية: كتابة ملف settings.json

باستخدام محررك المفضل، اكتب في ملف perm-demo/.claude/settings.json ما يلي:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

معنى هذه القواعد: السؤال عند كل خطوة افتراضياً، مع السماح بـ git status دون سؤال، ومنع git push تماماً.

الخطوة الثالثة: تشغيل Claude والتحقق من القواعد

claude

بمجرد الدخول، اكتب:

/permissions

النتيجة المتوقعة: ستظهر واجهة إدارة الصلاحيات، وستشاهد القواعد التي كتبتها للتو - حيث يظهر git status * في قائمة Allow، ويظهر git push * في قائمة Deny، مع الإشارة إلى أنها محملة من ملف settings.json. رؤية هاتين القاعدتين تعني أن الإعدادات تم تحميلها بشكل صحيح.

الخطوة الرابعة: التحقق من عمل قاعدة deny لمنع العمليات

اطلب منه تنفيذ عملية ممنوعة في صندوق الإدخال:

ساعدني في تشغيل git push origin main

النتيجة المتوقعة: لن يقوم Claude بالتنفيذ، ولن يظهر تنبيه "هل توافق على التشغيل" - بل سيخبرك مباشرة أن هذه العملية تم رفضها بسبب قواعد الصلاحيات. هذه هي قوة قاعدة deny: لا تنفيذ ولا تنبيه، منع مباشر.

الخطوة الخامسة: التحقق من سلاسة قاعدة allow

اطلب منه الآن تنفيذ عملية مسموح بها:

ساعدني في الاطلاع على git status

النتيجة المتوقعة: نظراً لمطابقة القاعدة allow: Bash(git status *)، سيتم التشغيل مباشرة دون إظهار تنبيه الموافقة (بما أن الدليل ليس مستودع git بعد، فقد يظهر أمر git خطأ يفيد بأنه "ليس مستودع git"، ولكن هذا يخص أداة git - الأهم هنا هو أنه لم يتوقف ليسألك، مما يعني نجاح عمل قاعدة allow).

بإتمام هذه الخطوات الخمس، تكون قد تحققت بنفسك من الدورة الكاملة لـ "كتابة القواعد ← تحميلها ← منع deny ← سماح allow". مستقبلاً، أي تهيئة صلاحيات ستقوم بها ستكون قائمة على إضافة قواعد إلى هذه الآلية.

💡 خلاصة سريعة: أنشئ ملف .claude/settings.json واكتب القواعد، واستخدم /permissions للتأكد من تحميلها، ثم اطلب من Claude تشغيل أمر ممنوع وآخر مسموح - تجربة هذه الدورة بنفسك أفضل من حفظ عشرات القواعد البرمجية.

---

07 ملخص

في هذا المقال، قمنا بشرح نظام صلاحيات Claude Code بالتفصيل - ما مدى التساهل أو التقييد، القرار لك بالكامل عبر بضعة أسطر من التهيئة.

لنراجع النقاط الأساسية معاً:

هدفك	الأداة المستخدمة	نقاط أساسية
ضبط "معدل تكرار السؤال"	أوضاع الصلاحيات الستة	طيف يبدأ من default (السؤال عند كل خطوة) وينتهي بـ bypassPermissions (مكشوف تماماً)
التبديل السريع أثناء الجلسة	Shift+Tab	تنقل دائري بين الأوضاع الثلاثة default / acceptEdits / plan
تثبيت الوضع الافتراضي	defaultMode	يكتب في ملف settings.json؛ وتفعيل auto يتطلب كتابته على مستوى المستخدم
التحكم الدقيق في عملية فردية	allow / ask / deny	ترتيب الأولوية deny هو الأقوى دائماً
حماية الملفات الحساسة	deny + البيئة الرملية	قاعدة deny وحدها لا تمنع قراءة الملفات عبر البرمجيات النصية الملتوية

يمكنك الآن: فهم أوضاع الصلاحيات الستة ومتى تستخدمها، والتبديل بينها باستخدام Shift+Tab بكل سهولة، وكتابة قواعد allow / deny للأدوات والأوامر في ملف settings.json لتناسب كلاً من مشاريع التجربة ومشاريع الإنتاج، ومعرفة أن الخط الأحمر --dangerously-skip-permissions لا يتم تفعيله إلا في البيئات المعزولة. هذا التحكم المرن يمنحك الثقة لترك Claude يعمل دون القلق من حدوث أخطاء غير متوقعة.

---

المقال القادم 21 "الأمان وحدود المخاطر" - تعلمنا في هذا المقال "كيفية تهيئة الصلاحيات"، ولكن التهيئة هي مجرد أداة، والسؤال الأهم هو: هل يجب حقاً الوثوق بـ AI للوصول إلى أكوادك ونظامك؟ ما هي السيناريوهات الأكثر خطورة؟ وكيف تبدو هجمات حقن التعليمات وتسريب البيانات الحساسة؟ الآن وقد أصبحت الصلاحيات بيديك، سنناقش في المقال القادم "متى يجب التقييد ومتى يمكن التساهل".

---

قراءات موصى بها

• دليل استخدام CLAUDE.md: كتابة قواعد المشروع في ذاكرة النموذج
• حل المشكلات الشائعة (FAQ / Troubleshooting)
• Agent Skills: تزويد Claude بمهارات تخصصية جاهزة للاستدعاء