विषय-सूची

अगर आपने Claude Code में लंबे सेशन चलाए हैं, तो शायद आपने अचानक स्क्रीन पर एक अजीब-सी स्ट्रिंग स्ट्रीम होते देखी होगी:

court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…description of the command…</parameter>
</invoke>

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

एक tool call (एक कमांड) जो परदे के पीछे चलना चाहिए था, वह कच्चे टेक्स्ट के रूप में चैट में लीक हो जाता है — और कभी एक्जीक्यूट नहीं होता। इसके सबसे आगे एक बेमतलब शब्द बैठा होता है, court (या call)। यह सोचकर घबराना स्वाभाविक है कि "क्या मेरी मशीन खराब हो गई?" या "क्या मैंने कुछ गलत कॉन्फ़िगर किया?" लेकिन छोटा-सा जवाब यह है: यह न तो आपका एनवायरनमेंट है, और न ही आपकी कमांड।

यह एक मॉडल-साइड की गड़बड़ी है जिसमें Claude (खासकर Opus 4.8 / 4.7 परिवार) tool call के "कंट्रोल टैग" को ठीक उसी क्षण भ्रष्ट कर देता है जब वह उन्हें जनरेट करता है। Anthropic की आधिकारिक रिपॉज़िटरी में इस बारे में कई खुले issue हैं (#64108, #64150, #64690, #65705, #66153, #67295, #68354, और भी)। यह लेख तंत्र, कारण, आम गलतफहमियाँ, उपयोगकर्ता/डेवलपर के लिए समाधान, इसे मिलती-जुलती त्रुटियों से अलग कैसे पहचानें, और आधिकारिक स्थिति को सामने रखता है — Anthropic के दस्तावेज़ों और असली issues पर आधारित। सबसे ज़रूरी कदम, सबसे पहले: जब court दिखे, तो उस सेशन में जूझते मत रहिए — जल्दी से एक नए सेशन (/clear) पर निकल जाइए। इसकी वजह नीचे समझाई गई है।

CLAUDE CODE · TOOL CALL LEAK

"court" + लीक हुए invoke टैग असल में क्या हैं

— एक कंट्रोल टैग टूटा हुआ जनरेट होता है, इसलिए एक्जीक्यूट होने के बजाय स्क्रीन पर लीक हो जाता है

claude-code — opus-4.8 (1M)
एडिट करने से पहले उस फ़ाइल का बैकअप ले लेता हूँ…
court ← 1) भ्रष्ट कंट्रोल टोकन
<invoke name="Bash">
<parameter name="command">cp file file.bak</parameter>
</invoke> ← 2) जो XML चलना चाहिए था, वह कच्चा दिख रहा है
Your tool call was malformed and could not be parsed.
↑ 3) fail-closed के तहत खारिज → कमांड कभी नहीं चलती

एक टूटी कॉल पार्स नहीं हो सकती, इसलिए वह कभी एक्जीक्यूट नहीं होती (fail-closed) — गलत कमांड चलने का कोई खतरा नहीं।
असली समस्याएँ हैं एक बर्बाद हुआ टर्न, और अगर अनदेखा छोड़ दें तो एक "चेन रिएक्शन"।

1. असल में हो क्या रहा है — "court" टोकन और invoke टैग

जो <invoke name="Bash"> और <parameter name="command"> आपको दिखते हैं, वे असल में "tool-call मार्कअप" हैं जिन्हें आपको कभी देखना ही नहीं चाहिए। जब Claude कोई कमांड चलाता है या फ़ाइल एडिट करता है, तो वह इन XML-शैली के संरचित टैग को टोकन के रूप में जनरेट करता है, और Claude Code (हार्नेस) उन्हें पार्स करके कमांड को असल में चलाता है। सामान्यतः हार्नेस इन टैग को सोख लेता है, वे कभी स्क्रीन तक नहीं पहुँचते, और आपको सिर्फ टूल का परिणाम दिखता है।

लेकिन इस बार, tool call का "शुरुआती कंट्रोल टोकन" टूटा हुआ जनरेट हुआ, जिसके सबसे आगे असंबंधित शब्द court या call घुस गया। हार्नेस केवल सख्त सिंटैक्स पर प्रतिक्रिया करता है, इसलिए वह तय कर लेता है कि "यह tool call नहीं है, बस टेक्स्ट है" और उसे सीधे स्क्रीन पर स्ट्रीम कर देता है। कमांड नहीं चलती, और आपको मिलता है "Your tool call was malformed and could not be parsed." कुछ मामलों में कोई एरर मैसेज भी नहीं आता और यह बस चुपचाप अटक जाता है (issue #65705 में जवाब stop_reason=end_turn के साथ लौटा जिसमें एक्जीक्यूट करने को कुछ नहीं था, इसलिए बातचीत अटक गई)।

शब्द court का अपने आप में कोई अर्थ नहीं है। लेकिन यह पूरी तरह यादृच्छिक, एक-बार का शब्द भी नहीं है — कई स्वतंत्र रिपोर्टों में, लीक court / call के रूप में चौंकाने वाली एकरूपता से सामने आता है। Issue #64690 इसका विश्लेषण इस तरह करता है कि "सही टैग के बजाय शब्दावली में पास का एक टोकन चुन लिया जा रहा है।" दूसरे शब्दों में, court को सबसे अच्छे तरीके से एक संकेत (signature) समझा जा सकता है जो इस बग को पहचानने में मदद करता है।

2. पृष्ठभूमि: एजेंट अपने tool call भी "जनरेट" करता है

आखिर एक "कंट्रोल टैग" टूट कैसे सकता है? कुंजी यह है कि एक AI एजेंट के लिए, tool call आखिरकार बस टेक्स्ट जनरेशन है।

जब आप Claude API के साथ टूल इस्तेमाल करते हैं, तो जो फॉर्मेट आपको डेवलपर के रूप में दिखता है वह JSON (एक tool_use ब्लॉक) है। लेकिन अंदरूनी तौर पर, मॉडल एक छिपे हुए सिस्टम प्रॉम्प्ट का पालन करता है जिसे Anthropic स्वचालित रूप से डालता है और लपेटने वाले टैग <function_calls>, <invoke>, और <parameter> को टोकन की एक धारा के रूप में जनरेट करता है। फिर API परत इन्हें पार्स करती है और एक साफ tool_use JSON ब्लॉक में बदल देती है (आधिकारिक tool-use दस्तावेज़ के अनुसार)। MCP और AI एजेंट में हर "tool call" इसी तंत्र के ऊपर चलता है।

यहाँ जो मायने रखता है वह यह है कि हार्नेस पार्सर "fail-closed" है (यह सुरक्षित पक्ष की ओर झुकता है)। अगर कोई टैग अपेक्षित रूप से एक टोकन भर भी अलग हो, तो हार्नेस अंदाज़ा लगाकर उसे चलाता नहीं — वह उसे तुरंत malformed मानकर खारिज कर देता है। यह सही हार्नेस डिज़ाइन है: किसी अस्पष्ट कमांड को "मददगार बनकर सुधारकर" चला देना कहीं ज़्यादा खतरनाक होता। इसलिए यह पूरा परिघटना "टूटा → खारिज हुआ → चला नहीं" का एक मामला है — दूसरे शब्दों में, यह सुरक्षित रूप से विफल हुआ।

एक वाक्य में

tool call "विशेष टैग वाला टेक्स्ट" है जिसे मॉडल जनरेट करता है। जब उन टैग का शुरुआती टोकन जनरेशन के दौरान टूट जाता है, तो हार्नेस उसे पहचान नहीं पाता, इसलिए वह सामान्य टेक्स्ट में लीक हो जाता है और चलता नहीं। खारिज करना अपने आप में एक सही सुरक्षा तंत्र है; बग पूरी तरह मॉडल-साइड जनरेशन में है।

3. ऐसा क्यों होता है — दो मूल कारण और ट्रिगर

असली issues को मिलाकर देखें तो कारण "(1) जनरेशन के समय भ्रष्टता" और "(2) स्व-विषाक्तता से चेन रिएक्शन" में बँटता है, जो इसे खतरनाक बनाता है।

2 ROOT CAUSES

यह कैसे टूटता है, और फिर "चेन" बनता है

कारण 1 · कंट्रोल-टोकन जनरेशन भ्रष्टता
tool call का शुरुआती टैग, सैंपलिंग की हलचल के कारण, पास के टोकन (court / call) में बदल जाता है। नेमस्पेस प्रिफिक्स भी छूट जाता है, और हार्नेस उसे पहचान नहीं पाता। एनवायरनमेंट-स्वतंत्र (Win/mac/Linux पर दोहराया गया — #68354)।
कारण 2 · स्व-विषाक्तता से चेन रिएक्शन
एक बार टूटा ब्लॉक बातचीत के इतिहास में रह जाता है, तो मॉडल उसे एक सही उदाहरण समझकर उसकी नकल कर लेता है। यही वजह है कि दोबारा कोशिश उल्टी पड़ती है और विफलता निश्चित रूप से दोहराती है (#64150, #62344)।
वे स्थितियाँ जो संभावना बढ़ाती हैं (रिपोर्ट की गई; कार्य-कारण अप्रमाणित)
· बहुत लंबे / कई दिनों तक फिर से शुरू किए गए सेशन; भारी 1M-स्केल कॉन्टेक्स्ट (#65705: 3 दिनों में 1,739 लाइनें)
· एक ही मैसेज में कई tool call / किसी टेक्स्ट के ठीक बाद रखी गई tool call (#66153)
· /compact चलाने के ठीक बाद की स्थिति (#67295: compact के बाद पहली कॉल पर ही दोहराता है)
· बैकग्राउंड Bash (run_in_background) या 3+ कनेक्टेड MCP सर्वर (#64690)
· पैराग्राफ जितने लंबे tool आर्गुमेंट (#49747: एक अलग वैरिएंट जहाँ XML, JSON में रिस जाता है)

मुख्य बात: टूटना अपने आप में दुर्लभ सैंपलिंग हलचल है। असली खतरनाक हिस्सा है (2) की चेन —
यही कारण है कि "उसी सेशन में बार-बार रीट्राई करते रहना" सबसे बुरा कदम हो सकता है।

4. तीन आम गलतफहमियाँ, सही की गईं

इस परिघटना के बारे में जानकारी आसानी से गड्डमड्ड हो जाती है। सही प्रतिक्रिया देने के लिए, यहाँ तीन आम गलतफहमियाँ सीधी की गई हैं।

आम धारणाहकीकत
"टूल बेकाबू हो गया / खराब हो गया"इसके उलट। टूटी कॉल को बिना एक्जीक्यूट किए खारिज कर दिया गया (fail-closed)। गलत कमांड चलने का कोई खतरा नहीं; जो हुआ वह बस "एक बर्बाद टर्न + एक दृश्य लीक" था। यह सुरक्षित रूप से विफल हुआ।
"बस रीट्राई करो — छोड़ दो तो खुद ठीक हो जाता है"आधा ही सच। हल्का मामला एक रीट्राई में ठीक हो जाता है, लेकिन एक बार टूटा ब्लॉक इतिहास में बैठ जाए तो मॉडल उसकी नकल करके चेन बनाता है। #65705 में 5+ घंटों में लगातार 14 विफलताएँ हुईं; #66153 में एक सेशन में 30+। उसी सेशन में जूझना उल्टा पड़ता है।
"court का कोई मतलब है / यह एक कमांड है"इसका कोई मतलब नहीं — बस एक भ्रष्ट कंट्रोल टोकन का मलबा है। लेकिन court/call एक मार्कर के रूप में बार-बार लौटते हैं, इसलिए ये एक डायग्नोस्टिक संकेत के तौर पर उपयोगी हैं।

दूसरी बात सबसे ज़्यादा मायने रखती है। घटना की रिपोर्टें अक्सर कहती हैं "रीट्राई पर ठीक हो गया, कोई समस्या नहीं" — लेकिन यह केवल चेन शुरू होने से पहले के "हल्के" मामले पर लागू होता है। इस बग का सार यह है कि एक बार चेन मोड में घुस जाने के बाद, उस सेशन में कितनी भी रीट्राई करें, यह ठीक नहीं होगा।

5. अभी ठीक करें (Claude Code उपयोगकर्ताओं के लिए)

प्रतिक्रिया इस पर निर्भर करती है कि "आप अभी भी हल्के में हैं, या चेन शुरू हो चुकी है?" प्राथमिकता के क्रम में:

USER FIXES

प्राथमिकता का क्रम

FIX 1 · नए सेशन पर निकलें (सर्वोच्च प्राथमिकता)
जब court दिखे, जल्दी /clear करें या नया सेशन शुरू करें। विषाक्त इतिहास को काट देना सबसे भरोसेमंद है। निकलने से पहले git commit या एक हैंडऑफ़ नोट से स्थिति सहेज लें।
FIX 2 · ठीक एक बार रीट्राई करें (हल्का मामला)
पहली, इक्का-दुक्का घटना पर, "जारी रखो" कहकर उकसाने पर अक्सर यह सही दोबारा निकाल देता है (#66153 में "resume" टाइप करने पर ठीक हुआ)। लेकिन अगर लगातार दो बार विफल हो, तो जूझना बंद करें और FIX 1 पर जाएँ।
FIX 3 · हल्का वर्कलोड चलाएँ
लंबे, कई दिनों के सेशन से बचें। एक मैसेज में बहुत कुछ मत ठूँसें। ध्यान दें कि /compact के ठीक बाद इसके दोहराने की रिपोर्ट है — यह भरोसेमंद समाधान नहीं।

नियम: "दो बार चूको, सेशन छोड़ दो और नए से शुरू करो।"
विषाक्त इतिहास में जितना जूझेंगे, घाव उतना गहरा होगा। CLI को अपडेट रखें (पर ध्यान दें: अभी तक कोई फिक्स नहीं आया है — अपडेट करना स्वच्छता है, कोई जादुई इलाज नहीं)।

सुझाव: अगर आप नियमित रूप से अपनी स्थिति git या एक .md हैंडऑफ़ नोट में सहेजते हैं, तो किसी भी पल नए सेशन में जाने में आपका कुछ नहीं जाता। आप जितने ज़्यादा लंबे स्वायत्त सेशन चलाते हैं, यह आदत उतनी ही फलदायी होती है (और यह सीधे आपके कॉन्टेक्स्ट विंडो के प्रबंधन से जुड़ती है)।

6. डेवलपर्स के लिए: API/SDK से रोकें

अगर आप Claude API / SDK पर अपना खुद का एजेंट बनाते हैं, तो आप अपने हार्नेस में निम्नलिखित बचाव जोड़ सकते हैं। issue #65705 में प्रस्तावित डिटेक्शन लॉजिक व्यावहारिक है।

// प्राप्त assistant टर्न को एक्जीक्यूट करने से पहले जाँचें
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);
}

// truncation से आई अधूरी 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) tool आर्गुमेंट छोटे रखें और लंबे आउटपुट को बाँटें (#49747 के लंबे-पेलोड वैरिएंट से बचें)। Claude Agent SDK जैसे आधिकारिक हार्नेस का उपयोग करते समय भी, यह समझना सार्थक है कि लंबे चलने वाले लूप कैसे व्यवहार करते हैं।

7. मिलती-जुलती त्रुटियों से फर्क कैसे करें

"टूल नहीं चलेगा" तरह की कई त्रुटियाँ हैं, और उन्हें अलग-अलग समाधान चाहिए। इन चारों को अलग पहचानें ताकि आप उन्हें भ्रमित न करें।

लक्षणअसल में यह क्या हैमुख्य समाधान
court / call + कच्चे invoke टैग दिखे, एक्जीक्यूट नहीं हुएइस लेख का विषय। कंट्रोल-टोकन जनरेशन भ्रष्टता + स्व-विषाक्तता से चेनिंगनए सेशन (/clear) को प्राथमिकता दें; दो बार चूकने के बाद मत जूझें
400 "thinking blocks cannot be modified" सेशन को अटका देता हैएक्सटेंडेड थिंकिंग में एक signature बेमेल (एक अलग बग)। एक API हार्ड एररसमर्पित लेख देखें (Esc×2 / rewind)
जवाब बीच धारा में कट जाता है (कोई गड़बड़ XML नहीं)max_tokens तक पहुँचने से एक सामान्य truncation। कोई एरर नहींmax_tokens बढ़ाएँ और दोबारा चलाएँ
Bedrock, LangChain आदि पर XML संरचित नहीं होताएक थर्ड-पार्टी क्लाइंट जो Anthropic के फॉर्मेट को पार्स करने में विफल है (langchain-aws #521)। आधिकारिक API / Claude Code पर नहीं दोहराताइंटीग्रेशन लाइब्रेरी / होस्टिंग परत की दोबारा जाँच करें

फर्क पहचानने की धुरी सरल है। अगर आपको "court / call गड़बड़ी + कच्चा XML" दिखे, तो यह यही बग है। एक 400 signature एरर thinking-block एरर है। एक साफ कटाव बस आउटपुट सीमा है। केवल Bedrock पर या LangChain के ज़रिए इंटीग्रेशन परत की ओर इशारा करता है। अन्य आम Claude Code त्रुटियों के लिए, एरर संग्रह देखें।

8. आधिकारिक स्थिति

जून 2026 तक, ऐसा कोई पुष्ट आधिकारिक फिक्स (चेंजलॉग एंट्री) नहीं है जो कहे कि यह परिघटना सुलझ गई है। नवीनतम Claude Code (2.1.183 लाइन) तक रिलीज़ नोट्स खंगालने पर भी, tool-call सीरियलाइज़ेशन भ्रष्टता को संबोधित करने वाली कोई एंट्री नहीं है, और कई संबंधित issues खुले रहते हैं, या "duplicate / stale" के रूप में दर्ज हैं। इसलिए इस लेख का हर समाधान आधिकारिक फिक्स की प्रतीक्षा में एक वर्कअराउंड है, और आप यह दावा नहीं कर सकते कि "नवीनतम संस्करण में अपडेट करने से यह ठीक हो जाता है" (अपडेट करने की सिफारिश है, पर यह कोई गारंटीशुदा इलाज नहीं)।

फिर भी, "टूटी कॉल को अंदाज़ा लगाकर चलाने के बजाय खारिज कर देने" का fail-closed हार्नेस डिज़ाइन अपने आप में सही है। जिसे ठीक करने की ज़रूरत है वह मॉडल की जनरेशन स्थिरता है — पार्सर को ढीला करके "सुधारकर फिर भी चला देना" नहीं, जो गलत कमांड चलने का गंभीर खतरा बुलाएगा। उपयोगकर्ता के रूप में हम सबसे अच्छी चीज़ यही कर सकते हैं कि चेन से बचने के लिए संचालन करें, और दोहराव होने पर अपने एनवायरनमेंट और लॉग के साथ आधिकारिक issues में रिपोर्ट करें (ज़्यादा रिपोर्टें प्राथमिकता बढ़ाती हैं और फिक्स को तेज़ करती हैं)।

9. रोकथाम चेकलिस्ट

Claude Code उपयोगकर्ता: (1) जब court/call दिखे, अधिकतम दो बार रीट्राई करें; अगर बना रहे, तो तुरंत /clear / नया सेशन। (2) बहुत लंबे / कई दिनों के सेशन से बचें; ब्रेकपॉइंट पर काम git/नोट्स में सहेजें। (3) एक मैसेज में कई tool call मत ठूँसें। (4) याद रखें कि /compact कोई रामबाण नहीं है (इसके ठीक बाद दोहरा सकता है)। (5) CLI को अपडेट रखें, और दोहराव को आधिकारिक issues में रिपोर्ट करें।

API/SDK डेवलपर: (1) हमेशा stop_reason जाँचें। (2) टेक्स्ट में <invoke name= / function_calls के लीक का पता लगाएँ और रीट्राई करें। (3) टूटी कॉल को इतिहास में मत रखें (स्व-विषाक्तता रोकें)। (4) tool आर्गुमेंट छोटे रखें; लंबे आउटपुट को बाँटें। (5) max_tokens कटाव से आई अधूरी tool_use को कभी एक्जीक्यूट मत करें — उसके बजाय रीट्राई करें।

सारांश

Claude Code में, "court / call + एक कच्चा <invoke> टैग दिखे, और टूल एक्जीक्यूट न हो" एक मॉडल-साइड गड़बड़ी है जिसमें Claude (Opus 4.8 / 4.7 परिवार) tool call के कंट्रोल टोकन को टूटे रूप में जनरेट कर देता है। हार्नेस उसे fail-closed तरीके से खारिज कर देता है, इसलिए गलत कमांड चलने का कोई खतरा नहीं (यह सुरक्षित रूप से विफल हुआ)। असली खतरनाक हिस्सा यह है कि एक बार टूटा ब्लॉक इतिहास में रह जाए, तो मॉडल उसकी नकल करके "चेन" बनाता है। इसलिए "रीट्राई से ठीक हो जाता है" केवल हल्के में सच है, और नियम बन जाता है "दो बार चूको, नए सेशन पर निकलो।"

कारण दो-परतों में है: (1) कंट्रोल-टोकन जनरेशन भ्रष्टता + (2) स्व-विषाक्तता से चेनिंग। ट्रिगर में शामिल हैं लंबे / कई दिनों के सेशन, भारी कॉन्टेक्स्ट, /compact के बाद की स्थिति, एक साथ कई टूल, 3+ MCP सर्वर, और लंबे tool आर्गुमेंट। चूँकि जून 2026 तक कोई आधिकारिक फिक्स नहीं आया है, हर उपाय एक वर्कअराउंड है। उपयोगकर्ताओं को "नए सेशन को प्राथमिकता दें + स्थिति बार-बार सहेजें"; डेवलपर्स को "stop_reason जाँचें, लीक डिटेक्शन पर रीट्राई करें, टूटे इतिहास को कभी न रखें, और आर्गुमेंट छोटे करें।" इसके साथ thinking-block 400 एरर, Claude Code एरर संग्रह, और MCP पढ़ने से आप tool-call से जुड़ी परेशानियों के प्रति कहीं ज़्यादा मज़बूत बन जाएँगे।

FAQ

Q. मेरी स्क्रीन पर दिखा "court" या invoke टैग क्या मेरी कमांड या सेटिंग्स की गलती से है?
A. नहीं — लगभग निश्चित रूप से नहीं। यह एक ज्ञात मॉडल-साइड गड़बड़ी है जिसमें Claude tool-call टैग को टूटे रूप में जनरेट कर देता है, और Anthropic की आधिकारिक रिपॉज़िटरी में कई issues दर्ज हैं (#64108, #65705, #66153, और भी)। यह आपके एनवायरनमेंट, कमांड या सेटिंग्स की गलती नहीं है। court/call को बग के एक "संकेत" के रूप में लें।

Q. क्या ऐसा होने पर कोई गलत कमांड चलकर मेरे सर्वर या फ़ाइलों को नुकसान पहुँचा सकती है?
A. नहीं। एक टूटी tool call को "malformed" मान लिया जाता है और बिना एक्जीक्यूट किए खारिज कर दिया जाता है (fail-closed डिज़ाइन)। बस इतना होता है कि टर्न बर्बाद हो जाता है और कंट्रोल टेक्स्ट दिखाई देने लगता है; आपके डेटा या सर्वर की स्थिति पर कोई असर नहीं। इसे सुरक्षित रूप से विफल होने के लिए डिज़ाइन किया गया है।

Q. मैंने सुना कि "बस रीट्राई करो और यह खुद ठीक हो जाता है।" क्या यह सच है?
A. केवल तब जब यह हल्का हो। पहली, इक्का-दुक्का घटना पर, "जारी रखो" कहकर उकसाने पर अक्सर यह सही दोबारा निकाल देता है। लेकिन एक बार टूटा ब्लॉक बातचीत के इतिहास में रह जाए, तो मॉडल उसे एक टेम्पलेट के रूप में इस्तेमाल करता है और वही भ्रष्टता दोहराता है (स्व-विषाक्तता)। उस मुकाम पर उसी सेशन में रीट्राई उल्टी पड़ती है। अगर लगातार दो बार विफल हो, तो जूझना बंद करें और एक नए सेशन (/clear) पर जाएँ।

Q. क्या /compact इसे ठीक कर देगा?
A. भरोसेमंद तरीके से नहीं। कॉन्टेक्स्ट को कॉम्पैक्ट करना कभी-कभी मदद करता है, लेकिन issue #67295 में यह /compact के ठीक बाद पहली ही tool call पर दोहरा गया। सबसे भरोसेमंद कदम /compact नहीं, बल्कि एक नया सेशन (/clear) है जो इतिहास को पूरी तरह रीसेट कर देता है। निकलने से पहले अपनी काम की स्थिति git या नोट्स में सहेज लें।

Q. क्या Claude Code को नवीनतम संस्करण में अपडेट करने से यह ठीक हो जाएगा?
A. आप यह नहीं कह सकते कि यह "ठीक" हो जाता है। जून 2026 तक फिक्स की पुष्टि करने वाली कोई आधिकारिक चेंजलॉग एंट्री नहीं है, और कई संबंधित issues खुले या duplicate बने हुए हैं। अपडेट करना स्वच्छता के तौर पर अनुशंसित है, पर यह कोई जादुई इलाज नहीं। फिलहाल सबसे अच्छा तरीका है चेन से बचने के लिए संचालन करना (दो बार चूको → नया सेशन) और दोहराव को आधिकारिक issues में रिपोर्ट करना।