أسرار مسرّبة في settings.local.json لـ Claude Code: راجع قواعد «Don't Ask Again» وبدّل المفاتيح المكشوفة

وجدت GitGuardian ما مجموعه 5,343 سرًّا كانت لا تزال صالحة للعمل عند اكتشافها، وكلها موجودة في نسخ عامة من ملف واحد من ملفات مشاريع Claude Code، هو .claude/settings.local.json. تصل بيانات الاعتماد إلى هناك لأن Claude Code يطلب الإذن قبل تشغيل أي أمر shell، وأحد الخيارات التي يعرضها، وهو "Yes, and don't ask again" (نعم، ولا تسألني مرة أخرى)، يكتب الأمر الموافق عليه في ذلك الملف. وقد نشرت كلٌّ من GitGuardian وفريق بحثي ثانٍ هو Apiiro أعدادًا تُظهر كميات كبيرة من بيانات الاعتماد، من كلمات مرور قواعد البيانات إلى رموز API، في نسخ عامة من هذا الملف وحده.

إذا كنت مدير هندسة، أو قائد فريق منصات أو DevSecOps، أو مدير تقنية (CTO) يستخدم مطوّروه Claude Code، فإن هذا الدليل يقدّم لك تسلسلًا عمليًّا: اعثر على كل نسخة مكشوفة، وأبطِل بيانات الاعتماد، ونظّف المستودعات والمخرجات، ثم أغلق المسارات التي يتسرّب عبرها الملف.

ما الذي يكتبه خيار "Yes, and don't ask again" فعليًّا على القرص

عندما يختار المطوّر "Yes, and don't ask again" لأمر Bash، يحدث أمران. فبحسب GitGuardian، يشغّل Claude Code الأمر ويكتب قاعدة سماح (allow rule) في ملف .claude/settings.local.json داخل مجلد المشروع، والقاعدة هي نص الأمر نفسه بما فيه مفتاح API. فكّر في الأوامر التي يوافق عليها المطوّرون في يوم عمل عادي: استدعاء PGPASSWORD=... psql لقاعدة بيانات تجريبية (staging)، أو تسجيل دخول sshpass -p '...' ssh، أو جلسة mysql -p...، أو طلب curl يحمل رمز bearer. وافق على أيٍّ منها موافقة دائمة، فتُحفظ بيانات الاعتماد مع الأمر.

تؤكد وثائق Anthropic ذلك. إذ تنص وثائق الإعدادات على أن اختيار "Yes, and don't ask again" لأمر Bash يحفظ تلك الموافقة بوصفها قاعدة سماح في settings.local.json. وتضيف وثائق الأذونات أن الموافقات الدائمة تُكتب في .claude/settings.local.json عند جذر مستودع git، مع حلّ مسارات worktrees إلى النسخة الرئيسية (main checkout).

لدى Anthropic بلاغ علني عن هذا السلوك منذ أغسطس 2025.

حجم الانكشاف: قراءة متوازية لإحصاءين بحثيين

نشرت Apiiro بحثها في 6 نوفمبر 2026. وأفادت بأن 1,122 من أصل 104,185 نسخة عامة من الملف على GitHub احتوت على سر واحد على الأقل. وضمّت تلك الملفات 1,379 سرًّا مميزًا، منها 379 كلمة مرور لقواعد بيانات، و43 بيانات دخول SSH لخوادم عامة، و23 مفتاح AWS. وعندما وسّعت Apiiro البحث ليشمل الإصدارات الأقدم من الملف، وملف الإعدادات المشترك الذي تودعه الفرق في المستودع عن قصد، ونصوص محادثات الوكيل المحفوظة، بلغ المجموع 2,539 سرًّا في 1,994 مستودعًا.

أما فحص GitGuardian الخاص فوجد 31,088 سرًّا مميزًا في .claude/settings.local.json على GitHub العام، موزعة على 23,276 مستودعًا، منها 5,343 كانت لا تزال صالحة عند اكتشافها. وتشمل الأسرار الصالحة في settings.local.json وحده 1,955 سلسلة اتصال Postgres مميزة، و292 كلمة مرور SSH، و941 مفتاح Google API. وقراءتنا لهذا المزيج أن جزءًا كبيرًا من الخطر القائم يكمن في قواعد البيانات والخوادم، وأن حسابات API لدى الأطراف الثالثة ليست سوى جزء من الصورة.

تختلف الدراستان في النطاق والإطار الزمني وطريقة الاكتشاف، لذا اقرأهما بوصفهما قياسين منفصلين لمشكلة واحدة. فجمعهما معًا يؤدي إلى عدّ مزدوج، ولا ينبغي اعتبار أيٍّ منهما تصحيحًا للأخرى.

تتبّعت GitGuardian الاتجاه أيضًا. فقد بلغت التسريبات الشهرية في settings.local.json ذروتها عند 12,535 حالة في أبريل 2026، ثم تراجعت إلى 959 بحلول أكتوبر. وتقول GitGuardian إنها لا تعرف بعدُ ما الذي تغيّر.

لماذا تفوّت الحمايةُ المدمجة وأدواتُ الفحص لديك هذه التسريبات

يأتي Claude Code بالفعل مع وسيلة حماية. فبحسب وثائق الإعدادات، عندما يكتب الملف لأول مرة في مستودع git لا يتجاهله مسبقًا، يضيف **/.claude/settings.local.json إلى ملف الاستثناءات العام لـ git لدى المستخدم. يوجد هذا الإدخال على جهاز المطوّر نفسه ولا يدخل ملف .gitignore الخاص بالمشروع. وتوضح المذكرة البحثية الصادرة عن Cloud Security Alliance سبب قصور ذلك: فالاستثناء العام يحمي مطوّرًا واحدًا على محطة عمل واحدة، ولا ينتقل مع المستودع إلى نسخة زميل أو مشغّل CI أو حاسوب محمول جديد أو صورة حاوية أو حزمة npm مضغوطة (tarball).

الاكتشاف هو الثغرة الثانية. ففي مجموعة بيانات Apiiro، رصدت أداة gitleaks عدد 564 من أصل 1,122 ملفًا مسرِّبًا، ورصدت TruffleHog عدد 643، لكن أيًّا من الأداتين لم ترصد 215 منها، ويعود ذلك في الغالب إلى أن الأسرار كانت كلمات مرور مضمّنة في صيغة الأوامر مثل PGPASSWORD= أو sshpass -p أو mysql -p. وتشير أرقام GitGuardian في الاتجاه نفسه. إذ أنتجت أدوات الكشف العامة (كلمات المرور، والسلاسل عالية العشوائية، ورموز JWT، ورموز bearer، وأزواج اسم المستخدم وكلمة المرور) نسبة 63% من جميع الحالات في settings.local.json: أي 44,755 من أصل 71,525.

ما وراء GitHub: صور Docker وحزم npm وملفات CLAUDE.md

لا يبقى الملف داخل git. فقد فحصت GitGuardian صور Docker Hub العامة ووجدت 613 سرًّا مميزًا في ملفات إعدادات Claude Code، منها 99 كانت صالحة عند اكتشافها، موزعة على 543 مستودع صور و7,625 وسمًا (tag).

تُظهر أعداد الوسوم هذه كيف يتضاعف خطأ واحد. فقد ظهر رمز Cloudflare API صالح واحد في 559 وسمًا لصورة واحدة، وظهرت كلمة مرور قاعدة بيانات واحدة في 643 وسمًا عبر سبعة مستودعات صور. وبحسب GitGuardian، فإن حذف الملف من المستودع لا يفيد شيئًا بالنسبة إلى الصور التي سبق دفعها.

تحمل سجلات الحزم الخطر نفسه. فقد وجد بحث أجرته Check Point، وتستشهد به مذكرة CSA، أن 428 حزمة npm عامة شُحنت مع ملف .claude/settings.local.json، وأن 33 من تلك الملفات، موزعة على 30 حزمة، احتوت على بيانات اعتماد. كما يجب أن يتجاوز التدقيق ملفات الإعدادات. فقد وجدت GitGuardian أن ملفات CLAUDE.md احتوت على 6,155 سرًّا مميزًا، منها 2,537 صالحة، وهي أعلى نسبة صلاحية بين جميع الملفات التي فحصتها.

دليل العمل: اكتشف، أبطِل، نظّف، أغلق (Find, Kill, Clean, Close)

ترتيب الخطوات أهم من أي أمر بعينه. تغطي مرحلة الاكتشاف (Find) الخطوات من 1 إلى 3، والإبطال (Kill) هو الخطوة 4، ويغطي التنظيف (Clean) الخطوات من 5 إلى 7، أما الإغلاق (Close) فهو أعمال الوقاية في القسم الذي يلي هذا القسم. ويأتي الإبطال قبل التنظيف لأن التنظيف لا يستطيع استرجاع النسخ الموجودة بالفعل في أماكن أخرى: فالتفرعات (forks) والصور التي سبق دفعها تحتفظ بالسر مهما أعدت كتابة السجل بدقة، والتدوير وحده هو ما يجعل تلك النسخ عديمة القيمة.

الخطوة 1 (اكتشف): الجرد

أعدّ قائمة بكل مستودع وسجل حاويات وحزمة منشورة تتحكم فيها مؤسستك، بما في ذلك المستودعات المؤرشفة والمرايا الداخلية والتفرعات الشخصية التي يستخدمها الأفراد في العمل. فأي شيء لا يرد في القائمة لن يُنظَّف.

الخطوة 2 (اكتشف): ابحث في الأشجار الحالية وسجل git الكامل

ابحث عن .claude/settings.local.json و.claude/settings.json وCLAUDE.md وأي نصوص محادثات مُصدَّرة للوكيل. ابحث في السجل الكامل إلى جانب الفرع الحالي، لأن الإحصاء الأكبر لدى Apiiro جاء من إصدارات أقدم للملف وملفات إعدادات مشتركة ونصوص محادثات. ويمثّل البحث المُرشَّح بالمسار على منصة استضافة الشيفرة لديك جولة أولى سريعة. ولجولة على مستوى كل مستودع، نقترح أمرًا على غرار ما يلي، وهو يبحث أيضًا عن ملفات .jsonl تحسّبًا لأن تكون نصوص محادثات فريقك قد حُفظت بهذه الصيغة:

git log --all --name-only --pretty=format: | grep -E '[.]claude/|CLAUDE[.]md|[.]jsonl$' | sort -u

تعامل مع هذا الناتج على أنه نقطة انطلاق للبحث عن نصوص المحادثات. أما النصوص المحفوظة خارج git، أو بأسماء ملفات أخرى، فتحتاج إلى بحث منفصل.

الخطوة 3 (اكتشف): اقرأ الملفات، لا مخرجات أدوات الفحص فقط

هذه الملفات قصيرة بما يكفي لأن يفتحها شخص ما ويقرأ قواعد السماح مباشرة. وللبحث على امتداد السجل في المستودعات الكبيرة، نقترح تمرير المراجعات (revisions) إلى git grep واحدة تلو الأخرى بدلًا من تمريرها دفعة واحدة:

git rev-list --all | while read -r rev; do
  git grep -nE 'PGPASSWORD=|sshpass -p|mysql[^|]*[[:space:]]-p[^[:space:]]|Authorization: Bearer' "$rev" -- '*.json' '*.jsonl' '*.md'
done

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

الخطوة 4 (أبطِل): دوّر كل بيانات الاعتماد أو ألغِها أولًا

بحسب GitHub، إذا كانت البيانات الحساسة سرًّا، فإن الخطوة الأولى هي إلغاؤه أو تدويره. وعمليًّا يعني ذلك تدوير كلمة مرور قاعدة البيانات، وإعادة إصدار الرمز، واستبدال بيانات اعتماد SSH، ثم التحقق من أن كل قيمة قديمة لم تعد تعمل. وإلى أن تتأكد من أن بيانات اعتماد ما قد أُبطلت، افترض أنها لا تزال فعّالة.

الخطوة 5 (نظّف): أوقف تتبّع الإعدادات المحلية وراجع الإعدادات المشتركة

أوقف تتبّع الملف المحلي وأضف قاعدة التجاهل إلى ملف .gitignore الخاص بالمشروع نفسه، حتى تنتقل إلى كل نسخة مستنسخة وكل مشغّل CI:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore
git commit -m "Stop tracking Claude Code local settings"

نقترح أيضًا أن تطلب من كل مطوّر حذف أي قواعد تحتوي على بيانات اعتماد من نسخته المحلية من الملف.

الخطوة 6 (نظّف): أعد كتابة السجل، وأعد بناء الصور، وأعد نشر الحزم

بعد التأكد من التدوير، أعد كتابة السجل حيث يكون ذلك مفيدًا، وأعد بناء الصور المتأثرة، وأعد نشر إصدارات نظيفة من الحزم، مع تقبّل أن بعض الانكشاف سيبقى. ويحذّر GitHub من أنه إذا كان الالتزام (commit) الذي أدخل البيانات الحساسة موجودًا في أي تفرعات، فسيظل الوصول إليه ممكنًا هناك. ونقترح التعامل مع إصدارات الحزم القديمة على أنها لا تزال قابلة للوصول ما لم تتأكد من خلاف ذلك.

الخطوة 7 (نظّف): وثّق ما قمت به

احتفظ بسجل حوادث موجز. ولكل بيانات اعتماد عُثر عليها، دوّن المالك وتاريخ التدوير وأي انكشاف متبقٍّ لا يمكنك إزالته، مثل التفرعات والصور التي سُحبت وإصدارات الحزم القديمة. يحوّل هذا السجل عملية تنظيف لمرة واحدة إلى شيء يستطيع المدققون والفرق المستقبلية التحقق منه، ومن المفيد دمج سجل الحوادث هذا في دليل التعامل مع حوادث الوكلاء لديك، حتى يسلك التسريب التالي مسارًا يعرفه الناس مسبقًا.

قائمة تحقق لتسليمها إلى الفرق

• [ ] اكتشف: إدراج المستودعات والسجلات والحزم، بما فيها المستودعات المؤرشفة والتفرعات
• [ ] اكتشف: البحث في الأشجار والسجل الكامل عن ملفات الإعدادات وCLAUDE.md وملفات .jsonl، والبحث بشكل منفصل عن نصوص المحادثات المحفوظة خارج git
• [ ] اكتشف: قراءة الملفات من قِبل شخص، إضافة إلى فحوص مخصصة لـ PGPASSWORD= وsshpass -p وmysql -p
• [ ] أبطِل: تدوير كل بيانات الاعتماد أو إلغاؤها، والتأكد من أن القيمة القديمة أُبطلت
• [ ] نظّف: إيقاف تتبّع settings.local.json وإدراجه في .gitignore الخاص بالمشروع، وتجريد settings.json من بيانات الاعتماد ومراجعته في طلبات الدمج (pull requests)
• [ ] نظّف: إعادة كتابة السجل حيث يفيد، وإعادة بناء الصور، وإعادة نشر الحزم
• [ ] نظّف: إكمال سجل الحوادث، مع إدراج التفرعات وإصدارات الحزم القديمة بوصفها انكشافًا متبقيًا
• [ ] أغلق: تطبيق ضوابط الوقاية الواردة أدناه

الإغلاق: إبقاء الأسرار خارج الأوامر الموافق عليها

قاعدة السماح هي نص الأمر الحرفي، لذا تتلخص الوقاية في إبقاء بيانات الاعتماد خارج هذا النص.

• استخدم المتغيرات بدلًا من القيم. مرّر بيانات الاعتماد عبر متغيرات البيئة أو مدير أسرار، بحيث يحمل الأمر الموافق عليه اسم متغير بدلًا من السر. اضبط المتغير خارج الأمر الموافق عليه، في جلسة shell أو عبر غلاف لمدير الأسرار، لأن الصيغة المضمّنة VAR=secret cmd لا تزال تكتب السر في قاعدة السماح. قبل: الموافقة على PGPASSWORD=s3cret psql -h staging-db -U app تحفظ كلمة المرور. بعد: مع ضبط PGPASSWORD مسبقًا في البيئة، لا تحفظ الموافقة على psql -h staging-db -U app أي سر. وللاطلاع على نمط أقوى، راجع كيف يُبقي وسيط بيانات الاعتماد مفاتيح API بعيدًا عن وكلاء الذكاء الاصطناعي.
• اقرأ قبل أن تنقر. قبل منح موافقة دائمة، نقترح قراءة الأمر الدقيق، وإذا كان يحتوي على بيانات اعتماد، فوافق عليه مرة واحدة فقط. وتنطبق عادة القراءة قبل الموافقة على موافقات الوكلاء عن بُعد كذلك.
• أودِع قاعدة التجاهل في المستودع وراجع الملف. ضع .claude/settings.local.json في ملف .gitignore لكل مشروع بدلًا من الاعتماد على الاستثناءات العامة، واحذف بين الحين والآخر القواعد التي لم يعد المطوّرون بحاجة إليها.
• احظره في pre-commit وCI. ارفض الالتزامات التي تضيف ملف الإعدادات المحلية، ونبّه إلى صيغ الأوامر التي تحمل بيانات اعتماد قد تفوتها أدوات الفحص القياسية.
• أغلق مسارات التغليف. أضف مسارات .claude/ إلى .dockerignore، واستخدم قائمة سماح صريحة للملفات أو قائمة تجاهل لحزم npm حتى لا يتسلل الملف معها.

ما قالته Anthropic حتى الآن

لبلاغ الخطأ الأصلي تاريخ متقلب. إذ تسجّل مذكرة CSA أنه وُسم بعبارة "not planned" (غير مخطط له) في 3 يناير 2026، دون أن تظهر على الصفحة أي استجابة من المشرفين. وقد قُدّم البلاغ في أغسطس 2025، ولا توضح المصادر التي رُوجعت هنا الفجوة بين تاريخ تقديمه وتاريخ إغلاقه في يناير.

ردّت Anthropic علنًا منذ ذلك الحين، لكنها لم تطرح إصلاحًا بعد. فقد قال Boris Cherny، قائد Claude Code، لموقع iTnews: "تاريخيًّا، لم يكن Claude Code يقوم بتنقية الأسرار (فهناك أدوات جيدة كثيرة لذلك)، لكننا ندرس ما يمكننا فعله لمنع هذا." وعلى Hacker News، عدّد Cherny مقاربات ممكنة، منها التأكد من أن الوضع التلقائي (auto mode) يلتقط هذه الحالات، وبناء فحص أساسي للأسرار داخل الأداة. وقال إن الفريق سيبني نماذج أولية لبعضها لفهم المفاضلات قبل طرح أي شيء.

تحفظات وحدود هذه الإرشادات

• الصلاحية لقطة لحظية. تعكس الأسرار الصالحة لدى GitGuardian وعددها 5,343 لحظة الاكتشاف. وربما دُوّر بعضها منذ ذلك الحين، وربما لم يُدوَّر بعضها الآخر.
• التراجع غير مفسَّر. لا تعرف GitGuardian سبب انخفاض الحالات الشهرية بعد أبريل 2026، لذا لا يُثبت هذا الانخفاض أن المشكلة قد حُلّت.
• المستودعات الخاصة خارج النطاق. يغطي البحث المستودعات والصور والحزم العامة. وتواجه المستودعات الخاصة الانكشاف نفسه حيثما تُشارَك الملفات أو تُدمج في مخرجات البناء.
• قد يتغير السلوك. راجع وثائق إعدادات Claude Code وأذوناته الرسمية مجددًا قبل اعتماد سياستك الداخلية بصيغتها النهائية.
• الأوامر نقاط انطلاق. مقتطفات البحث أعلاه اقتراحات ينبغي تكييفها واختبارها في بيئتك، وليست أدوات اكتشاف متكاملة.