كيف تعرف أن Claude Code أو Codex أو OpenCode ينتظرك

تشغّل خطافات Claude Code أمرًا تضبطه أنت عند وقوع حدث معيّن، وثلاثة منها تخبرك بأنه ينتظرك. فخطاف PreToolUse على أداة AskUserQuestion ينطلق حين يفتح نافذة السؤال. وخطاف Notification من النوع permission_prompt ينطلق حين تبقى نافذة طلب الإذن مفتوحة بضع ثوانٍ. وخطاف Stop ينطلق في نهاية كل رد ويحمل نص الرد في last_assistant_message، فتستطيع أن تتحقق مما إذا كان قد انتهى بسؤال. وتجاهل idle_prompt: فهو يصل بعد نحو دقيقة من أي رد لم يكتب بعده أحد شيئًا، لا بعد الأسئلة وحدها.

يستخدم Foxl Code، الذي يشغّل وكلاء البرمجة في طرفيات بعيدة، هذه الثلاثة بالضبط ليعلّم طرفية Claude Code البعيدة بأنها تنتظر مستخدمها. ومنذ v0.9.3-beta.5 صار أمر الإبلاغ نفسه يقرأ أيضًا Codex وOpenCode وHermes عبر خطافاتها وإضافاتها الخاصة. وفيما يلي الخريطة لكل CLI، والفخاخ في كل منها، وكيف تكتب الخطاف بحيث يكلّف الوكيل أقل ما يمكن ولا يسرّب نصًا إلى سياق النموذج أبدًا. ولم تُبلغ أي طرفية سحابية حية عن سؤال بعد؛ ويذكر القسم الأخير ما لم يُتحقق منه بعد.

لماذا لا ترى أن وكيلًا في طرفية ينتظرك؟

من يشغّل وكلاء في طرفيات بعيدة قد يفتح عدة طرفيات في وقت واحد ولا ينظر إلى أي منها. في 2026-10-21، طرحت طرفية Claude Code بعيدة سؤالًا جوابه نعم أو لا وبقيت عند موجّهها، بينما كانت واجهة API الخاصة بـ Foxl تقول إنه لا توجد مهمة تنتظر أحدًا. وبقي الشريط الجانبي في Foxl Code، وقائمة «يحتاج إلى إجراء منك» التي تضم المهام المنتظرة لشخص ما، وتطبيق الهاتف، كلها صامتة. فقبل هذا التغيير، لم يكن في Foxl Code ما يصغي إلى تلك اللحظة.

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

أي خطافات Claude Code تعني «أنا أنتظرك»؟

تثبّت صورنا السحابية Claude Code 2.1.296. وحيثما وُسم تفصيل أدناه بأنه مقروء من الحزمة، فهو من حزمة npm لذلك الإصدار، لا من طرفية قيد التشغيل.

صف idle_prompt هو حيث تخطئ معظم الإعدادات. فرسالته تبدو تمامًا ما تريده، لكنها تتبع أي رد لم يكتب بعده أحد، لذا فمعاملتها كسؤال تطلق تنبيهًا بعد كل دور تقريبًا (في حالة Foxl، بند في «يحتاج إلى إجراء منك» وإشعار على الهاتف). ونسجّل خطاف Notification بالمطابِق permission_prompt وحده، ويتحقق السكربت من النوع مرة أخرى. ولاختبار Stop، نزيل قبل الفحص المسافات البيضاء في النهاية، وتنسيق التوكيد في Markdown، وعلامات الاقتباس العكسية، والأقواس الختامية، وعلامات التنصيص، ونقبل علامة الاستفهام كاملة العرض ？ التي تكتبها طرق الإدخال في اللغات الصينية واليابانية والكورية.

ويسرد التوثيق الحالي لـ Claude Code أيضًا حدثًا مخصصًا هو PermissionRequest وأنواع إشعارات أكثر من هذه. ولم نتحقق مما إذا كان الإصدار 2.1.296 يحتوي الحدث الأحدث. أما permission_prompt فلا يزال في القائمة الحالية، وانتظاره ست ثوانٍ يستبعد النافذة التي يجيب عنها شخص أمام الشاشة. أضف الخطافات إلى ملف إعدادات Claude Code على مستوى المستخدم، بعد أي خطافات مضبوطة أصلًا للحدث نفسه، لتستمر الخطافات الموجودة في العمل:

{
  "hooks": {
    "PreToolUse": [{ "matcher": "AskUserQuestion",
      "hooks": [{ "type": "command", "command": "report-prompt", "timeout": 10 }] }],
    "Notification": [{ "matcher": "permission_prompt",
      "hooks": [{ "type": "command", "command": "report-prompt", "timeout": 10 }] }],
    "Stop": [{ "hooks": [{ "type": "command", "command": "report-prompt", "timeout": 10 }] }]
  }
}

كلها تستدعي سكربتًا صغيرًا واحدًا، هو أمر الإبلاغ (report-prompt أعلاه)، الذي يقرأ بيانات اعتماد المهمة من بيئته. والأحداث التي تعني أن الشخص أجاب، UserPromptSubmit والبقية (أحداث الإغلاق)، تُسجَّل بالطريقة نفسها، خلف حارس نصفه أدناه.

كيف تكتب خطافًا يكلّف الوكيل أقل ما يمكن؟

يعمل خطاف الإبلاغ داخل حلقة الوكيل نفسه، لذا فكل خطأ فيه مشكلة الوكيل. وانتهينا إلى خمس قواعد، كل منها مأخوذ من التوثيق أو من حزمة 2.1.296:

• لا تطبع شيئًا على stdout. في معظم الأحداث لا يفعل Claude Code بمخرجات stdout للخطاف سوى تسجيلها، لكن في UserPromptSubmit وبضعة أحداث أخرى "Claude Code adds plain-text stdout as context that Claude can see and act on." فسطر حالة من سكربت إبلاغ سيصبح جزءًا من الموجّه.
• اخرج دائمًا بالرمز 0. الرمز 2 يمنع الإجراء في الأحداث التي يمكن منعها، وأي رمز آخر غير الصفر يعرض إشعار خطأ. وفي سكربتنا، لا يكلّف فشل الشبكة أكثر من سطر واحد على stderr.
• اعمل بشكل متزامن، بمهلة قصيرة. يمكن للخطافات أن تعمل مع "async": true، لكن الإصدار المثبّت يطبع سطرًا في الطرفية كلما انتهى خطاف غير متزامن، وهذا يصير ضجيجًا حين تعمل الخطافات بعد كل استدعاء أداة. خطافاتنا متزامنة مع timeout: 10، والسكربت يمنح طلبه ثلاث ثوانٍ ويخرج من تلقاء نفسه بعدها بلحظة. وعلى Claude Code، التكلفة الحقيقية هي تشغيل Node.js مرة واحدة وطلب واحد في نهاية كل رد، أي نحو ثلاث ثوانٍ على الأكثر حين يتعذر الوصول إلى خادم Foxl.
• احرس الأحداث المتكررة في الصدفة. ينطلق PostToolUse عند كل استدعاء أداة. ويُنشئ أمر الإبلاغ ملف علامة حين يُبلغ عن سؤال مفتوح. ولا تشغّل خطافات الإغلاق Node.js إلا إذا كان ذلك الملف موجودًا، وإلا فإنها تستنزف stdin حتى لا ترى CLI أنبوبًا مكسورًا أبدًا:

  if [ -e /tmp/foxl-agent-prompt/open ]; then exec report-prompt; else cat >/dev/null; fi

  وما دام لا شيء مفتوحًا، فهذا مجرد test -e واحد لكل استدعاء أداة.
• أبقِ بيانات الاعتماد خارج سطر الأوامر. يرث الخطاف بيئة CLI، لذا يُقرأ الرمز من متغير بيئة ولا يظهر أبدًا في ps.

كيف تقول ذلك Codex وOpenCode وHermes؟

لكل CLI نقطة توسعة خاصة بها؛ وقرأنا كلًا منها من الإصدار الذي تثبّته صورنا. يملك Codex محرك خطافات يقبل صيغة خطافات Claude Code. أما OpenCode وHermes (واجهة CLI للوكيل من Nous Research) فلا يشغّلان خطافات صدفة في واجهة الطرفية؛ بل يحمّلان إضافات، وإضافاتنا تسلّم أمر الإبلاغ نفسه حدثًا موحّد الصيغة. أما Kiro، واجهة CLI للبرمجة من AWS، فليس فيها حدث يمكن الإصغاء إليه.

Codex. يراجع Codex الخطافات الموجودة في إعداداتك قبل تشغيلها: فالخطافات الجديدة أو المعدّلة "are marked for review and skipped until trusted." أما الخطاف المُدار، المضبوط في الإعدادات على مستوى النظام، فموثوق بحكم السياسة، ولذلك نثبّت خطافاتنا بهذه الطريقة. ولا يُثبَّت أمر الإبلاغ نفسه إلا في الطرفيات التي طلب فيها Foxl Code تقارير الأسئلة. وبالقياس على 0.162.1، يشغّل codex exec غير التفاعلي أيضًا الخطافات المُدارة ويطبع سطرين عنها لكل استدعاء أداة في مخرجاته، لذا نوقف الخطافات في عمليات التشغيل التي يبدؤها Foxl Code بـ codex exec. وبحسب ما قرأناه من مصدر 0.162.1، تعرض واجهة الطرفية في Codex أي خطاف يعمل أكثر من 300 ms، لذا يقرر أمر الإبلاغ ما إذا كان هناك سؤال، ويكتب ملف العلامة، ويسلّم طلب الشبكة إلى نسخة منفصلة من نفسه.

ونافذة السؤال في وضع Plan في Codex لا يُبلَغ عنها عمدًا، لأن خطاف PreToolUse الخاص بها ينطلق قبل أن يقرر Codex ما إذا كان السؤال مسموحًا به، وخارج وضع Plan يرفضه Codex. وبالقياس على 0.162.1، انطلق الخطاف ومعه السؤال ثم أجاب Codex بـ "request_user_input is unavailable in Default mode". وطرفيات Foxl Code تبدأ في وضع Default، فالإبلاغ عن ذلك الخطاف كان سيرسل إلى هاتفك سؤالًا لم يُطرح على أحد قط. والثمن أن طرفية Codex في وضع Plan لا تصل نافذة سؤالها إلى «يحتاج إلى إجراء منك».

OpenCode. تصغي إضافتنا إلى ناقل أحداث OpenCode. وأحداث السؤال ليست في قائمة الأحداث في توثيق إضافات OpenCode؛ بل في مصدر المخطط لإصدار v1.19.0، وهو ما قرأناه. وحالة الخمول تنهي الدور، ويُعدّ الدور سؤالًا حين ينتهي آخر رد فيه بـ ?. وما دامت نافذة سؤال أو طلب إذن مفتوحة، تُتجاهل تغييرات الحالة، فلا يغلقها انشغال الوكيل أو خموله حولها. وتُتخطى الأحداث القادمة من جلسة وكيل فرعي.

Hermes. على عكس ما يوحي به اسمه، ينطلق on_session_end في Hermes في نهاية كل دور على 0.19.0، مباشرة بعد الرد. وحين كانت إضافتنا تعامله كإغلاق، كانت تسحب السؤال الذي طرحه الدور للتو: أُغلق 7 من 12 سؤالًا فورًا، وفي 1 من 12 وصل السؤال إلى الخادم بعد إغلاقه هو نفسه، فبقي مفتوحًا دون أي شيء يغلقه. الآن لا يُعدّ إغلاقًا إلا انتهاء الجلسة المقطوع، وتخرج التقارير واحدًا تلو الآخر بالترتيب الذي أطلقها به Hermes.

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

ماذا يحدث حين يعلم Foxl؟

يذهب كل تقرير إلى نقطة نهاية واحدة على خادم Foxl Code، موثّقًا ببيانات اعتماد تلك المهمة نفسها، فيفتح أو يغلق بندًا في قائمة «يحتاج إلى إجراء منك» نفسها التي تضم أسئلة الوكلاء الأخرى. وتُعلَّم المهمة بأنها في انتظار ردك، كما في الشكل.

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

لا يُشعَر الهاتف إلا بالأسئلة التي قد تمر دون أن يراها أحد. فنافذة السؤال أو طلب الإذن التي لا تزال مفتوحة بعد 15 ثانية من علم Foxl بها ترسل إشعارًا، لأن الشخص الذي يراقب الطرفية يجيب في غضون ثوانٍ. ونافذة طلب الإذن في Claude Code يُبلَغ عنها بعد نحو ست ثوانٍ من فتحها، فيصل إشعارها بعد نحو 21 ثانية. أما الرد الذي ينتهي بسؤال فيظهر في «يحتاج إلى إجراء منك» دون إعلان، لأن ردودًا كثيرة تنتهي بسؤال. وسؤال 2026-10-21 كان من هذا النوع، فسيظهر الآن في «يحتاج إلى إجراء منك» وعلى المهمة، ولن يرنّ الهاتف مع ذلك.

ما الذي لم يُتحقق منه بعد؟

في اختباراتنا، عمل أمر الإبلاغ الحقيقي على حمولات كل CLI مثبّتة، وعملت الإضافات تحت Node.js وPython على صيغ الأحداث المثبّتة، وعملت نقطة النهاية على الخادم في نسخة محلية من بيئة تشغيل Cloudflare. أما ما لم يحدث بعد:

• سؤال حي من طرفية سحابية حقيقية. حتى 2026-10-23 لا يحتوي جدول الإنتاج أي سؤال من إحداها، لذا لا يزال التحقق الكامل على طرفية حية مستحقًا.
• تشغيل Claude Code لهذه الخطافات. تفاصيل Claude Code، ومنها التأخير ست ثوانٍ وسطر الخطاف غير المتزامن، قُرئت من حزمة 2.1.296، ولم تُشاهد على طرفية قيد التشغيل. لدينا اختبار يشغّل ذلك الإصدار مع هذه الخطافات؛ ولم يُشغَّل بعد.
• طرفيات واجهات CLI الأخرى. قُرئت عدة تفاصيل عن Codex وOpenCode وHermes من المصدر، ومنها أن OpenCode يسلّم أحداث السؤال بهذه الأسماء بالضبط؛ ولم يُشغَّل سوى codex exec.

إن كنت تشغّل وكلاء في طرفيات خاصة بك، فجدول خطافات Claude Code هو الجزء الذي يستحق النسخ. اربط الخطافات الثلاثة بأي شيء يصل إليك، وتجاهل idle_prompt، ولا تطبع شيئًا، واخرج بالرمز 0، وانتظر بضع ثوانٍ قبل أن ترسل تنبيهًا. ولجانب الطرفية في Foxl Code، يشرح مقالنا عن لماذا ذهبت كل ضغطة مفتاح ذات يوم إلى الجهاز الخطأ (بالإنجليزية) كيف تصل الكتابة إلى وكيل بعيد من الأساس.