الأذونات وأوضاع الأذونات
- ماذا تعني أحكام الأذونات الثلاثة (allow / ask / deny)
- كيف تطابق قواعد الأذونات أداةً مع نمط
- أوضاع الأذونات الستة ومتى تستخدم كل واحد منها
- لماذا أصبح وضع auto الآن الوضع الابتدائي للجلسات التفاعلية — وكيف تعطّله
- كيف يستبدل وضع auto طلبات التأكيد بمصنِّف أمان
- كيف تبني قائمة سماح (allowlist) ابتدائية معقولة تقلّل الطلبات دون أن تفقد الأمان
- أين تخزّن قواعد الأذونات الخاصة بالمشروع والقواعد الشخصية
تحدد الأذونات ما يستطيع Claude Code فعله دون أن يتوقف ليسألك. إذا ضبطتها جيداً حصلت على انسيابية دون فقدان السيطرة؛ وإذا ضبطتها بشكل سيئ فإما أن توافق على كل شيء دون تدقيق أو تغرق في الطلبات.
الأحكام الثلاثة
كل إجراء محتمل ينتهي إلى أحد هذه الأحكام:
تطابق القواعد عادةً أداةً مع نمط، مثل allow للأمر Bash(npm run test:*) أو deny للأمر Read(./.env).
السماح بأداة + نمط
Bash(npm run test:*)
منع أداة + نمط
Read(./.env)
أوضاع الأذونات
يحدد الوضع الموقف العام للجلسة. هناك ستة أوضاع. بدّل بين الشائعة منها بـ Shift+Tab، أو اضبط permissions.defaultMode في الإعدادات.
| الوضع | يعمل دون سؤال | متى تستخدمه |
|---|---|---|
default (يظهر باسم Manual) | القراءة فقط | العمل اليومي، التغييرات الحساسة |
acceptEdits | القراءة، وتعديل الملفات، وأوامر نظام الملفات الشائعة | جلسة تحرير موثوقة ومحددة النطاق جيداً |
plan | القراءة، إضافةً إلى الأوامر التي يوافق عليها المصنِّف عندما يكون وضع auto متاحاً؛ لا يعدّل شيفرتك المصدرية أبداً | المهام الكبيرة أو الخطرة — انظر Plan Mode |
auto (الوضع الابتدائي للجلسات التفاعلية منذ v2.1.283) | كل شيء، بعد فحصه بمصنِّف أمان | المهام الطويلة التي يكون فيها إرهاق الطلبات هو الخطر الحقيقي |
dontAsk | قراءة الملفات في أدلة عملك والأدوات المعتمدة مسبقاً؛ وأي شيء كان سيستدعي طلباً يُرفض | بيئات CI والسكربتات المقفلة |
bypassPermissions | كل شيء، دون أي فحوصات | بيئات العزل/الحاويات فقط — لا تستخدمه أبداً على جهاز يحتوي أسراراً |
وضع auto هو الآن الافتراضي في Claude Code
منذ Claude Code v2.1.283، أصبح auto الوضع الابتدائي المدمج للجلسات التفاعلية في الطرفية وVS Code على كل الخطط ولدى كل المزوّدين. أما في الإصدارات الأقدم فكان الافتراضي للجلسات الجديدة على خطط Pro وMax وTeam فقط، اعتباراً من 14 أغسطس 2026. مبرر Anthropic (من اختباراتها الخاصة على أكثر من 1,000 مستخدم مدفوع): التقط المصنِّف 89% من الإجراءات الضارة مقابل 13.6% للمراجعة اليدوية — لأن المستخدمين الذين اعتادوا الأمر كانوا يقبلون نحو 97% من الطلبات اليدوية دون قراءتها.
استثناءان يحفظان قصدك:
- إذا ضبطتَ أنت
permissions.defaultModeفي إعدادات المستخدم، فسيبقى كما هو ما لم تقبل مرة واحدة رسالة التبديل داخل التطبيق. - إذا كانت مؤسستك تدير الإعداد الافتراضي (الإعدادات المُدارة في Team/Enterprise)، فلن يتغير شيء تلقائياً.
يمكنك دائماً التبديل بين الأوضاع في منتصف الجلسة بـ Shift+Tab. وهناك تغيير ذو صلة سارٍ فعلاً على تلك الخطط: استدعاءات المصنِّف التي يجريها وضع auto لم تعد تُحتسب ضمن حدود استخدامك.
اشترك مبكراً (قبل 14 أغسطس) — اجعل auto الافتراضي لديك
~/.claude/settings.json
{
"permissions": {
"defaultMode": "auto"
}
}ابقَ على سلوك الطلبات القديم بعد 14 أغسطس
~/.claude/settings.json
{
"permissions": {
"defaultMode": "default"
}
}كيف يعمل وضع auto فعلاً
auto هو الحل الوسط بين طلب التأكيد على كل شيء وإيقاف الأمان. فبدلاً من سؤالك، يراجع نموذج مصنِّف منفصل كل إجراء قبل تنفيذه، ويحجب أي شيء يتجاوز ما طلبتَه، أو يمسّ بنية تحتية لا يعرفها، أو يبدو مدفوعاً بمحتوى عدائي قرأه Claude للتو. أما قواعد ask الصريحة فتتوقف وتسألك كالمعتاد.
يحجب أموراً مثل curl | bash، وعمليات force push، وعمليات النشر والترحيل في بيئة الإنتاج، وrm -rf على متغيرات غير محلولة، والعبث بسجل المحادثة، وأوامر git المدمّرة التي تتخلص من عمل غير مُلتزَم به، وإرسال الأسرار إلى نقاط نهاية خارجية — بينما يترك العمل الروتيني (التعديلات المحلية، وتثبيت التبعيات المعلنة، وطلبات HTTP للقراءة فقط، والدفع إلى فرعك الخاص) يمرّ مباشرة. وإذا حجب الإجراء نفسه مراراً، يتوقف وضع auto مؤقتاً ويعيد إليك مسؤولية الطلبات.
وضع auto ليس ضماناً للأمان — فهو يقلّل الطلبات، لكنه لا يُلغي الحاجة إلى مراجعة العمليات الحساسة. يعتمد توافره على خطتك والنموذج، و(في Team/Enterprise) على مفتاح يتحكم به المسؤول. وإذا كنت تعمل فعلاً دون إشراف (cron، جلسات سحابية، CI)، فاقرنه بـ Hardening Autonomous Runs — فما زال auto ليس bypassPermissions.
- مكان bypassPermissions هو بيئة العزل. تشغيل جهازك الحقيقي مع إيقاف كل الطلبات هو ما يجعل الوكيل ينتهي بلمس ما لا ينبغي له. احتفظ به للبيئات التي تُرمى بعد الاستخدام — وإذا كان ما تريده فعلاً هو طلبات أقل، فاستخدم وضع auto بدلاً منه. انظر Hardening Autonomous Runs على /docs/security/hardening-autonomous-runs.
قائمة سماح ابتدائية معقولة
الهدف: السماح مسبقاً بالأمور الآمنة المتكررة؛ وإبقاء المدمِّر منها على ask أو deny.
- قراءة الملفات، وتشغيل أوامر الاختبار/lint/البناء، وgit status/diff.
- تثبيت التبعيات، وكتابة ملفات خارج المشروع، واستدعاءات الشبكة.
- قراءة الملفات السرية (.env، ملفات المفاتيح)، وforce-push، وrm -rf.
خزّن قواعد المشروع في settings.json (مشترك) والتجاوزات الشخصية في settings.local.json.
- دعه يتعلم من طلباتك: وافق على الأمر الآمن نفسه بضع مرات وستعرف بالضبط ما يجب إضافته إلى قائمة السماح — فتتحول الطلبات المتكررة إلى قاعدة تُكتب مرة واحدة.
- ثلاثة أحكام: allow (دون طلب)، ask (الافتراضي — توقّف وأكّد)، deny (أبداً).
- تطابق القواعد أداةً مع نمط، مثل Bash(npm run test:*) أو Read(./.env).
- ستة أوضاع تحدد موقف الجلسة: default (Manual)، acceptEdits، plan، auto، dontAsk، bypassPermissions.
- منذ v2.1.283، auto هو الوضع الابتدائي للجلسات التفاعلية في الطرفية وVS Code على كل الخطط؛ وdefaultMode الذي تضبطه بنفسك يبقى كما هو، والإعدادات الافتراضية التي تديرها المؤسسة لا تُمَسّ.
- يفحص وضع auto كل إجراء بمصنِّف أمان بدلاً من سؤالك — هذه هي الأداة المناسبة لإرهاق الطلبات، وليس bypassPermissions.
- ابنِ قائمة سماح: allow للآمن والمتكرر، وask لمتوسط الخطورة، وdeny للمدمِّر.
- القواعد المشتركة تذهب إلى settings.json؛ والتجاوزات الشخصية إلى settings.local.json.
اختبر نفسك
0/6التالي
- settings.json: نظام الإعدادات
- Hooks — فرض القواعد بشكل حتمي، بما يتجاوز allow/deny
- Sandbox Credential Masking — اسمح لـ
ghوnpmوawsبالمصادقة دون أن يحمل الأمر المعزول السرّ الحقيقي أبداً - الأمان والاستخدام المسؤول