تكون منهمكاً في عملك حين يتجمّد Claude Desktop فجأة فتموت معه كل جلسات Claude Code المفتوحة دفعةً واحدة. تُغلقه قسراً وتعيد تشغيله — وقد تكتشف عندئذ أن التطبيق نفسه لم يعد يبدأ أصلاً. وفي هذه الحالة يكون آخر سطر في السجلّ هو السطر نفسه في الغالب.

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

يوضّح هذا المقال ماذا يعني exitCode 101457950 (أي 0x060C201E)، ولماذا تُجرّ معه جلسات لا علاقة لها بالأمر، وأيّ العلاجات حقيقي وأيّها ليس كذلك.

⚠️ مستويات الثقة في هذا المقال: ✅ مُؤكَّد = مُسجَّل في مشكلة معلَنة على GitHub، أو مقيس على جهاز الكاتب / 🟡 حسب البلاغات = توجد بلاغات متعددة لكن دون تأكيد رسمي / 🔴 غير مؤكَّد = لا يمكن الجزم به. لم تنشر Anthropic أي تفسير رسمي لهذا العَرَض ولا أي إعلان عن إصلاح (ضمن ما أمكن التحقّق منه حتى 15 أغسطس 2026).

GPU PROCESS GONE · 0x060C201E

صفحة واحدة تُسقط كل الجلسات معها

— لأن عملية GPU مورد مشترك لا يوجد منه سوى نسخة واحدة لكل تطبيق

ما الذي يحدث
يصبح التطبيق بلا استجابة. لا ينهار بل يتجمّد، فلا يعود إلا بإغلاق قسري
نطاق الضرر
كل الجلسات المفتوحة. حتى المشاريع التي لا صلة لها تتوقّف في اللحظة نفسها
هل يمكن عزلها
لا. هذا من بنية Electron/Chromium، ولا يغيّره أي إعداد
كيف تُصلحه
إغلاق قسري ثم إعادة تشغيل. وإن لم يعد يبدأ فاختر «إصلاح»

1. الخلاصة — العطل ليس في Claude Code بل في الوعاء الذي يحتويه

لنبدأ بالفصل بين الأمور. قد تشعر أن «Claude Code انهار»، لكن المنهار ليس Claude Code (أي واجهة سطر الأوامر). المنهار هو عملية GPU في تطبيق سطح المكتب (Electron) الذي يستضيفه.

✅ مُؤكَّد: التمييز سهل — انظر إلى نهاية %APPDATA%\Claude\logs\main.log. إن كان السطر السابق مباشرةً لإعادة التشغيل هو GPU process gone فهذه هي حالتنا. ينقطع السجلّ عند تلك النقطة، ويكون السطر التالي Starting app.

والمهمّ أن ما يُفقد هو العملية لا البيانات. فسجلّ المحادثات والنصوص الكاملة مكتوبة على القرص، ويكفي أن تفتح الجلسة من جديد بعد إعادة التشغيل لتقرأ من حيث توقّفت. أما العمل الذي كان جارياً في تلك اللحظة فأمر آخر، ونعود إليه في §6.

2. العَرَض — لا «ينهار» بل «يتجمّد»

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

على جهاز الكاتب (Windows 11 / RTX 2080 Ti / ذاكرة 32GB)، وفي ثلاث حوادث لوحظت يوم 14 أغسطس 2026، بلغ أطول فاصل بين موت عملية GPU والإغلاق القسري نحو 30 دقيقة. وطوال تلك المدة ظلّت الجلسات الثماني المفتوحة متوقّفة كلها.

ثلاث علامات للتمييز

  • الأمر جماعي لا فردي — إن توقّفت جلسة واحدة فقط فالسبب مختلف. أما إن أعادت عدة جلسات التشغيل في الدقيقة نفسها فالتطبيق ذاته هو الذي سقط
  • ينقطع السجلّ في المنتصف — الخروج الطبيعي تتبعه أسطر إنهاء. أما هنا فتتوقّف الكتابة نفسها مباشرةً بعد GPU process gone
  • لا توجد ملفات تفريغ — إن لم يزدد عدد الملفات في %APPDATA%\Claude\Crashpad\ فالانهيار ليس انهياراً أصلياً في جانب واجهة سطر الأوامر

3. لماذا تُجرّ معه جلسات لا علاقة لها بالأمر

هذا هو جوهر العطل، وهو أيضاً سبب أنه ليس أمراً يمكن تدبيره بإعداد.

يُجمِّع Electron (أي Chromium) كل عمليات الرسم في عملية مخصّصة اسمها عملية GPU. ومن هذه العملية نسخة واحدة لكل تطبيق، تتشاركها جميع النوافذ وجميع الألسنة وجميع الجلسات.

بعبارة أخرى: إذا قتلت صفحةٌ واحدة فُتحت في المتصفح المدمَج عمليةَ GPU، سقطت معها في اللحظة نفسها جلساتٌ لا صلة لها بتلك الصفحة إطلاقاً. لا يوجد عزل لكل لسان ولا لكل جلسة. ✅ مُؤكَّد: هذا هو تصميم نموذج العمليات في Chromium، ولا يستطيع المستخدم فصلها بأي إعداد.

الجميع يتشارك عملية GPU واحدة

الجلسة A
مشروع مختلف
الجلسة B
مشروع مختلف
الجلسة C
تفتح صفحة ثقيلة
↓ ↓ ↓
عملية GPU (واحدة لكل تطبيق)
إن ماتت هذه، توقّف كل ما فوقها

4. المُشغِّل — المتصفح المدمَج هو الأكثر، لكنه ليس الوحيد

✅ مُؤكَّد: أكثر مُشغِّل يتكرّر في المشكلات المعلَنة هو المتصفح المدمَج (لوحة المتصفح). فـ#80444 يسجّل موت عملية GPU بعد 15 إلى 36 ثانية من تشغيل صفحةٍ مفتوحة في لسان المتصفح لفحص إمكانات WebGL/WebGPU، وبالرمز 0x060C201E نفسه في المرات الأربع كلها.

و#82967 أكثر تحديداً: فهو يحصر المُشغِّل في التقاط لقطة الشاشة الخاصة بالمعاينة ضمن أداة المتصفح (capturePreviewScreenshotIfChanged). ويبلّغ #83478 عن إعادة إنتاج المشكلة بترك «معاينة تتحدّث باستمرار» مفتوحة.

🟡 حسب البلاغات: لكن المتصفح ليس المُشغِّل الوحيد. فـ#68049 يبلّغ عن السقوط بالرمز نفسه عند بدء التشغيل على بيئة ARM64، دون أي تعامل مع المتصفح. و#83028 يذكر إعادة الإنتاج على بطاقة Intel المدمَجة. فلا يصحّ القول إن الأمر «لن يحدث أبداً ما دمت لا تستخدم المتصفح».

💡 قياس على جهاز الكاتب (لا يمكن تعميمه): أثناء بحث عن أدوات الذكاء الاصطناعي، كرّرتُ في اليوم نفسه نحو 18 مرة عملية فتح أربع صفحات متتالية في المتصفح المدمَج بفاصل ثانية إلى ثانيتين، فماتت عملية GPU في ثلاث منها. أي إنها لا تسقط في كل مرة، بل حين تتضافر تركيبة بعينها من الصفحات الثقيلة فقط. وهذه مُلاحَظة على جهاز واحد، فلا يمكن نقل معدّل التكرار نفسه إلى بيئات أخرى.

5. الجزم من السجلّات

لا تكتفِ بالتخمين: ثلاثة ملفات تكفي للجزم. وانتبه إلى أن دليلاً باسم ~/.claude/logs غير موجود أصلاً.

ما تنظر إليه المسار الحكم
التطبيق نفسه%APPDATA%\Claude\logs\main.logإن كان السطر السابق مباشرةً لإعادة التشغيل هو GPU process gone فهذه حالتنا
نافذة المتصفح%APPDATA%\Claude\logs\unknown-window.logإن ظهر CONTEXT_LOST_WEBGL في التوقيت نفسه، فسقوط GPU مرئي من جانب الرسم أيضاً
انهيار أصلي%APPDATA%\Claude\Crashpad\إن لم يزدد عدد ملفات التفريغ فالعطل ليس في جانب واجهة سطر الأوامر

⚠️ تحذير requestAdapter الذي يظهر في السجلّ نفسه ليس هو الجاني. فالسطر «The powerPreference option is currently ignored when calling requestAdapter() on Windows.» ليس علامةً على انهيار، بل هو رسالة عادية من Chromium تُعلمك بأن powerPreference لا مفعول له على Windows (Chrome for Developers / Chromium issue 40268366). ويظهر بمجرّد فتح صفحة تستخدم WebGPU حتى لو لم يسقط شيء. فلا تتّخذ من وجوده نفسه دليلاً.

ويمكن تمييز الخروج الطبيعي من رمز الخروج. فكلمة «انتهى» نفسها تحمل معاني مختلفة، ونريد أن نتعقّب ما يستحقّ التعقّب فقط.

exitCode بالنظام السداسي عشري المعنى
1014579500x060C201Eبصمة هذه الحالة. هذا ما يجب تعقّبه
-10737412050xC000026Bعند تسجيل الخروج أو إيقاف التشغيل. طبيعي
10738073640x40010004إنهاء متعمَّد. طبيعي

6. الاستعادة — متى يُعيده «إصلاح» ومتى لا يُعيده

الإغلاق القسري ثم إعادة التشغيل يكفيان في أغلب الأحيان. المشكلة في الحالة التي تحاول فيها إعادة التشغيل فتجد أن التطبيق لم يعد يبدأ أصلاً.

✅ مُؤكَّد: بعد انهيار GPU، قد يحكم Windows على حزمة MSIX بأنها «معدَّلة» فيرفض تشغيلها. ويسجّل #80444 ذلك في صورة appxState=2 (Modified)، ويبلّغ أن المسار الإعدادات ثم التطبيقات ثم Claude ثم الخيارات المتقدّمة ثم «إصلاح» أعاده في كل مرة. و#81836 يقول كذلك إن «إصلاح» يحلّها.

وما يلي هو أنفع جزء في هذا المقال في رأيي. توجد أيضاً بلاغات بأن «إصلاح» لا ينفع. فـ#82967 يصف حزمة بلغت حالتها Modified, NeedsRemediation، حيث كان «إصلاح» يفشل دائماً، ولم يُعد التطبيق سوى إزالة تثبيت كاملة ثم إعادة تثبيت.

الترتيب الذي تمضي فيه حين لا يعود يبدأ

  1. أنهِ العمليات المقيمة — ما دامت ممسكةً بالملفات فسيُرفض «إصلاح» بحجّة أن التطبيق قيد التشغيل
  2. «إصلاح» — الإعدادات ثم التطبيقات ثم التطبيقات المثبَّتة ثم Claude ثم الخيارات المتقدّمة. وتبقى بياناتك محفوظة
  3. وإن لم ينفع ذلك، أزل التثبيت وأعده (وستحتاج إلى تسجيل الدخول من جديد)

تفاصيل الخطوات، ومسألة ما إذا كانت المحادثات والجلسات تُمحى أم لا، مجموعة في خطوات إصلاح رسالة «Can't open this app».

وعن بياناتك. تبقى النصوص الكاملة على القرص، فيمكنك قراءتها من جديد بعد إعادة التشغيل. لكن #81698 يبلّغ بأن صاحبه «فقد العمل الجاري كله، وذهبت معه نتائج الوكلاء الفرعيين الذين كانوا يعملون بالتوازي». ما حُفظ يبقى، وما كان قيد التنفيذ لا يعود — وهذا فرق يستحقّ أن تُبقيه منفصلاً في ذهنك.

7. ما ينفع وما لا ينفع

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

◯ ما ينفع
  • لا تفتح الصفحات الثقيلة في المتصفح المدمَج. حوّلها إلى متصفح حقيقي
  • لا تفتح صفحات كثيرة دفعةً واحدة. باعِد بينها
  • لا تترك المعاينة مفتوحة باستمرار (شرط إعادة الإنتاج في #83478)
  • عطّل ميزة المتصفح نفسها — وهو الالتفاف الذي يذكره #82967. لكن ذلك يوقف ما ينشأ عن المتصفح فقط، ولا ينفع مع عائلة السقوط عند بدء التشغيل (#68049)
  • لا تراكم عملاً طويلاً في جلسة واحدة. فتصبح إعادة القراءة بعد الاستعادة أخفّ
× ما لا ينفع أو ما لا يمكن
  • --disable-gpu غير متاح — يرفضه إصدار MSIX برسالة «تم رفض الوصول» (#82967)
  • تحديث التطبيق لا يُصلحه — تكرّر العطل على جهاز الكاتب في نسخة لاحقة للتحديث
  • عزل عملية GPU — غير ممكن بنيوياً (§3)
  • تغيير جدولة GPU أو إعدادات تعريف البطاقة — جرّب صاحب #82967 عدة تغييرات وأبلغ بأن لا أثر لها

🟡 حسب البلاغات: إن كنت تستخدم بطاقة رسوم هجينة (تركيبة تبدّل بين المدمَجة والمنفصلة)، فقد يستحقّ الأمر أن تجرّب تثبيت أفضلية GPU لـ Claude من الإعدادات ثم النظام ثم الشاشة ثم الرسومات في Windows. والسند لذلك من جانب Chromium: تحديد GPU عبر powerPreference لا مفعول له على Windows — لأن Chrome لا يستطيع بعد أن يستخدم بطاقتين ويؤلّف بينهما، وهو أمر متعقَّب بوصفه Chromium issue 40268366. أي إن التطبيق لا يملك تثبيت البطاقة التي يرسم بها، فإن أردت تثبيتها فلا سبيل إلا إعدادات نظام التشغيل. لكن لم يُعثر على أي بلاغ يفيد بأن ذلك نفع في هذا العَرَض تحديداً، فلا تعقد عليه آمالاً كبيرة.

8. ظاهرة أخرى يسهل الخلط بينها وبينه — إنهاء قسري بسبب تحديث المتجر

إصدار Microsoft Store (أي MSIX) مُعطَّل فيه التحديث الذاتي للتطبيق. وبدلاً من ذلك يُنهي المتجر التطبيق العامل قسراً ليستبدله. وبما أن التطبيق يختفي فجأةً أثناء العمل، يسهل الخلط بينه وبين انهيار GPU.

والتمييز في السجلّ واضح. فعند تحديث المتجر يبقى سطر Windows session ending (close-app)، ولا يظهر GPU process gone. وإن تغيّر رقم الإصدار عند التشغيل التالي فقد حُسم الأمر.

وهذه لا مفرّ منها، فالتخفيف الوحيد هو إنهاء التحديثات قبل الدخول في عمل طويل.

الخلاصة

  • ما هو: ليس عطلاً في Claude Code، بل انهيار عملية GPU في تطبيق سطح المكتب (exitCode 101457950 / 0x060C201E)
  • لماذا يسقط كل شيء: عملية GPU مورد مشترك لا يوجد منه سوى نسخة واحدة لكل تطبيق. صفحة واحدة تُسقط كل الجلسات معها. ولا يمكن فصلها بإعداد
  • المُشغِّل: المتصفح المدمَج هو الأكثر. لكن توجد بلاغات بالسقوط عند بدء التشغيل أيضاً، فهو ليس الوحيد
  • خطوة الجزم: انظر إلى السطر السابق مباشرةً لإعادة التشغيل في main.log. إن كان GPU process gone فهذه حالتنا
  • الاستعادة: إغلاق قسري ثم إعادة تشغيل. وإن لم يعد يبدأ فاختر «إصلاح». وتوجد بلاغات بحالات تتقدّم إلى حدّ لا ينفع فيه «إصلاح»
  • البيانات: ما حُفظ يبقى، أما العمل الذي كان قيد التنفيذ فلا يعود
  • لم يصدر أي إعلان رسمي عن إصلاح (حتى 15 أغسطس 2026)

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

س. هل يُمحى سجلّ المحادثات؟

ج. لا. النصوص الكاملة مكتوبة على القرص، فيكفي أن تعيد فتحها بعد إعادة التشغيل لتقرأها. لكن ما كان يعمل لحظة الانهيار يضيع — وهناك بلاغ بضياع نتائج وكلاء فرعيين كانوا يعملون بالتوازي (#81698).

س. هل يُصلحه تحديث التطبيق؟

ج. ليس بالضرورة. فقد تكرّر العطل بالبصمة نفسها على جهاز الكاتب في نسخة لاحقة للتحديث. لكن #80444 يبلّغ عنه بوصفه ارتداداً (regression) بدأ من إصدار بعينه، فـمن الوارد أن يختلف احتمال ظهوره بين إصدار وآخر.

س. هل يُصلحه تحديث تعريف بطاقة الرسوم؟

ج. إجراء ضعيف. فلو كانت طبقة التعريف هي السبب لسُجِّل في سجلّ نظام Windows حدث TDR (المعرّف 4101)، ولم يظهر منه ولا حدث واحد على جهاز الكاتب خلال ثلاثين يوماً. كما يبلّغ #68049 بتكرار العطل رغم تحديث التعريف وإعادة تثبيت نظيفة.

س. أليس السبب نقص الذاكرة أو تضخّم النصوص الكاملة؟

ج. كلاهما استُبعد على جهاز الكاتب. فمجموع عمليات Electron كلها وقت الانهيار كان نحو 1.7GB، والذاكرة الحرة 14.8GB من أصل 31.9GB. وكانت هناك جلسة بلغ نصّها الكامل 98.5MB، لكن لا ارتباط بينها وبين توقيت السقوط.

س. وهل الأمر نفسه إن توقّفت جلسة واحدة فقط؟

ج. لا. هنا يتجمّد التطبيق نفسه، فالنمط جماعي دائماً. فإن توقّفت واحدة فقط فابحث عن سبب آخر. وإن كان الردّ ينقطع في منتصفه فحسب فتلك عائلة Connection closed mid-response وresponse stalled mid-stream.