Codex harness
زمان اجرای هارنس Codex
این صفحه قرارداد زمان اجرای نوبتهای harness مربوط به Codex را مستند میکند. برای راهاندازی و مسیریابی، از harness مربوط به Codex شروع کنید. برای فیلدهای پیکربندی، مرجع harness مربوط به Codex را ببینید.
نمای کلی
حالت Codex همان PI با یک فراخوانی مدل متفاوت در زیرساخت نیست. Codex بخش بیشتری از حلقه بومی مدل را در اختیار دارد، و OpenClaw سطوح Plugin، ابزار، نشست، و عیبیابی خود را پیرامون آن مرز تطبیق میدهد.
OpenClaw همچنان مالک مسیریابی کانال، فایلهای نشست، تحویل پیام قابل مشاهده، ابزارهای پویای OpenClaw، تأییدها، تحویل رسانه، و آینه رونوشت است. Codex مالک رشته بومی مرجع، حلقه بومی مدل، ادامه بومی ابزار، و Compaction بومی است.
پیوندهای رشته و تغییرات مدل
وقتی یک نشست OpenClaw به یک رشته موجود Codex متصل است، نوبت بعدی
مدل OpenAI انتخابشده فعلی، سیاست تأیید، sandbox، و سطح سرویس را
دوباره به app-server میفرستد. تغییر از openai/gpt-5.5 به
openai/gpt-5.2 پیوند رشته را حفظ میکند اما از Codex میخواهد با
مدل تازه انتخابشده ادامه دهد.
پاسخهای قابل مشاهده و Heartbeatها
وقتی یک نوبت گفتوگوی منبع از طریق harness مربوط به Codex اجرا میشود، پاسخهای قابل مشاهده
اگر استقرار messages.visibleReplies را صراحتاً پیکربندی نکرده باشد، بهطور پیشفرض
از ابزار message در OpenClaw استفاده میکنند. عامل همچنان میتواند نوبت Codex خود را بهصورت خصوصی تمام کند؛
فقط وقتی در کانال پست میکند که message(action="send") را فراخوانی کند. برای نگه داشتن
پاسخهای نهایی گفتوگوی مستقیم در مسیر تحویل خودکار قدیمی، مقدار
messages.visibleReplies: "automatic" را تنظیم کنید.
نوبتهای Heartbeat مربوط به Codex نیز بهطور پیشفرض heartbeat_respond را در کاتالوگ
قابل جستوجوی ابزارهای OpenClaw دریافت میکنند، تا عامل بتواند ثبت کند آیا بیدارباش باید
بیصدا بماند یا اعلان بدهد، بدون اینکه این جریان کنترل را در متن نهایی کدگذاری کند.
راهنمای ابتکار ویژه Heartbeat بهعنوان یک دستور توسعهدهنده در حالت همکاری Codex در خود نوبت Heartbeat فرستاده میشود. نوبتهای عادی گفتوگو حالت پیشفرض Codex را بازیابی میکنند، بهجای اینکه فلسفه Heartbeat را در prompt معمول زمان اجرای خود حمل کنند.
مرزهای hook
harness مربوط به Codex سه لایه hook دارد:
| لایه | مالک | هدف |
|---|---|---|
| hookهای Plugin در OpenClaw | OpenClaw | سازگاری محصول/Plugin در سراسر harnessهای PI و Codex. |
| میانافزار افزونه app-server مربوط به Codex | Pluginهای همراه OpenClaw | رفتار آداپتر در هر نوبت پیرامون ابزارهای پویای OpenClaw. |
| hookهای بومی Codex | Codex | چرخهعمر سطح پایین Codex و سیاست ابزار بومی از پیکربندی Codex. |
OpenClaw از فایلهای hooks.json پروژه یا سراسری Codex برای مسیریابی
رفتار Pluginهای OpenClaw استفاده نمیکند. برای پل پشتیبانیشده ابزار بومی و مجوز،
OpenClaw پیکربندی Codex در سطح هر رشته را برای PreToolUse، PostToolUse،
PermissionRequest، و Stop تزریق میکند.
وقتی تأییدهای app-server مربوط به Codex فعال باشند، یعنی approvalPolicy برابر
"never" نباشد، پیکربندی پیشفرض hook بومی تزریقشده PermissionRequest را حذف میکند تا
بازبین app-server مربوط به Codex و پل تأیید OpenClaw پس از بازبینی، escalationهای واقعی را مدیریت کنند.
اپراتورها وقتی به رله سازگاری نیاز دارند، میتوانند صراحتاً permission_request را به
nativeHookRelay.events اضافه کنند.
hookهای دیگر Codex مانند SessionStart و UserPromptSubmit همچنان
کنترلهای سطح Codex باقی میمانند. آنها در قرارداد v1 بهعنوان hookهای Plugin در OpenClaw
در معرض قرار نمیگیرند.
برای ابزارهای پویای OpenClaw، پس از اینکه Codex درخواست فراخوانی میدهد، OpenClaw ابزار را اجرا میکند، بنابراین OpenClaw رفتار Plugin و میانافزاری را که مالک آن است در آداپتر harness اجرا میکند. برای ابزارهای بومی Codex، Codex مالک رکورد مرجع ابزار است. OpenClaw میتواند رویدادهای منتخب را آینه کند، اما نمیتواند رشته بومی Codex را بازنویسی کند مگر اینکه Codex آن عملیات را از طریق app-server یا callbackهای hook بومی در معرض قرار دهد.
اعلانهای آیتم app-server مربوط به Codex همچنین مشاهدههای async after_tool_call
را برای تکمیل ابزارهای بومی فراهم میکنند که از قبل توسط رله بومی
PostToolUse پوشش داده نشدهاند. این مشاهدهها فقط برای تلهمتری و سازگاری Plugin هستند؛
نمیتوانند فراخوانی ابزار بومی را مسدود، با تأخیر، یا تغییر دهند.
پروجکشنهای چرخهعمر Compaction و LLM از اعلانهای app-server مربوط به Codex
و وضعیت آداپتر OpenClaw میآیند، نه از فرمانهای hook بومی Codex.
رویدادهای before_compaction، after_compaction، llm_input، و
llm_output در OpenClaw مشاهدههای سطح آداپتر هستند، نه ثبت بایتبهبایت
درخواست داخلی Codex یا payloadهای Compaction.
اعلانهای app-server بومی hook/started و hook/completed مربوط به Codex
بهعنوان رویدادهای عامل codex_app_server.hook برای مسیر حرکت و عیبیابی
پروجکت میشوند. آنها hookهای Plugin در OpenClaw را فراخوانی نمیکنند.
قرارداد پشتیبانی V1
پشتیبانیشده در زمان اجرای v1 مربوط به Codex:
| سطح | پشتیبانی | چرا |
|---|---|---|
| حلقه مدل OpenAI از طریق Codex | پشتیبانی میشود | app-server مربوط به Codex مالک نوبت OpenAI، ازسرگیری رشته بومی، و ادامه ابزار بومی است. |
| مسیریابی و تحویل کانال OpenClaw | پشتیبانی میشود | Telegram، Discord، Slack، WhatsApp، iMessage، و کانالهای دیگر بیرون از زمان اجرای مدل میمانند. |
| ابزارهای پویای OpenClaw | پشتیبانی میشود | Codex از OpenClaw میخواهد این ابزارها را اجرا کند، بنابراین OpenClaw در مسیر اجرا باقی میماند. |
| Pluginهای prompt و زمینه | پشتیبانی میشود | OpenClaw پوششهای prompt را میسازد و پیش از شروع یا ازسرگیری رشته، زمینه را در نوبت Codex پروجکت میکند. |
| چرخهعمر موتور زمینه | پشتیبانی میشود | assemble، ingest، نگهداری پس از نوبت، و هماهنگی Compaction موتور زمینه برای نوبتهای Codex اجرا میشوند. |
| hookهای ابزار پویا | پشتیبانی میشود | before_tool_call، after_tool_call، و میانافزار نتیجه ابزار پیرامون ابزارهای پویای تحت مالکیت OpenClaw اجرا میشوند. |
| hookهای چرخهعمر | بهعنوان مشاهدههای آداپتر پشتیبانی میشود | llm_input، llm_output، agent_end، before_compaction، و after_compaction با payloadهای صادقانه حالت Codex اجرا میشوند. |
| gate بازبینی پاسخ نهایی | از طریق رله hook بومی پشتیبانی میشود | Stop در Codex به before_agent_finalize رله میشود؛ revise از Codex یک گذر مدل دیگر پیش از نهاییسازی میخواهد. |
| مسدودسازی یا مشاهده shell، patch، و MCP بومی | از طریق رله hook بومی پشتیبانی میشود | PreToolUse و PostToolUse در Codex برای سطوح ابزار بومی commitشده رله میشوند، از جمله payloadهای MCP روی app-server مربوط به Codex نسخه 0.125.0 یا جدیدتر. مسدودسازی پشتیبانی میشود؛ بازنویسی آرگومان پشتیبانی نمیشود. |
| سیاست مجوز بومی | از طریق تأییدهای app-server مربوط به Codex و رله سازگاری hook بومی پشتیبانی میشود | درخواستهای تأیید app-server مربوط به Codex پس از بازبینی Codex از طریق OpenClaw مسیریابی میشوند. رله hook بومی PermissionRequest برای حالتهای تأیید بومی opt-in است، چون Codex آن را پیش از بازبینی guardian منتشر میکند. |
| ثبت مسیر حرکت app-server | پشتیبانی میشود | OpenClaw درخواستی را که به app-server فرستاده و اعلانهای app-server را که دریافت میکند ثبت میکند. |
پشتیبانینشده در زمان اجرای v1 مربوط به Codex:
| سطح | مرز V1 | مسیر آینده |
|---|---|---|
| تغییر آرگومان ابزار بومی | hookهای پیش از ابزار بومی Codex میتوانند مسدود کنند، اما OpenClaw آرگومانهای ابزار بومی Codex را بازنویسی نمیکند. | به پشتیبانی hook/schema در Codex برای ورودی ابزار جایگزین نیاز دارد. |
| تاریخچه قابل ویرایش رونوشت بومی Codex | Codex مالک تاریخچه مرجع رشته بومی است. OpenClaw مالک یک آینه است و میتواند زمینه آینده را پروجکت کند، اما نباید internals پشتیبانینشده را تغییر دهد. | اگر جراحی رشته بومی لازم باشد، APIهای صریح app-server مربوط به Codex اضافه شود. |
tool_result_persist برای رکوردهای ابزار بومی Codex |
آن hook نوشتنهای رونوشت تحت مالکیت OpenClaw را تبدیل میکند، نه رکوردهای ابزار بومی Codex را. | میتوان رکوردهای تبدیلشده را آینه کرد، اما بازنویسی مرجع به پشتیبانی Codex نیاز دارد. |
| فراداده غنی Compaction بومی | OpenClaw شروع و تکمیل Compaction را مشاهده میکند، اما فهرست پایدار نگهداشته/حذفشده، delta توکن، یا payload خلاصه دریافت نمیکند. | به رویدادهای غنیتر Compaction در Codex نیاز دارد. |
| مداخله در Compaction | hookهای فعلی Compaction در OpenClaw در حالت Codex در سطح اعلان هستند. | اگر Pluginها نیاز به veto یا بازنویسی Compaction بومی دارند، hookهای پیش/پس از Compaction در Codex اضافه شود. |
| ثبت بایتبهبایت درخواست API مدل | OpenClaw میتواند درخواستها و اعلانهای app-server را ثبت کند، اما هسته Codex درخواست نهایی OpenAI API را بهصورت داخلی میسازد. | به رویداد ردیابی درخواست مدل در Codex یا API عیبیابی نیاز دارد. |
مجوزهای بومی و elicitations مربوط به MCP
برای PermissionRequest، OpenClaw فقط وقتی سیاست تصمیم بگیرد، تصمیمهای صریح allow یا deny
را برمیگرداند. نتیجه بدون تصمیم، allow نیست. Codex آن را بهعنوان نبود تصمیم hook
در نظر میگیرد و به guardian خود یا مسیر تأیید کاربر ادامه میدهد.
حالتهای تأیید Codex app-server این قلاب بومی را بهصورت پیشفرض حذف میکنند. این رفتار زمانی اعمال میشود که permission_request صراحتاً در nativeHookRelay.events گنجانده شده باشد یا یک زمان اجرای سازگاری آن را نصب کند.
وقتی یک اپراتور برای درخواست مجوز بومی Codex گزینه allow-always را انتخاب میکند، OpenClaw اثر انگشت دقیق ارائهدهنده/نشست/ورودی ابزار/cwd را برای یک بازه نشست محدود به خاطر میسپارد. تصمیم بهخاطر سپردهشده عمداً فقط برای تطابق دقیق است: تغییر در فرمان، آرگومانها، بار داده ابزار، یا cwd تأیید تازهای ایجاد میکند.
درخواستهای تأیید ابزار Codex MCP وقتی Codex مقدار _meta.codex_approval_kind را برابر با "mcp_tool_call" قرار دهد، از طریق جریان تأیید Plugin در OpenClaw مسیریابی میشوند. اعلانهای Codex request_user_input به گفتوگوی مبدأ بازگردانده میشوند، و پیام پیگیری بعدی در صف به همان درخواست سرور بومی پاسخ میدهد، بهجای اینکه بهعنوان زمینه اضافی هدایت شود. سایر درخواستهای فراخوانی MCP در حالت بسته با شکست مواجه میشوند.
هدایت صف
هدایت صف اجرای فعال روی turn/steer در Codex app-server نگاشت میشود. با مقدار پیشفرض messages.queue.mode: "steer"، OpenClaw پیامهای گفتوگوی صفشده را برای پنجره سکوت پیکربندیشده دستهبندی میکند و آنها را بهترتیب ورود، بهعنوان یک درخواست turn/steer میفرستد. حالت قدیمی queue درخواستهای turn/steer جداگانه میفرستد.
نوبتهای بازبینی Codex و Compaction دستی میتوانند هدایت در همان نوبت را رد کنند. در این حالت، وقتی حالت انتخابشده اجازه بازگشت را بدهد، OpenClaw از صف پیگیری استفاده میکند. صف هدایت را ببینید.
بارگذاری بازخورد Codex
وقتی /diagnostics [note] برای نشستی که از harness بومی Codex استفاده میکند تأیید شود، OpenClaw همچنین برای رشتههای مرتبط Codex، feedback/upload در Codex app-server را فراخوانی میکند. این بارگذاری از app-server میخواهد برای هر رشته فهرستشده و زیررشتههای ایجادشده Codex، در صورت موجود بودن، لاگها را شامل کند.
بارگذاری از مسیر معمول بازخورد Codex به سرورهای OpenAI عبور میکند. اگر بازخورد Codex در آن app-server غیرفعال باشد، فرمان خطای app-server را برمیگرداند. پاسخ تکمیلشده diagnostics کانالها، شناسههای نشست OpenClaw، شناسههای رشته Codex، و فرمانهای محلی codex resume <thread-id> را برای رشتههایی که ارسال شدهاند فهرست میکند.
اگر تأیید را رد کنید یا نادیده بگیرید، OpenClaw آن شناسههای Codex را چاپ نمیکند و بازخورد Codex را ارسال نمیکند. این بارگذاری جایگزین خروجی diagnostics محلی Gateway نمیشود. برای رفتار تأیید، حریم خصوصی، بسته محلی، و گفتوگوی گروهی، خروجی Diagnostics را ببینید.
از /codex diagnostics [note] فقط وقتی استفاده کنید که مشخصاً بارگذاری بازخورد Codex را برای رشتهای که در حال حاضر متصل است میخواهید، بدون بسته کامل diagnostics Gateway.
Compaction و آینه رونوشت
وقتی مدل انتخابشده از harness Codex استفاده میکند، Compaction بومی رشته به Codex app-server واگذار میشود. OpenClaw یک آینه رونوشت برای تاریخچه کانال، جستوجو، /new، /reset، و تغییر مدل یا harness در آینده نگه میدارد.
آینه شامل اعلان کاربر، متن نهایی دستیار، و رکوردهای سبک استدلال یا برنامه Codex است، وقتی app-server آنها را منتشر کند. در حال حاضر، OpenClaw فقط سیگنالهای شروع و تکمیل Compaction بومی را ثبت میکند. هنوز خلاصهای خوانا برای انسان از Compaction یا فهرستی قابل ممیزی از اینکه Codex پس از Compaction کدام ورودیها را نگه داشته است ارائه نمیکند.
از آنجا که Codex مالک رشته بومی مرجع است، tool_result_persist در حال حاضر رکوردهای نتیجه ابزار بومی Codex را بازنویسی نمیکند. این فقط زمانی اعمال میشود که OpenClaw در حال نوشتن نتیجه ابزار رونوشت نشست تحت مالکیت OpenClaw باشد.
رسانه و تحویل
OpenClaw همچنان مالک تحویل رسانه و انتخاب ارائهدهنده رسانه است. تصویر، ویدیو، موسیقی، PDF، TTS، و فهم رسانه از تنظیمات ارائهدهنده/مدل متناظر مانند agents.defaults.imageGenerationModel، videoGenerationModel، pdfModel، و messages.tts استفاده میکنند.
متن، تصاویر، ویدیو، موسیقی، TTS، تأییدها، و خروجی ابزار پیامرسانی همچنان از مسیر معمول تحویل OpenClaw عبور میکنند. تولید رسانه به PI نیاز ندارد. وقتی Codex یک آیتم تولید تصویر بومی با savedPath منتشر کند، OpenClaw همان فایل دقیق را از طریق مسیر معمول رسانه پاسخ ارسال میکند، حتی اگر نوبت Codex هیچ متن دستیار نداشته باشد.