Claude Code 2.1.268: ما الذي أُصلح في قواعد deny وMCP

صدر الإصدار 2.1.268 من Claude Code في 10 سبتمبر 2026، وتلاه الإصدار 2.1.269 في اليوم التالي. ينبغي لك التحديث فورًا: ففي حالتين، لم تكن قواعد deny التي تستخدمها لمنع الوكيل من الوصول إلى .env ومجلدات الخدمات نافذة، من دون أي تنبيه. إضافة إلى ذلك، كان بإمكان الأمر /mcp طباعة أسرار من ملفات الإعدادات في الطرفية.

يستند كل ما يلي إلى سجل التغييرات والوثائق الرسمية من Anthropic كما كانا في 17 سبتمبر 2026، وهو تاريخ المادة المصدرية. كان أحدث إصدار في ذلك التاريخ هو 2.1.274. نصف طريقة عمل الأخطاء بالاستناد إلى تلك الإدخالات؛ ولم تُعَد إعادة إنتاج طرق التجاوز على الإصدار المعرّض للثغرات.

للاطلاع على تعليمات إضافية حول العمل مع Ailoot، راجع الوثائق.

ما الذي أُصلح في Claude Code 2.1.268 و2.1.269؟#

هناك أربعة إصلاحات تخص قواعد الأذونات:

1. لم تعمل حالات المنع على الروابط الرمزية. لم تُفعّل قواعد deny وask المكتوبة لمجلدات مرتبطة رمزيًا (/etc و/tmp و/var على macOS، و/bin على Linux) عندما جرى تحديد المسار بموقعه الحقيقي. كما تجاهلت أوامر Bash قواعد deny المكتوبة لمسار عبر رابط رمزي.
2. فشل المنع عند القراءة والتحرير مع env -C أو eval. إذا احتوى سطر الأوامر نفسه على صياغة تعذّر على فحص الأذونات تحليلها، فقد لا تُفعّل قاعدة deny على Read أو Edit.
3. طُبقت قاعدة تحتوي على “!” على نطاق أوسع من المقصود. كانت قاعدة deny أو ask التي تبدأ بـ ! تُطبّق خارج ملف الإعدادات الذي كُتبت فيه. أصبحت الآن تُطبّق ضمن نطاق مصدرها فقط، ويُتجاهل النفي المنفرد !.
4. تجاوز tee حالات المنع عند الكتابة. لم تُطبّق قواعد deny الخاصة بـ Edit() وفحص مسار الكتابة على ملف أنشأه أمر Bash tee. ولم يعد الإذن Bash(tee:*) يشمل الكتابة خارج مجلدات العمل.

أصلحت هذه الإصدارات أيضًا مشكلتين تتعلقان بكشف الأسرار. لم يعد WebFetch ينتظر إلى ما لا نهاية ردًا من خادم يُبقي الاتصال مفتوحًا: يفشل الطلب الآن بعد 300 ثانية، ويمكن ضبط المهلة باستخدام المتغير CLAUDE_CODE_WEBFETCH_DEADLINE_MS. كما أُزيل الاستخدام المرتفع المستمر لوحدة المعالجة المركزية في الجلسات الطويلة الخاملة.

كيف تعمل حالات المنع في Claude Code؟#

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

تُخزَّن القواعد في ثلاثة مواضع: قواعد المستخدم في ~/.claude/settings.json، وقواعد المشروع في .claude/settings.json داخل المستودع، والقواعد المحلية في .claude/settings.local.json. إليك مثالًا على إعدادات تمنع قراءة ملف يحتوي على مفاتيح:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

يمكنك الاطلاع على جميع القواعد النشطة والملف الذي جاءت منه كل قاعدة بتشغيل /permissions في جلسة. إذا منعت قاعدةٌ القراءة، فسيذكر إشعار المنع اسم القاعدة، وهذا مفيد للفحص أدناه.

ما الأخطاء التي أثرت في حالات المنع ونطاق القواعد؟#

أثرت الأخطاء في فحوص المسارات والأوامر، وكذلك في نطاق القواعد الواردة من ملفات إعدادات مختلفة.

الحالة الأولى: الروابط الرمزية. على macOS، تُعد /etc و/tmp و/var روابط رمزية إلى مجلدات حقيقية ضمن /private؛ وعلى Linux، غالبًا ما يكون /bin رابطًا رمزيًا مشابهًا. إذا كتبت قاعدة deny بصيغة لمسار معيّنة، لكن الوكيل وصل إليه باستخدام صيغة أخرى (مثل موقعه الحقيقي بدلًا من الرابط الرمزي)، فلن تُفعّل القاعدة. كما تجاهلت أوامر Bash قاعدة منع مكتوبة لمسار عبر رابط رمزي. أُصلحت الحالتان في 2.1.268: تنطبق القاعدة الآن بصرف النظر عن صيغة المسار المستخدمة.

الحالة الثانية: env -C وeval في السطر نفسه. يحلل فحص الأذونات أمرًا لتحديد الملفات التي سيصل إليها. ويتعذر عليه تحليل صيغ مثل env -C أو eval. تمثلت المشكلة في أنه عند ظهور صيغة كهذه في السطر، قد لا تُطبّق قاعدة deny على Read أو Edit. ونتيجة لذلك، كان بإمكان الأمر تجاوز المنع المفروض على قراءة ملف محمي أو تحريره.

الحالة الثالثة: تجاوزت قاعدة تحتوي على “!” حدودها. يُفترض أن تنطبق القاعدة التي تبدأ بـ ! داخل ملف الإعدادات الذي كُتبت فيه فقط. قبل 2.1.269، كانت تُطبّق أيضًا على مصادر إعدادات أخرى. أصبح نطاقها الآن مقتصرًا على ملفها، ويُتجاهل أيّ قاعدة تتكون من ! منفردة.

الحالة الرابعة: الكتابة عبر tee. يمكن لأمر Bash tee الكتابة إلى ملف. ولم يُطبَّق فحص مسار الكتابة ولا قواعد deny الخاصة بـ Edit() على ذلك الملف. وفي الوقت نفسه، كان الإذن Bash(tee:*) يشمل الكتابة خارج مجلدات العمل. في 2.1.269، بدأ تطبيق هذه الفحوص على الكتابة عبر tee: يسري المنع المفروض على الملف، ولا يشمل Bash(tee:*) إلا مجلدات العمل.

إذا كنت تستخدم حالات منع محددة الهدف — لمنع الوصول إلى .env أو بضعة مجلدات خدمات أو أوامر خطرة — فينبغي لك فحصها أيضًا. الخطوات موضحة أدناه.

لماذا كان بإمكان /mcp إظهار مفاتيحك؟#

غالبًا ما تحفظ إعدادات خوادم MCP المفاتيح في متغيرات البيئة وتشير إليها عبر ${VAR}، بحيث يمكن حفظ الملف في مستودع من دون تضمين الأسرار نفسها. تمثلت المشكلة في أن أوامر العرض (/mcp و/plugin وclaude mcp list وclaude mcp get) ورسائل أخطاء تسجيل الدخول إلى MCP كانت تعرض الإعدادات بعد استبدال المتغيرات بقيمها. وكان المفتاح نفسه يظهر على الشاشة.

يتعلق إصلاح آخر بأخطاء الإضافات والأسواق: إذ كان بإمكانها عرض رمز مميز أو كلمة مرور من عنوان URL لمصدر Git.

إذا ظهر ناتج /mcp أو claude mcp list من إصدار أقدم في بث مباشر أو لقطة شاشة أو رسالة إلى زميل أو سجل خرج من جهازك، بما في ذلك الخروج تلقائيًا، فافترض أن مفاتيح إعدادات MCP قد كُشفت وغيّرها. إذا لم يغادر الناتج جهازك قط، فيكفي التحديث. لدينا دليل منفصل عن خوادم MCP والإعدادات الجاهزة: خوادم Claude Code MCP.

تغييرات أخرى في هذه الإصدارات#

WebFetch والآثار المنشورة. في السابق، كانت قاعدة WebFetch من دون تفاصيل في deny أو ask تنطبق أيضًا على قراءة الآثار المنشورة وتعديلها. بدءًا من 2.1.268، لم تعد تنطبق عليها. لحظر الآثار، تحتاج إلى قاعدة Artifact منفصلة أو قاعدة للنطاق، مثل WebFetch(domain:claude.ai). إذا كنت تعتمد على منع عام لـ WebFetch للحماية من قراءة الآثار، فأعِد فحص إعداداتك: لم تعد القاعدة السابقة تمنع هذه الإجراءات.

أصبح لدى WebFetch حد زمني. يفشل الآن الطلب إلى خادم يُبقي الاتصال مفتوحًا ولا يُكمل رده بعد 300 ثانية. في السابق، كان مثل هذا الطلب قد يظل معلقًا إلى أجل غير مسمى. يمكن ضبط السلوك باستخدام المتغير CLAUDE_CODE_WEBFETCH_DEADLINE_MS؛ ويؤدي ضبطه على 0 إلى تعطيل المهلة.

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

ثبّت أحدث إصدار. ظهر خطأ جديد في 2.1.269: بعد تشغيل الجلسة مدة طويلة، بدأت أوامر Bash الخاصة بـ Git التي تكتفي بقراءة البيانات تطلب الإذن. أُصلح هذا الخطأ في 2.1.270. لذا حدّث إلى أحدث إصدار (كان 2.1.274 في 17 سبتمبر 2026)؛ ولا تتوقف عند 2.1.268 أو 2.1.269.

كيف تحدّث وتتحقق من عمل حالات المنع؟#

1. تحقق من إصدارك الحالي. شغّل claude --version في الطرفية. صدرت إصلاحات المشكلات الموضحة أعلاه في 2.1.268 و2.1.269. إذا كان رقم الإصدار أقل من 2.1.268، فهذا يعني أن إصدارك لا يتضمن هذه الإصلاحات بعد، مع أن انطباق كل مشكلة يعتمد على المسارات والأوامر والقواعد التي تستخدمها.
2. حدّث البرنامج. يحتوي دليل كيفية تحديث Claude Code إلى أحدث إصدار على تعليمات خطوة بخطوة وإرشادات لاستكشاف الأخطاء وإصلاحها. اختر أحدث إصدار، ولا تتوقف عند 2.1.268.
3. اختبر المنع. لا تختبر قاعدة على ملف .env حقيقي؛ فإذا فشل المنع، فسيطّلع الوكيل على مفاتيح حقيقية. أنشئ ملف اختبار، مثل secret-test.txt، يحتوي على أي نص مثل «هذا اختبار»؛ وأضف القاعدة "Read(./secret-test.txt)" إلى قائمة deny في .claude/settings.json الخاص بالمشروع؛ وأعِد تشغيل الجلسة؛ ثم اطلب: «اقرأ الملف secret-test.txt وأخبرني بما يحتويه.» السلوك المتوقع هو ظهور إشعار منع يذكر قاعدتك. إذا قرأ الوكيل الملف، فهذا يعني أن المنع لم يعمل في هذا الاختبار. ابدأ بالتحقق من الصياغة في القسم أعلاه، وافتح /permissions للاطلاع على القواعد النشطة والملفات التي حُمّلت منها. لا تحدد نتيجة الاختبار وحدها السبب. يثبت اختبار قاعدة واحدة أن القاعدة الخاصة بهذا الملف تعمل، لكنه لا يخبرك بشيء عن قواعدك الأخرى؛ لذا افحصها واحدة تلو الأخرى بالطريقة نفسها.
4. تحقق من حالة الروابط الرمزية إذا كنت تستخدم مسارات كهذه. إذا كانت لديك قواعد منع لـ /tmp أو /etc أو /var على macOS، أو لـ /bin على Linux، فأعِد الاختبار لهذه المسارات بعد التحديث.
5. راجع القواعد التي تحتوي على “!”. إذا استخدمت أيًّا منها، فتحقق من أن كل واحدة مكتوبة في الملف الذي يُفترض أن تنطبق فيه.

إذا كان المنع يعمل لكن Claude Code لا يزال عاجزًا عن رؤية الملفات التي تحتاج إليها، فراجع الشرح المنفصل: لماذا لا يستطيع Claude Code رؤية ملفات المشروع.

إذا لم تتمكن من التحديث الآن#

أحيانًا يتعين عليك تأجيل التحديث: قد لا تتمكن من تغيير البيئة، أو قد يكون الجهاز مملوكًا للشركة، أو قد تحتاج إلى إنهاء المهمة الحالية. إلى أن تحدّث، يمكنك تقليل المخاطر بهذه الطريقة:

• اكتب قواعد deny بصيغتي المسار كلتيهما: صيغة الرابط الرمزي والموقع الحقيقي (توجد المسارات الحقيقية تحت /private على macOS)؛
• لا تضع عدة أوامر في سطر واحد، وتجنب env -C وeval في الأوامر التي تطلب من الوكيل تشغيلها؛
• لا تعرض ناتج /mcp أو /plugin أو claude mcp list أو claude mcp get لأي شخص، وغيّر مفاتيح إعدادات MCP التي ربما وصلت إلى أيدي آخرين؛
• تذكّر أن tee يتجاوز المنع على Edit عند الكتابة؛ فلا تعتبر الملفات محمية إذا كان Bash مسموحًا.

تقلل هذه الإجراءات احتمال حدوث حالات تجاوز محددة، لكنها لا تغني عن الإصلاح. حدّث ونفّذ الاختبار من القسم السابق بمجرد أن تتمكن من ذلك.

ملخص موجز#

أصلح الإصداران 2.1.268 و2.1.269 أربع مشكلات في أذونات Claude Code: الروابط الرمزية، والأسطر التي تحتوي على env -C وeval، وقواعد “!” التي تتجاوز نطاق ملفها، والكتابة عبر tee. كما أُصلحت، بصورة منفصلة، مشكلة كشف الأسرار في ناتج /mcp وظهور الرموز المميزة في أخطاء الإضافات. تحقق من رقم الإصدار، وحدّث إلى أحدث إصدار، ونفّذ الاختبار باستخدام ملف الاختبار المذكور في القسم أعلاه. إذا ذكر إشعار المنع قاعدتك، فهذا يثبت أن المنع عمل في هذا الاختبار. وجود القاعدة في الإعدادات وحده لا يكفي للتحقق من عملها.

لمواصلة العمل مع النماذج، يمكنك الانتقال إلى Ailoot.