ثقب الموارد في Claude Code: من حزمة ملف واحد بحجم 11.3 ميغابايت إلى استهلاك قرص يصل إلى 1.2 تيرابايت

عميل Claude Code هو تطبيق Node.js ملف واحد بدون إدارة دورة حياة الموارد: عند بدء التشغيل يحلل ملف حزمة بحجم 11.3 ميغابايت، ويكتب إلى القرص بلا حدود أثناء التشغيل، وتستمر العملية في استهلاك الذاكرة بعد إغلاق الطرفية حتى يتعطل النظام. استنادًا إلى تقارير المستخدمين الحقيقية في GitHub Issues وتحليل المجتمع العكسي، نستعرض في هذه المقالة عيوب إدارة الموارد على ثلاثة أبعاد: الذاكرة، وحدة المعالجة المركزية، والقرص، مكشفين عن مشكلات هيكلية في بنية الحزمة، وتصميم التخزين، وإدارة دورة حياة العملية. هذه ليست حالات طرفية، بل مشكلات هيكلية مستمرة تم الإبلاغ عنها من أغسطس 2025 حتى أبريل 2026، وتم إغلاقها جماعيًا بواسطة روبوت stale.

بنية الحزمة: تكلفة ملف واحد بحجم 11.3 ميغابايت

النواة في Claude Code هي ملف واحد باسم cli.js بحجم تقريبًا 11.3 ميغابايت. قام المستخدم المجتمعي paultendo بتحليل ثابت مفصل في Issue #29481، مكشفًا عن عدة مشكلات هيكلية خطيرة.

زمن بدء V8: 32% من الوقت للتحليل

أظهر ملف تعريف وحدة المعالجة المركزية أن compileSourceTextModule استهلك 31.7% من وقت العينة في مرحلة البدء. يحتاج محرك V8 حوالي 300 مللي ثانية لتحليل هذا الملف الواحد بحجم 11.3 ميغابايت، بينما يستغرق تحليل سكريبت Node.js عادي 23 مللي ثانية فقط. استهلك 7.3% إضافية في استدعاء spawnSync، و3.5% في جمع القمامة. هذا يعني أنه قبل أن يدخل المستخدم أي أمر، تم إهدار أكثر من 40% من وقت البدء في مجرد التحليل.

التحميل الكامل: 20 استيرادًا ديناميكيًا فقط

يتم تحليل وتنفيذ كامل ملف الحزمة عند البدء، مع وجود 20 تعبيرًا import() فقط. يدفع كل مستخدم تكلفة جميع الوظائف بغض النظر عن الاستخدام. المكونات التي كان من المفترض تحميلها حسب الحاجة ولكن تم حزمها بالكامل هي:

pie title مكونات ملف الحزمة (≈ 13.5 ميغابايت)
    "منطق التطبيق الأساسي" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 لغة)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "أخرى (Ink, Zod, Ajv, Axios وغيرها)" : 1807

يحتاج مساعد الترميز إلى تمييز 182 لغة مثل Brainfuck، MIPS assembly، Flix، Zephir، Inform7، Lasso وغيرها، وهذا يوضح مدى السطحية في استراتيجية الحزم. يمكن توفير حوالي 786 كيلوبايت من تكلفة التحليل باقتصارها على حوالي 40 لغة شائعة.

تبذير الاعتمادات: أربعة عملاء 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 غلافًا. هذه الأغلفة تزيد من وزن التحليل وتضيف حمولة تشغيلية صغيرة لكل وحدة.

polyfill غير ضروري لـ Node 20

يحتوي ملف الحزمة على 62 غلاف Promise (مدعوم أصلاً منذ Node 0.12)، 57 غلاف Symbol (من Node 4)، 57 دالة مساعدة async (من Node 8)، و3 polyfill لـ AbortController (من Node 15). هذه الاعتمادات جاءت من تبعيات نقلية موجهة لإصدارات Node أو المتصفحات القديمة، وهي غير ضرورية في بيئة التشغيل المستهدفة.

ripgrep يضم جميع المنصات الستة: 61 ميغابايت

تم حزم جميع المنصات الستة لـ ripgrep، مجموعها 61 ميغابايت. بالمقابل، يستخدم sharp dependencies اختيارية، مثبتًا فقط الثنائية الخاصة بالمنصة الحالية. هذا يعني إهدار حوالي 51 ميغابايت من مساحة القرص لكل تثبيت.

تدهور أداء Ink مع طول المحادثة

تستخدم واجهة الطرفية Ink (React for Terminal). أظهر التحليل وجود 6457 استدعاء createElement، 578 هوك useState، لكن فقط 11 غلاف React.memo()، بنسبة 1.9% فقط. في Ink، كل تحديث حالة يسبب تنسيق كامل لـ Virtual DOM. أثناء الاستجابة المتدفقة، كل رمز token يطلق تحديث حالة، مما يجعل المكونات غير memoized تُعاد رسمها بلا داعٍ. مع زيادة طول المحادثة، يزداد حجم الإخراج، وكل إعادة رسم تتطلب مزيدًا من الفروقات في محتوى الطرفية. هذا يتطابق مع الظاهرة المبلغ عنها في Issue #22265 بعنوان “المحادثة تصبح أبطأ مع تقدمها”.

استهلاك القرص: من جيجابايت إلى تيرابايت بنمو غير محدود

مشكلات القرص هي أخطر عيوب إدارة الموارد في Claude Code، وتؤثر على أوسع نطاق وتسبب أسوأ العواقب.

تسرب وحدة .node الأصلية على Windows: 20 جيجابايت أسبوعيًا

يسجل Issue #23095 مشكلة مستمرة لعدة أشهر: ملف الثنائي الأصلي لـ Windows (claude.exe) ينسخ مكوّن Node.js الأصلي إلى دليل مؤقت في كل جلسة دون تنظيف. كل ملف حوالي 6.6 ميغابايت؛ جمع المستخدم SlothKing16 2813 ملفًا في 4 أيام، أي 18 جيجابايت. إحصاءات المستخدم kolkov أكثر صدمة: حوالي 20 جيجابايت أسبوعيًا، ويمكن للمستخدمين المكثفين الوصول إلى 100 جيجابايت أسبوعيًا. تم الإبلاغ عن هذه المشكلة منذ أوائل 2025، وتم إغلاقها عدة مرات بواسطة الروبوت.

دليل ~/.claude: أكثر من 3 جيجابايت بدون إدارة

قام المستخدم kolkov بتدقيق جهاز يستخدم Claude Code بانتظام لمدة 8 أشهر في Issue #5024:

pie title استهلاك دليل ~/.claude (≈ 3.1 جيغابايت)
    "projects/ (سجلات الجلسات)" : 2500
    "debug/ (سجلات التصحيح)" : 303
    "file-history/ (لقطات الملفات)" : 232
    "history.jsonl (السجل العام)" : 10
    "أخرى" : 55

أهم الأرقام: أكبر ملف JSONL لجلسة واحدة 203 ميغابايت، أكبر ملف فرعي 72 ميغابايت، history.jsonl يحتوي على أكثر من 37000 مدخل. لا توجد تدوير للبيانات، ولا ضغط، ولا آلية تنظيف. ملفات file-history/ لا تُدمج؛ كل تعديل للملف يُخزن نسخة كاملة. ولا يتم تنظيف سجلات debug/.

ملفات إخراج المهام الخلفية: حلقة ميتة ذات 1.2 تيرابايت

يكشف Issue #32282 عن عيب تصميم مذهل. عندما يطلق Claude Code عدة وكلاء خلفية ويشغل أمر bash يتحقق من التقدم، يُكتب ملف الإخراج في نفس الدليل الذي يطابقه glob، مما يخلق حلقة تغذية مرتدة لا نهائية:

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.2 تيرابايت، 460 جيجابايت، 303 جيجابايت، 235 جيجابايت، 480 جيجابايت، 36 جيجابايت. جمّع المعلقون 70 قضية مفتوحة، مقسمة إلى 15 مجموعة؛ مجموع استهلاك القرص للمجموعتين الأوليين وصل إلى حوالي 9.5 تيرابايت. يمكن أن يصل معدل الكتابة إلى 425 ميغابايت/ثانية، مستمرًا 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()) تفشل لأن rename() تُعيد EPERM عندما يكون الملف مقفولًا، مما يُدمّر الذرية تمامًا.

الذاكرة ووحدة المعالجة المركزية: من 13 جيجابايت RSS إلى ذعر نواة

استهلاك الذاكرة المتطرف على Windows

يسجل Issue #24840 حالة متطرفة على Windows: RSS 13.21 جيجابايت، استهلاك الذاكرة الظاهرية 47.17 جيجابايت، بينما الذاكرة الفعلية للجهاز 42.56 جيجابايت فقط. حدث 3.75 مليون خطأ صفحة، مما يدل على نشاط قرص مستمر. خلال 347 ثانية تشغيل، كان وقت CPU في وضع المستخدم 35 ثانية فقط، أي حوالي 90% من الوقت كان ينتظر I/O وswap. أدى ذلك إلى توقف تطبيقات أخرى مثل متصفح Opera تمامًا.

ذعر نواة macOS

يُبلغ Issue #39253 عن عواقب أكثر خطورة: على MacBook Pro M3 Pro (18 جيجابايت RAM)، تشغيل عدة نسخ من Claude Code يسبب ذعر نواة macOS. لوحظ نوعان من الذعر: قتل OOM بواسطة Jetsam (ضغط الذاكرة يقتل عملية watchdogd الحيوية) وwatchdog timeout (watchdogd لا يُسجل أي نشاط لمدة 90+ ثانية). يعيد النظام تشغيل نفسه دون تحذير، ولا توجد نافذة حوار خطأ، ولا فرصة لحفظ العمل.

عملية يتيمة: تستمر بعد إغلاق الطرفية

يُبلغ Issue #44507 (أبريل 2026، قبل أيام) عن نقص أساسي في إدارة دورة الحياة: تستمر عملية Claude Code في العمل بعد إغلاق نافذة الطرفية. استهلكت عملية منفردة 35.4 جيجابايت RSS و95.5% CPU خلال 21 يومًا. السبب هو عدم وجود معالج process.stdin.on("end") في نقطة الدخول الرئيسية، ووجود أكثر من 55 setInterval (للتنقيب، التتبع، تحديث شريط الحالة) يبقي حلقة حدث Node.js حية إلى ما لا نهاية. تتوسع كومة V8 بلا حدود، ولا توجد ضغط جمع قمامة، ولا حد --max-old-space-size، ولا مراقب إغلاق ذاتي.

تجميد 100% CPU

يُبلغ Issue #27415 عن تجميد CPU بنسبة 100% نتيجة لتفعيل TaskStop، السبب هو حلقة غير منضبطة في posix_spawn داخل وقت تشغيل Bun. كما يُشير Issue #26224 إلى تجميد Claude Code لمدة 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 يومًا.

مقارنة إدارة الموارد مع أدوات مماثلة

GitHub Copilot يعمل كملحق VS Code، مقيد بحدود الذاكرة وإدارة دورة الحياة التي يوفرها المضيف. Cursor هو فرع من VS Code، يشارك نفس إطار إدارة الموارد؛ كلاهما يستخدم SQLite أو قاعدة بيانات مشابهة، مما يدعم التزامن والمعاملات بطبيعة الحال. اختار Claude Code نهج العملية المستقلة + ملفات مسطحة، لكنه لم يطبق مسؤوليات إدارة الموارد المتوقعة من عملية مستقلة—لا حد للذاكرة، لا حصة قرص، لا مراقب عملية، ولا إغلاق أنيق. سلوكه أقرب إلى نموذج نموذج أولي تجريبي وليس أداة جاهزة للإنتاج.

التناقض بين قدرة النموذج وجودة الهندسة

ملف حزمة بحجم 11.3 ميغابايت، 413 استدعاء نظام ملفات متزامن، 1087 غلاف CJS/ESM، لا تنظيف للموارد، لا تحكم في التزامن، ولا مراقبة مساحة القرص—هذه ليست حالات طرفية، بل عيوب هيكلية نظامية. من أغسطس 2025 (Issue #5024) إلى أبريل 2026 (Issue #44507)، استمر المجتمع في الإبلاغ عن نفس الفئة من المشكلات، مقدمًا تحليلات مفصلة وتوصيات إصلاح، بينما تم تصنيف العديد من القضايا على أنها “غير مخطط لها” أو أُغلقت تلقائيًا بواسطة روبوت stale. أداة ترميز AI ذات جودة شفرة منخفضة تعتمد على المجتمع لتدقيقها وإصلاحها—وهذا التناقض بحد ذاته يستحق التفكير.

إذا كنت تستخدم Claude Code، يُنصح بفحص حجم دليل ~/.claude بانتظام، وتنظيف ملفات .node المؤقتة، واستخدام Ctrl+C للخروج بشكل صحيح قبل إغلاق الطرفية. إذا اختفت مساحة القرص فجأة، الآن تعرف إلى أين تبحث عن السبب.

• ←السابق
• التالي→