رسالة «API Error: The response stopped arriving» تعني أن البيانات توقفت عن الوصول في منتصف بثّ الرد مع أن الاتصال ظل مفتوحًا، فقطع مؤقّت المراقبة الخاص بـ Claude Code ذلك الاتصال. كل ما اكتمل من مخرجات قبل تلك اللحظة يبقى ظاهرًا على الشاشة. وفي الجلسة التفاعلية يكفي أن ترد بـcontinue ليستأنف Claude من آخر نقطة مكتملة.

API Error: The response stopped arriving. The response above may be incomplete.

قبل v2.1.227 كانت هذه الرسالة تُعرض بنص Response stalled mid-stream. مرجع الأخطاء الرسمي ينص صراحة على تغيير الاسم، وما يحدث فعليًا هو نفسه. فإذا بحثت عن معلومات أو بلاغات أخطاء كُتبت بالصيغة القديمة، فابحث بالنصّين معًا.

انظر أولًا إلى الصياغة التي تلي «API Error:»

رسائل «توقّف» و«انقطع» تختلف صياغتها باختلاف السبب

The response stopped arriving
بدأت المخرجات بالظهور، ثم توقفت البيانات والاتصال لا يزال مفتوحًا
← استأنف بـ continue من حيث توقّف
موضوع هذا المقال
Connection lost mid-response
بدأت المخرجات بالظهور، ثم انقطع الاتصال نفسه
← الفرق بين الانقطاع والصمت
الصيغة القديمة: Connection closed
The response stalled before a response was produced
انتهى التفكير، ثم توقف كل شيء قبل أن تبدأ أي مخرجات
Streaming response ended before any complete data was received
انتهى الرد دون أي بيانات صالحة للاستخدام، فأُعيد إرساله دون بثّ
← اشتبه في الوكيل (proxy) على المسار
لم يتوقف، بل انتهى فارغًا
مخطط مبني على شروح مرجع الأخطاء الرسمي، لاختيار ما تتحقق منه انطلاقًا من صياغة الرسالة.

المحتويات

1. معنى هذه الرسالة — ليس انقطاعًا بل «صمت»

يشرح مرجع الأخطاء الرسمي لـ Claude Code هذه الرسالة بأن «الاتصال ظل مفتوحًا لكنه توقف عن توصيل البيانات، فقطعه مراقب الخمول الخاص بالبث (idle watchdog)». فهي ليست نص خطأ أعادته الـ API، بل ملاحظة يضيفها Claude Code بنفسه، وهو الطرف الذي كان يستقبل الرد.

ولحالات «التوقف في المنتصف» يستخدم Claude Code صياغات مختلفة بحسب السبب. يسرد المرجع الرسمي أربعًا منها، تشترك كلها في الخاتمة «The response above may be incomplete.» (أي: قد يكون الرد أعلاه ناقصًا).

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.

السطر الأول يظهر حين يُعيد الخادم في منتصف الرد خطأ حِمل زائد أو خطأ من فئة 5xx، والثاني حين ينقطع الاتصال، والثالث حين يدخل الحاسوب في وضع السكون أثناء الرد. أما السطر الرابع، وهو موضوعنا، فهو وحده الذي يعني أن البيانات توقفت عن الوصول دون أن يقع خطأ أو انقطاع.

من يقطع الاتصال: أربعة مؤقّتات مراقبة

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

المؤقّتشرط القطعالمدة الافتراضية
المراقبة على مستوى البايتلا يصل أي بايت على الخط (ولا حتى رسائل keep-alive الخاصة بـ SSE)180 ثانية عند الاتصال المباشر بـ Anthropic API، و300 ثانية في غير ذلك
المراقبة على مستوى الأحداثلا يُقرأ أي حدث من أحداث الرد300 ثانية (لجميع المزوّدين)
مهلة خمول جسم الردلا تصل أي بايتات لمدة 5 دقائق5 دقائق (باستثناء Anthropic API المباشر وClaude Platform on AWS)
مهلة البايت الأولبعد الإرسال لا تصل أي ترويسة للرد180 ثانية مع الـ API المباشر، و300 ثانية في غير ذلك (مع ثانية إضافية لكل 32KB من جسم الطلب). والرسالة هنا ليست هذه بل No response from API

إذا كنت متصلًا بـ Anthropic API مباشرة، فالمرجع هو مراقبة البايت ومدتها 180 ثانية. أي أن الشاشة ستبدو متجمدة بضع دقائق قبل أن تظهر هذه الرسالة. وبحسب الوثائق الرسمية، إذا بقي الطلب حيًّا ومرّت 20 ثانية دون بيانات، يظهر الشريط التالي أولًا. معناه «لم يفشل الأمر بعد»، والعدّ التنازلي فيه يشير إلى لحظة القطع (قبل v2.1.185 كانت المدة 10 ثوانٍ والصياغة مختلفة).

Waiting for API response · will retry in … · check your network

إذا عادت البيانات يختفي الشريط من تلقاء نفسه. أما إذا لم يختفِ واستمر حتى لحظة القطع، وكان جزء من المخرجات قد اكتمل بالفعل، فعندها تظهر الرسالة التي يتناولها هذا المقال.

2. تغيّر اسمها في v2.1.227 من «Response stalled mid-stream»

بعد شرح الرسائل الأربع مباشرة، يكتب مرجع الأخطاء الرسمي أنه «قبل v2.1.227 كانت Connection lost mid-response تُعرض بنص Connection closed mid-response، وكانت The response stopped arriving تُعرض بنص Response stalled mid-stream». وفي الإصدار نفسه تغيّرت أيضًا صياغة الرسالة التي تظهر قبل بدء المخرجات.

الرسالة قبل v2.1.227الرسالة الحاليةالمقال على موقعنا
Response stalled mid-streamThe response stopped arrivingهذا المقال
Response stalled while thinking, before producing a responseThe response stalled before a response was producedالقسم 3 من هذا المقال
Connection closed mid-responseConnection lost mid-responseمقالا closed وlost (في النص أدناه)

جمعنا في مقال Response stalled mid-stream والحلقة اللانهائية لكلمة «court» الحالةَ التي ظهرت فيها الصيغة القديمة Response stalled mid-stream مع تكرار النموذج للكلمة نفسها بلا توقف. أما رسالة انقطاع الاتصال، فشرحنا بلاغات عهد الصيغة القديمة في مقال Connection closed mid-response، والصيغة الجديدة بعد تغيير الاسم في مقال Connection lost mid-response.

دليل على الإصدار

إذا رأيت stopped arriving فإصدار Claude Code لديك هو v2.1.227 أو أحدث. وإذا رأيت stalled mid-stream فإصدارك أقدم من ذلك.

غير مذكور في CHANGELOG

قرأنا في 22 سبتمبر 2026 بند v2.1.227 في سجل التغييرات الرسمي (CHANGELOG)، ولم يرد فيه أي ذكر لتغيير الصياغة. وقد نُشر الإصدار على npm في 10 أغسطس 2026 (بتوقيت UTC).

ابحث في البلاغات بالصيغتين

الظاهرة نفسها مُبلَّغ عنها باسمين. عند البحث في Issues على GitHub، جرّب الصيغتين القديمة والجديدة.

قبل v2.1.222 قد تكون الرسالة إنذارًا كاذبًا

بحسب الوثائق الرسمية، كان في Claude Code قبل v2.1.222 نوعان من الإنذارات الكاذبة. الأول مع البوابات (gateway) التي يمر عبرها الاتصال عن طريق ANTHROPIC_BASE_URL أو ANTHROPIC_AWS_BASE_URL: كانت رسائل keep-alive من الخادم تصل، لكن Claude Code لم يكن يحسب إلا الأحداث التي تمكّن من قراءتها، فيقطع الاتصال. والثاني أنه كان يضيف هذه الملاحظة حتى حين يتوقف الاتصال بعد اكتمال الرد، فيعامل ردًّا كاملًا على أنه خطأ. إذا كان ناتج claude --version أقل من 2.1.222، فحدّث أولًا.

3. الفرق بينها وبين الرسائل المشابهة

أي رسالة ستظهر يتحدد بـالمرحلة التي بلغها الرد حين توقف. وإذا رتّبنا شرح «Automatic retries» الرسمي بحسب تقدّم الرد، نحصل على ما يلي.

كلما تأخرت لحظة التوقف، بقي من المخرجات أكثر وقلّت إعادة الإرسال التلقائية

① أثناء انتظار الترويسات

لا تصل ترويسات الرد خلال المهلة. يُعاد الإرسال مرة واحدة كحد أقصى

No response from API

② قبل اكتمال أي شيء

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

The response stalled before a response was produced

③ بعد اكتمال كتلة

توقف بعد اكتمال كتلة نصية أو استدعاء أداة واحد (بما في ذلك بعد انتهاء التفكير وبدء الكتابة). لا يُعاد الإرسال

The response stopped arriving (هذا المقال)

④ بعد اكتمال الرد

يُحفظ الرد كاملًا وينتهي الدور بشكل طبيعي. لا تظهر أي ملاحظة

لا رسالة (منذ v2.1.222)

المصدر: مخطط مبني على أقسام «Automatic retries» و«No response from API» و«The response above may be incomplete» في مرجع الأخطاء الرسمي لـ Claude Code.

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

الرسالةما يحدثالمخرجات الباقية وإعادة الإرسال
The response stopped arrivingالاتصال مفتوح، لكن البيانات توقفتيبقى ما اكتمل. لا يُعاد الإرسال
Connection lost mid-responseانقطع الاتصال نفسهيبقى ما اكتمل. لا يُعاد الإرسال
Server error mid-responseأعاد الخادم في المنتصف خطأ حِمل زائد أو 5xxيبقى ما اكتمل (منذ v2.1.199). لا يُعاد الإرسال
The response stalled before a response was producedبعد انتهاء التفكير توقف مرتين متتاليتين قبل بدء المخرجاتلا تبقى مخرجات. تظهر بعد إعادة إرسال واحدة
No response from APIلم تصل أي ترويسة للرد خلال المهلةلا تبقى مخرجات. تظهر بعد إعادة إرسال واحدة
Streaming response ended before any complete data was receivedانتهى الرد دون أي بيانات صالحة للاستخداميُعاد الإرسال تلقائيًا دون بثّ (تحذير فقط)

الفرق عن Connection lost mid-response: «انقطاع أم صمت»

كلتاهما تظهر بعد أن تكون المخرجات قد بدأت، وتشتركان في بقاء ما اكتمل وفي الاستئناف بـcontinue. الفرق في طريقة التوقف. lost حكمٌ بأن الاتصال فُقد، فتشتبه في انقطاع لحظي في شبكتك أو في إعادة إنشاء اتصال الـ VPN أو في قطعٍ من جهاز على المسار. أما stopped arriving فحكمٌ بأن الاتصال باقٍ لكن المحتوى لا يتدفق، والقطع يحدث بعد الانتظار حتى نهاية مدة مؤقّت المراقبة. لذلك فإن ضبط المؤقّتات الذي يتناوله القسم 6 قد يفيد في حالة stopped arriving وحدها.

الفرق عن Streaming response ended…: «توقف أم انتهى فارغًا»

بحسب الوثائق الرسمية، Streaming response ended before any complete data was received تحذير يظهر حين ينتهي الرد دون أن يوصل أي بيانات صالحة للاستخدام. عندها يتخلى Claude Code عن البث ويعيد إرسال الطلب نفسه، ويواصل الدور. ويظهر التحذير مرة واحدة فقط في كل جلسة تفاعلية (قبل v2.1.239 كانت إعادة الإرسال تتم بصمت). وتقول الوثائق الرسمية إن السبب الشائع هو وكيل (proxy) أو بوابة على المسار تستهلك جسم الرد أو تحوّله. أما stopped arriving فرد وصل جزء منه ثم توقف، ولا يُعاد إرساله تلقائيًا.

4. ماذا يحدث للعمل الذي أُنجز حتى لحظة التوقف

بحسب الشرح الرسمي، يحتفظ Claude Code بكل الكتل المكتملة، ويتخلّى في نهاية الدور عن الكتلة الأخيرة التي كانت قيد الكتابة. ولهذا قد تجد الجمل الأخيرة على الشاشة، أو آخر استدعاء أداة، ناقصة. أما استدعاءات الأدوات التي اكتملت فتُنفَّذ، ويواصل الدور من نتائجها. ويختلف التعامل بعد التوقف بحسب بيئة التشغيل.

الجلسة التفاعلية

اقرأ الرد الباقي على الشاشة، ثم أرسل continue ليُستأنف العمل من آخر كتلة مكتملة. أما إعادة إعطاء التعليمات من البداية فقد تكرر عمليات سبق تنفيذها.

-p وAgent SDK والجلسات السحابية

إذا كان الرد الذي توقف نصًّا فقط دون استدعاء أداة، يحثّ Claude Code نفسه على المتابعة. يحاول حتى 3 مرات متتالية، ولا تظهر الملاحظة إلا بعد استنفادها (منذ v2.1.246).

الوكلاء الفرعيون (subagents)

سواء كانت الجلسة تفاعلية أم لا، إذا كان الرد نصًّا فقط يُحَثّ الوكيل الفرعي على المتابعة. وإذا استُنفدت محاولات الحث، تصبح الملاحظة آخر رسالة للوكيل الفرعي (منذ v2.1.257).

الخطافات (hooks)

بحسب الشرح الرسمي للخطافات، الدور الذي ينتهي بخطأ API يُشغّل StopFailure لا Stop. وهذا الخطاف يتجاهل المخرجات ورمز الخروج معًا، فلا يمكن استخدامه لإرسال continue تلقائيًا.

المخرجات عند التوقف مع -p وطريقة المتابعة

في الوضع غير التفاعلي، ومع مخرجات النص الافتراضية، يطبع Claude Code آخر كتلة نصية اكتملت في ذلك الدور ثم يُتبعها بهذه الرسالة (قبل v2.1.219 كانت الرسالة وحدها تظهر ويُتخلّى عن الرد). لكن إذا لم يبقَ لديه نص مكتمل، كأن يكون ذلك النص قد اختفى بسبب ضغط المحادثة في منتصف الدور، فلا تظهر إلا الرسالة (أضفنا ذلك بعد التحقق من مرجع الأخطاء الرسمي في 26 سبتمبر 2026). ومع --output-format json أو stream-json توضع هذه الرسالة في الحقل result. والإجراء الرسمي هو استئناف الجلسة وإرسال continue بعد أن يستقر الاتصال.

# متابعة المحادثة الأخيرة
claude -p "continue" --continue

# المتابعة بتحديد معرّف الجلسة
claude -p "continue" --resume "$session_id"

أما الاستئناف التلقائي عبر الخطافات، فقد كتب صاحب البلاغ في Issue #87972 أن «خطاف Stop كان يعمل في عهد الصيغة القديمة ويتيح المتابعة تلقائيًا، لكنه توقف عن العمل في الفترة نفسها تقريبًا التي تغيّر فيها الاسم». هذه ملاحظة صاحب البلاغ، ولا تذكر الوثائق الرسمية هل كان السلوك السابق مقصودًا. وبحسب الوثائق الرسمية الحالية، يمكنك عبر الخطافات أن تسجّل أو ترسل إشعارًا، لكن لا يمكنك استئناف الدور.

5. الأسباب — ما تذكره الوثائق الرسمية وما يرد في البلاغات

هذه الرسالة لا تنقل إلا النتيجة: «البيانات لم تعد تصل». أما سبب التوقف فلا يمكن معرفته منها. نرتّب ما نعرفه هنا بحسب درجة اليقين.

✅ عوامل تُسكت البث أو تقطعه، مذكورة في الوثائق الرسمية وCHANGELOG

  • الآلية: الاتصال مفتوح والبيانات متوقفة، فيقطعه مؤقّت المراقبة. مع الـ API المباشر يُقطع إذا مرّت 180 ثانية دون أي بايت، بما في ذلك رسائل keep-alive
  • الإنذارات الكاذبة مع البوابات: قبل v2.1.222 كان الاتصال عبر بوابة بواسطة ANTHROPIC_BASE_URL ونحوه يُقطع أحيانًا رغم وصول رسائل keep-alive. أما البوابات التي يمر إليها الاتصال عبر عنوان URL أساسي خاص بالمزوّد، مثل ANTHROPIC_BEDROCK_BASE_URL، فلا تشملها المراقبة على مستوى البايت
  • الصمت أثناء التفكير الطويل: في CHANGELOG، بند v2.1.229 يذكر «بثّ رسائل keep-alive الخاصة بـ SSE في ردود البوابة المتدفقة حتى أثناء التفكير الطويل، لمنع قطع الخمول حين يكون Vertex أو Bedrock في المنبع»، وبند v2.1.257 يذكر «إصلاح مشكلة في Bedrock وBedrock Mantle مع Opus 4.7 وما بعده، كان الطلب فيها يصمت أثناء تفكير طويل غير ظاهر فيُقطع الاتصال بمهلة الخمول»
  • التعافي من القطع: في v2.1.232 أُصلحت مشكلة «كانت فيها مهلة خمول البث في إعدادات Bedrock وVertex والبوابات تُفشل الطلب دون تعافٍ»
  • التخزين المؤقت في الوكيل (buffering): شرح متغيرات البيئة الرسمي يعلّل جعل الحد الأدنى لـ CLAUDE_STREAM_IDLE_TIMEOUT_MS خمس دقائق بأنه «لاستيعاب فترات التفكير الطويل والتخزين المؤقت في الوكلاء»

تضع الوثائق الرسمية هذه الرسالة ضمن قسم «Server errors» في مرجع الأخطاء. وفي مطلع القسم أن «معظمها يأتي من جهة مزوّد الاستدلال، مثل خدمات Anthropic»، لكن ما تشرحه الوثائق عن هذه الصياغة تحديدًا لا يتجاوز الآلية المذكورة أعلاه. فالوثائق الرسمية لا تحدد أين توقف الاتصال: في شبكتك، أم في جهاز على المسار، أم في الخادم.

🟡 حالات مُبلَّغ عنها على GitHub لم يتأكد سببها

في 22 سبتمبر 2026 فتحنا وقرأنا الـ Issues التالية التي تتضمن هذه الصياغة. كلها بلاغات أو تقديرات من المستخدمين، ولم نجد فيما قرأناه ردًّا علنيًّا من Anthropic.

  • #88900 (Linux، الإصدار 2.1.240، بلا وكيل ولا بوابة): بلاغ عن رد توقف بعد وصول نحو 0.5 إلى 2.7KB، ثم قطعته المراقبة على مستوى البايت بعد 180 ثانية. ويذكر صاحبه أن جلسات منفصلة توقفت معًا في الدقيقة نفسها، ويطلب مراجعة سجلات الخادم
  • #90005 (Windows 11، الإصدار 2.1.246): بلاغ عن ظهورها 33 مرة في يوم واحد مقابل صفر مرة في الأيام السابقة. قاس صاحبه عرض النطاق وفقد الحزم والوكيل ووجدها سليمة، لكنه نبّه إلى أن اختباره لا يقيس الاتصالات التي تبقى مفتوحة مدة طويلة، وكتب أنه لا يستطيع استبعاد قطع الخمول في NAT على مستوى المشغّل (carrier-grade NAT)
  • #89027 (macOS، إضافة VS Code من 2.1.238 إلى 2.1.241): بلاغ عن سجل يتضمن قطعًا على مستوى «byte-level» وصمتًا لمدة 180000ms. وقد حدث ذلك في منتصف WebFetch لدى وكيل فرعي
  • #87246 (macOS، الإصدار 2.1.232): بلاغ لم يتضمن سوى نص هذه الرسالة، وأُغلق بوصف «لا خطة للتعامل معه» (not planned). وفي إضافة لاحقة ملاحظة بأن وكلاء فرعيين في الخلفية توقفوا بهذه الرسالة واحدًا تلو الآخر

يذكر البلاغان #88900 و#90005 أن التوقف حدث رغم عدم وجود خلل ظاهر في شبكة المستخدم. لكن ذلك وحده لا يكفي للجزم بأن السبب من جهة الخادم؛ فكما كتب صاحب #90005 نفسه، اختبارات الاتصال القصيرة لا تعيد إنتاج حالة «اتصال مفتوح لبضع دقائق يصمت في منتصفه».

6. خطوات المعالجة عند التوقف

الخطوات مرتبة من الأعلى بحسب قلة الجهد وكبر الأثر. إذا حدث الأمر مرة واحدة فقط، فتكفي الخطوة 2.

01

تحقّق من المخرجات الباقية ومن الحالة الفعلية للعمل

استدعاءات الأدوات التي اكتملت قد نُفّذت بالفعل. إذا توقف الأمر أثناء تعديل ملفات أو تنفيذ أمر، فانظر أولًا بـgit status وgit diff إلى أي حدّ تغيّرت الأمور.

02

أرسل continue

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

03

تحقّق من الإصدار وحدّثه

اعرف الإصدار بـclaude --version، وحدّث بـclaude update. إذا كان أقدم من 2.1.222 فقد تكون الرسالة من الإنذارات الكاذبة المذكورة في القسم 2. وإذا كنت تستخدم Bedrock أو Vertex أو بوابة، ففي 2.1.229 و2.1.232 و2.1.257 أيضًا إصلاحات ذات صلة (القسم 5).

04

اعزل مسار الاتصال

تحقّق من الوكيل الذي تستخدمه عبر سطر Proxy في /status. ثم جرّب أحد الخيارات: إزالة الـ VPN أو الوكيل، أو الاتصال بشبكة أخرى، أو إزالة البوابة (ANTHROPIC_BASE_URL) والاتصال مباشرة. إذا توقفت المشكلة، فالسبب في أحد ما أزلته.

05

قصّر الرد الواحد

قسّم التعليمات التي تطلب قراءة عدد كبير من الملفات ثم كتابة تقرير طويل إلى مرحلتين: القراءة ثم الكتابة. هذه ليست من الحلول التي تذكرها الوثائق الرسمية لهذه الرسالة، لكن بند «Request timed out» فيها يوصي بتقسيم المهام الطويلة إلى تعليمات أصغر. كما يعرض #87972 حيلة أحد المستخدمين: إبقاء الرد الواحد قصيرًا يقلل التوقف.

06

راجع معلومات الأعطال

تحقّق على status.claude.com من عدم وجود عطل جارٍ. لكن صاحب #90005 كتب أن الحالة كانت «كل شيء يعمل» طوال الفترة التي استمر فيها التوقف. فلا تجزم بأن المشكلة عندك لمجرد أن المؤشر أخضر.

07

إذا كان المسار يصمت طويلًا، فمدّد مدة المراقبة

في البيئات التي يخزّن فيها الوكيل أو البوابة الرد مؤقتًا، يقلّ القطع إذا مدّدت المراقبة على مستوى البايت. ضع الإعداد في env داخل ملف الإعدادات كما في المثال أدناه. فمتغيرات البيئة في الصدفة (shell) قد لا تصل إلى الوكلاء العاملين في الخلفية، ولذلك توصي الوثائق الرسمية بملف الإعدادات بدلًا من export في الصدفة.

مثال لما تكتبه في ~/.claude/settings.json (لجعل المراقبة على مستوى البايت 10 دقائق).

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}
متغير البيئةالشرح الرسمي
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MSمدة المراقبة على مستوى البايت وحدها. تُحصر بين 10 ثوانٍ و30 دقيقة. منذ v2.1.210
CLAUDE_STREAM_IDLE_TIMEOUT_MSمدة المراقبة على مستوى البايت وعلى مستوى الأحداث معًا. ما يقل عن 5 دقائق يُرفع إلى 5 دقائق، والحد الأقصى على مستوى البايت 30 دقيقة
API_FORCE_IDLE_TIMEOUTالقيمة 0 توقف مهلة خمول جسم الرد (5 دقائق)، والقيمة 1 تطبّقها على جميع المزوّدين. مستقل عن مؤقّتات المراقبة
CLAUDE_CODE_MAX_RETRIESعدد مرات إعادة المحاولة (الافتراضي 10). الحالة التي تظهر فيها هذه الرسالة مصممة أصلًا على عدم إعادة الإرسال، فزيادته لا تقلل ظهورها

لا ننصح بإيقاف المراقبة

إذا ضبطت CLAUDE_ENABLE_BYTE_WATCHDOG أو CLAUDE_ENABLE_STREAM_WATCHDOG على 0 تتوقف المراقبة نفسها. والوثائق الرسمية تشرح أن هذه المؤقّتات موجودة «حتى لا يبقى الاتصال الميت معلّقًا، بل يفشل ويُعاد المحاولة». إيقافها قد يُخفي الرسالة، لكنك ستنتظر بلا نهاية اتصالًا توقف فعلًا. وإذا كانت البيانات من الخادم متوقفة حقًّا، فتمديد المدة لن يفعل سوى تأخير الفشل.

7. التحقق من أن المشكلة زالت

لا تعتبر الأمر محلولًا لمجرد أنها لم تظهر مرة واحدة. شغّل عملًا بالحجم نفسه، وراقب النقاط الأربع التالية.

الإصدار

هل انعكس التحديث في claude --version؟ قد تُحدَّث النسخة المضمّنة في إضافات بيئات التطوير (IDE) أو في تطبيق سطح المكتب بمعزل عن واجهة سطر الأوامر (CLI)

شريط الانتظار

إذا ظهر Waiting for API response ثم اختفى من تلقاء نفسه، فالصمت قصير. وتوصي الوثائق الرسمية بمعاملته مشكلةً في الشبكة إن ظهر في كل محاولة

سجل التصحيح

إذا شغّلت claude --debug يُكتب السجل في ~/.claude/debug/<session-id>.txt. وقد وجد صاحبا #88900 و#89027 عند لحظة القطع سطرًا يبدأ بـ«Streaming idle timeout (byte-level)» (نص هذا السطر غير مذكور في الوثائق الرسمية)

عدد المرات في سجل المحادثة

تُحفظ المحادثات بصيغة JSONL تحت ~/.claude/projects/. عُدّ مرات ظهور هذه الصياغة قبل التحديث أو تغيير الإعدادات وبعده وقارن بينها. وتنبّه الوثائق الرسمية إلى أن هذه الصيغة داخلية وتتغير من إصدار إلى آخر

# التحقق من الإصدار
claude --version

# التشغيل مع تسجيل سجل التصحيح
claude --debug

# عدّ ملفات سجل المحادثة التي تتضمن هذه الصياغة (macOS وLinux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# وبالمثل، عدّ الأسطر التي تتضمن هذه الصياغة (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

استخدم العدد مؤشرًا تقريبيًا فقط. فقد كتب صاحب #90005 أن الشاشة توقفت 15 مرة خلال 85 دقيقة، بينما لم يُسجَّل في سجل المحادثة سوى إدخال واحد. وحتى إن كان العدد في السجل صفرًا، فالأضمن أن تدوّن بنفسك أيضًا عدد مرات التوقف على الشاشة.

8. المعلومات التي تحفظها عند الإبلاغ

يذكر مرجع الأخطاء الرسمي القنوات الأربع التالية حين لا تُحلّ المشكلة.

  • شغّل /feedback داخل Claude Code. يُرسل سجل المحادثة ووصفك إلى Anthropic، ويمكنك أيضًا فتح Issue على GitHub بمحتوى معبّأ مسبقًا. ومع مزوّدين مثل Bedrock وVertex يُحفظ ذلك محليًا بدلًا من إرساله
  • شغّل claude doctor في الصدفة لترى تشخيصًا للقراءة فقط لتثبيتك
  • تحقّق من الأعطال على status.claude.com
  • ابحث في الـ Issues الموجودة على GitHub، بالصيغتين القديمة والجديدة

نموذج لملاحظات البلاغ

البيئة
ناتج claude --version / نظام التشغيل / مكان الاستخدام (CLI في الطرفية، أو إضافة VS Code، أو تطبيق سطح المكتب)
المسار
API مباشر أم Bedrock أو Vertex أو بوابة (ANTHROPIC_BASE_URL) / هل يوجد وكيل أو VPN
الرسالة
النص الكامل للخطأ / وقت الحدوث والمنطقة الزمنية / هل ظهر Waiting for API response قبلها مباشرة / هل حدث في المحادثة الرئيسية أم لدى وكيل فرعي
التكرار
عدد المرات في اليوم، واليوم الذي بدأت فيه / هل حدّثت أو غيّرت الإعدادات في ذلك اليوم
ما جرّبته
ما الذي تغيّر قبل وبعد: التحديث، إزالة الـ VPN أو الوكيل، شبكة أخرى، تقسيم الدور

9. ما هو مؤكد وما لم يتأكد بعد

✅ ما يمكن التحقق منه رسميًا

  • المعنى: «الاتصال مفتوح، والبيانات توقفت، فقطعه مؤقّت المراقبة»
  • قبل v2.1.227 كانت تُعرض بنص Response stalled mid-stream
  • المخرجات المكتملة تبقى، والاستئناف بـcontinue
  • لا يُعاد الإرسال، تجنبًا لتنفيذ استدعاء الأداة نفسه مرتين
  • قبل v2.1.222 كانت هناك إنذارات كاذبة مع البوابات ومع التوقف بعد اكتمال الرد

🟡 مُبلَّغ عنه لكن غير مؤكد

  • تتوقف حتى مع سلامة شبكة المستخدم (#88900 و#90005)
  • تتوقف بعد وصول بضعة كيلوبايتات، وتحدث في عدة جلسات في الوقت نفسه (#88900)
  • عدد المرات المسجّلة في سجل المحادثة أقل مما ظهر على الشاشة (#90005)
  • في عهد الصيغة القديمة كان الاستئناف التلقائي ممكنًا بخطاف Stop (#87972)

🔴 ما لم يُعلَن

  • شرح رسمي لسبب توقف البيانات (لا يوجد رد علني في الـ Issues أعلاه)
  • أين يقع التوقف: عند المستخدم، أم على المسار، أم في الخادم
  • سبب تغيير الاسم (غير مذكور في CHANGELOG)

10. الخلاصة

رسالة «API Error: The response stopped arriving» تعني أن الرد تدفق جزئيًا، ثم توقفت البيانات والاتصال لا يزال مفتوحًا، فقطعه مؤقّت المراقبة في Claude Code. وهي نفسها Response stalled mid-stream في الإصدارات السابقة لـ v2.1.227، والمخرجات المكتملة تبقى. تحقّق أولًا من حالة العمل، ثم أرسل continue.

إذا تكرر ظهورها، فجرّب بالترتيب: تحديث الإصدار، ثم عزل الـ VPN والوكيل والبوابة، ثم تقصير الرد الواحد. وفي البيئات التي يصمت فيها المسار طويلًا فقط، يمكنك تمديد مدة المراقبة على مستوى البايت. أما Connection lost mid-response، حيث ينقطع الاتصال نفسه، فموضع الاشتباه فيها مختلف، لذا قارن صياغة الرسالة أولًا. وقد جمعنا الأخطاء الأخرى في ملخص أخطاء Claude Code الشائعة وحلولها.

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

س. ماذا تعني رسالة «API Error: The response stopped arriving»؟
ج. تعني أن البيانات توقفت عن الوصول في منتصف تدفق الرد مع بقاء الاتصال مفتوحًا، فقطع مؤقّت المراقبة في Claude Code ذلك الاتصال. وهي الرسالة التي تظهر حين يحدث التوقف بعد اكتمال نص أو استدعاء أداة واحد، والمخرجات السابقة تبقى.

س. هل هي خطأ مختلف عن «Response stalled mid-stream»؟
ج. هي الشيء نفسه. ينص مرجع الأخطاء الرسمي صراحة على أن هذه الرسالة كانت Response stalled mid-stream قبل v2.1.227. تغيّر النص المعروض فقط، ولم يظهر نوع جديد من الأعطال.

س. بماذا أرد لأستأنف من حيث توقف؟
ج. أرسل continue، فيُستأنف العمل من آخر كتلة مكتملة. وإذا حدث التوقف أثناء عمليات على الملفات أو تنفيذ أوامر، فالأسلم أن تتحقق أولًا من الحالة الفعلية بـgit status أو ما شابهه ثم ترد.

س. هل تختفي إذا زدت عدد مرات إعادة المحاولة؟
ج. لا. في هذه الحالة صُمّم Claude Code على ألا يعيد الإرسال من البداية، تجنبًا لتنفيذ استدعاء الأداة نفسه مرتين. وCLAUDE_CODE_MAX_RETRIES لا يؤثر إلا في حالات الفشل التي تقع قبل بدء المخرجات.

س. ما الفرق بينها وبين «Connection lost mid-response»؟
ج. lost حكمٌ بأن الاتصال نفسه انقطع، وstopped arriving حكمٌ بأن الاتصال باقٍ لكن البيانات لم تعد تصل. في الحالتين تبقى المخرجات المكتملة ويمكن الاستئناف بـcontinue، لكن ضبط مدة المراقبة قد يفيد في حالة stopped arriving وحدها.

المصادر الأولية التي اعتمدنا عليها