Claude Code 2.1.310: गेटवे त्रुटियाँ और Windows हुक सुधार

अगर Claude Code गेटवे के ज़रिए अनुरोध भेजते समय Unexpected value(s) के साथ effort-2025-11-24 का उल्लेख करता है, या Unexpected role "system" त्रुटि देता है, तो 2.1.310 या नए संस्करण में अपडेट करें और प्रभावित बातचीत में अनुरोध दोबारा भेजें। Windows पर काम करने वाली टीमों को यह भी जाँचना चाहिए कि हुक का इंटरप्रेटर विफल होने पर टूल कॉल सचमुच रुकती है या नहीं। अगर cleanupPeriodDays का बहुत बड़ा मान रखने के दौरान पेस्ट की गई इमेज गायब हुई हैं, तो डेटा रखने की अवधि बदलने से पहले बचा हुआ डेटा सुरक्षित करें।

2026-10-25 तक उपलब्ध 2.1.310 के आधिकारिक रिलीज़ नोट्स गेटवे, Windows हुक और सफ़ाई से जुड़ी इन समस्याओं के सुधार की पुष्टि करते हैं। नीचे हर समस्या की जाँच अलग से दी गई है।

पुष्टि करें कि टर्मिनल 2.1.310 या नया संस्करण चला रहा है

पहले जाँचें कि आपका टर्मिनल कौन-सी executable फ़ाइल चला रहा है, फिर उसी इंस्टॉलेशन विधि से अपडेट करें जिसे आप पहले से इस्तेमाल करते हैं। Bash में, या बिना बदलाव के Windows PowerShell में, ये कमांड चलाएँ:

claude --version
claude doctor

claude doctor इंस्टॉलेशन और सेटिंग्स की केवल जाँच करता है; उन्हें बदलता नहीं है। संस्करण का आउटपुट रख लें, ताकि अपडेट के बाद उससे तुलना कर सकें।

Anthropic के इंस्टॉलेशन और अपडेट निर्देशों में से अपने इंस्टॉलेशन के अनुसार कमांड चुनें:

मौजूदा इंस्टॉलेशन	शेल	अपडेट कमांड
नेटिव इंस्टॉलर	Bash या PowerShell	claude update
Homebrew का stable cask	Bash	brew upgrade claude-code
Homebrew का latest cask	Bash	brew upgrade claude-code@latest
WinGet	PowerShell	winget upgrade Anthropic.ClaudeCode
npm	Bash या PowerShell	npm install -g @anthropic-ai/claude-code@latest

नेटिव अपडेट कॉन्फ़िगर किए गए रिलीज़ चैनल का पालन करते हैं। Homebrew का claude-code cask stable चैनल से आता है, जबकि claude-code@latest latest चैनल से; इसलिए अपडेट सफल होने के बाद भी संस्करण आपकी ज़रूरत से पुराना हो सकता है।

मौजूदा नेटिव इंस्टॉलेशन में CLI से कोई निश्चित संस्करण भी इंस्टॉल किया जा सकता है: इसके लिए claude install 2.1.310 चलाएँ। पैकेज मैनेजर से संचालित इंस्टॉलेशन में उसी व्यवस्था की सामान्य प्रक्रिया अपनाकर ऐसा पैकेज या चैनल चुनें जो आवश्यक संस्करण उपलब्ध कराता हो।

फिर से claude --version चलाएँ और Claude Code का नया सेशन शुरू करें। अगर अभी भी पुराना संस्करण दिखता है, तो Bash में which -a claude या PowerShell में where.exe claude चलाकर आपस में टकराने वाले इंस्टॉलेशन जाँचें। एडिटर के टर्मिनल में बदला हुआ PATH लागू करने के लिए एडिटर को भी दोबारा शुरू करना पड़ सकता है।

गेटवे की त्रुटि से पहचानें कि कौन-सा पुनः प्रयास लागू होता है

लौटे हुए त्रुटि संदेश के आधार पर सुधार चुनें। केवल सामान्य 400 प्रतिक्रिया से पता नहीं चलता कि गेटवे ने किस क्षमता को अस्वीकार किया है।

Anthropic की गेटवे संगतता गाइड में अनुरोध को दोबारा काम करने योग्य बनाने के ये तरीके दर्ज हैं:

प्रतिक्रिया में पहचानने योग्य अंश	अपने-आप किया जाने वाला बदलाव	क्या जाँचें
400 जो Unexpected value(s) से शुरू होता है और anthropic-beta के लिए effort-2025-11-24 का उल्लेख करता है	Claude Code बंद होने तक उस मॉडल के लिए effort फ़ील्ड और beta को छोड़ देता है।	अगर आपने यह मान ANTHROPIC_BETAS में खुद जोड़ा है, तो उसे हटाएँ।
400 जो output_config.effort के साथ Extra inputs are not permitted दिखाता है, या बताता है कि effort समर्थित नहीं है	effort को हटाकर अनुरोध दोबारा भेजने वाला तरीका अपनाता है।	पुष्टि करें कि अस्वीकृत फ़ील्ड effort ही है।
400, जैसे Unexpected role "system"	बातचीत के बीच आने वाले system संदेशों का टेक्स्ट user संदेशों में ले जाता है; /clear या संदर्भ का संक्षिप्तीकरण होने तक यही रूप रखता है।	प्रभावित बातचीत में अनुरोध दोबारा भेजें।

यह फॉलबैक, यानी संगतता के लिए अपनाया गया वैकल्पिक तरीका, अनुरोध बदल देता है। effort पैरामीटर नियंत्रित करता है कि मॉडल टोकन कैसे खर्च करे, इसलिए उसे हटाकर अनुरोध सफल हो जाना यह साबित नहीं करता कि आपकी माँगी गई effort सेटिंग लागू हुई। इसी तरह system टेक्स्ट को user संदेशों में ले जाने पर टेक्स्ट बचता है, लेकिन उसे भेजने का रूप बदल जाता है।

उसी बातचीत में समस्या दोबारा उत्पन्न करें

अपडेट की जाँच करते समय गेटवे, क्रेडेंशियल का स्रोत और चुना हुआ मॉडल वही रखें। तभी तुलना उपयोगी होगी: प्रदाता और संस्करण दोनों एक साथ बदलने पर कारण स्पष्ट नहीं रहेगा।

पहले Claude Code शुरू करें और /status चलाएँ। गेटवे से कनेक्शन के निर्देश बताते हैं कि वहाँ सक्रिय बेस URL और क्रेडेंशियल का स्रोत कैसे जाँचना है। अगर अपेक्षित गेटवे नहीं दिखता, तो उसके beta समर्थन की जाँच करने से पहले यह कॉन्फ़िगरेशन ठीक करें।

इसके बाद सेशन से बाहर निकलें और स्थानीय डायग्नोस्टिक लॉग के साथ प्रभावित बातचीत फिर खोलें। Bash में:

claude --resume --debug-file ./claude-gateway-debug.log

चयन सूची से विफल हुआ सेशन चुनें और समस्या पैदा करने वाला सबसे छोटा अनुरोध दोहराएँ। इन फ़्लैग का विवरण CLI संदर्भ में है।

तुरंत सफलता की पहचान यह है कि जिस अनुरोध पर पहले त्रुटि आती थी, वहाँ अब सहायक का उपयोगी उत्तर मिले। यह साबित करने के लिए कि संगतता फॉलबैक से ही समस्या सुलझी, उपलब्ध क्लाइंट डायग्नोस्टिक्स और, जहाँ उपलब्ध हों, गेटवे के अनुरोध डायग्नोस्टिक्स देखें: अस्वीकृति के बाद बदले हुए अनुरोध का पुनः प्रयास दिखना चाहिए। नई बातचीत का पहला प्रॉम्प्ट सफल होने से उन सभी संदेश संरचनाओं की जाँच नहीं हो जाती जो आगे बन सकती हैं।

BetterToken के लिए उसकी Claude Code सेटअप गाइड में ANTHROPIC_BASE_URL=https://bettertoken.ai दिया गया है, बिना /v1 के; क्लाइंट अपडेट की जाँच करते समय यही दस्तावेज़ में दिया गया पता रखें।

अगर अपडेट के बाद भी क्लाइंट विफल हो

अपस्ट्रीम सेवा की त्रुटि प्रतिक्रियाओं का बॉडी टेक्स्ट जस का तस आगे भेजें: पहचानने योग्य अस्वीकृति को गेटवे की अस्पष्ट त्रुटि से बदलने पर क्लाइंट शायद फॉलबैक की ज़रूरत पहचान न पाए। साथ ही, CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 effort और बातचीत के बीच की system प्रविष्टियाँ बनाए रखता है, इसलिए यह इन त्रुटियों को हल करने वाला सार्वभौमिक स्विच नहीं है।

अब जो प्रमाण मिल रहे हैं, उनके अनुसार अगला कदम चुनें:

• वही पहचानने योग्य अस्वीकृति दोहर रही है: सक्रिय executable, खुद जोड़े गए beta मान और गेटवे द्वारा अपस्ट्रीम त्रुटि में किए गए बदलाव जाँचें।
• प्रमाणीकरण विफल है: गेटवे के क्रेडेंशियल निर्देश अपनाएँ। कनेक्शन गाइड Bearer प्रमाणीकरण के लिए ANTHROPIC_AUTH_TOKEN और x-api-key के लिए ANTHROPIC_API_KEY में अंतर बताती है; अपने प्रदाता के दस्तावेज़ में दी गई विधि इस्तेमाल करें।
• त्रुटि किसी दूसरे फ़ील्ड का नाम लेती है: उस फ़ील्ड की संगतता संबंधी आवश्यकताएँ जाँचें। हर स्कीमा अस्वीकृति को effort की समस्या न मानें।
• API की प्रतिक्रिया आने से पहले कनेक्शन विफल हो जाता है: endpoint, proxy, DNS या TLS कनेक्शन की जाँच करें।

मामला सहायता टीम तक ले जाने के लिए क्लाइंट संस्करण, ऑपरेटिंग सिस्टम, चुने गए मॉडल का ID, अनुरोध का समय या अनुरोध ID, HTTP स्थिति और हूबहू त्रुटि जुटाएँ। डायग्नोस्टिक का संवेदनशील जानकारी हटाया हुआ अंश साझा करें; क्रेडेंशियल या बातचीत का पूरा लॉग साझा न करें।

जाँचें कि Windows हुक सचमुच टूल कॉल रोकते हैं

कम से कम 2.1.310 तक अपडेट करें, फिर उन हुक की विफलता की स्थिति जाँचें जिन पर आपकी नीतियाँ लागू करने का भरोसा है। हुक किसी इवेंट पर चलने वाला हैंडलर होता है; इन लगातार दो रिलीज़ ने अलग-अलग स्थितियाँ ठीक की हैं:

• 2.1.309 PowerShell हुक के exit code की हैंडलिंग और ऐसे हुक में Git न होने पर होने वाली विफलताएँ ठीक करता है जो स्पष्ट रूप से PowerShell चुनते हैं।
• 2.1.310 एक अतिरिक्त स्थिति ठीक करता है: Git Bash न हो और हुक कमांड में केवल उद्धरण चिह्नों के भीतर लिखी स्ट्रिंग हों।

हुक में त्रुटि आने भर से यह तय नहीं होता कि कार्रवाई रोक दी जाएगी। हुक संदर्भ में command और HTTP हुक के लिए onFailure: "block" दिया गया है, जब हुक विफल होने पर उसे शुरू करने वाली कार्रवाई रुकनी चाहिए।

उद्धरण चिह्नों वाली कमांड की समस्या जाँचें

ऐसा अस्थायी नेटिव Windows परीक्षण वातावरण लें जिसे जाँच के बाद हटाया जा सके। उसमें Git Bash न हो, Claude Code का कनेक्शन काम करता हो और कोई असंबंधित हुक या प्लगइन नतीजे को प्रभावित न करे। इससे काम करने वाले कंप्यूटर से Git हटाए बिना Git Bash अनुपस्थित होने वाली स्थिति जाँची जा सकती है।

PowerShell में जाँच के लिए नई डायरेक्टरी और एक साधारण, सुरक्षित फ़ाइल बनाएँ:

$hookProbe = Join-Path $env:TEMP ("claude-hook-probe-" + [guid]::NewGuid().ToString("N"))
New-Item -ItemType Directory -Path (Join-Path $hookProbe '.claude') -Force | Out-Null
Set-Location $hookProbe
Set-Content -LiteralPath .\probe.txt -Value ([guid]::NewGuid().ToString())
Test-Path 'C:\__claude_hook_probe_missing__\python.exe'
claude --version

Test-Path का परिणाम False होना चाहिए, और संस्करण कम से कम 2.1.310 होना चाहिए।

इस परीक्षण डायरेक्टरी में .claude/settings.local.json बनाएँ और उसमें यह रखें:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read",
        "hooks": [
          {
            "type": "command",
            "command": "\"C:\\__claude_hook_probe_missing__\\python.exe\""
          }
        ]
      }
    ]
  }
}

shell, args और onFailure फ़ील्ड जान-बूझकर छोड़े गए हैं: यह चरण उद्धरण चिह्नों वाली कमांड के फॉलबैक की ही जाँच करता है।

PowerShell में सेशन शुरू करें:

claude --tools Read --debug-file .\phase1.log

इस अस्थायी डायरेक्टरी के लिए वर्कस्पेस पर भरोसे की पुष्टि करें। फिर /hooks चलाकर पुष्टि करें कि PreToolUse हुक Read से मेल खाता है। यह निर्देश दें:

probe.txt पढ़ने के लिए Read टूल का ठीक एक बार उपयोग करो। अगर कॉल रोक दी जाए, तो इसकी जानकारी देकर रुक जाओ। कोई दूसरा तरीका इस्तेमाल मत करो।

अपेक्षित परिणाम: Read कॉल रुक जाए और त्रुटि या डायग्नोस्टिक्स में PowerShell started no program दिखे। PowerShell सामान्यतः उद्धरण चिह्नों में लिखे पाथ को स्ट्रिंग मानता है; Microsoft का कॉल ऑपरेटर दस्तावेज़ बताता है कि उस पाथ को कमांड के रूप में चलाने के लिए अलग सिंटैक्स क्यों चाहिए।

अगर Read वास्तव में सफल होकर परिणाम देता है, तो यह जाँच विफल है। अगर Claude ने Read चलाने की कोशिश ही नहीं की, तो नतीजा अनिर्णायक है। मॉडल के वर्णन को प्रमाण मानने के बजाय टूल का परिणाम और लॉग देखें।

अगर /hooks में कॉन्फ़िगरेशन नहीं दिखती, तो हुक लोड होने की जाँच करें। सेटिंग्स आमतौर पर अपने-आप फिर लोड हो जाती हैं, लेकिन फ़ाइल पर नज़र रखने वाली प्रक्रिया बदलाव न पकड़ पाए तो रीस्टार्ट से उन्हें फिर लोड कराया जा सकता है। अगर संगठन की प्रबंधित नीति केवल प्रबंधित हुक की अनुमति देती है, तो प्रोजेक्ट स्तर की यह जाँच चली ही नहीं है।

वास्तव में अनुपस्थित इंटरप्रेटर की जाँच करें

इंटरप्रेटर शुरू न हो पाने पर क्या होता है, यह जाँचने के लिए विफलता की स्पष्ट नीति रखें। परीक्षण सेशन से बाहर निकलें और केवल हुक के अंदर वाले ऑब्जेक्ट को इससे बदलें:

{
  "type": "command",
  "command": "C:\\__claude_hook_probe_missing__\\python.exe",
  "args": [],
  "onFailure": "block"
}

यहाँ args executable को सीधे चलाने का तरीका चुनता है। अब executable अनुपस्थित होने से वास्तव में लॉन्च विफल होगा; केवल उद्धरण चिह्नों वाली स्ट्रिंग का मूल्यांकन नहीं होगा।

PowerShell में सेशन फिर शुरू करें और Read वाला वही निर्देश दोहराएँ:

claude --tools Read --debug-file .\phase2.log

अपेक्षित परिणाम: इंटरप्रेटर शुरू न हो पाने के कारण Read रुक जाए। यह विफलता की स्पष्ट नीति की जाँच है और Git Bash की उपलब्धता पर निर्भर नहीं करती; यह उद्धरण चिह्नों वाली कमांड की समस्या से अलग जाँच है।

नतीजे देखने के बाद परीक्षण कॉन्फ़िगरेशन हटा दें। वास्तविक नीतियाँ लागू करने वाले हुक में काम करने वाला इंटरप्रेटर बहाल करें और जहाँ जाँच विफल होने पर कार्रवाई रुकनी चाहिए, वहाँ स्पष्ट ब्लॉकिंग नीति बनाए रखें।

ये परीक्षण PreToolUse को जाँचते हैं। PermissionRequest हुक के लिए ऐसी कार्रवाई के साथ अलग जाँच चाहिए जो अनुमति माँगने के चरण तक पहुँचे। उसकी सामान्य अस्वीकृति के लिए hookSpecificOutput.decision.behavior को "deny" किया जाता है; केवल exit code 2 उस इवेंट को अस्वीकार नहीं करता। onFailure: "block" के साथ वास्तविक विफलता अनुरोध को अस्वीकार करती है।

डेटा रखने की बहुत लंबी अवधि सोच-समझकर बदलें

अगर आपकी टीम को किसी विशेष संग्रहण अवधि की ज़रूरत नहीं है, तो दस्तावेज़ में दिया गया 30 दिन का डिफ़ॉल्ट अपनाएँ। मौजूदा अवधि कम करने से पहले वह इतिहास अलग से सुरक्षित कर लें जिसे आगे रखना है।

सफ़ाई का यह सुधार cleanupPeriodDays के बहुत बड़े मानों से जुड़ी हाल की फ़ाइलों के मिटने की समस्या को ठीक करता है। इससे यह सेटिंग स्थायी संग्रह की व्यवस्था नहीं बन जाती और पहले मिट चुकी फ़ाइलें वापस नहीं आतीं।

समय-सीमा बदलने से पहले बचा हुआ डेटा सुरक्षित करें

सक्रिय सेशन रोकें और जिस डेटा की अभी भी ज़रूरत है, उसे Claude Code द्वारा प्रबंधित डायरेक्टरी से बाहर कॉपी करें। इसमें ~/.claude का संबंधित डेटा, या Windows पर %USERPROFILE%\.claude का डेटा, और बचे हुए इमेज अटैचमेंट शामिल करें।

वर्तमान एप्लिकेशन डेटा दस्तावेज़ के अनुसार, नई पेस्ट की गई इमेज Claude Code के अस्थायी रूट के नीचे प्रत्येक सेशन की images/ डायरेक्टरी में रहती हैं। उस रूट को CLAUDE_CODE_TMPDIR नियंत्रित करता है। इसलिए केवल ~/.claude का बैकअप यह साबित नहीं करता कि वर्तमान इमेज कॉपियाँ भी सुरक्षित हो गई हैं।

डेटा सुरक्षित करने के बाद संबंधित सेटिंग्स फ़ाइल में यह सेटिंग मिलाएँ:

{
  "cleanupPeriodDays": 30
}

निजी डिफ़ॉल्ट के लिए यह फ़ाइल ~/.claude/settings.json है, या Windows पर %USERPROFILE%\.claude\settings.json। उसमें मौजूद दूसरी कुंजियाँ बनाए रखें।

2026-10-25 के दस्तावेज़ के अनुसार न्यूनतम मान 1 है; 0 सत्यापन में असफल होता है। अवधि घटाने पर नए कटऑफ़ से पुराना डेटा सफ़ाई के दौरान हटाया जा सकता है, इसलिए ज़रूरी डेटा पहले सुरक्षित करें।

सेटिंग्स की वैधता जाँचने के लिए claude doctor चलाएँ। अगर इच्छित मान लागू नहीं होता, तो सेटिंग्स की प्राथमिकता देखें: प्रबंधित सेटिंग्स और अधिक प्राथमिकता वाली सेशन या प्रोजेक्ट सेटिंग्स आपकी निजी फ़ाइल को ओवरराइड कर सकती हैं। /status लोड हुए स्रोत दिखाता है, हर कुंजी का अंतिम प्रभावी मान नहीं।

गायब अटैचमेंट अलग से पुनः प्राप्त करें

गायब इमेज को उसकी मूल फ़ाइल या फ़ाइल सिस्टम के मौजूदा बैकअप से बहाल करें और उस कॉपी को बातचीत में फिर अटैच करें। जाँचें कि फ़ाइल स्थानीय रूप से खुलती है और Claude उस अटैचमेंट का फिर उपयोग कर सकता है।

डेटा रखने की अवधि बदलने से मिट चुके बाइट दोबारा नहीं बनते। यह भी न मानें कि /rewind अटैचमेंट लौटा देगा: चेकपॉइंट के स्नैपशॉट भी समाप्त हो जाते हैं, और आवश्यक स्नैपशॉट न बचने पर बहाली विफल हो सकती है।

अगर आपकी टीम पहले से टेलीमेट्री निर्यात करती है, तो पूरा हुआ claude_code.retention_sweep इवेंट देखें। मॉनिटरिंग संदर्भ में result: "complete" और स्ट्रिंग मान वाला period_days दिया गया है; "30" पुष्टि करता है कि उस विशेष सफ़ाई चक्र में 30 दिन की अवधि इस्तेमाल हुई थी।

क्लाइंट रीस्टार्ट करके थोड़ी देर चलाना यह साबित नहीं करता कि सफ़ाई हो चुकी है। सफ़ाई बैकग्राउंड में प्रति सेशन अधिकतम एक बार चलती है, और पिछले 24 घंटे में सफ़ाई हो चुकी हो तो अगले सेशन की सफ़ाई कम से कम 10 मिनट देर से शुरू होती है। अटैचमेंट का खुल पाना और सफ़ाई का पूरा होना दो अलग अवलोकन मानें।

Monitor की उपलब्धता एक अलग बदलाव है

संस्करण 2.1.310 Monitor टूल और प्लगइन मॉनिटर को Bedrock, Vertex और Foundry पर भी उपलब्ध कराता है। इसमें वे कॉन्फ़िगरेशन भी शामिल हैं जिनमें टेलीमेट्री या गैर-ज़रूरी नेटवर्क ट्रैफ़िक बंद है। रिलीज़ नोट्स यह भी बताते हैं कि इन वातावरणों में फ़ोरग्राउंड की लंबी प्रतीक्षा अब ब्लॉक होती है।

अगर ऐसे किसी परिनियोजन में Monitor नहीं दिख रहा था, तो टेलीमेट्री नीति बदलने से पहले चल रहे संस्करण की जाँच करें। उपलब्धता का यह बदलाव इस प्रश्न से अलग है कि कोई खास गेटवे effort सेटिंग्स या बातचीत के बीच की system प्रविष्टियाँ स्वीकार करता है या नहीं।