حدث الأمان safety_event في Claude Code: ماذا يسجل، وتم اختباره

claude_code.safety_event هو حدث OpenTelemetry أضافه Claude Code 2.1.307 لتسجيل استدعاءات الأدوات التي تم إيقافها، أو طلب إذن لها، أو إرجاعها بواسطة قاعدة أذونات، أو الوضع التلقائي (auto mode)، أو فحص أمان، أو hook أو الـ sandbox. في عمليات تشغيل claude -p على الإصدار 2.1.310، تم تفعيل هذا الحدث في حالات قواعد الرفض (deny rules)، وقواعد الطلب (ask rules)، ووضع dontAsk، والـ hooks واثنين من فحوصات الأمان المدمجة، ولم يتم تفعيله عندما رفض تشغيل -p أمر Bash لم يتم منحه إذن.

لقد احتفظت بسجلات ١٠٨ جلسات headless تم تشغيلها باستخدام console log exporter، لمعرفة ما يحتويه الحدث وما يغفله. ووجدت فجوة تستحق المعرفة قبل أن تقوم ببناء تنبيه (alert) بناءً عليه.

ما ستتعلمه

• ما هو claude_code.safety_event وأي إصدار أضافه
• كيفية طباعته باستخدام console exporter عبر متغيرين للبيئة
• أي حالات الرفض تنتج حدثًا، مع سمة الفئة (category) والتفاصيل (detail) لكل منها
• أي حالات الرفض لا تنتج حدثًا، وكيفية العثور عليها
• ما الذي يغفله الحدث، وكيفية ربطه بالأمر

ما هو هذا الحدث

claude_code.safety_event هو حدث سجل مهيكل يصدره Claude Code عندما يقوم شيء ما بإيقاف استدعاء أداة، أو طلب إذن لها، أو إرجاعها. تدرجه سجل التغييرات (changelog) تحت الإصدار 2.1.307، بتاريخ ٢١ أكتوبر ٢٠٢٦: "تم إضافة حدث OpenTelemetry claude_code.safety_event لكل استدعاء أداة تم إيقافه، أو طلب إذن له، أو إرجاعه بواسطة قاعدة أذونات، أو الوضع التلقائي، أو فحص أمان، أو hook أو الـ sandbox".^١

تقول وثائق المراقبة أن الحدث "يتم تصديره مع الأحداث الأخرى وليس له إعداد منفصل".^٢ إذا كنت ترسل بالفعل بيانات telemetry لـ Claude Code، فستصل مع البقية. تحدد الوثائق ١٤ قيمة لسمة category: permission_rule، managed_policy، permission_mode، hook، auto_mode_block، auto_mode_no_verdict، safety_check، static_analysis، sandbox_override، user_rejected، sandbox_network، sandbox_other، hook_review و other.^٢

تكون سمة decision هي accept، أو reject، أو sent_back عندما يقوم "hook" بحظر نتيجة أو نهاية دور.^٢

كيف قمت باختبار ذلك

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

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=console
export OTEL_LOGS_EXPORT_INTERVAL=1000   # docs default is 5000

claude -p "Use the Bash tool to run exactly this command and nothing else: touch made-by-lab.txt
If the tool is refused, reply with the single word REFUSED and stop." \
  --model haiku --max-turns 4 --disallowedTools "Bash(touch:*)" < /dev/null > run.txt

grep -A 30 'body: "claude_code.safety_event"' run.txt

يقوم مصدّر الكونسول بكتابة كل حدث إلى stdout ككائن بنمط JavaScript، وليس JSON، لذا يتشارك رد النموذج والأحداث في تدفق واحد. استخدمت grep ومحلل صغير لاستخراج السمات. الـ < /dev/null في الأمر يتخطى فقط تحذير stdin، ولم تستخدمه عمليات التشغيل المبرمجة الخاصة بي.

استخدم كل تشغيل دليلاً جديداً خاصاً به، والاسم المستعار haiku ونظام Linux x86_64، في ٢٦ أكتوبر ٢٠٢٦. تظهر السجلات النموذج كـ claude-haiku-5-5 في كل تشغيل تم الإبلاغ عنه، في جميع الإصدارات الثلاثة. كان 2.1.310 هو الوسم latest على npm عندما تحققت.^٣ استخدمت touch made-by-lab.txt كأمر. تم السماح بثلاث عمليات تشغيل باستخدام echo في وضع dontAsk دون وجود أي قاعدة على الإطلاق، لذا لم يتمكن echo من إظهار رفض، لذا استبعدته.

قمت بتشغيل ٢٣ تكويناً ثلاث مرات لكل منها على الإصدار 2.1.310، وهو ما يعادل ٦٩ عملية تشغيل. ولمقارنة الإصدارات، قمت بتثبيت 2.1.306 و 2.1.307 من npm في مجلدات خاصة بهما وشغلت ثلاث حالات ثلاث مرات لكل منها على كليهما، بالإضافة إلى نفس الحالات الثلاث مرة أخرى على 2.1.310. هذا يمثل ٢٧ عملية تشغيل. أربعة فحوصات متابعة من ثلاث عمليات تشغيل لكل منها، فحص echo المذكور أعلاه وثلاثة فحوصات للقراءة والكتابة الموضحة أدناه، ترفع الإجمالي إلى ١٠٨ جلسة مع سجلات محفوظة.

كنت قد شغلت حالات 2.1.306 و 2.1.307 مرة واحدة سابقاً، ثلاث عمليات تشغيل لكل حالة، دون الاحتفاظ بالسجلات. تطابقت النتائج، ويستخدم الجدول إعادة التشغيل.

اثنان من التكوينات الـ ٢٣ لم يتم الإبلاغ عنهما كنتائج. كان أحدهما اختبار PostToolUse حيث كانت قاعدة السماح موجودة في إعدادات المشروع، وهو ما تسبب في تداخل بسبب خلل موصوف أدناه، لذا أعدت تنفيذه مع وضع قاعدة السماح في سطر الأوامر. والآخر كان اختبار كتابة في وضع التخطيط (plan mode) حيث رفض النموذج قبل استدعاء الأداة في اثنتين من ثلاث عمليات تشغيل، وتظهر سجلاته نموذجاً ثانياً، وهو claude-sonnet-5-5، لذا استبعدته. في جدول النتائج وجدول الإصدارات، أعطت كل حالة نفس أنواع الأحداث ونفس قيم السمات في جميع عمليات التشغيل الثلاث. استبعدت معرفات الأحداث وأرقام التسلسل من تلك المقارنة.

النتائج على الإصدار 2.1.310

تبلغ حالات رفض القواعد عن طبقة الإعدادات التي قدمت القاعدة. تطابقت قيمة rule_source مع المكان الذي وضعت فيه القاعدة في كل مرة: projectSettings، و localSettings، و flagSettings لملف --settings، و cliArg لـ --disallowedTools، و policySettings لملف إعدادات مدار وضعته في /etc/claude-code/managed-settings.json. كما تغير الحالة المدارة الفئة إلى managed_policy، لذا يسهل فصل القاعدة المدارة عن قاعدة الرفض الخاصة بالمطور.

تم رفض قاعدة طلب (ask rule) في تشغيل -p في اختباري، وهو ما يتناسب مع جلسة لا يمكن لأحد فيها الإجابة على مطالبة. تم تسجيلها كـ permission_rule مع تعيين rule_source إلى projectSettings. كما تفوقت قاعدة رفض في إعدادات المشروع على سماح لنفس الأمر في سطر الأوامر (--allowedTools)، في ثلاث عمليات تشغيل من أصل ثلاث، وتم تسجيلها بنفس الطريقة.

تنقسم الـ Hooks إلى نوعين. الـ hook من نوع PreToolUse الذي أعاد قرار بالرفض (deny) أعطى الفئة hook، والقرار decision reject، وكود السبب reason_code hook:PreToolUse. أما الـ hook من نوع PostToolUse الذي أعاد حظراً (block) فقد أعطى الفئة hook_review والقرار decision sent_back. وفي الحالة الثانية، ذكر حدث tool_decision المطابق أنه accept، لأن قاعدة السماح كانت قد وافقت على الاستدعاء قبل تشغيله، ثم قام الـ hook بحظر النتيجة بعد ذلك.

لقد اختبرت فحصين مدمجين، وكلاهما وقع تحت safety_check. عملية كتابة إلى .claude/settings.json في وضع acceptEdits حملت circuit_breaker مضبوطاً على claudeSettingsFile. وظلت مرفوضة، مع نفس الحدث، عندما أضفت --allowedTools Write، في ثلاث محاولات من أصل ثلاث. أما عملية قراءة لـ /etc/hostname، وهي خارج دليل العمل، فقد حملت reason_code مضبوطاً على workingDir وبدون سمة circuit_breaker. تلك القراءة لم يكن لها قاعدة سماح. ومع استخدام --allowedTools Read، تم قبول نفس القراءة ولم يتم تسجيل أي حدث أمان، في ثلاث محاولات من أصل ثلاث. لذا في اختباري، منحت قاعدة السماح إذن القراءة الخارجية، بينما ظلت كتابة ملف الإعدادات مرفوضة حتى مع وجود إذن سماح. لقد جربت مساراً واحداً وصيغة قاعدة واحدة لكل منهما. استخدم اختبار القراءة الأول قاعدة سماح في إعدادات المشروع، والتي تم تجاهلها بسبب خلل موصوف أدناه. أعدت تشغيله بدون أي قاعدة سماح على الإطلاق وحصلت على نفس الحدث. تذكر الوثائق circuit_breaker كسمة تفصيلية لهذه الفئة، مع اعتبار outsideReadsBlocked كإحدى القيم المثال.^٢ لم أرَ هذه القيمة في عملية القراءة العادية الخاصة بي. تعامل مع السمة الدقيقة للقراءة الخارجية كشيء يجب التأكد منه في إصدارك الخاص.

ظهر لأول مرة في الإصدار 2.1.307

قمت بتشغيل قاعدة رفض في إعدادات المشروع، ووضع dontAsk، ورفض PreToolUse hook في الإصدارات 2.1.306 و 2.1.307 و 2.1.310، ثلاث مرات لكل منها، مع نفس الأمر (prompt) والإعدادات في كل إصدار.

يسرد npm الإصدار 2.1.306 على أنه نُشر في ٢١ أكتوبر ٢٠٢٦ الساعة ٠٢:٢٨ بالتوقيت العالمي المنسق، والإصدار 2.1.307 الساعة ٢٠:٤٧ بالتوقيت العالمي المنسق في نفس اليوم، وهو ما يتطابق مع سجل التغييرات.^٣ الإصدار 2.1.306 هو الإصدار الأقدم الوحيد الذي قمت بتشغيله، ولكن سجل التغييرات يدرج الحدث تحت 2.1.307، لذا فإن أي لوحة تحكم مبنية عليه لا ينبغي أن تظهر شيئاً للأجهزة التي تعمل بإصدارات أقدم.

الفجوة: حالات الرفض بدون حدث

تقول الوثائق أن بعض حالات الرفض لا تنتج حدث أمان. إحداها هي عملية تشغيل -p حيث لم يكن للأمر أي فئة ولم يتمكن أحد من الإجابة عليه، "بدون استخدام --permission-prompt-tool أو --permission-prompts none".^٢

لقد لاحظت نفس السلوك. في حالة عدم وجود قاعدة تمنح touch، رفض تشغيل -p الاستدعاء، وذكر حدث tool_decision حالة reject مع source config، ولم يتبع ذلك أي حدث أمان (safety event)، وذلك في ثلاث محاولات من أصل ثلاث. أما إضافة --permission-prompts none إلى نفس الأمر فقد أنتجت حدث أمان بفئة permission_mode، و reason_type asyncAgent و reason_code unknown.

تحليلنا: أي تنبيه يعتمد فقط على safety_event سيفقد فشلاً واحداً "بدون واجهة" (headless failure) يمكن أن تواجهه الوظائف التي تعمل بدون إشراف، وهو قيام العميل (agent) بطلب شيء لم يوافق عليه أحد مسبقاً. اقتراح الوثائق نفسها هو البحث عن أحداث tool_decision التي تبلغ عن reject مع source config ولا يوجد حدث أمان يشاركها نفس الـ tool_use_id.^٢ إذا كنت تقوم بتشغيل وظائف بدون إشراف، فقم ببناء هذا الاستعلام الثاني أيضاً، أو مرر --permission-prompts none حتى تحصل حالات الرفض هذه على فئة محددة.

الأداة المرفوضة التي لم يستدعها النموذج أبداً لا تعتبر رفضاً، ولم تترك أي حدث أيضاً. مع رفض WebFetch، ذكر النموذج في جميع المحاولات الثلاث أن الأداة لم تكن متاحة، ولم أرَ أي safety_event في أي منها. في كل محاولة، بحث النموذج أولاً عن الأداة باستخدام ToolSearch. وفي اثنتين من المحاولات الثلاث، ذكرت ردوده أنه حاول بعد ذلك استخدام curl عبر Bash، ولم يكن لتلك الرفوضات حدث أمان أيضاً، وهذا هو الفراغ المذكور أعلاه. لم أقم بتشغيل تجربة ضابطة بدون قاعدة الرفض. نتيجة WebFetch تتفق مع اختبار قواعد أذونات MCP الخاص بي، حيث أدت قواعد الرفض إلى إخراج الأداة من قائمة أدوات الجلسة في المحاولات التي فحصتها، على الرغم من أن النموذج ظل يحاول استدعاءها في ٨ من أصل ١١ محاولة كانت فيها الأداة مفقودة. لم أفحص قائمة الأدوات هنا، لذا أنا أستنتج ذلك مما قاله النموذج.

ما الذي يحتويه الحدث، وكيفية ربطه

تقول الوثائق إن سمات الحدث نفسها لا تحتوي على نص الأمر، أو مسارات الملفات، أو أسماء المضيفين، أو أسماء خوادم وأدوات MCP.^٢ قوائم السمات في عمليات تشغيل Bash و Read و Write الخاصة بي لم تحتوي على أي من ذلك. لم يتم استدعاء أي أداة MCP في أي عملية تشغيل، لذا لم أتحقق من أسماء خوادم أو أدوات MCP. مع ضبط OTEL_LOG_TOOL_DETAILS=1 في حالة رفض واحدة، عبر ثلاث محاولات، حمل حدث tool_decision الأمر كاملاً في tool_parameters، بينما لم يفعل safety_event لنفس الاستدعاء.

يرتبط الحدثان عبر tool_use_id. عبر ٦٩ محاولة على الإصدار 2.1.310، تطابقت جميع أحداث الأمان الـ ٤٢ مع حدث tool_decision بنفس الـ tool_use_id. في ٣٩ منها، جاء حدث الأمان بعد رقم event.sequence واحد من القرار. وفي الحالات الثلاث الأخرى، وهي حالات PostToolUse، جاء بعد خمسة أرقام، بعد أن تكونت الأداة قد عملت.

يحمل السجل أيضاً السمات القياسية، والتي تقول الوثائق إنها قد تشمل workspace.host_paths وسمات المستودع.^٢ في مخرجات وحدة التحكم الخاصة بي، تضمنت أيضاً user.email ومعرفات الحساب. إذا كنت تقوم بتوجيه هذه الأحداث إلى مجمع مشترك، فتحقق مما تكشف عنه السمات القياسية قبل القيام بذلك.

شيء واحد رأيته ولم أشرحه

قاعدة السماح (allow rule) المكتوبة في .claude/settings.json في دليل المسودات الخاص بي لم يتم تفعيلها في عمليات تشغيل -p. تم رفض استدعاء touch بدون حدث أمان (safety event)، في ثلاث محاولات من أصل ثلاث، وتكرر الأمر في دليل ثانٍ يحتوي على مجلد .git وهمي. بينما عملت نفس قاعدة السماح في settings.local.json، أو في ملف --settings أو في --allowedTools. أما قاعدة المنع (deny rule) في .claude/settings.json فقد طُبقت بشكل طبيعي. لم أبحث في السبب، ولن أعمم النتيجة خارج إعداداتي، ولكن هذا يفسر سبب ظهور حالات رفض في نسخة مبكرة من اختباري كنت أتوقع السماح بها.

ما لم أقم باختباره

• الجلسات التفاعلية، حيث يقوم شخص بالرد على المطالبات. تذكر الوثائق user_rejected للمطالبة المرفوضة أو التي تم تجاهلها، وهو ما لم أقم بتفعيله.
• الوضع التلقائي (Auto mode): auto_mode_block، و auto_mode_no_verdict وسمة classifier_category.
• فئات صندوق الرمل (sandbox) وهي sandbox_network، و sandbox_other و sandbox_override، و static_analysis.
• تصدير OTLP. استخدمت مصدّر وحدة التحكم (console exporter) فقط.
• أدوات MCP، والوكلاء الفرعيون (subagents)، والمهارات والإضافات.
• وضع التخطيط (Plan mode)، وخطافات (hooks) PermissionRequest و Stop. تذكر الوثائق هذه تحت permission_mode، و hook و hook_review، وكان اختباري الوحيد لوضع التخطيط غير حاسم.
• إعدادات مستوى المستخدم كمصدر للقواعد، والنماذج الأخرى، وأنظمة التشغيل الأخرى و Bedrock أو Vertex أو Foundry.
• الإصدارات بخلاف 2.1.306 و 2.1.307 و 2.1.310.

قراءات ذات صلة

• قواعد أذونات Claude Code MCP: تم اختبار الإصدار 2.1.299
• إخفاقات خطافات Claude Code: تم اختبار حظر onFailure
• خطافات updatedInput في Claude Code: تم اختبار تغيير الإصدار 2.1.300
• تعديلات Claude Code: ١٠ حالات استخدام مختبرة (٢٠٢٦)
• أساسيات أمن الذكاء الاصطناعي: الهجمات، الدفاعات والضوابط، الدورة التدريبية حول الضوابط والدفاع ضد حقن المطالبات (prompt injection)

الخلاصة

في عمليات claude -p الخاصة بي، وفر claude_code.safety_event سجل مراجعة مفيد لرفض القواعد، والخطافات (hooks)، وفحصين مدمجين، مع تسمية طبقة الإعدادات لكل قاعدة. وقد ظل صامتاً عندما رفض تشغيل بدون واجهة (headless run) أمر Bash لم يمنحه شيء، لذا قم بدمجه مع استعلام عن حالات رفض tool_decision التي ليس لها حدث أمان مطابق.

ابدأ بمصدر تصدير وحدة التحكم (console exporter) على جهاز واحد، وقم بتفعيل قاعدة رفض، واقرأ السجل. ثم قرر ما إذا كانت السمات القياسية آمنة للإرسال قبل توجيه المصدر إلى جامع بيانات مشترك.

المراجع