Claude Code 2.1.211 يمنع رموز Unicode الخفية من تغيير شكل رسالة الموافقة

تضمّن تحديث Claude Code رقم 2.1.211، الصادر في 15 يوليو 2026، سطرًا قصيرًا في سجل التغييرات. فقد أصبحت معاينات طلبات الإذن (permission previews) تعطّل رموز bidirectional override والرموز صفرية العرض (zero-width) وعلامات التنصيص المشابهة للأصلية، وذلك، بحسب نص السجل، حتى لا تستطيع مدخلات الأدوات تغيير شكل رسالة الموافقة بصريًا.

ولفهم أهمية هذا السطر لا بد من شرح Unicode bidi. فحين يجمع سطر واحد بين العربية والإنجليزية، يواجه الحاسوب مشكلة: العربية تُقرأ من اليمين إلى اليسار، والإنجليزية من اليسار إلى اليمين. ولذلك يتضمن Unicode رموزًا خاصة تُسمى bidirectional override، أشهرها U+202E، ووظيفتها أن تطلب من الشاشة عرض ما بعدها بترتيب معكوس.

وهذه الرموز لم تُصمم للاختراق، بل صُممت أصلًا لتُعرض العربية والعبرية بشكل صحيح. كما أنها لا تظهر على الشاشة، فهي تغيّر ترتيب العرض فقط.

وبذلك يصبح لكل سطر ترتيبان: الترتيب المنطقي (logical order)، أي ترتيب البايتات الفعلي المخزن، وترتيب العرض (display order)، أي ما تراه العين. وفي أغلب الأحوال يتطابق الاثنان، لكن وجود هذه الرموز يمكن أن يجعلهما مختلفين تمامًا.

وتظهر خطورة ذلك مع وكلاء الذكاء الاصطناعي. فحين يريد الوكيل تنفيذ أمر، يعرض على المستخدم طلب موافقة، وهذا الطلب في النهاية نص معروض على الشاشة. فإذا احتوت مدخلات الأداة على هذه الرموز، قد يقرأ المستخدم شيئًا بينما يُنفَّذ شيء آخر. فالخلل هنا في العرض لا في التنفيذ.

وقد استُغلت فكرة مشابهة من قبل في بحث Trojan Source، الذي أظهر كيف يمكن لرموز bidi أن تجعل الكود المعروض مختلفًا عن الكود الفعلي.

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

والمفارقة أن المطورين الذين يكتبون بالعربية يعرفون هذا الفرق بين ترتيب العرض وترتيب التخزين جيدًا، من كل سطر مختلط انقلب عند النسخ أو اسم ملف عربي ظهر معكوسًا في الـ terminal.