Meteora Web

Claude Code 2.1.314 ने कार्यस्थल के बाहर लिखने पर रोक लगाई और दर्जनों बग ठीक किए

Claude Code 2.1.314 में फ़ोल्डर के बाहर लिखने पर रोक, गेटवे पर IdP समूह और दर्जनों सुधार आए हैं। जानिए क्या बदला और यह किसके काम आएगा।

Ing. Calogero Bono 1 मिनट में पढ़ें
Claude Code 2.1.314 ने कार्यस्थल के बाहर लिखने पर रोक लगाई और दर्जनों बग ठीक किए

Anthropic ने GitHub पर Claude Code का संस्करण 2.1.314 जारी किया है। यह टूल टर्मिनल से, VS Code से और Claude Desktop से कोड पर काम करता है। सबसे ठोस नई बात एक नई परमिशन सेटिंग है, जो Claude को कार्यस्थल के फ़ोल्डरों के बाहर फ़ाइलें लिखने से रोकती है। बाकी रिलीज़ में सुधारों की लंबी सूची है, जिनमें से कई उन लोगों के लिए हैं जो कंपनी के भीतर गेटवे, क्लाउड प्रोवाइडर और केंद्रीय नियमों के साथ Claude Code चलाते हैं। सुरक्षा और प्रबंधन से जुड़ी बारीकियाँ ही तय करती हैं कि ऐसा टूल किसी टीम में जगह बना पाएगा या नहीं।

कुछ शब्द पहले समझ लें। गेटवे एक बीच का सर्वर है जो डेवलपर और मॉडल के बीच खड़ा होता है और कंपनी को यह नियंत्रित करने देता है कि कौन क्या इस्तेमाल करे। IdP (identity provider) वह सिस्टम है जो उपयोगकर्ताओं की पहचान और उनके समूह संभालता है। Bedrock, Vertex और Foundry क्रमशः Amazon, Google और Microsoft की क्लाउड सेवाएँ हैं, जहाँ से मॉडल इस्तेमाल किए जा सकते हैं। कंपैक्शन किसी लंबी बातचीत का सारांश है, ताकि मॉडल की मेमोरी न भरे। हुक एक स्क्रिप्ट है जो किसी खास क्षण पर चलती है, जैसे किसी कमांड से पहले।

Zenithby Meteora Web आपके व्यवसाय का ऑपरेटिंग सिस्टम। सोशल मीडिया, क्लाइंट, बुकिंग और इनवॉइस एक ही प्लेटफ़ॉर्म पर। जिम, बार्बर और पेशेवरों के लिए। Zenith देखें → मुफ़्त डेमो · कार्ड की ज़रूरत नहीं

फ़ोल्डर के बाहर लिखने की रोक क्या करती है?

आधिकारिक Claude Code रिपॉज़िटरी की रिलीज़ नोट्स के अनुसार नई सेटिंग का नाम permissions.blockWritesOutsideWorkingDirectories है। चालू होने पर Write, Edit और NotebookEdit टूल उन पाथ को अस्वीकार कर देते हैं जो कार्यस्थल के फ़ोल्डरों से बाहर हैं, और यह हर परमिशन मोड में लागू होता है।

सबसे अहम बात यही आख़िरी हिस्सा है। अब तक सख़्त नियमों के बावजूद व्यवहार चुने गए मोड पर निर्भर था। इस नोट के अनुसार अस्वीकृति हर मोड में लागू होती है, यानी तब भी जब उपयोगकर्ता ने एजेंट को ज़्यादा छूट देने का फ़ैसला किया हो। विकल्प के नाम से साफ़ है कि यह वैकल्पिक है और इसे खुद चालू करना पड़ेगा।

इसी दिशा में sandbox से जुड़े कुछ सुधार भी हैं। sandbox.excludedCommands के विवरण में लिखा था कि सूची में दिए कमांड हमेशा sandbox के बाहर चलते हैं, जबकि अब स्पष्ट किया गया है कि किसी कॉल के हर कमांड का किसी प्रविष्टि से मेल होना चाहिए। साथ ही claude -p --resume या --continue से खोले गए worktree पर sandbox की सुरक्षा लागू नहीं हो रही थी, जो अब लागू होती है। एक और सुधार --setting-sources से बाहर रखी गई सेटिंग फ़ाइल से जुड़ा है, जो कुछ सेटिंग्स जैसे auto mode के नियम और पहले से सहेजी गई अनुमतियाँ लागू करती रह रही थी।

गेटवे और एडमिनिस्ट्रेटर के लिए क्या बदला है?

Claude Apps के गेटवे को संगठनों के लिए एक नई सुविधा मिली है। हर upstream, यानी वह गंतव्य जहाँ गेटवे अनुरोध भेजता है, के लिए समूहों की वैकल्पिक सूची रखी जा सकती है। सूची में दिए IdP समूहों के डेवलपर ही उस upstream पर भेजे जाते हैं, failover की स्थिति में भी। failover का मतलब है कि किसी गड़बड़ी के बाद गेटवे किसी वैकल्पिक विकल्प पर चला जाए।

Bedrock upstream के लिए guardrail_trace भी आ गया है। इससे यह दर्ज होता है कि किसी अनुरोध पर Amazon Bedrock का कौन सा guardrail फ़िल्टर लगा, और वह टेक्स्ट सेव नहीं होता जिस पर फ़िल्टर लगा था। जिन्हें यह समझना है कि कोई अनुरोध क्यों रुका, पर लॉग में संवेदनशील डेटा नहीं रखना चाहते, उनके लिए यह संतुलित समाधान है।

कई सुधार एडमिनिस्ट्रेटर द्वारा दी गई सेटिंग्स से जुड़े हैं।

  • एडमिनिस्ट्रेटर की TLS सेटिंग्स Claude Desktop के सत्रों में लागू नहीं हो रही थीं, अब हो रही हैं।
  • जब forceRemoteSettingsRefresh केवल remote settings में सेट था, तो पुरानी सहेजी गई कॉपी लागू नहीं होती थी। सर्वर पहुँच में न हो तो सत्र बिना policy के शुरू हो सकते थे।
  • प्रबंधित plugins वाली मशीनों पर, अगर किसी निजी plugin का manifest टूटा हो या डाउनलोड विफल हो, तो मॉडल बदलने से इनकार हो जाता था।
  • अगर एडमिनिस्ट्रेटर किसी मॉडल का effort स्तर सीमित करे, तो Claude Code effort घटाकर फिर कोशिश करता है और बताता है कि कौन सा स्तर चल रहा है। पहले हर टर्न पर सत्र विफल हो जाते थे।

गेटवे का एक Vertex upstream भी कई मिनट तक अटका रह सकता था, जब कोई Google token endpoint कनेक्शन स्वीकार करके जवाब नहीं देता था। यह भी ठीक कर दिया गया है।

Bedrock, Foundry और Vertex से जुड़े कौन से सुधार हैं?

यह रिलीज़ उन लोगों के लिए भी कई सुधार लाती है जो सीधे Anthropic की API इस्तेमाल नहीं करते।

Bedrock

कई तस्वीरों वाले Bedrock सत्र हर टर्न पर विफल हो रहे थे, और /compact भी इनपुट बहुत लंबा होने की त्रुटि के साथ रुक जाता था। अब Claude Code पुरानी तस्वीरें हटाकर कंपैक्ट करता है। एक और सुधार Bedrock और Vertex पर मॉडल अपडेट के प्रस्ताव से जुड़ा है, जो हर स्टार्टअप पर दोबारा आ जाता था, भले ही प्रबंधित सेटिंग्स ने मॉडल लॉक कर रखा हो।

Microsoft Foundry

जब संसाधन में डिफ़ॉल्ट Sonnet, Opus या Haiku मॉडल के लिए deployment नहीं होता था, तो सत्र विफल हो जाते थे। अब Claude Code उसी परिवार के किसी पुराने मॉडल पर चला जाता है।

तीसरे पक्ष के गेटवे

अगर कोई गेटवे tool search के tool_reference ब्लॉक स्वीकार नहीं करता, तो अनुरोध एक बार उस सुविधा के बिना दोबारा भेजा जाता है और सत्र उसे याद रखता है। यही व्यवहार तब भी है जब कोई गेटवे या प्रोवाइडर Claude Code के किसी beta header को नाम लेकर ठुकरा दे। जिन मॉडल ID में बिंदु होता है, जैसे claude-opus-4.8, उन्हें पुराना मॉडल माना जा रहा था, जिससे context window, output limit, effort, reasoning मोड और लागत गलत आती थी। अब ऐसा नहीं होता।

प्रमाणपत्रों के मोर्चे पर, जब system store में नया रूट certificate हो जो पुराने वाले से cross-signed हो, तो TLS कनेक्शन UNABLE_TO_GET_ISSUER_CERT के साथ विफल हो जाते थे। यह भी ठीक हो गया है।

रोज़ के उपयोग में क्या बदला है?

कोड लिखने वालों के लिए सबसे दिखने वाली बात VS Code और Claude Desktop के Code टैब में idle compaction है। 200K टोकन से लंबी, बिना इस्तेमाल पड़ी बातचीत का सारांश बनता है, और अगला संदेश आने पर प्रॉम्प्ट कैश समाप्त होने की स्थिति में यही सारांश काम आता है।

इसके अलावा टर्मिनल और CI से जुड़े कई सुधार हैं।

  • claude -p स्टार्टअप विफल होने पर बिना आउटपुट के कोड 0 के साथ बाहर निकलता था। अब वह त्रुटि छापता है और कोड 1 के साथ बाहर आता है, जो स्क्रिप्ट के लिए मायने रखता है।

  • claude ultrareview और claude remote-control CI जॉब में, जिसमें टर्मिनल हो, अब folder trust का सवाल नहीं पूछते। CI सेट होने पर अविश्वसनीय फ़ोल्डर को सीधे अस्वीकार कर देते हैं।
  • बहुत बड़े आउटपुट वाला PreCompact hook कंपैक्शन को विफल या दोबारा चलाने पर मजबूर करता था। अब हर hook का आउटपुट 10,000 अक्षरों पर काटा जाता है।
  • बैकग्राउंड में diff अपडेट repository का index lock कुछ देर के लिए ले लेते थे, जिससे उसी समय चल रहा git कमांड विफल हो सकता था।
  • Bash को पकड़ने वाले hooks Monitor टूल से चलाए गए कमांड पर नहीं चलते थे। अब चलते हैं, पर वे उन कमांड को ब्लॉक या कन्फ़र्म करा सकते हैं, मंज़ूर या बदल नहीं सकते।

बाकी बदलाव इंटरफ़ेस की बारीकियाँ हैं, जैसे markdown टेबल, vim मोड, एजेंट चयन, टेक्स्ट और तस्वीरों का पेस्ट, सत्र के शीर्षक और परमिशन डायलॉग।

सीमाएँ जिन्हें जानना ज़रूरी है

हमारे पास जो रिलीज़ नोट है, वह आख़िर में कटा हुआ है, इसलिए हम दूसरी प्रविष्टियों से इनकार नहीं कर सकते। हमें प्रकाशन की तारीख नहीं मिली और लेखन-रोक सेटिंग का कोई विस्तृत दस्तावेज़ भी उपलब्ध नहीं है। यह भी नहीं पता कि यह डिफ़ॉल्ट रूप से चालू है या नहीं, और टेक्स्ट से लगता है कि नहीं है। कार्यस्थल फ़ोल्डर की ठीक परिभाषा भी स्पष्ट नहीं है, जैसे symbolic links या जुड़े हुए repositories के मामले में।

ये निर्माता के दावे हैं, स्वतंत्र परीक्षण नहीं। लेखन टूल पर रोक का मतलब यह नहीं कि shell कमांड भी वही करेगा, वह sandbox के नियम मानता है। Monitor पर hooks वाली बात को भी सावधानी से पढ़ें, क्योंकि इससे पता चलता है कि एक hook क्या वादा कर सकता है।

डिजिटल काम करने वालों के लिए इसका क्या मतलब है

अगर आप टीम संभालते हैं, तो पहला काम सूची पढ़कर यह देखना है कि कौन से सुधार आपके मामले को छूते हैं। जो Bedrock पर कई तस्वीरों के साथ काम करते हैं, Foundry पर आंशिक deployment रखते हैं या कंपनी का गेटवे चलाते हैं, उन्हें सीधे लाभ मिलेगा। जो अकेले काम करते हैं और बेसिक प्लान इस्तेमाल करते हैं, उन्हें मुख्य रूप से idle compaction और छोटे सुधार दिखेंगे।

किसी एजेंसी या software house के लिए लेखन वाली नियम एक अच्छा तर्क है, जिसे ग्राहकों के सामने रखा जा सकता है। इससे पता चलता है कि एजेंट को प्रोजेक्ट तक सीमित रखा जा सकता है, जो तब काम आता है जब एक ही कंप्यूटर पर कई repositories या कॉन्फ़िगरेशन फ़ाइलें हों। मूल सिद्धांत फिर भी वही है कि एजेंट को न्यूनतम पहुँच वाले सहयोगी की तरह देखा जाए। यह हमने Cursor पर Claude Code की ट्रोजन-ग्रस्त एक्सटेंशन के मामले में भी देखा था, जहाँ खतरा टूल के आसपास के ढाँचे से आया था।

जो CI में claude -p वाली स्क्रिप्ट चलाते हैं, उन्हें exit codes दोबारा जाँचने चाहिए। जो त्रुटि पहले सफलता जैसी दिखती थी, अब pipeline रोक देगी। यह सही है, पर चौंका सकता है। अगर आप अपने सर्वर पर डेवलपमेंट वातावरण चलाते हैं, तो याद रखें कि मशीन भी मायने रखती है, इसलिए सुरक्षा अपडेट वाले प्रबंधित सर्वर ज़रूरी हैं।

हमारी राय

यह रिलीज़ बताती है कि प्रोग्रामिंग एजेंट आज किस चरण में हैं। नई सुविधाएँ कम हैं, जबकि बड़ा हिस्सा किनारे के मामलों, proxy, प्रमाणपत्र, नीतियों और fallback के सुधारों से भरा है। यह उस टूल का संकेत है जो एक डेवलपर के लैपटॉप से निकलकर ऐसे माहौल में जा रहा है जहाँ कुछ भी अस्पष्ट नहीं रह सकता।

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

सवाल यह भी है कि तैयार कोड की जाँच कौन करेगा। कम बँधा हुआ एजेंट इंसानी समीक्षा की जगह नहीं ले सकता, इसलिए GitHub पर pull request और code review के तरीके और code review के लिए AI वाले टूल आज भी काम के हैं।

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

permissions.blockWritesOutsideWorkingDirectories क्या करता है?

यह Write, Edit और NotebookEdit को फ़ोल्डर के बाहर के पाथ पर लिखने से रोकता है। रिलीज़ नोट्स के अनुसार यह हर परमिशन मोड में लागू होता है। symbolic links जैसे खास मामलों में यह कैसे काम करता है, इसकी जानकारी हमारे पास नहीं है।

क्या यह रोक डिफ़ॉल्ट रूप से चालू है?

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

क्या Bedrock या Foundry वालों को अपडेट करना चाहिए?

अगर आपने बताई गई समस्याएँ देखी हैं, तो हाँ। यह रिलीज़ कई तस्वीरों वाले Bedrock सत्र और डिफ़ॉल्ट मॉडल के बिना Foundry deployment वाले मामले ठीक करती है। पूरी टीम की मशीनें अपडेट करने से पहले इसे एक मशीन पर आज़मा लें।

गेटवे के upstream पर समूह क्या होते हैं?

ये हर upstream से जुड़ी IdP समूहों की वैकल्पिक सूची है। उन समूहों के डेवलपर ही वहाँ भेजे जाते हैं, failover में भी। इसका उपयोग यह तय करने के लिए होता है कि कौन सी मंज़िल किसके लिए खुली है।

क्या idle compaction हर जगह इस्तेमाल हो सकता है?

नहीं, नोट्स के अनुसार यह VS Code और Claude Desktop के Code टैब में जोड़ा गया है। यह 200K टोकन से लंबी, बिना इस्तेमाल पड़ी बातचीत पर लागू होता है। सारांश तभी काम आता है जब प्रॉम्प्ट कैश समाप्त हो चुका हो।

आने वाले महीनों में किस पर नज़र रखें, परमिशन और कंपनी के एजेंट

मुद्दा यह रिलीज़ नहीं, इसकी दिशा है। एजेंटों पर केंद्रीय नियंत्रण बढ़ेगा, इसलिए अभी से तैयारी समझदारी है।

  • अपनी परमिशन कॉन्फ़िगरेशन जाँचें और तय करें कि फ़ोल्डर के बाहर लिखने की रोक चालू करनी है या नहीं, शायद पहले किसी टेस्ट प्रोजेक्ट पर।
  • claude -p वाले CI स्क्रिप्ट जाँचें, क्योंकि अब स्टार्टअप की त्रुटि कोड 1 के साथ निकलती है और pipeline रोक सकती है।
  • अगर आप गेटवे या क्लाउड प्रोवाइडर इस्तेमाल करते हैं, तो सुधारों की पूरी सूची दोबारा पढ़ें और मामलों को अपने लॉग से मिलाएँ। अलग-अलग प्रोवाइडरों की लागत समझने के लिए Claude और OpenAI की तुलना भी पढ़ें, और ध्यान रखें कि कई मॉडलों पर चल रही गड़बड़ियाँ आपके साथ भी हो सकती हैं।

स्रोत

Zenithby Meteora Web आपके व्यवसाय का ऑपरेटिंग सिस्टम। सोशल मीडिया, क्लाइंट, बुकिंग और इनवॉइस एक ही प्लेटफ़ॉर्म पर। जिम, बार्बर और पेशेवरों के लिए। Zenith देखें → मुफ़्त डेमो · कार्ड की ज़रूरत नहीं

यह भी पढ़ें

ब्लॉग से

नवीनतम लेख