--- title: 'حدث الأمان safety_event في Claude Code: ماذا يسجل، وتم اختباره' description: أضاف Claude Code 2.1.307 حدث OpenTelemetry باسم safety_event. لقد قمت بتشغيل الإصدارات 2.1.306 و 2.1.307 و 2.1.310 لمعرفة أي حالات الرفض يتم تسجيلها وأيها يتم تخطيها في عمليات التشغيل باستخدام -p. url: https://nerdleveltech.com/ar/claude-code-safety-event-opentelemetry-tested language: ar date: '2026-10-26' category: security tags: - claude code - OpenTelemetry - claude code safety_event - claude code permissions - ai agent audit logging - agentic coding - developer tools markdown_url: https://nerdleveltech.com/ar/claude-code-safety-event-opentelemetry-tested.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/ar/claude-code-safety-event-opentelemetry-tested' terms: https://nerdleveltech.com/llms.txt --- # حدث الأمان 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 لم يتم منحه إذن. لقد احتفظت بسجلات 108 جلسات headless تم تشغيلها باستخدام console log exporter، لمعرفة ما يحتويه الحدث وما يغفله. ووجدت فجوة تستحق المعرفة قبل أن تقوم ببناء تنبيه (alert) بناءً عليه. ## ملخص - ظهر `claude_code.safety_event` لأول مرة في الإصدار 2.1.307. في الإصدار 2.1.306، أنتجت حالات الرفض الثلاث التي جربتها على كل إصدار حدث `tool_decision` فقط. أما في الإصدارين 2.1.307 و 2.1.310 فقد أنتجت كليهما. - غطى الحدث قواعد الرفض من خمسة مصادر (المشروع، المحلي، ملف `--settings`، علم `--disallowedTools`، الإعدادات المدارة)، وقاعدة طلب في إعدادات المشروع، ووضع `dontAsk`، و `--permission-prompts none`، ورفض من `PreToolUse` hook، وحظر من `PostToolUse`، وعملية قراءة خارج دليل العمل بدون قاعدة سماح، وعملية كتابة إلى `.claude/settings.json`. - لم يتم تفعيل الحدث عندما رفض تشغيل `-p` أمر Bash لم يتم منحه إذن. ظهر هذا الرفض فقط كحدث `tool_decision` مع تعيين `decision` إلى `reject`. تصف الوثائق هذه الحالة بأنها مطالبة (prompt) بدون فئة. أما الأداة المرفوضة التي لم يستدعها النموذج أبدًا، `WebFetch`، فلم تنتج أي حدث لتلك الأداة. - لم تحتوي سمات الحدث نفسها على نص أمر Bash، بما في ذلك في عمليات التشغيل التي استخدمت `OTEL_LOG_TOOL_DETAILS=1`. ظهر الأمر في حدث `tool_decision` المطابق. جميع أحداث الأمان الـ 42 في عمليات التشغيل الرئيسية الـ 69 على الإصدار 2.1.310 تشاركت `tool_use_id` مع حدث `tool_decision`. - اختبرت `claude -p` فقط، باستخدام الاسم المستعار `haiku`. الوضع التلقائي، وفئات الـ sandbox، والمطالبات التفاعلية وتصدير OTLP لم يتم اختبارها. ## ما ستتعلمه - ما هو `claude_code.safety_event` وأي إصدار أضافه - كيفية طباعته باستخدام console exporter عبر متغيرين للبيئة - أي حالات الرفض تنتج حدثًا، مع سمة الفئة (category) والتفاصيل (detail) لكل منها - أي حالات الرفض لا تنتج حدثًا، وكيفية العثور عليها - ما الذي يغفله الحدث، وكيفية ربطه بالأمر ## ما هو هذا الحدث `claude_code.safety_event` هو حدث سجل مهيكل يصدره Claude Code عندما يقوم شيء ما بإيقاف استدعاء أداة، أو طلب إذن لها، أو إرجاعها. تدرجه [سجل التغييرات (changelog)](https://code.claude.com/docs/en/changelog) تحت الإصدار 2.1.307، بتاريخ 21 أكتوبر 2026: "تم إضافة حدث OpenTelemetry `claude_code.safety_event` لكل استدعاء أداة تم إيقافه، أو طلب إذن له، أو إرجاعه بواسطة قاعدة أذونات، أو الوضع التلقائي، أو فحص أمان، أو hook أو الـ sandbox".[^1] تقول [وثائق المراقبة](https://code.claude.com/docs/en/monitoring-usage) أن الحدث "يتم تصديره مع الأحداث الأخرى وليس له إعداد منفصل".[^2] إذا كنت ترسل بالفعل بيانات telemetry لـ Claude Code، فستصل مع البقية. تحدد الوثائق 14 قيمة لسمة `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`.[^2] تكون سمة `decision` هي `accept`، أو `reject`، أو `sent_back` عندما يقوم "hook" بحظر نتيجة أو نهاية دور.[^2] ## كيف قمت باختبار ذلك يتكون الإعداد من متغيرين مطلوبين للبيئة وshell. كما قمت بتقصير فاصل التصدير إلى ثانية واحدة. لم أختبر ما إذا كان الإعداد الافتراضي سيقوم بعملية flush قبل خروج تشغيل قصير. ```bash 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، في 26 أكتوبر 2026. تظهر السجلات النموذج كـ `claude-haiku-5-5` في كل تشغيل تم الإبلاغ عنه، في جميع الإصدارات الثلاثة. كان 2.1.310 هو الوسم `latest` على npm عندما تحققت.[^3] استخدمت `touch made-by-lab.txt` كأمر. تم السماح بثلاث عمليات تشغيل باستخدام `echo` في وضع `dontAsk` دون وجود أي قاعدة على الإطلاق، لذا لم يتمكن `echo` من إظهار رفض، لذا استبعدته. قمت بتشغيل 23 تكويناً ثلاث مرات لكل منها على الإصدار 2.1.310، وهو ما يعادل 69 عملية تشغيل. ولمقارنة الإصدارات، قمت بتثبيت 2.1.306 و 2.1.307 من npm في مجلدات خاصة بهما وشغلت ثلاث حالات ثلاث مرات لكل منها على كليهما، بالإضافة إلى نفس الحالات الثلاث مرة أخرى على 2.1.310. هذا يمثل 27 عملية تشغيل. أربعة فحوصات متابعة من ثلاث عمليات تشغيل لكل منها، فحص `echo` المذكور أعلاه وثلاثة فحوصات للقراءة والكتابة الموضحة أدناه، ترفع الإجمالي إلى 108 جلسة مع سجلات محفوظة. كنت قد شغلت حالات 2.1.306 و 2.1.307 مرة واحدة سابقاً، ثلاث عمليات تشغيل لكل حالة، دون الاحتفاظ بالسجلات. تطابقت النتائج، ويستخدم الجدول إعادة التشغيل. اثنان من التكوينات الـ 23 لم يتم الإبلاغ عنهما كنتائج. كان أحدهما اختبار `PostToolUse` حيث كانت قاعدة السماح موجودة في إعدادات المشروع، وهو ما تسبب في تداخل بسبب خلل موصوف أدناه، لذا أعدت تنفيذه مع وضع قاعدة السماح في سطر الأوامر. والآخر كان اختبار كتابة في وضع التخطيط (plan mode) حيث رفض النموذج قبل استدعاء الأداة في اثنتين من ثلاث عمليات تشغيل، وتظهر سجلاته نموذجاً ثانياً، وهو `claude-sonnet-5-5`، لذا استبعدته. في جدول النتائج وجدول الإصدارات، أعطت كل حالة نفس أنواع الأحداث ونفس قيم السمات في جميع عمليات التشغيل الثلاث. استبعدت معرفات الأحداث وأرقام التسلسل من تلك المقارنة. ## النتائج على الإصدار 2.1.310 ![جدول لفئة safety\_event وسمة detail المبلغ عنها لكل حالة رفض في Claude Code 2.1.310، مع صفين لم يظهر فيهما safety\_event. أحدهما هو أمر Bash مرفوض لم يمنحه شيء.](https://nerdleveltech.com/images/claude-code-safety-event-opentelemetry-tested-results.png) تبلغ حالات رفض القواعد عن طبقة الإعدادات التي قدمت القاعدة. تطابقت قيمة `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] لم أرَ هذه القيمة في عملية القراءة العادية الخاصة بي. تعامل مع السمة الدقيقة للقراءة الخارجية كشيء يجب التأكد منه في إصدارك الخاص. ## ظهر لأول مرة في الإصدار 2.1.307 قمت بتشغيل قاعدة رفض في إعدادات المشروع، ووضع `dontAsk`، ورفض `PreToolUse` hook في الإصدارات 2.1.306 و 2.1.307 و 2.1.310، ثلاث مرات لكل منها، مع نفس الأمر (prompt) والإعدادات في كل إصدار. | الحالة | 2.1.306 | 2.1.307 | 2.1.310 | | ---------------------------- | ------------------- | -------------------------------- | -------------------------------- | | قاعدة رفض في إعدادات المشروع | `tool_decision` فقط | `tool_decision` + `safety_event` | `tool_decision` + `safety_event` | | وضع `dontAsk` | `tool_decision` فقط | `tool_decision` + `safety_event` | `tool_decision` + `safety_event` | | رفض `PreToolUse` hook | `tool_decision` فقط | `tool_decision` + `safety_event` | `tool_decision` + `safety_event` | يسرد npm الإصدار 2.1.306 على أنه نُشر في 21 أكتوبر 2026 الساعة 02:28 بالتوقيت العالمي المنسق، والإصدار 2.1.307 الساعة 20:47 بالتوقيت العالمي المنسق في نفس اليوم، وهو ما يتطابق مع سجل التغييرات.[^3] الإصدار 2.1.306 هو الإصدار الأقدم الوحيد الذي قمت بتشغيله، ولكن سجل التغييرات يدرج الحدث تحت 2.1.307، لذا فإن أي لوحة تحكم مبنية عليه لا ينبغي أن تظهر شيئاً للأجهزة التي تعمل بإصدارات أقدم. ## الفجوة: حالات الرفض بدون حدث تقول الوثائق أن بعض حالات الرفض لا تنتج حدث أمان. إحداها هي عملية تشغيل `-p` حيث لم يكن للأمر أي فئة ولم يتمكن أحد من الإجابة عليه، "بدون استخدام `--permission-prompt-tool` أو `--permission-prompts none`".[^2] لقد لاحظت نفس السلوك. في حالة عدم وجود قاعدة تمنح `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`.[^2] إذا كنت تقوم بتشغيل وظائف بدون إشراف، فقم ببناء هذا الاستعلام الثاني أيضاً، أو مرر `--permission-prompts none` حتى تحصل حالات الرفض هذه على فئة محددة. الأداة المرفوضة التي لم يستدعها النموذج أبداً لا تعتبر رفضاً، ولم تترك أي حدث أيضاً. مع رفض `WebFetch`، ذكر النموذج في جميع المحاولات الثلاث أن الأداة لم تكن متاحة، ولم أرَ أي `safety_event` في أي منها. في كل محاولة، بحث النموذج أولاً عن الأداة باستخدام `ToolSearch`. وفي اثنتين من المحاولات الثلاث، ذكرت ردوده أنه حاول بعد ذلك استخدام `curl` عبر Bash، ولم يكن لتلك الرفوضات حدث أمان أيضاً، وهذا هو الفراغ المذكور أعلاه. لم أقم بتشغيل تجربة ضابطة بدون قاعدة الرفض. نتيجة `WebFetch` تتفق مع [اختبار قواعد أذونات MCP](https://nerdleveltech.com/claude-code-mcp-allow-deny-rules-server-names-tested) الخاص بي، حيث أدت قواعد الرفض إلى إخراج الأداة من قائمة أدوات الجلسة في المحاولات التي فحصتها، على الرغم من أن النموذج ظل يحاول استدعاءها في 8 من أصل 11 محاولة كانت فيها الأداة مفقودة. لم أفحص قائمة الأدوات هنا، لذا أنا أستنتج ذلك مما قاله النموذج. ## ما الذي يحتويه الحدث، وكيفية ربطه تقول الوثائق إن سمات الحدث نفسها لا تحتوي على نص الأمر، أو مسارات الملفات، أو أسماء المضيفين، أو أسماء خوادم وأدوات MCP.[^2] قوائم السمات في عمليات تشغيل Bash و Read و Write الخاصة بي لم تحتوي على أي من ذلك. لم يتم استدعاء أي أداة MCP في أي عملية تشغيل، لذا لم أتحقق من أسماء خوادم أو أدوات MCP. مع ضبط `OTEL_LOG_TOOL_DETAILS=1` في حالة رفض واحدة، عبر ثلاث محاولات، حمل حدث `tool_decision` الأمر كاملاً في `tool_parameters`، بينما لم يفعل `safety_event` لنفس الاستدعاء. يرتبط الحدثان عبر `tool_use_id`. عبر 69 محاولة على الإصدار 2.1.310، تطابقت جميع أحداث الأمان الـ 42 مع حدث `tool_decision` بنفس الـ `tool_use_id`. في 39 منها، جاء حدث الأمان بعد رقم `event.sequence` واحد من القرار. وفي الحالات الثلاث الأخرى، وهي حالات `PostToolUse`، جاء بعد خمسة أرقام، بعد أن تكونت الأداة قد عملت. يحمل السجل أيضاً السمات القياسية، والتي تقول الوثائق إنها قد تشمل `workspace.host_paths` وسمات المستودع.[^2] في مخرجات وحدة التحكم الخاصة بي، تضمنت أيضاً `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](https://nerdleveltech.com/claude-code-mcp-allow-deny-rules-server-names-tested) - [إخفاقات خطافات Claude Code: تم اختبار حظر onFailure](https://nerdleveltech.com/claude-code-hook-fail-closed-onfailure-tested) - [خطافات updatedInput في Claude Code: تم اختبار تغيير الإصدار 2.1.300](https://nerdleveltech.com/claude-code-pretooluse-updatedinput-validation-tested) - [تعديلات Claude Code: 10 حالات استخدام مختبرة (2026)](https://nerdleveltech.com/claude-code-mods-use-cases-examples) - [أساسيات أمن الذكاء الاصطناعي: الهجمات، الدفاعات والضوابط](https://nerdleveltech.com/courses/ai-security-fundamentals)، الدورة التدريبية حول الضوابط والدفاع ضد حقن المطالبات (prompt injection) ## الأسئلة الشائعة ### ما هو claude\_code.safety\_event؟ هو حدث سجل (log event) من OpenTelemetry تمت إضافته في Claude Code 2.1.307 يقوم بتسجيل استدعاءات الأدوات التي أوقفتها أو طلبتها أو أعادتها قاعدة أذونات، أو الوضع التلقائي، أو فحص أمان، أو خطاف، أو صندوق الرمل.[^1] توضح سمة `category` الخاصة به أي فحص تم تفعيله، وتوضح سمة `decision` ما إذا كان الاستدعاء قد تم قبوله أو رفضه أو إعادته.[^2] ### كيف أرى أحداث الأمان محلياً؟ قم بتعيين `CLAUDE_CODE_ENABLE_TELEMETRY=1` و `OTEL_LOGS_EXPORTER=console`، ثم قم بتشغيل `claude -p` واقرأ مخرجات stdout. لا يوجد إعداد منفصل للحدث.[^2] في عمليات تشغيل `-p` الخاصة بي، طُبعت الأحداث في المخرجات القياسية، ممتزجة مع رد النموذج. ### هل يتضمن حدث الأمان الأمر الذي تم حظره؟ لا. تقول الوثائق إن سمات الحدث نفسها لا تحتوي على نص الأمر، أو مسارات الملفات، أو أسماء الخوادم، ولم تحتوي قوائم السمات في عمليات Bash و Read و Write الخاصة بي على أي من ذلك.[^2] في عملياتي الثلاث باستخدام `OTEL_LOG_TOOL_DETAILS=1`، ظهر الأمر فقط في حدث `tool_decision`، والذي يتم ربطه بواسطة `tool_use_id`. ### لماذا لم يكن للأمر المحظور حدث أمان (safety event)؟ في عملية `-p`، يتم رفض المطالبة التي ليس لها فئة ولا يمكن لأحد الإجابة عليها دون حدث أمان، وتذكر الوثائق هذه الحالة.[^2] لقد رأيت نفس السلوك مع أمر Bash لم تمنحه أي قاعدة، في 3 من أصل 3 عمليات. لا يزال الرفض يظهر كحدث `tool_decision` مع `decision` `reject` و `source` `config`. أما تمرير `--permission-prompts none` فقد أعطى نفس الاستدعاء حدث أمان من نوع `permission_mode`. ### أي إصدار من Claude Code أضاف safety\_event؟ الإصدار 2.1.307، المنشور في 21 أكتوبر 2026.[^1][^3] لقد تأكدت من ذلك عن طريق تشغيل ثلاثة إصدارات: الإصدار 2.1.306 أصدر فقط `tool_decision` لثلاث حالات رفض، بينما أصدر الإصداران 2.1.307 و 2.1.310 كلا الحدثين. ## الخلاصة في عمليات `claude -p` الخاصة بي، وفر `claude_code.safety_event` سجل مراجعة مفيد لرفض القواعد، والخطافات (hooks)، وفحصين مدمجين، مع تسمية طبقة الإعدادات لكل قاعدة. وقد ظل صامتاً عندما رفض تشغيل بدون واجهة (headless run) أمر Bash لم يمنحه شيء، لذا قم بدمجه مع استعلام عن حالات رفض `tool_decision` التي ليس لها حدث أمان مطابق. ابدأ بمصدر تصدير وحدة التحكم (console exporter) على جهاز واحد، وقم بتفعيل قاعدة رفض، واقرأ السجل. ثم قرر ما إذا كانت السمات القياسية آمنة للإرسال قبل توجيه المصدر إلى جامع بيانات مشترك. ## المراجع [^1]: [Claude Code changelog](https://code.claude.com/docs/en/changelog), Anthropic, version 2.1.307, October 21, 2026, read October 26, 2026. Source for the release of `claude_code.safety_event` and its quoted description. [^2]: [Monitoring](https://code.claude.com/docs/en/monitoring-usage), Claude Code documentation, Anthropic, read October 26, 2026. Source for the event description, the 14 category values, the attribute list, the export behavior, the `OTEL_LOG_TOOL_DETAILS` flag and the cases without a safety event. [^3]: [@anthropic-ai/claude-code on npm](https://www.npmjs.com/package/@anthropic-ai/claude-code), publish times and dist-tags queried with `npm view`, October 26, 2026. Source for the 2.1.306 and 2.1.307 publish times and for 2.1.310 as the `latest` tag.