جدول المحتويات

إذا كنت قد شغّلت جلسات طويلة في Claude Code، فربما رأيت نصاً غريباً ينساب فجأة إلى شاشتك:

court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…وصف الأمر…</parameter>
</invoke>

Your tool call was malformed and could not be parsed. Please retry.

استدعاء أداة (أمر) كان من المفترض أن يُنفَّذ خلف الكواليس يتسرّب إلى المحادثة كنص خام — ولا يُنفَّذ أبداً. وفي المقدمة تجلس كلمة بلا معنى، court (أو call). من الطبيعي أن تقلق «هل تعطّل جهازي؟» أو «هل أخطأت في إعدادٍ ما؟» لكن الجواب المختصر هو: هذه ليست مشكلة في بيئتك، ولا في أمرك.

إنها خلل من جانب النموذج، حيث يُفسِد Claude (خاصةً عائلة Opus 4.8 / 4.7) «وسوم التحكّم» الخاصة باستدعاء الأداة في لحظة توليدها. وقد فُتحت في المستودع الرسمي لـ Anthropic مشكلاتٌ عديدة بشأنه (#64108, #64150, #64690, #65705, #66153, #67295, #68354، وغيرها). تعرض هذه المقالة الآلية والأسباب والمفاهيم الخاطئة الشائعة وإصلاحات المستخدم/المطوّر وكيفية تمييزها عن الأخطاء المشابهة والموقف الرسمي — مستندةً إلى وثائق Anthropic والمشكلات الفعلية. أهم خطوة منفردة، نقولها مقدّماً: عند ظهور court، لا تكدّ في تلك الجلسة — اهرب باكراً إلى جلسة جديدة (/clear). والسبب موضّح أدناه.

CLAUDE CODE · TOOL CALL LEAK

ما حقيقة «court» + وسوم invoke المتسرّبة

— وسم تحكّم يُولَّد مكسوراً، فيتسرّب إلى الشاشة بدل أن يُنفَّذ

claude-code — opus-4.8 (1M)
دعني آخذ نسخة احتياطية من الملف قبل التعديل…
court ← ١) رمز تحكّم تالف
<invoke name="Bash">
<parameter name="command">cp file file.bak</parameter>
</invoke> ← ٢) الـ XML الذي كان يُفترض أن يُنفَّذ، معروضاً خاماً
Your tool call was malformed and could not be parsed.
↑ ٣) مرفوض بنمط fail-closed → الأمر لا يُنفَّذ أبداً

الاستدعاء المكسور يتعذّر تحليله، لذا لا يُنفَّذ أبداً (fail-closed) — ولا خطر من تشغيل أمر خاطئ.
المشكلتان الحقيقيتان هما دورة مهدورة، و«تفاعل متسلسل» إذا تركتها دون رادع.

1. ماذا يحدث فعلاً — رمز «court» ووسوم invoke

إن <invoke name="Bash"> و<parameter name="command"> التي تراها هي «ترميز استدعاء الأداة» الذي لا يُفترض أن تراه أبداً. فحين يشغّل Claude أمراً أو يحرّر ملفاً، فإنه يولّد هذه الوسوم المهيكلة بأسلوب XML على هيئة رموز (tokens)، ثم يحلّلها Claude Code (الهيكل/harness) ويشغّل الأمر فعلاً. في الوضع الطبيعي يمتصّ الهيكل الوسوم، فلا تصل إلى الشاشة أبداً، وكل ما تراه هو نتيجة الأداة.

لكن هذه المرة، «رمز التحكّم الافتتاحي» لاستدعاء الأداة وُلِّد مكسوراً، فتسللت كلمةٌ لا علاقة لها court أو call إلى المقدمة. والهيكل لا يتفاعل إلا مع بناءٍ صارم، لذا يقرّر «هذا ليس استدعاء أداة، بل مجرد نص» ويرسله مباشرةً إلى الشاشة. فلا يُنفَّذ الأمر، وتحصل على رسالة «Your tool call was malformed and could not be parsed». وفي بعض الحالات لا تظهر أي رسالة خطأ على الإطلاق، بل يتوقّف ببساطة في صمت (في المشكلة #65705 عاد الردّ بحالة stop_reason=end_turn دون أي شيء ليُنفَّذ، فتعلّقت المحادثة).

كلمة court نفسها لا تحمل معنى. لكنها ليست أيضاً كلمة عشوائية تماماً تظهر مرة واحدة — فعبر تقارير مستقلة متعددة، يظهر التسرّب على هيئة court / call باتساقٍ مريب. وتحلّلها المشكلة #64690 على أنها «رمز مجاور في المفردات يُنتقى بدلاً من الوسم الصحيح». بعبارة أخرى، خير فهم لـ court أنه توقيع يساعدك على التعرّف على هذه العلّة.

2. الخلفية: الوكيل «يولّد» استدعاءات أدواته أيضاً

لماذا يمكن أن ينكسر «وسم تحكّم» أصلاً؟ المفتاح هو أنه بالنسبة لوكيل الذكاء الاصطناعي، استدعاء الأداة في نهاية المطاف مجرد توليد نص.

عند استخدام الأدوات مع Claude API، فإن الصيغة التي تراها كمطوّر هي JSON (كتلة tool_use). لكن داخلياً، يتّبع النموذج موجّه نظام خفياً تحقنه Anthropic تلقائياً، ويولّد الوسوم المُحيطة <function_calls> و<invoke> و<parameter> على هيئة تدفّق من الرموز. ثم تتولّى طبقة الـ API تحليل هذه الوسوم وتحويلها إلى كتلة tool_use نظيفة بصيغة JSON (وفق وثائق tool-use الرسمية). وكل «استدعاء أداة» في MCP ووكلاء الذكاء الاصطناعي يقوم فوق هذه الآلية.

المهم هنا أن مُحلّل الهيكل «fail-closed» (ينحاز إلى الجانب الآمن). فإذا اختلف وسمٌ عن الشكل المتوقّع ولو برمزٍ واحد، فإن الهيكل لا يخمّن ويشغّله — بل يرفضه فوراً باعتباره مشوّهاً. وهذا هو تصميم الهيكل الصحيح: «إصلاح» أمر غامض «بحُسن نيّة» وتشغيله سيكون أخطر بكثير. لذا فإن هذه الظاهرة برمّتها حالةٌ من «انكسر → رُفِض → لم يُنفَّذ» — أي أنها فشلت بأمان.

في جملة واحدة

استدعاء الأداة هو «نص بوسوم خاصة» يولّده النموذج. وحين ينكسر الرمز الافتتاحي لتلك الوسوم أثناء التوليد، يعجز الهيكل عن التعرّف عليه، فـيتسرّب إلى النص العادي ولا يُنفَّذ. الرفض نفسه آلية أمان صحيحة؛ والعلّة تكمن خالصةً في التوليد من جانب النموذج.

3. لماذا يحدث — سببان جذريان وشروط محفّزة

بدمج المشكلات الفعلية، ينقسم السبب إلى «(1) فساد عند لحظة التوليد» و«(2) التفاعل المتسلسل من التسمّم الذاتي» الذي يجعله مزعجاً.

2 ROOT CAUSES

كيف ينكسر، ثم «يتسلسل»

السبب ١ · فساد توليد رمز التحكّم
الوسم الافتتاحي لاستدعاء الأداة، بسبب تذبذب أخذ العينات، ينقلب إلى رمز مجاور (court / call). وتسقط بادئة فضاء الأسماء أيضاً، فيعجز الهيكل عن التعرّف عليه. مستقل عن البيئة (تكرّر على Win/mac/Linux — #68354).
السبب ٢ · تفاعل متسلسل من التسمّم الذاتي
بمجرد أن تبقى الكتلة المكسورة في سجلّ المحادثة، يخلطها النموذج بأنها مثال صحيح فينسخها. ولهذا يأتي إعادة المحاولة بنتيجة عكسية ويتكرّر الفشل حتمياً (#64150، #62344).
شروط ترفع الاحتمالية (مبلّغ عنها؛ السببية غير مثبتة)
· جلسات مستأنَفة طويلة جداً / متعددة الأيام؛ سياق ثقيل بمقياس 1M (#65705: 1,739 سطراً على مدى 3 أيام)
· استدعاءات أدوات متعددة في رسالة واحدة / استدعاء أداة موضوع مباشرةً بعد نص (#66153)
· الحالة مباشرةً بعد تشغيل /compact (#67295: يتكرّر في أول استدعاء بعد compact)
· Bash في الخلفية (run_in_background) أو ٣ خوادم MCP متصلة فأكثر (#64690)
· وسائط أداة طويلة بطول فقرة (#49747: متغيّر منفصل يتسرّب فيه XML داخل JSON)

الخلاصة: الانكسار نفسه تذبذب نادر في أخذ العينات. أما الجزء المزعج حقاً فهو التسلسل في (2) —
ولهذا قد يكون «الكدّ بإعادة المحاولة في الجلسة نفسها» أسوأ خطوة.

4. تصحيح ثلاثة مفاهيم خاطئة شائعة

تختلط المعلومات حول هذه الظاهرة بسهولة. وللتعامل معها بشكل صحيح، إليك ثلاثة مفاهيم خاطئة شائعة مصحّحة.

الاعتقاد الشائعالحقيقة
«الأداة تمرّدت / تعطّلت»العكس تماماً. الاستدعاء المكسور رُفِض دون تنفيذ (fail-closed). لا خطر من تشغيل أمر خاطئ؛ كل ما حدث «دورة مهدورة + تسرّب بصري». لقد فشل بأمان.
«أعِد المحاولة فحسب — يشفى ذاتياً إن تركته»صحيح نصفياً فقط. تتعافى الحالة الخفيفة بإعادة محاولة واحدة، لكن بمجرد بقاء الكتلة المكسورة في السجلّ يقلّدها النموذج فيتسلسل. سجّلت #65705 14 فشلاً متتالياً على مدى 5 ساعات فأكثر؛ وسجّلت #66153 أكثر من 30 في جلسة واحدة. الكدّ في الجلسة نفسها يأتي بنتيجة عكسية.
«court يعني شيئاً / هو أمر»لا يعني شيئاً — مجرد ركام من رمز تحكّم تالف. لكن court/call يتكرّران كعلامة، فهما مفيدان كإشارة تشخيصية.

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

5. أصلِحها الآن (لمستخدمي Claude Code)

تعتمد الاستجابة على «هل ما زلت في الحالة الخفيفة، أم بدأ التسلسل؟» حسب ترتيب الأولوية:

USER FIXES

ترتيب الأولوية

FIX 1 · اهرب إلى جلسة جديدة (الأولوية القصوى)
عند ظهور court، نفّذ /clear أو ابدأ جلسة جديدة باكراً. قطع السجلّ المسموم هو الأكثر موثوقية. قبل الانتقال، احفظ الحالة عبر git commit أو مذكّرة تسليم.
FIX 2 · أعِد المحاولة مرة واحدة فقط (حالة خفيفة)
في ظهور أول لمرة واحدة، غالباً ما يدفعه تنبيهٌ بـ«تابِع» إلى إعادة إصداره صحيحاً (في #66153 أدّت كتابة «استأنِف» إلى تعافيه). لكن إن فشل مرتين متتاليتين، توقّف عن الكدّ وانتقل إلى FIX 1.
FIX 3 · شغّل حملاً أخفّ
تجنّب الجلسات الطويلة متعددة الأيام. لا تحشُ الكثير في رسالة واحدة. لاحظ أن /compact أُبلِغ عن تكراره مباشرةً بعده — فهو ليس إصلاحاً موثوقاً.

القاعدة: «أخفِق مرتين، فاترك الجلسة وابدأ من جديد».
كلما كددت أكثر في سجلٍّ مسموم، عمق الجرح. أبقِ الـ CLI محدَّثاً (لكن لاحظ: لم يُشحَن أي إصلاح بعد — التحديث نظافة لا علاج سحري).

نصيحة: إن اعتدت حفظ الحالة في git أو مذكّرة تسليم بصيغة .md، فلن يكلّفك الانتقال إلى جلسة جديدة في أي لحظة شيئاً. وكلما شغّلت جلسات مستقلة طويلة، زاد مردود هذه العادة (وهي تتصل مباشرةً بإدارة نافذة السياق لديك).

6. للمطوّرين: امنعها عبر API/SDK

إذا كنت تبني وكيلك الخاص على Claude API / SDK، فيمكنك إضافة الدفاعات التالية في هيكلك. ومنطق الكشف المقترح في المشكلة #65705 عملي.

// افحص دور المساعد المستلَم قبل التنفيذ
const text = assistantText(resp);
const looksLeaked =
  /<invoke\s+name=/.test(text) ||
  /function_calls/.test(text) ||
  /\bcourt\s*<invoke/.test(text);

// 1) الترميز أعلاه موجود لكن لا توجد كتلة tool_use مهيكلة → استدعاء مكسور
if (looksLeaked && !hasToolUseBlock(resp)) {
  // 2) لا تعرضه؛ سجّله. لا تُبقِ الكتلة المكسورة في السجلّ (يمنع التسمّم الذاتي)
  // 3) نبّه «أصدِره ككتلة tool_use مهيكلة، لا كنص» وأعِد المحاولة تلقائياً
  return retryWithNudge(messages);
}

// ارفض tool_use غير مكتمل ناتجاً عن البتر
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
  return retryWith({ max_tokens: higher }); // لا تنفّذ
}

أربعة مبادئ. (1) تحقّق دائماً من stop_reason (حالة end_turn دون تشغيل أي أداة فعلاً = اكشف التوقّف الصامت). (2) قبل التنفيذ، تأكّد من أن النص لا يحتوي <invoke name= أو function_calls؛ وإن احتوى، أعِد المحاولة بدل التنفيذ. (3) لا تُبقِ الكتلة المكسورة في سجلّ المحادثة (إبقاؤها يجعل التوليد التالي يقلّدها — تسمّم ذاتي / #62344). (4) أبقِ وسائط الأداة قصيرة وقسّم المخرجات الطويلة (تجنّب متغيّر الحمولة الطويلة في #49747). وحتى عند استخدام هيكل رسمي مثل Claude Agent SDK، يجدر فهم سلوك الحلقات الطويلة الأمد.

7. كيف تميّزها عن الأخطاء المشابهة

توجد عدة أخطاء من نوع «الأداة لا تعمل»، وتحتاج إصلاحات مختلفة. ميّز هذه الأربعة كي لا تخلط بينها.

العَرَضما هو حقاًالإصلاح الرئيسي
court / call + وسوم invoke خام معروضة، دون تنفيذموضوع هذه المقالة. فساد توليد رمز التحكّم + تسلسل عبر التسمّم الذاتيفضّل جلسة جديدة (/clear)؛ لا تكدّ بعد إخفاقين
400 «thinking blocks cannot be modified» يجمّد الجلسةعدم تطابق توقيع في التفكير الموسّع (علّة مختلفة). خطأ API صارمراجع المقالة المخصّصة (Esc×2 / rewind)
يُبتر الردّ في منتصف التدفّق (دون XML مشوّه)بترٌ طبيعي من بلوغ max_tokens. ليس خطأًارفع max_tokens وأعِد التشغيل
لا يُهيكَل XML على Bedrock وLangChain وغيرهاعميل طرف ثالث يعجز عن تحليل صيغة Anthropic (langchain-aws #521). لا يتكرّر على API الرسمي / Claude Codeأعِد النظر في مكتبة التكامل / طبقة الاستضافة

محور التمييز بسيط. إن رأيت «تشويش court / call + XML خام»، فهي هذه العلّة. وخطأ التوقيع 400 هو خطأ كتلة التفكير. والبتر النظيف مجرد حدّ المخرجات. وعلى Bedrock أو عبر LangChain فقط يشير إلى طبقة التكامل. ولأخطاء Claude Code الشائعة الأخرى، راجع مجموعة الأخطاء.

8. الموقف الرسمي

حتى يونيو 2026، لا يوجد إصلاح رسمي مؤكَّد (مدخل في سجلّ التغييرات) يفيد بأن هذه الظاهرة قد حُلّت. فبتتبّع ملاحظات الإصدار حتى أحدث إصدار من Claude Code (سلسلة 2.1.183)، لا يوجد مدخل يعالج فساد تسلسل استدعاء الأداة، ولا تزال كثير من المشكلات ذات الصلة مفتوحة، أو مصنّفة كـ«مكرّرة / راكدة». لذا فإن كل إصلاح في هذه المقالة هو حلٌّ بديل في انتظار إصلاح رسمي، ولا يمكنك الادّعاء بأن «التحديث إلى أحدث إصدار يصلحها» (التحديث مُوصى به، لكنه ليس علاجاً مضموناً).

ومع ذلك، فإن تصميم الهيكل fail-closed القائم على «رفض الاستدعاء المكسور بدل تنفيذه بالتخمين» صحيحٌ بذاته. ما يحتاج إلى إصلاح هو استقرار توليد النموذج — لا تليين المحلّل ليصبح «يصلحه ويشغّله رغم كل شيء»، فذلك يستدعي الخطر الجسيم المتمثّل في تشغيل أمر خاطئ. وأفضل ما يمكننا فعله كمستخدمين هو التشغيل بطريقة تتجنّب التسلسل، والإبلاغ عن إعادة الإنتاج في المشكلات الرسمية مع بيئتك وسجلّاتك (مزيد من البلاغات يرفع الأولوية ويسرّع الإصلاح).

9. قائمة الوقاية

مستخدمو Claude Code: (1) عند ظهور court/call، أعِد المحاولة مرتين كحدٍّ أقصى؛ وإن استمرّ، نفّذ /clear / جلسة جديدة فوراً. (2) تجنّب الجلسات الطويلة جداً / متعددة الأيام؛ احفظ العمل في git/مذكّرات عند نقاط التوقّف. (3) لا تحشُ استدعاءات أدوات متعددة في رسالة واحدة. (4) تذكّر أن /compact ليس حلّاً شاملاً (قد يتكرّر مباشرةً بعده). (5) أبقِ الـ CLI محدَّثاً، وأبلِغ عن إعادة الإنتاج في المشكلات الرسمية.

مطوّرو API/SDK: (1) تحقّق دائماً من stop_reason. (2) اكشف تسرّب <invoke name= / function_calls إلى النص وأعِد المحاولة. (3) لا تُبقِ الاستدعاءات المكسورة في السجلّ (امنع التسمّم الذاتي). (4) أبقِ وسائط الأداة قصيرة؛ قسّم المخرجات الطويلة. (5) لا تنفّذ أبداً tool_use غير مكتمل ناتجاً عن بتر max_tokens — أعِد المحاولة بدلاً من ذلك.

الخلاصة

في Claude Code، فإن «court / call + وسم <invoke> خام معروض، مع عدم تنفيذ الأداة» هو خلل من جانب النموذج، حيث يولّد Claude (عائلة Opus 4.8 / 4.7) رمز التحكّم لاستدعاء الأداة بشكل مكسور. والهيكل يرفضه بنمط fail-closed، لذا لا خطر من تشغيل أمر خاطئ (لقد فشل بأمان). الجزء المزعج حقاً هو أنه بمجرد بقاء الكتلة المكسورة في السجلّ، يقلّدها النموذج و«يتسلسل». لذا فإن «إعادة المحاولة تصلحها» لا يصحّ إلا في الحالة الخفيفة، وتصبح القاعدة «أخفِق مرتين، فاهرب إلى جلسة جديدة».

السبب من طبقتين: (1) فساد توليد رمز التحكّم + (2) التسلسل عبر التسمّم الذاتي. والشروط المحفّزة تشمل الجلسات الطويلة / متعددة الأيام، السياق الثقيل، الحالة بعد /compact، الأدوات المتعددة المتزامنة، 3 خوادم MCP فأكثر، ووسائط الأداة الطويلة. ولأنه لم يُشحَن أي إصلاح رسمي حتى يونيو 2026، فكل علاج هو حلٌّ بديل. على المستخدمين «تفضيل جلسة جديدة + حفظ الحالة كثيراً»؛ وعلى المطوّرين «التحقّق من stop_reason، وإعادة المحاولة عند كشف التسرّب، وعدم إبقاء سجلٍّ مكسور، وتقصير الوسائط». وقراءة خطأ كتلة التفكير 400 ومجموعة أخطاء Claude Code وMCP جنباً إلى جنب مع هذه المقالة سيجعلك أكثر صموداً أمام مشكلات استدعاء الأدوات.

الأسئلة الشائعة

Q. هل «court» أو وسم invoke على شاشتي ناتج عن خطأ في أمري أو إعداداتي؟
A. لا — على الأرجح ليس كذلك. هذا خلل معروف من جانب النموذج حيث يولّد Claude وسوم استدعاء الأداة بشكل مكسور، وقد فُتحت بشأنه عدة مشكلات في المستودع الرسمي لـ Anthropic (#64108, #65705, #66153، وغيرها). ليس خطأً في بيئتك أو أمرك أو إعداداتك. عامِل court/call باعتبارهما «توقيع» للعلّة.

Q. هل يمكن أن يُنفَّذ أمر خاطئ فيُتلف خادمي أو ملفاتي عند حدوث ذلك؟
A. لا. يُحكَم على استدعاء الأداة المكسور بأنه «مشوّه» ويُرفَض دون تنفيذ (تصميم fail-closed). كل ما يحدث أن تُهدَر الدورة ويصبح نص التحكّم مرئياً؛ ولا أثر على بياناتك أو حالة خادمك. إنه مصمَّم ليفشل بأمان.

Q. سمعت «أعِد المحاولة فحسب فتُصلح نفسها». أصحيح ذلك؟
A. فقط حين تكون خفيفة. في ظهور أول لمرة واحدة، غالباً ما يدفعه تنبيهٌ بـ«تابِع» إلى إعادة إصداره صحيحاً. لكن بمجرد بقاء الكتلة المكسورة في سجلّ المحادثة، يستخدمها النموذج كقالب ويكرّر الفساد نفسه (تسمّم ذاتي). عند تلك النقطة تأتي إعادة المحاولة في الجلسة نفسها بنتيجة عكسية. إن فشل مرتين متتاليتين، توقّف عن الكدّ وانتقل إلى جلسة جديدة (/clear).

Q. هل يصلحها /compact؟
A. ليس بشكل موثوق. قد يساعد ضغط السياق أحياناً، لكن في المشكلة #67295 تكرّر في أول استدعاء أداة مباشرةً بعد /compact. أكثر خطوة موثوقية ليست /compact بل جلسة جديدة (/clear) تعيد ضبط السجلّ بالكامل. احفظ حالة عملك في git أو مذكّرات قبل الانتقال.

Q. هل يصلحها تحديث Claude Code إلى أحدث إصدار؟
A. لا يمكنك القول إنه «يصلحها». حتى يونيو 2026 لا يوجد مدخل رسمي في سجلّ التغييرات يؤكّد إصلاحاً، ولا تزال كثير من المشكلات ذات الصلة مفتوحة أو مكرّرة. التحديث مُوصى به كنظافة، لكنه ليس علاجاً سحرياً. وفي الوقت الراهن، أفضل نهج هو التشغيل بطريقة تتجنّب التسلسل (أخفِق مرتين → جلسة جديدة) والإبلاغ عن إعادة الإنتاج في المشكلات الرسمية.