काम के बीचोंबीच Claude Desktop अचानक जम जाता है और खुले हुए Claude Code के सारे सेशन एक साथ मर जाते हैं। ज़बरदस्ती बंद करके दोबारा चलाइए, तो कभी-कभी ऐप ख़ुद ही चालू नहीं होता — और ऐसे मौक़ों पर लॉग की आख़िरी पंक्ति लगभग हमेशा एक ही होती है।

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

यह लेख बताता है कि वह exitCode 101457950 (= 0x060C201E) है क्या, बिलकुल असंबंधित सेशन भी साथ में क्यों चले जाते हैं, और असल में कौन-से उपाय काम के हैं और कौन-से नहीं।

⚠️ इस लेख में इस्तेमाल हुए भरोसे के लेबल: ✅ पुष्ट = किसी सार्वजनिक issue में दर्ज है, या लेखक की मशीन पर ख़ुद मापा गया / 🟡 रिपोर्ट के आधार पर = रिपोर्टें कई हैं, पर आधिकारिक पुष्टि नहीं / 🔴 अपुष्ट = तथ्य की तरह नहीं कहा जा सकता। Anthropic ने इस लक्षण के लिए न वजह की कोई व्याख्या प्रकाशित की है, न सुधार की कोई घोषणा (15 अगस्त 2026 तक जितना देखा जा सका)।

GPU PROCESS GONE · 0x060C201E

एक टैब सारे सेशन अपने साथ ले डूबता है

— क्योंकि GPU प्रोसेस एक साझा संसाधन है, और हर ऐप में उसकी सिर्फ़ एक ही होती है

क्या होता है
ऐप जवाब देना बंद कर देती है। वह ग़ायब नहीं होती, जम जाती है — और जब तक ज़बरदस्ती बंद न करें, जमी ही रहती है
असर कहाँ तक
खुले हुए सारे सेशन पर। असंबंधित प्रोजेक्ट भी उसी पल रुक जाते हैं
क्या अलग किया जा सकता है?
नहीं। यह Electron/Chromium की बनावट से निकलता है, और कोई सेटिंग इसे बदलती नहीं
कैसे उबरें
ज़बरदस्ती बंद कीजिए, फिर दोबारा चलाइए। अगर अब चालू ही न हो, तो Repair

1. निष्कर्ष — ख़राबी Claude Code की नहीं, उसे ढोने वाले खोल की है

पहले दोनों को अलग कर लीजिए। महसूस भले «Claude Code क्रैश हो गया» जैसा होता हो, पर क्रैश Claude Code (CLI) नहीं हुआ है। क्रैश उस डेस्कटॉप ऐप (Electron) की GPU प्रोसेस हुई है, जिसके अंदर वह चलता है।

✅ पुष्ट: जाँच आसान है — %APPDATA%\Claude\logs\main.log का आख़िरी हिस्सा देख लीजिए। अगर दोबारा चालू होने से ठीक पहले वाली पंक्ति GPU process gone है, तो मामला यही है। लॉग वहीं कट जाता है, और अगली पंक्ति Starting app होती है।

और अहम बात यह है कि जो गँवाया जाता है वह एक प्रोसेस है, आपका डेटा नहीं। बातचीत का इतिहास और ट्रांसक्रिप्ट डिस्क पर लिखे जाते हैं, इसलिए दोबारा चालू करके सेशन खोलिए तो जहाँ छोड़ा था वहीं से पढ़ा जा सकता है। जो काम उसी वक़्त चल रहा था, उसकी बात अलग है — उस पर §6 में लौटेंगे।

2. लक्षण — यह «गिरता» नहीं, «जम» जाता है

इस ख़राबी की सबसे परेशान करने वाली बात यही है कि ऐप ग़ायब नहीं होती, बिना जवाब दिए वहीं बैठी रह जाती है। न कोई क्रैश डायलॉग आता है, न वह अपने आप दोबारा चालू होती है। जब तक आप ध्यान देकर उसे ज़बरदस्ती बंद न करें, वह बस जमी रहती है।

यहाँ इस्तेमाल हुई मशीन (Windows 11 / RTX 2080 Ti / RAM 32GB) पर 14 अगस्त 2026 को यह तीन बार हुआ, और GPU प्रोसेस के मरने से ज़बरदस्ती बंद करने तक का सबसे लंबा अंतराल क़रीब 30 मिनट रहा। उतनी देर खुले हुए आठों सेशन रुके ही रहे।

पहचानने के तीन तरीक़े

  • एक नहीं, सब — अगर सिर्फ़ एक सेशन रुका है तो वजह कोई और है। अगर एक ही मिनट में कई सेशन दोबारा चालू हुए हैं, तो ऐप ख़ुद गिरी है
  • लॉग बीच में कट जाता है — सामान्य ढंग से बंद होने पर बंद होने की प्रक्रिया की पंक्तियाँ आगे चलती रहती हैं। यहाँ GPU process gone के ठीक बाद लिखना ही रुक जाता है
  • कोई डंप नहीं — अगर %APPDATA%\Claude\Crashpad\ में डंप नहीं बढ़े हैं, तो यह CLI की तरफ़ का नेटिव क्रैश नहीं है

3. असंबंधित सेशन भी साथ में क्यों चले जाते हैं

यही इस ख़राबी की असली जड़ है, और यही वजह भी है कि यह सेटिंग से सुलझने वाली बात नहीं है।

Electron (Chromium) सारी रेंडरिंग एक ख़ास प्रोसेस में समेट देता है, जिसे GPU प्रोसेस कहते हैं। और यह प्रोसेस हर ऐप्लिकेशन में सिर्फ़ एक होती है। सारी विंडो, सारे टैब, सारे सेशन उसी को साझा करते हैं।

यानी in-app ब्राउज़र में खुला एक पन्ना अगर GPU प्रोसेस को मार दे, तो उस पन्ने से कोई नाता न रखने वाले सेशन भी उसी पल साथ में चले जाते हैं। टैब-दर-टैब या सेशन-दर-सेशन कोई अलगाव है ही नहीं। ✅ पुष्ट: Chromium के प्रोसेस मॉडल में यह डिज़ाइन से ही ऐसा है, और यूज़र की तरफ़ की किसी सेटिंग से इन्हें अलग नहीं किया जा सकता।

एक ही GPU प्रोसेस, और उसे सब साझा करते हैं

सेशन A
अलग प्रोजेक्ट
सेशन B
अलग प्रोजेक्ट
सेशन C
भारी पन्ना खोलता है
↓ ↓ ↓
GPU प्रोसेस (ऐप में एक ही)
यह मरी, तो ऊपर वाले सब रुक जाते हैं

4. ट्रिगर — in-app ब्राउज़र सबसे आम है, पर अकेला नहीं

✅ पुष्ट: सार्वजनिक issues में सबसे आम ट्रिगर in-app ब्राउज़र (ब्राउज़र पेन) है। #80444 में दर्ज है कि ब्राउज़र टैब में खुले पन्ने ने WebGL/WebGPU की फ़ीचर डिटेक्शन चलाई और उसके 15 से 36 सेकंड बाद GPU प्रोसेस मर गई — चारों बार वही 0x060C201E।

#82967 और भी ठोस है: वह ट्रिगर को ब्राउज़र टूल के प्रीव्यू के लिए स्क्रीनशॉट लेने (capturePreviewScreenshotIfChanged) पर टिकाता है। #83478 बताता है कि लगातार अपडेट होता प्रीव्यू खुला छोड़ने पर यह दोबारा हो जाता है।

🟡 रिपोर्ट के आधार पर: पर ट्रिगर सिर्फ़ ब्राउज़र नहीं है। #68049 ARM64 माहौल में चालू होते समय वही exitCode मिलने की रिपोर्ट करता है, जिसमें ब्राउज़र से कोई छेड़छाड़ शामिल ही नहीं। #83028 कहता है कि यह Intel के इंटीग्रेटेड GPU पर भी दोहराया जा सकता है। इसलिए यह नहीं कहा जा सकता कि «ब्राउज़र इस्तेमाल न करें तो यह कभी होगा ही नहीं»।

💡 यहाँ इस्तेमाल हुई मशीन पर की गई माप (इसे आम नियम नहीं बनाया जा सकता): AI टूल्स पर शोध करते हुए in-app ब्राउज़र में चार पन्ने 1–2 सेकंड के अंतर पर लगातार खोलने वाला काम उसी दिन क़रीब 18 बार किया गया, और उनमें से 3 बार 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\डंप नहीं बढ़े हैं, तो ख़राबी CLI की तरफ़ की नहीं है

⚠️ उसी लॉग में दिखने वाली requestAdapter की चेतावनी दोषी नहीं है। «The powerPreference option is currently ignored when calling requestAdapter() on Windows.» वाली पंक्ति क्रैश का संकेत नहीं है, बल्कि Chromium का सामान्य संदेश है, जो बताता है कि Windows पर powerPreference का असर नहीं होता (Chrome for Developers / Chromium issue 40268366)। WebGPU इस्तेमाल करने वाला कोई भी पन्ना खोलिए, यह बिना किसी क्रैश के भी दिख जाएगी। इसके मौजूद होने को अपने आप में सबूत मत मानिए।

exitCode से सामान्य समाप्ति को अलग पहचाना जा सकता है। «बंद होना» एक जैसा दिखने पर भी मतलब अलग-अलग होता है, और पीछे सिर्फ़ उसी के पड़ना चाहिए जिसके पीछे पड़ना ज़रूरी है।

exitCode हेक्स मतलब
1014579500x060C201Eइसी मामले का हस्ताक्षर। इसी के पीछे पड़ना है
-10737412050xC000026Bलॉग ऑफ़ / शटडाउन के समय। सामान्य
10738073640x40010004जान-बूझकर बंद करना। सामान्य

6. वापसी — जहाँ Repair से लौट आता है, और जहाँ नहीं

ज़बरदस्ती बंद करके दोबारा चला दीजिए, तो ज़्यादातर बार काम वहीं से चल पड़ता है। दिक़्क़त उन मामलों में है जहाँ दोबारा चलाने की कोशिश पर ऐप खुलती ही नहीं।

✅ पुष्ट: GPU क्रैश के बाद कभी-कभी Windows यह मान लेता है कि MSIX पैकेज «बदल दिया गया है», और उसे चलाने से इनकार कर देता है। #80444 ने इसे appxState=2 (Modified) के रूप में दर्ज किया और बताया कि Settings → Apps → Claude → advanced options → Repair से हर बार वापसी हो गई। #81836 भी यही कहता है कि Repair से ऐप लौट आती है।

इसके आगे का हिस्सा शायद इस लेख का सबसे काम का हिस्सा है। ऐसी रिपोर्टें भी हैं जहाँ Repair काम नहीं करता। #82967 में पैकेज की हालत Modified, NeedsRemediation तक पहुँच चुकी थी, और Repair हर बार फ़ेल हुआ; ऐप सिर्फ़ पूरी तरह हटाकर दोबारा इंस्टॉल करने पर लौटी।

जब ऐप चालू ही न हो, तो किस क्रम में

  1. बैकग्राउंड में चल रही प्रोसेस बंद कीजिए — वे फ़ाइलें पकड़े रहीं तो Repair «ऐप चल रही है» कहकर रुक जाएगा
  2. Repair — Settings → Apps → Installed apps → Claude → advanced options। डेटा बचा रहता है
  3. फिर भी न चले तो हटाकर दोबारा इंस्टॉल कीजिए (दोबारा साइन इन करना पड़ेगा)

क़दमों का पूरा ब्योरा, और बातचीत का इतिहास व सेशन मिटते हैं या नहीं — यह सब «Can't open this app» ठीक करने का तरीक़ा में है।

डेटा के बारे में। ट्रांसक्रिप्ट डिस्क पर बने रहते हैं, इसलिए दोबारा चालू करके उन्हें फिर पढ़ा जा सकता है। पर #81698 की रिपोर्ट है कि «जो काम चल रहा था वह पूरा का पूरा चला गया। समांतर चल रहे सबएजेंट के नतीजे भी सब मिट गए»। जो सहेजा जा चुका है वह रहता है, पर जो उसी वक़्त चल रहा था वह लौटता नहीं — इन दोनों को अलग-अलग समझ लेना बेहतर है।

7. जो किया जा सकता है, और जो नहीं

अफ़सोस कि जड़ से बचाने वाला कोई उपाय नहीं है। इतना ही हो सकता है कि ट्रिगर दबने के मौक़े कम कर दिए जाएँ — और उसमें भी «काम न करने की रिपोर्ट वाले» उपाय मिले हुए हैं, इसलिए दोनों को अलग-अलग लिख रहे हैं।

◯ जो किया जा सकता है
  • भारी पन्ने in-app ब्राउज़र में मत खोलिए। उन्हें असली ब्राउज़र में ले जाइए
  • एक साथ कई पन्ने मत खोलिए। बीच में अंतराल रखिए
  • प्रीव्यू खुला मत छोड़िए (#83478 में इसी शर्त पर दोबारा हुआ)
  • ब्राउज़र फ़ीचर ही बंद कर दीजिए — #82967 यही उपाय गिनाता है। पर इससे सिर्फ़ ब्राउज़र से शुरू होने वाले क्रैश रुकते हैं; चालू होते समय गिरने वाले सिलसिले (#68049) पर इसका असर नहीं
  • लंबा काम एक ही सेशन में जमा मत कीजिए। वापसी के बाद दोबारा पढ़ना हल्का रहेगा
× जो काम नहीं करता, या हो ही नहीं सकता
  • --disable-gpu इस्तेमाल नहीं हो सकता — MSIX वाले बिल्ड पर «access is denied» कहकर मना कर दिया जाता है (#82967)
  • ऐप अपडेट करने से ठीक नहीं होता — यहाँ इस्तेमाल हुई मशीन पर अपडेट के बाद वाले वर्शन में भी दोबारा हुआ
  • GPU प्रोसेस को अलग करना — ढाँचे के कारण संभव ही नहीं (§3)
  • GPU शेड्यूलिंग या ड्राइवर सेटिंग बदलना — #82967 कई चीज़ें आज़माकर बताता है कि कोई असर नहीं हुआ

🟡 रिपोर्ट के आधार पर: अगर आप हाइब्रिड GPU (इंटीग्रेटेड और डिस्क्रीट के बीच अदला-बदली वाला ढाँचा) इस्तेमाल कर रहे हैं, तो Windows की Settings → System → Display → Graphics में Claude के लिए GPU तय कर देना आज़माने लायक़ है। इसका आधार Chromium की तरफ़ है: Windows पर powerPreference से GPU चुनने का असर नहीं होता — क्योंकि Chrome अभी दो GPU का अलग-अलग इस्तेमाल करके कंपोज़िट नहीं कर पाता; इसे Chromium issue 40268366 के रूप में ट्रैक किया जा रहा है। यानी रेंडरिंग किस GPU पर हो, यह ऐप की तरफ़ से तय नहीं किया जा सकता, इसलिए तय करना हो तो OS की सेटिंग का ही सहारा है। पर इस लक्षण में इससे फ़ायदा हुआ हो, ऐसी कोई रिपोर्ट नहीं मिली, इसलिए इससे ज़्यादा उम्मीद मत रखिए।

8. मिलती-जुलती दिखने वाली अलग बात — Store के अपडेट से ज़बरदस्ती बंद होना

Microsoft Store (MSIX) वाले बिल्ड में ऐप का अपना ऑटो-अपडेट बंद कर दिया गया है। उसकी जगह Store चलती हुई ऐप को ज़बरदस्ती बंद करके उसे बदल देता है। काम के बीच ऐप अचानक ग़ायब हो जाती है, इसलिए इसे GPU क्रैश समझ लेना आसान है।

लॉग में फ़र्क़ साफ़ दिखता है। Store के अपडेट पर Windows session ending (close-app) वाली पंक्ति रह जाती है, और GPU process gone आता ही नहीं। अगली बार चालू करने पर वर्शन बदला हुआ मिले, तो बात पक्की।

इससे बचा नहीं जा सकता, इसलिए लंबे काम में उतरने से पहले अपडेट निपटा लेना ही इकलौता उपाय है।

निष्कर्ष

  • असल में है क्या: Claude Code की ख़राबी नहीं, डेस्कटॉप ऐप की GPU प्रोसेस का क्रैश (exitCode 101457950 / 0x060C201E)
  • सब क्यों चले जाते हैं: GPU प्रोसेस एक साझा संसाधन है और ऐप में एक ही होती है। एक टैब सारे सेशन ले डूबता है। सेटिंग से अलगाव संभव नहीं
  • ट्रिगर: सबसे आम in-app ब्राउज़र। पर चालू होते समय क्रैश होने की रिपोर्टें भी हैं, इसलिए यह अकेला नहीं
  • पक्का करने का तरीक़ा: main.log में दोबारा चालू होने से ठीक पहले वाली पंक्ति देखिए। GPU process gone हो तो मामला यही है
  • वापसी: ज़बरदस्ती बंद → दोबारा चालू। न खुले तो Repair। ऐसी रिपोर्टें भी हैं जहाँ बात Repair के काम न करने तक पहुँच जाती है
  • डेटा: सहेजा हुआ बचा रहता है, पर जो काम चल रहा था वह नहीं लौटता
  • सुधार की कोई आधिकारिक घोषणा नहीं आई है (15 अगस्त 2026 तक)

अक्सर पूछे जाने वाले सवाल

Q. क्या बातचीत का इतिहास मिट जाता है?

A. नहीं, वह नहीं मिटता। ट्रांसक्रिप्ट डिस्क पर लिखे जाते हैं, इसलिए दोबारा चालू करके सेशन खोलिए तो वे पढ़े जा सकते हैं। पर क्रैश के ठीक उसी पल जो काम चल रहा था, वह चला जाता है — समांतर चल रहे सबएजेंट के नतीजों समेत सब मिट जाने की रिपोर्ट है (#81698)।

Q. ऐप अपडेट कर दें तो ठीक हो जाएगा?

A. ज़रूरी नहीं। यहाँ इस्तेमाल हुई मशीन पर अपडेट के बाद वाले वर्शन में भी वही हस्ताक्षर दोबारा मिला। हालाँकि #80444 इसे एक ख़ास वर्शन से शुरू हुआ regression बताता है, इसलिए वर्शन के हिसाब से इसके होने के आसार बदल सकते हैं।

Q. GPU का ड्राइवर अपडेट कर दें तो ठीक हो जाएगा?

A. यह कमज़ोर उपाय है। अगर वजह ड्राइवर की परत में होती, तो Windows के सिस्टम लॉग में TDR (इवेंट ID 4101) दर्ज होता; पर यहाँ इस्तेमाल हुई मशीन पर 30 दिन में एक भी नहीं मिला। #68049 भी बताता है कि ड्राइवर अपडेट और साफ़-सुथरे दोबारा इंस्टॉल के बाद भी यह दोबारा हुआ।

Q. कहीं वजह मेमोरी की कमी या ट्रांसक्रिप्ट का बहुत बड़ा हो जाना तो नहीं?

A. यहाँ इस्तेमाल हुई मशीन पर दोनों बातें ख़ारिज हो गईं। क्रैश के समय Electron की सारी प्रोसेस मिलाकर क़रीब 1.7GB थीं, और 31.9GB में से 14.8GB मेमोरी ख़ाली थी। एक सेशन का ट्रांसक्रिप्ट 98.5MB तक बढ़ चुका था, फिर भी गिरने के समय से उसका कोई संबंध नहीं दिखा।

Q. अगर सिर्फ़ एक सेशन रुका हो, तो क्या यह वही मामला है?

A. नहीं। इसमें ऐप ख़ुद जम जाती है, इसलिए यह हमेशा «सब एक साथ» वाला ही होता है। सिर्फ़ एक रुका हो तो किसी और वजह पर शक कीजिए। अगर जवाब बस बीच में कट जाता है, तो वह Connection closed mid-response या response stalled mid-stream वाले सिलसिले की बात है।