الأذونات و plan mode والبقاء مسيطرًا

هذا عادةً أول سؤال يطرحه أي شخص، وهو يستحق جوابًا مباشرًا: لا، لا يعيد Claude ترتيب ملفاتك بصمت. فهو افتراضيًا يتوقّف ويسأل — نافذة موافقة أو رفض داخل المحادثة مباشرة — قبل أن يغيّر أي شيء أو ينفّذ أمرًا. والإعداد الذي توصي به الوثائق للمستخدمين الجدد اسمه Ask permissions، وهو يفعل ما يقوله اسمه بالضبط، في كل مرة، حتى تقرّر خلاف ذلك.

ومعظم اللبس في هذا الباب يتبدّد بمجرد أن تلاحظ وجود مؤشّرين منفصلين، لا مؤشّر واحد. الأول هو كم مرة يتوقّف Claude ليسأل. والثاني هو هل يقترح Claude نهجًا قبل أن يبدأ أي عمل أصلًا. يبدوان السؤال نفسه وهما ليسا كذلك، ولهذا يوجد دليل المقارنة أدناه.

مؤشّر السؤال

هناك خمسة أوضاع؛ ثلاثة منها تغطّي كل يوم عادي تقريبًا، وتتنقّل بينها من محدِّد الوضع في التطبيق — بلا ملف إعدادات، وبلا شيء تحفظه.

• Ask permissions — الطرف الحذر. كل ما يغيّر العالم ينتظر نقرة. وهو الوضع الصحيح للعمل غير المألوف، ولمشروع لا تعرفه، ولكل ما ستأسف على إعادته.
• auto mode — الوسط الصادق. يمرّر مصنّفٌ الأشياءَ الآمنة المملّة (القراءات، الاختبارات، فحوص الحالة) ويظلّ يتوقّف عند أي شيء قد يسبّب ضررًا حقيقيًا، فتسير المهمة الطويلة دون أن تجالس كل خطوة فيها. وله متطلّبات تخصّ الحساب والـ model، فليس متاحًا دائمًا.
• Accept edits — الوسط الذي ينساه الناس. يعدّل Claude الملفات بحرّية لكنه ما زال يسأل قبل تنفيذ الأوامر أو الوصول إلى الشبكة. يناسب فترة طويلة كثيفة التعديل تكون شبكة أمانك الحقيقية فيها هي قدرتك على إعادة الملفات كما كانت، وهو جواب أفضل بكثير من وضع سريع حين تكون الضوضاء التي تهرب منها هي تحديدًا نوافذ التعديل.
• الـ plan mode — المؤشّر الآخر، وتجده أدناه.
• Bypass permissions — تخطّي كل موافقة، بلا أيّ فحص أمان. وهو flag من مسار Power Track مخصّص للـ sandboxes القابلة للإتلاف وللأتمتة المقيَّدة في headless mode، واسمه المقلق ليس زينة.

والقاعدة التي تبقيك بعيدًا عن المتاعب قصيرة: اختر أبطأ وضع تحتمله، لا أسرع وضع تستطيع الإفلات به. فالوضع الأبطأ يلتقط أخطاءً أكثر؛ والأسرع يقايض معدّل الالتقاط بالاندفاع، ومعدّل الالتقاط أثمن في معظم الأحيان. مشروع جديد، أو كود مشترك، أو أيّ شيء يتعلّق به مال ← Ask permissions. وفترة طويلة من عمل روتيني تثق به ← auto mode. والغريزة في كل ذلك هي شدّ قبل أن ترخي: ابدأ حذرًا، ودع كل إجراء يكسب حقّه في العمل وحده. ولأن الأذونات محدّدة النطاق لكل مشروع، يستطيع repository بالكاد تثق به أن يبقى صارمًا بينما يعمل sandbox على وسعه.

ضع المملّ في allowlist بدل أن ترخي الوضع

ثمّة إخفاق يبدو كفاءةً وليس كذلك. بعد بضع جلسات تكون قد وافقت على «اعرض الملفات» أربعين مرة وعلى «أرِني ما تغيّر» ثلاثين، وكففت عن قراءتها. والخطر ليس الثواني الضائعة — بل أنك متى كففت عن قراءة النوافذ المملّة، كففت عن قراءة المهمّة أيضًا.

والعلاج ليس وضعًا أسرع، لأن الوضع الأسرع يُسقط كل السؤال دفعةً واحدة — الإجراءات المخيفة مع البليدة. العلاج allowlist: الإجراءات المملّة المحدّدة التي يجوز لـ Claude أن ينفّذها دون سؤال مجدّدًا، مع بقاء كل ما عداها يتوقّف عند النافذة.

وتبنيها نقرةً نقرة. فكلما اخترت Always allow على إجراء غير مؤذٍ حقًّا، كانت تلك الـ allowlist تنمو؛ وهي ليست أكثر من السجلّ الجاري لقرارات «دائمًا» التي اتخذتها.

الـ allowlist الجيّدة تجعل النوافذ التي تراها مستحيلة التجاهل.

ومحكّ إضافة شيء إليها: هل كنت سأفعل هذا بنفسي دون تفكير؟ إن كان الجواب نعم، فـ Always allow. وإن ترددت ولو لحظة، فوافِق مرةً واحدة واتركه خارجها. والمرشّحون الجيّدون قراءة فقط ومتكرّرون — عرض الملفات، وعرض المحتويات، والبحث، وعرض ما تغيّر، وفحص حالة. أمّا المرشّحون السيّئون فيبقون على النافذة في كل مرة: كل ما يحذف أو ينقل أو يكتب فوق شيء يهمّ؛ وكل ما يشغّل كودك مقابل أنظمة حقيقية أو بيانات حقيقية؛ وكل ما يصل إلى الشبكة؛ وكل ما عرفته بالأمس فقط. ونمِّ القائمة ببطء، إجراءً واحدًا في كل مرة، بعد أن تكون قد رأيته بما يكفي لتعرف أنه آمن في كل موضع قد تسمح له فيه.

أين تقيم الـ allowlist فعلًا

يستحقّ أن تعرف أن القائمة ملف حقيقي، لأن هذا ما يجعلها قابلة للمشاركة بدل أن تكون فولكلورًا شخصيًا. الـ allowlist تقيم في settings.json، وكل «Always allow» نقرتها كانت تكتب سطرًا فيه بهدوء. وهو ليس إعدادًا تؤلّفه من الصفر — بل سجلّ قرارات اتخذتها سلفًا، وصار بإمكانك قراءته وتحريره مباشرةً:

{
  "permissions": {
    "allow": ["Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)"],
    "deny": ["Bash(git push:*)"]
  }
}

ما في allow يعمل دون سؤال. وما في deny لا يعمل ولا يُسأل عنه أصلًا. وما ليس في أيّهما يمرّ بالنافذة المعتادة. ولست بحاجة إلى حفظ صيغة Bash(...) — فالنقر على Always allow يكتبها صحيحةً، ويمكنك أيضًا أن تقول ببساطة «أضِف git status إلى الـ allowlist» في المحادثة.

وهناك ثلاثة ملفات، وفيها الانقسام نفسه بين المشروع والشخصي الذي ستراه في كل مكان في Claude Code:

• .claude/settings.json — في الـ repository، مشترك مع الفريق. القواعد التي ينبغي أن تكون عند الجميع.
• ~/.claude/settings.json — في مجلدك الرئيسي، ينطبق على كل مشروع، ولك وحدك.
• .claude/settings.local.json — داخل المشروع لكنه خاصّ بك (يتجاهله git).

وافتراضيًا يكتب Always allow في ملفك المحلي، كي لا تُفرَض تسهيلاتك الشخصية على الزملاء. ورقِّ القاعدة إلى .claude/settings.json المُلتزَم عن قصد، متى قرّرت أن الفريق كله ينبغي أن يحملها. (وعلى مسار Power Track، يقرأ الـ CLI الملفات نفسها، فما هيّأته على سطح المكتب ينتقل معك — ويستطيع أيضًا أن يأخذ allowlist كـ flag عند الإطلاق، لكن القواعد الدائمة تعيش في هذه الملفات في الحالتين.)

والتحرير اليدوي أسرع من النقر، ما يجعل التهوّر أسهل. والقاعدة أعلاه لا تتغيّر: لا تضع في الـ allowlist إلا ما كنت ستنفّذه بنفسك دون تفكير ثانٍ. الملف يجعل القائمة مرئية؛ ولا يغيّر ما يستحقّ أن يكون فيها.

الـ plan mode

الـ plan mode هو المؤشّر الآخر، وهو الذي يقصّر الناس في استخدامه. في الـ plan mode يكون Claude للقراءة فقط: يدرس المشكلة، ويكتب خطة مرقّمة، ويتوقّف. لم يحدث شيء بعد — أنت توافق على النهج، لا على النتيجة، وخطة تقرأها في عشر ثوانٍ هي أرخص مكان ممكن لالتقاط منعطف خاطئ. اقرأها بعين متشكّكة وجادلها؛ فهذا هو الغرض منها. والمؤشّران يتركّبان جيدًا: خطّط أولًا ليكون النهج صحيحًا، ثم دع الـ auto mode يحمل الخطوات الآمنة من تلك الخطة دون أن يقاطعك.

أمّا كيف تقرأ خطةً كما ينبغي — وكيف يندرج ذلك في الإيقاع الأوسع لعمل أكبر من prompt واحد — فتجده في مهامّ أكبر من أن يتّسع لها prompt واحد.

الثقة بمجلد قرار أكبر من أيّ نافذة مفردة

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

وسبب استحقاق ذلك لوقفة أن المشروع ليس بيانات يقرأها Claude فحسب:

المشروع أيضًا تعليمات يتّبعها Claude — ملف CLAUDE.md، ومجلد .claude/ فيه أوامر وإعدادات، وskills على مستوى المشروع تُحمَّل تلقائيًا.

وهذه موجودة لأسباب وجيهة؛ فهي كيف يدوّن فريق «هكذا نعمل هنا» ليكون Claude نافعًا من الدقيقة الأولى. لكن الآليّة نفسها تعني أن مجلدًا من شخص غريب قد يحمل تعليمات مكتوبة لـ Claude لا لك. واختباء تعليمات معادية أو غير متوقّعة داخل محتوى يقرأه Claude اسمه prompt injection، ونافذة الثقة هي البوّابة أمامه.

كن متعمَّدًا لا مذعورًا. مشاريعك أنت: ثِق بحرّية. ومشاريع فريقك: ثِق، لكن ألقِ نظرة واحدة على CLAUDE.md و.claude/ أول مرة تفتحه. ومجلد غريب من الإنترنت: اقرأ تلك الملفات قبل أن تثق به. وشيء تفحصه تحديدًا لأنه يبدو مريبًا: لا تثق به إطلاقًا — انظر دون أن تسلّم المفاتيح. والغريزة نفسها تنطبق على المحتوى داخل مشروع موثوق: ملف README مسحوب من رابط مشبوه، أو مستند نُزِّل من مكان ما، أو ملاحظة من خارج فريقك. النصّ الذي يقرأه Claude قادر على تغيير ما يفعله Claude.

حدّان لا تغطّيهما هذه الصفحة

أيّ النوافذ تراها سؤال إعدادات. أمّا هل تقول نعم للنافذة التي أمامك فحكم، وله صفحته الخاصة: كيف تقرّر على ماذا توافق — الـ blast radius، والـ one-way doors، وقائمة الفحص التي تستغرق عشر ثوانٍ.

والموافقة على إجراء ليست فهمًا لما فعله. فلحظة القبول أو الرفض لتعديل ملف، واسترجاع تغيير بعد وقوعه، تعيش في رؤية ما غيّره Claude والتراجع عنه. وكل إذن تمنحه هو منح حقيقي للمدى، وهنا تتوقّف بيانات الشركة والخصوصية عن كونها قلقًا مجرّدًا.