Claude Code का संसाधन ब्लैकहोल: 11.3MB सिंगल‑फ़ाइल पैकेज से 1.2TB डिस्क ख़पत तक

Claude Code का क्लाइंट एक बिना संसाधन लाइफ़साइकल मैनेजमेंट वाला Node.js सिंगल‑फ़ाइल एप्लिकेशन है: शुरूआत में 11.3MB पैकेज फ़ाइल को पार्स करता है, रन‑टाइम में डिस्क पर अनियंत्रित रूप से लिखता है, टर्मिनल बंद करने के बाद भी प्रोसेस जीवित रहता है और मेमोरी खपत करता रहता है, अंततः सिस्टम क्रैश हो जाता है। GitHub Issues में वास्तविक उपयोगकर्ता रिपोर्ट और समुदाय द्वारा किए गए रिवर्स‑इंजीनियरिंग विश्लेषण के आधार पर, यह लेख मेमोरी, CPU, डिस्क तीनों आयामों में उसके संसाधन प्रबंधन की कमियों को व्यवस्थित रूप से प्रस्तुत करता है, और पैकेजिंग आर्किटेक्चर, स्टोरेज डिज़ाइन तथा प्रोसेस लाइफ़साइकल मैनेजमेंट में संरचनात्मक समस्याओं को उजागर करता है। ये कोई किनारे के केस नहीं हैं, बल्कि 2025‑08 से 2026‑04 तक समुदाय द्वारा लगातार रिपोर्ट किए गए, लेकिन stale बॉट द्वारा बैच में बंद किए गए प्रणालीगत आर्किटेक्चर दोष हैं।

पैकेजिंग आर्किटेक्चर: 11.3MB सिंगल‑फ़ाइल की कीमत

Claude Code का कोर cli.js नामक एक सिंगल‑फ़ाइल पैकेज है, जिसका आकार लगभग 11.3MB है। समुदाय के उपयोगकर्ता paultendo ने Issue #29481 में इसका विस्तृत स्थैतिक विश्लेषण किया, जिसमें कई गंभीर आर्किटेक्चर समस्याओं को उजागर किया गया।

V8 स्टार्ट‑अप समय: 32% समय पार्सिंग में

CPU प्रोफाइलिंग दिखाती है कि compileSourceTextModule ने स्टार्ट‑अप चरण के 31.7% सैंपल समय का उपभोग किया। V8 इंजन को इस 11.3MB सिंगल‑फ़ाइल को पार्स करने में लगभग 300ms लगते हैं, जबकि एक साधारण Node.js स्क्रिप्ट को केवल 23ms में पार्स किया जा सकता है। अतिरिक्त 7.3% समय spawnSync कॉल पर, 3.5% समय गार्बेज कलेक्शन पर खर्च होता है। इसका मतलब है कि उपयोगकर्ता कोई कमांड इनपुट करने से पहले ही 40% से अधिक स्टार्ट‑अप समय केवल पार्सिंग में बर्बाद हो जाता है।

पूर्ण लोड: केवल 20 डायनामिक इम्पोर्ट

पूरे पैकेज फ़ाइल को स्टार्ट‑अप पर पूरी तरह से पार्स और एक्सीक्यूट किया जाता है, जिसमें केवल 20 import() एक्सप्रेशन होते हैं। प्रत्येक उपयोगकर्ता को सभी फ़ीचर के लिए लागत उठानी पड़ती है, चाहे वह उपयोग करे या नहीं। नीचे उन कंपोनेंट्स की सूची है जो ऑन‑डिमांड लोड होने चाहिए थे, लेकिन पूरी तरह से पैकेज हो गए हैं:

pie title पैकेज फ़ाइल संरचना (लगभग 13.5MB)
    "एप्लिकेशन कोर लॉजिक" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 भाषाएँ)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "अन्य (Ink, Zod, Ajv, Axios आदि)" : 1807

एक कोडिंग असिस्टेंट को Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso आदि 182 भाषाओं को हाईलाइट करने की आवश्यकता होती है, जो पैकेजिंग रणनीति की मोटी प्रकृति को दर्शाता है। केवल लगभग 40 सामान्य उपयोग की भाषाओं को रखकर लगभग 786KB पार्सिंग ओवरहेड बचाया जा सकता है।

निर्भरता की अतिप्रचलन: चार HTTP क्लाइंट, तीन वैलिडेशन लाइब्रेरी

विभिन्न SDK ने स्वतंत्र निर्भरताएँ लाई हैं, जिसके कारण पैकेज फ़ाइल में चार HTTP क्लाइंट (Axios, Undici, Got, नेटिव fetch) और तीन वैलिडेशन लाइब्रेरी (Zod, Ajv, JSON Schema) एक साथ मौजूद हैं। Node 18+ में नेटिव fetch पूरी तरह से उपलब्ध है, अतिरिक्त HTTP क्लाइंट की कोई आवश्यकता नहीं है।

413 सिंक्रोनस फ़ाइल सिस्टम कॉल

पैकेज फ़ाइल में 196 existsSync, 109 statSync, 108 readFileSync, 58 mkdirSync आदि कुल 413 सिंक्रोनस फ़ाइल सिस्टम कॉल शामिल हैं। प्रत्येक कॉल इवेंट लूप को ब्लॉक करती है। कई कॉल existsSync(path) && readFileSync(path) पैटर्न का पालन करती हैं, जिसे एक try { await readFile(path) } catch {} असिंक्रोनस कॉल से बदला जा सकता था।

1087 CJS/ESM इंटरऑप रैपर

हर CommonJS मॉड्यूल जो ESM में पैकेज किया गया है, उसके लिए __toESM/__commonJS/__require कम्पैटिबिलिटी पैच बनते हैं, कुल 1087। ये पैच पार्सिंग वज़न बढ़ाते हैं और प्रत्येक मॉड्यूल में मामूली रन‑टाइम ओवरहेड जोड़ते हैं।

अनावश्यक Node 20 पॉलीफ़िल

पैकेज में 62 Promise पैच (Node 0.12 से नेटिव सपोर्ट), 57 Symbol पैच (Node 4 से नेटिव सपोर्ट), 57 async ट्रांसफ़ॉर्म हेल्पर (Node 8 से नेटिव सपोर्ट), और 3 AbortController पॉलीफ़िल (Node 15 से नेटिव सपोर्ट) शामिल हैं। ये पुराने Node या ब्राउज़र टार्गेट के लिए ट्रांसिटिव डिपेंडेंसी से आए हैं, और लक्ष्य रन‑टाइम में पूरी तरह से अनावश्यक हैं।

ripgrep के सभी 6 प्लेटफ़ॉर्म बाइनरी: 61MB

ripgrep के 6 प्लेटफ़ॉर्म बाइनरी सभी पैकेज किए गए, कुल 61MB। इसके विपरीत, sharp ने optional dependencies का सही उपयोग किया और केवल वर्तमान प्लेटफ़ॉर्म का बाइनरी इंस्टॉल किया। इसका मतलब है कि प्रत्येक इंस्टॉलेशन में लगभग 51MB डिस्क स्पेस बर्बाद हो रहा है।

Ink रेंडरिंग प्रदर्शन का संवाद लंबाई के साथ गिरावट

टर्मिनल UI Ink (React for Terminal) का उपयोग करता है। विश्लेषण से पता चलता है कि कंपोनेंट ट्री में 6457 createElement कॉल, 578 useState हुक, लेकिन केवल 11 React.memo() रैपर हैं, अनुपात केवल 1.9%। Ink में प्रत्येक स्टेट अपडेट पूरी वर्चुअल DOM कोऑर्डिनेशन ट्रिगर करता है। स्ट्रीमिंग रिस्पॉन्स के दौरान, प्रत्येक टोकन स्टेट अपडेट ट्रिगर करता है, जिससे अन‑memoized कंपोनेंट अनावश्यक री‑रेंडर होते हैं। संवाद बढ़ने के साथ रेंडर आउटपुट भी बढ़ता है, और प्रत्येक री‑रेंडर अधिक टर्मिनल कंटेंट को डिफ़ाइन करता है। यह Issue #22265 में रिपोर्ट किए गए “सेशन के दौरान धीरे‑धीरे धीमा होना” के साथ मेल खाता है।

डिस्क ख़पत: GB से TB तक अनियंत्रित वृद्धि

डिस्क समस्या Claude Code की सबसे गंभीर संसाधन प्रबंधन कमी है, जिसका प्रभाव सबसे व्यापक और परिणाम सबसे गंभीर हैं।

Windows .node नेटिव मॉड्यूल लीक: प्रति सप्ताह 20GB

Issue #23095 ने कई महीनों तक अनसॉल्व्ड समस्या दर्ज की: Claude Code का Windows नेटिव बाइनरी (claude.exe) प्रत्येक सत्र में सिस्टम टेम्प फ़ोल्डर में नेटिव Node.js प्लगइन फ़ाइलें एक्सट्रैक्ट करता है, लेकिन कभी साफ़ नहीं करता। प्रत्येक फ़ाइल लगभग 6.6MB है; उपयोगकर्ता SlothKing16 ने 4 दिनों में 2813 फ़ाइलें जमा कीं, कुल 18GB। उपयोगकर्ता kolkov ने 20GB/सप्ताह की आँकड़े रिपोर्ट किए; भारी उपयोगकर्ता 100GB/सप्ताह तक पहुंच सकते हैं। यह समस्या 2025 की शुरुआत से रिपोर्ट हो रही है, लेकिन बॉट द्वारा कई बार डुप्लिकेट के रूप में टैग करके बंद कर दी गई।

~/.claude फ़ोल्डर: 3GB+ बिना प्रबंधन

उपयोगकर्ता kolkov ने Issue #5024 में 8 महीने से दैनिक उपयोग की मशीन का ऑडिट किया:

pie title ~/.claude फ़ोल्डर उपयोग (लगभग 3.1GB)
    "projects/ (सेशन रिकॉर्ड)" : 2500
    "debug/ (डिबग लॉग)" : 303
    "file-history/ (फ़ाइल स्नैपशॉट)" : 232
    "history.jsonl (ग्लोबल हिस्ट्री)" : 10
    "अन्य" : 55

मुख्य आँकड़े: सबसे बड़ा सिंगल सत्र JSONL फ़ाइल 203MB, सबसे बड़ा सब‑एजेंट JSONL फ़ाइल 72MB, history.jsonl में 37,000+ एंट्रीज़। सभी डेटा बिना रोटेशन, बिना कम्प्रेशन, बिना क्लीन‑अप मैकेनिज़्म के रहता है। file-history/ में फ़ाइल स्नैपशॉट डुप्लिकेट नहीं होते; एक ही फ़ाइल को 10 बार एडिट करने पर 10 पूर्ण कॉपीज़ संग्रहीत होती हैं। debug/ डायरेक्टरी के डिबग लॉग कभी साफ़ नहीं होते।

बैकग्राउंड टास्क आउटपुट फ़ाइल: 1.2TB का स्वयं‑संदर्भ लूप

Issue #32282 ने एक अविश्वसनीय डिज़ाइन दोष उजागर किया। जब Claude Code कई बैकग्राउंड एजेंट लॉन्च करता है और स्वचालित रूप से एक प्रोग्रेस‑चेक बाश कमांड चलाता है, तो उस कमांड का आउटपुट फ़ाइल उसी डायरेक्टरी में लिखी जाती है जो ग्लॉब पैटर्न से मेल खाती है, जिससे स्वयं‑संदर्भ अनंत फ़ीडबैक लूप बनता है:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["आउटपुट लिखता है tasks/task-A.output"]
    B --> C["glob task-A.output को स्वयं मैच करता है"]
    C --> D["tail -5 स्वयं आउटपुट पढ़ता है"]
    D --> E["स्वयं में जोड़ता है"]
    E --> C

कई उपयोगकर्ताओं ने समान समस्या रिपोर्ट की: 1.2TB, 460GB, 303GB, 235GB, 480GB, 36GB। इस इश्यू के टिप्पणीकार ने 70 संबंधित ओपन इश्यू को 15 समूहों में वर्गीकृत किया, और केवल पहले दो समूहों ने लगभग 9.5TB डिस्क उपयोग रिपोर्ट किया। लिखने की गति 425MB/s तक पहुँच सकती है, लगातार 18 मिनट तक चलती है, जब तक डिस्क समाप्त नहीं हो जाता।

चेन फेल्योर: डिस्क भरने के बाद अपरिवर्तनीय क्रैश

Issue #24207 ने डिस्क भरने के बाद की आपदा‑समान चेन रिएक्शन का वर्णन किया:

flowchart TD
    A["डिस्क स्पेस = 0"] --> B[".claude.json लिखना विफल"]
    B --> C["शून्य‑लंबाई फ़ाइल बनती है"]
    C --> D["अमान्य JSON पढ़ी जाती है"]
    D --> E["सभी प्रोजेक्ट सेटिंग्स ओवरराइट"]
    E --> F["OAuth/API टोकन करप्ट"]
    F --> G["पुनः ऑथेंटिकेशन आवश्यक"]
    G --> H["सभी चल रहे एजेंट/सेशन रोकें"]
    H --> I["डिस्क स्पेस मुक्त करने के बाद भी पुनर्स्थापना नहीं"]

कोई प्री‑अलर्ट नहीं, कोई ग्रेसफ़ुल डिग्रेड नहीं, कोई रीकवरी पाथ नहीं। उपयोगकर्ता को सभी प्रोसेस मैन्युअली टर्मिनेट करना पड़ता है, डिस्क स्पेस मैन्युअली मुक्त करना पड़ता है, कॉन्फ़िगरेशन मैन्युअली री‑स्टोर करना पड़ता है, फिर से ऑथेंटिकेशन करना पड़ता है, और सभी सेटिंग्स को फिर से कॉन्फ़िगर करना पड़ता है।

समवर्ती लिखना: कोई लॉक, कोई ट्रांज़ैक्शन, कोई समन्वय नहीं

~/.claude/ डायरेक्टरी में唯一 लॉक फ़ाइल .update.lock (5 बाइट) है। अन्य सभी फ़ाइल लिखने में कोई सुरक्षा नहीं है। जब कई Claude Code प्रोसेस एक साथ चलते हैं (एजेंट + सब‑एजेंट सामान्य उपयोग परिदृश्य हैं), तो वे साझा फ़ाइलों पर कोई समन्वय नहीं रखते:

Windows पर स्थिति और भी खराब है: एटॉमिक राइट वर्कअराउंड (.tmp लिखें फिर rename()) Windows में विफल हो जाता है, क्योंकि लक्ष्य फ़ाइल अन्य प्रोसेस द्वारा रखी होने पर rename() EPERM रिटर्न करता है, जिससे एटॉमिकिटी पूरी तरह टूट जाती है।

मेमोरी और CPU: 13GB RSS से कर्नेल पैनिक तक

Windows में अत्यधिक मेमोरी खपत

Issue #24840 ने Windows पर एक अत्यधिक केस दर्ज किया: RSS 13.21GB, वर्चुअल मेमोरी कमिट 47.17GB, जबकि मशीन की कुल मेमोरी केवल 42.56GB थी। पेज फ़ॉल्ट 3.75 मिलियन बार हुए, जो लगातार डिस्क I/O दर्शाते हैं। 347 सेकंड रन‑टाइम में, यूज़र‑स्पेस CPU समय केवल 35 सेकंड था, लगभग 90% समय I/O और स्वैप की प्रतीक्षा में बीता। इससे अन्य एप्लिकेशन (जैसे Opera) पूरी तरह अनुत्तरदायी हो गए।

macOS कर्नेल पैनिक

Issue #39253 ने अधिक गंभीर परिणाम रिपोर्ट किए: MacBook Pro M3 Pro (18GB RAM) पर कई Claude Code इंस्टेंस चलाने से macOS कर्नेल पैनिक हुआ। दो प्रकार के पैनिक देखे गए: Jetsam OOM किल (मेमोरी प्रेशर के कारण macOS ने महत्वपूर्ण watchdogd प्रोसेस को मार दिया) और watchdog टाइमआउट (watchdogd ने 90+ सेकंड तक सिस्टम रिसोर्स की कमी के कारण हर्टबिट नहीं किया)। सिस्टम बिना किसी चेतावनी के रीबूट हो गया, कोई एरर डायलॉग नहीं, कोई कार्य सहेजने का अवसर नहीं।

प्रोसेस ऑरफ़न: टर्मिनल बंद करने के बाद भी जीवित

Issue #44507 (2026‑04, कुछ दिन पहले) ने एक बुनियादी लाइफ़साइकल मैनेजमेंट दोष रिपोर्ट किया: टर्मिनल विंडो बंद करने के बाद भी Claude Code प्रोसेस जीवित रहता है। एक ऑरफ़न प्रोसेस ने 21 दिनों में 35.4GB RSS और 95.5% CPU उपयोग किया। कारण यह है कि मुख्य CLI एंट्री पॉइंट में process.stdin.on("end") हैंडलर नहीं है, और 55+ setInterval टायमर (पोलिंग, टेलीमेट्री, स्टेटस बार रिफ्रेश आदि) Node.js इवेंट लूप को अनंत तक जीवित रखते हैं। V8 हीप अनियंत्रित रूप से बढ़ता है, कोई फ्री GC प्रेशर नहीं, --max-old-space-size सीमा नहीं, कोई सेल्फ‑टर्मिनेट वॉचडॉग नहीं।

100% CPU फ्रीज़

Issue #27415 ने TaskStop ट्रिगर के कारण 100% CPU फ्रीज़ की रिपोर्ट की, जिसका कारण Bun रनटाइम में posix_spawn का अनियंत्रित लूप था। Issue #26224 ने बड़े प्रॉम्प्ट प्रोसेसिंग के दौरान 5‑20 मिनट के हैंग की समस्या बताई।

फ्लैट फ़ाइल आर्किटेक्चर की प्रणालीगत विफलता

अलोकेट लेकिन क्लीन नहीं: सभी इश्यूज़ में दोहराई गई आर्किटेक्चर पैटर्न

समुदाय सदस्य kolkov ने कई इश्यूज़ में बार‑बार बताया कि सभी समस्याओं की मूल वजह समान है:

यह .node लीक कोई अलग बग नहीं है — यह एक दोहराए जाने वाले आर्किटेक्चर पैटर्न का लक्षण है, जहाँ Claude Code संसाधन अलोकेट करता है लेकिन क्लीन नहीं करता।

2025 से 2026 तक, समस्या .claude.json सिंगल फ़ाइल के विस्तार से JSONL फ़ाइलों के फ़्रैगमेंटेड विस्तार तक विकसित हुई, लेकिन मूल आर्किटेक्चर नहीं बदला: फ्लैट फ़ाइल, कोई लॉक नहीं, कोई ट्रांज़ैक्शन नहीं, कोई क्लीन‑अप नहीं, कोई कम्प्रेशन नहीं।

SQLite और लोकल डेमन: समुदाय के वैकल्पिक समाधान

समुदाय ने कई बार SQLite को फ्लैट फ़ाइल स्टोरेज के विकल्प के रूप में प्रस्तावित किया। एक SQLite डेटाबेस सभी समस्याओं को एक साथ हल कर सकता है: WAL मोड समवर्ती रीड + सिंगल‑राइट एटॉमिकिटी देता है, ट्रांज़ैक्शन पूरी या कुछ नहीं लिखने की गारंटी देता है, बिल्ट‑इन कम्प्रेशन, TTL क्लीन‑अप, कंटेंट डिडुप्लिकेशन, और क्रॉस‑प्लेटफ़ॉर्म कंसिस्टेंसी।

एक अन्य सुझाव लोकल डेमन (जैसे LSP सर्वर, Docker‑स्टाइल आर्किटेक्चर) को इंट्रोड्यूस करने का है, जहाँ सभी Claude Code प्रोसेस IPC के माध्यम से संवाद करते हैं, समन्वय प्रदान करते हैं, लेकिन स्टोरेज बैकएंड को नहीं बदलते।

समुदाय रिवर्स‑इंजीनियरिंग बनाम stale बॉट

समुदाय सदस्य gebeer की टिप्पणी वर्तमान स्थिति को सटीक रूप से सारांशित करती है:

आपका विस्तृत विश्लेषण बहुत सराहनीय है। यह काम मेंटेनर को कई साल पहले ही करना चाहिए था।

kolkov ने आगे कहा:

विडंबना यह है कि समुदाय वास्तव में उनके लिए डिबग कर रहा है — रिवर्स‑इंजीनियरिंग, कोड को डिकॉम्पाइल करना, बग पाथ ट्रेस करना, कोड स्निपेट्स के साथ फिक्स प्रस्ताव देना — और प्रतिक्रिया एक 60‑दिन बाद सभी चीज़ों को बंद करने वाले stale‑issue बॉट की है।

समान टूल्स के संसाधन प्रबंधन की तुलना

GitHub Copilot VS Code एक्सटेंशन के रूप में चलता है, जो एक्सटेंशन होस्ट की मेमोरी लिमिट और लाइफ़साइकल मैनेजमेंट प्रतिबंधों के अधीन है; Cursor VS Code का फोर्क है और समान संसाधन प्रबंधन फ्रेमवर्क को अपनाता है। दोनों की स्टोरेज SQLite या समान डेटाबेस का उपयोग करती है, जिससे समवर्तीता और ट्रांज़ैक्शन स्वाभाविक रूप से समर्थित होते हैं। Claude Code ने स्वतंत्र प्रोसेस + फ्लैट फ़ाइल मॉडल चुना, लेकिन स्वतंत्र प्रोसेस की अपेक्षित संसाधन प्रबंधन जिम्मेदारियों — मेमोरी लिमिट, डिस्क कोटा, प्रोसेस वॉचडॉग, ग्रेसफ़ुल शटडाउन — को लागू नहीं किया। इसका व्यवहार एक प्रोटोटाइप डेमो जैसा है, न कि प्रोडक्शन‑ग्रेड टूल।

मॉडल क्षमता और इंजीनियरिंग गुणवत्ता का विरोधाभास

11.3MB सिंगल‑फ़ाइल पैकेज, 413 सिंक्रोनस फ़ाइल सिस्टम कॉल, 1087 CJS/ESM इंटरऑप रैपर, कोई रिसोर्स क्लीन‑अप नहीं, कोई समवर्ती नियंत्रण नहीं, कोई डिस्क स्पेस मॉनिटरिंग नहीं — ये किनारे के केस नहीं, बल्कि प्रणालीगत आर्किटेक्चर दोष हैं। 2025‑08 के Issue #5024 से 2026‑04 के Issue #44507 तक, समुदाय लगातार समान श्रेणी की समस्याओं की रिपोर्ट करता रहा, विस्तृत विश्लेषण और सुधार सुझाव प्रदान करता रहा, जबकि कई इश्यू “not planned” के रूप में टैग किए गए या stale बॉट द्वारा स्वचालित रूप से बंद किए गए। एक AI कोडिंग टूल, जिसका अपना कोड क्वालिटी समुदाय द्वारा ऑडिट और फिक्स किया जाना चाहिए, यह स्वयं एक गहन विचारणीय विरोधाभास है।

यदि आप Claude Code का उपयोग कर रहे हैं, तो नियमित रूप से ~/.claude फ़ोल्डर का आकार जांचें, टेम्प फ़ोल्डर में .node फ़ाइलों को साफ़ करें, और टर्मिनल बंद करने से पहले Ctrl+C से सही ढंग से एग्ज़िट करें। यदि डिस्क स्पेस अचानक गायब हो जाए, तो अब आप जानते हैं कि कारण कहाँ खोजें।

• ←पिछला
• अगला→