अवलोकन
Codex नेटिव मॉडल लूप, नेटिव थ्रेड पुनः आरंभ, नेटिव टूल निरंतरता और नेटिव Compaction का स्वामी है। OpenClaw चैनल रूटिंग, सत्र फ़ाइलों, दृश्यमान संदेश डिलीवरी, OpenClaw डायनेमिक टूल, अनुमोदनों, मीडिया डिलीवरी और उस सीमा के आसपास ट्रांस्क्रिप्ट मिरर का स्वामी है। प्रॉम्प्ट रूटिंग केवल प्रोवाइडर स्ट्रिंग का नहीं, बल्कि चयनित रनटाइम का अनुसरण करती है। एक नेटिव Codex टर्न को Codex app-server डेवलपर निर्देश मिलते हैं; एक स्पष्ट OpenClaw संगतता रूट, Codex-सदृश OpenAI प्रमाणीकरण या ट्रांसपोर्ट का उपयोग करने पर भी, सामान्य OpenClaw सिस्टम प्रॉम्प्ट बनाए रखता है। OpenClaw, Codex की अंतर्निहित पर्सनैलिटी अक्षम करके (personality: "none")
नेटिव Codex थ्रेड शुरू और पुनः आरंभ करता है, ताकि वर्कस्पेस पर्सनैलिटी फ़ाइलें
और OpenClaw एजेंट पहचान प्रामाणिक बने रहें। अन्यथा नेटिव Codex, Codex के स्वामित्व वाले
बेस/मॉडल निर्देश और प्रोजेक्ट-दस्तावेज़ लोडिंग बनाए रखता है। हल्के
OpenClaw रन (उदाहरण के लिए cron) अब भी प्रोजेक्ट-दस्तावेज़ लोडिंग को रोकते हैं।
OpenClaw डेवलपर निर्देश OpenClaw रनटाइम संबंधी विषयों को कवर करते हैं: स्रोत-चैनल
डिलीवरी, OpenClaw डायनेमिक टूल, ACP डेलिगेशन, अडैप्टर संदर्भ और
सक्रिय एजेंट वर्कस्पेस प्रोफ़ाइल फ़ाइलें। Skill कैटलॉग और टूल द्वारा रूट किए गए
MEMORY.md पॉइंटर, टर्न-स्कोप वाले सहयोग डेवलपर
निर्देशों के रूप में प्रक्षेपित किए जाते हैं। जब मेमोरी टूल उपलब्ध नहीं होते, तब सक्रिय BOOTSTRAP.md सामग्री
और पूर्ण MEMORY.md, इसके बजाय सामान्य टर्न इनपुट संदर्भ में फ़ॉलबैक होते हैं।
अधिकांश OpenClaw डायनेमिक टूल खोज योग्य openclaw नेमस्पेस का उपयोग करते हैं। वे टूल
जिन्हें catalogMode: "direct-only" चिह्नित किया गया है, openclaw_direct का उपयोग करते हैं, जिसे Codex
नेस्टेड Code Mode निष्पादन के लिए उजागर करने के बजाय सीधे
DirectModelOnly के रूप में मॉडल-दृश्यमान रखता है।
थ्रेड बाइंडिंग और मॉडल परिवर्तन
जब कोई OpenClaw सत्र किसी मौजूदा Codex थ्रेड से जुड़ा होता है, तो अगला टर्न वर्तमान में चयनित मॉडल, अनुमोदन नीति, सैंडबॉक्स, अनुमोदन समीक्षक और सेवा स्तर को app-server पर फिर से भेजता है।openai/gpt-5.5
से openai/gpt-5.2 पर स्विच करने से थ्रेड बाइंडिंग बनी रहती है, लेकिन Codex से
नए चयनित मॉडल के साथ जारी रखने को कहा जाता है।
पर्यवेक्षित बाइंडिंग इसका अपवाद हैं। OpenClaw मॉडल पिकर लॉक रहता है,
और पुनः आरंभ में मॉडल तथा प्रोवाइडर ओवरराइड छोड़ दिए जाते हैं, ताकि Codex प्रामाणिक
थ्रेड के स्थायी मॉडल और प्रोवाइडर को पुनर्स्थापित करे। एक अलग नेटिव Codex नियंत्रण
उस स्थायी जोड़ी को बदल सकता है, और आरंभिक स्नैपशॉट Codex की सामान्य
मॉडल-अंतर चेतावनी उत्पन्न कर सकता है; बाहरी OpenClaw मॉडल और फ़ॉलबैक शृंखला
दोनों में से किसी को कभी प्रतिस्थापित नहीं करते।
पर्यवेक्षण और सुरक्षित निरंतरता
Codex पर्यवेक्षण उसीcodex Plugin की वैकल्पिक क्षमता है। यह
एक अलग कनेक्शन के माध्यम से नेटिव थ्रेड खोजता है और Gateway कैटलॉग में केवल गैर-संग्रहीत
सत्रों को प्रक्षेपित करता है। स्पष्ट appServer कनेक्शन
सेटिंग के बिना, वह कनेक्शन प्रबंधित उपयोगकर्ता-होम stdio का उपयोग करता है, जबकि सामान्य
हार्नेस एजेंट-स्कोप वाला रहता है। सूचीकरण और मेटाडेटा रीड निष्क्रिय होते हैं: वे
किसी थ्रेड को पुनः आरंभ नहीं करते, OpenClaw को उसके लाइव इवेंट की सदस्यता नहीं दिलाते, या उसके
अनुमोदनों का उत्तर नहीं देते।
Gateway कंप्यूटर पर संग्रहीत या निष्क्रिय सत्र के लिए, शाखा के रूप में जारी रखें
एक सामान्य, मॉडल-लॉक Chat बनाता है और स्रोत के अंतिम टर्मिनल स्थायी टर्न तक
सीमित उपयोगकर्ता और सहायक इतिहास को मिरर करता है। पहला सामान्य
Chat टर्न वास्तविक अनुमोदन हैंडलर स्थापित करता है और मॉडल या प्रोवाइडर ओवरराइड के बिना
स्नैपशॉट को पिन करने के लिए अस्थायी नेटिव फ़ोर्क का उपयोग करता है। Codex App Server अपने
वर्तमान नेटिव कॉन्फ़िगरेशन का उपयोग करता है और चयनित जोड़ी लौटाता है; यदि वह मॉडल स्रोत के
अंतिम रिकॉर्ड किए गए मॉडल से भिन्न हो, तो यह अपनी सामान्य चेतावनी जारी करता है।
उसी पर्यवेक्षण कनेक्शन पर, OpenClaw प्रामाणिक
appServer-स्रोत Codex हार्नेस थ्रेड को उसके cwd और रनटाइम नीति के अंतर्गत
उस आरंभिक शुरुआत के लिए ठीक उसी लौटाए गए मॉडल और प्रोवाइडर के साथ शुरू करता है,
सीमित दृश्यमान इतिहास इंजेक्ट करता है और अस्थायी फ़ोर्क को संग्रहीत करता है। स्रोत को कभी
पुनः आरंभ नहीं किया जाता। प्रामाणिक थ्रेड में पूर्ण OpenClaw हार्नेस टूल सतह होती है;
स्रोत से तर्क, टूल कॉल और टूल परिणाम उसमें क्लोन नहीं किए जाते।
निजी कनेक्शन स्कोप लंबित और प्रतिबद्ध बाइंडिंग स्थितियों में बना रहता है, इसलिए
हर बाद का टर्न नेटिव प्रमाणीकरण और प्रोवाइडर कॉन्फ़िगरेशन के साथ उसी कनेक्शन पर रहता है।
अक्षम पर्यवेक्षण या बाइंडिंग/कनेक्शन विचलन, सामान्य एजेंट-होम हार्नेस पर
स्विच करने के बजाय बंद होकर विफल होता है।
मूल CLI, VS Code, Atlas या ChatGPT स्रोत दोनों
कैटलॉग के लिए पात्र बना रहता है। प्रामाणिक शाखा एक नेटिव Codex थ्रेड है, लेकिन उसका स्रोत प्रकार
appServer है; नेटिव क्लाइंट उस स्रोत प्रकार को फ़िल्टर कर सकते हैं, इसलिए
Codex Desktop में उसका दिखाई देना सुनिश्चित नहीं है।
सक्रिय स्रोत नई शाखा शुरू नहीं कर सकते या संग्रहीत नहीं किए जा सकते; मौजूदा पर्यवेक्षित
Chat फिर भी खोला जा सकता है। notLoaded का अर्थ है कि गतिविधि अज्ञात है, निष्क्रिय नहीं;
OpenClaw स्थानीय idle या notLoaded पंक्ति को संग्रहीत करने की अनुमति केवल स्पष्ट
अन्य-रनर-न-होने की पुष्टि और नई प्रक्रिया-स्थानीय स्थिति रीड के बाद देता है। Codex
एक App Server प्रक्रिया के भीतर थ्रेड म्यूटेशन को क्रमबद्ध करता है, लेकिन
विशिष्ट क्रॉस-प्रोसेस रनर या अनुमोदन-स्वामी लीज़ प्रदान नहीं करता, इसलिए वह रीड यह
सिद्ध नहीं कर सकती कि कोई अन्य प्रक्रिया थ्रेड का उपयोग नहीं कर रही है। OpenClaw सटीक
लक्ष्य या Codex की पृष्ठांकित वंशज क्वेरी द्वारा लौटाए गए किसी भी गैर-संग्रहीत उत्पन्न वंशज के लिए
ज्ञात सक्रिय बाइंडिंग स्वामी को अवरुद्ध करता है। गणना त्रुटियाँ, चक्र और
सुरक्षा-सीमा समाप्ति बंद होकर विफल होती हैं। नेटिव संग्रहण फिर भी दूसरी प्रक्रिया में
नए टर्न के साथ प्रतिस्पर्धा कर सकता है, इसलिए पुष्टि अज्ञात क्लाइंट और
स्थिति रीड तथा संग्रहण के बीच के अंतराल को कवर करती है। पर्यवेक्षित मॉडल-लॉक Chat को तब तक
हटाया नहीं जा सकता, जब तक वह नेटिव बाइंडिंग की सुरक्षा करता है।
आरंभिक रिलीज़ में युग्मित-Node कैटलॉग केवल मेटाडेटा तक सीमित रहते हैं। वर्तमान
Node इनवोक सीमा अनुरोध/प्रतिक्रिया आधारित है और वास्तविक Codex हार्नेस
बाइंडिंग के लिए आवश्यक दीर्घकालिक टर्न इवेंट, अनुमोदन अनुरोध या स्ट्रीमिंग आउटपुट
नहीं ले जा सकती। इसलिए पंक्ति के निष्क्रिय होने पर भी रिमोट जारी रखें और संग्रहित करें
अनुपलब्ध रहते हैं।
ऑपरेटर सेटअप और दृश्यमान Control UI व्यवहार के लिए
Codex पर्यवेक्षण देखें।
दृश्यमान उत्तर और Heartbeat
Codex हार्नेस से होकर जाने वाले प्रत्यक्ष/स्रोत चैट टर्न आंतरिक WebChat सतहों के लिए डिफ़ॉल्ट रूप से स्वचालित अंतिम सहायक डिलीवरी का उपयोग करते हैं, जो Pi हार्नेस अनुबंध से मेल खाता है: एजेंट सामान्य रूप से उत्तर देता है और OpenClaw अंतिम टेक्स्ट को स्रोत वार्तालाप में पोस्ट करता है। अंतिम सहायक टेक्स्ट को निजी रखने के लिएmessages.visibleReplies: "message_tool" सेट करें, जब तक एजेंट message(action="send") को कॉल न करे।
Codex Heartbeat टर्न को डिफ़ॉल्ट रूप से खोज योग्य OpenClaw टूल
कैटलॉग में heartbeat_respond मिलता है, ताकि एजेंट रिकॉर्ड कर सके कि जागरण शांत रहना चाहिए
या सूचना देनी चाहिए। Heartbeat पहल मार्गदर्शन, Heartbeat टर्न तक सीमित Codex सहयोग-मोड
डेवलपर निर्देश के रूप में भेजा जाता है; सामान्य चैट टर्न
Codex Default मोड में रहते हैं। जब HEARTBEAT.md रिक्त नहीं होता, तब Heartbeat
निर्देश उसकी सामग्री को इनलाइन करने के बजाय Codex को फ़ाइल की ओर निर्देशित करते हैं।
हुक सीमाएँ
OpenClaw, Plugin व्यवहार को रूट करने के लिए प्रोजेक्ट या ग्लोबल Codex
hooks.json फ़ाइलों का उपयोग नहीं करता। नेटिव टूल और अनुमति ब्रिज के लिए, OpenClaw
PreToolUse, PostToolUse, PermissionRequest,
और Stop हेतु प्रति-थ्रेड Codex कॉन्फ़िग इंजेक्ट करता है।
जब Codex app-server अनुमोदन सक्षम होते हैं (approvalPolicy,
"never" नहीं होता), तो डिफ़ॉल्ट इंजेक्ट किया गया नेटिव हुक कॉन्फ़िग
PermissionRequest को छोड़ देता है, ताकि Codex का app-server समीक्षक और OpenClaw का
अनुमोदन ब्रिज समीक्षा के बाद वास्तविक एस्केलेशन संभालें। फिर भी संगतता रिले को बाध्य करने के लिए
nativeHookRelay.events में permission_request जोड़ें।
SessionStart और UserPromptSubmit जैसे अन्य Codex
हुक Codex-स्तरीय नियंत्रण बने रहते हैं; उन्हें v1 अनुबंध में OpenClaw Plugin हुक के रूप में
उजागर नहीं किया जाता।
OpenClaw डायनेमिक टूल के लिए, Codex द्वारा कॉल माँगे जाने के बाद OpenClaw टूल
निष्पादित करता है, इसलिए Plugin और मिडलवेयर व्यवहार हार्नेस अडैप्टर में चलता है। Codex
Code Mode सामान्य डायनेमिक परिणामों को टेक्स्ट के रूप में प्राप्त करता है और नेस्टेड
डायनेमिक कॉल को क्रमबद्ध करता है; कॉलर को JSON-सदृश परिणामों को पार्स करना होगा और
समवर्ती सबमिशन के लिए Promise.all पर निर्भर नहीं रह सकते। Codex-नेटिव टूल के लिए,
Codex प्रामाणिक टूल रिकॉर्ड का स्वामी है; OpenClaw चयनित इवेंट को मिरर कर सकता है, लेकिन
नेटिव थ्रेड को फिर से नहीं लिख सकता, जब तक Codex इसे app-server या नेटिव हुक
कॉलबैक के माध्यम से उजागर न करे।
Codex app-server रिपोर्ट-मोड PreToolUse इवेंट Plugin अनुमोदन को
मेल खाते app-server अनुमोदन तक स्थगित करते हैं। यदि कोई OpenClaw before_tool_call हुक
requireApproval लौटाता है जबकि नेटिव पेलोड openclaw_approval_mode: "report" सेट करता है, तो नेटिव हुक रिले Plugin अनुमोदन आवश्यकता को रिकॉर्ड करता है और
कोई नेटिव निर्णय नहीं लौटाता। जब Codex बाद में उसी टूल उपयोग के लिए app-server अनुमोदन
अनुरोध भेजता है, तो OpenClaw Plugin अनुमोदन प्रॉम्प्ट खोलता है और
निर्णय को वापस Codex पर मैप करता है। Codex PermissionRequest इवेंट एक
अलग अनुमोदन पथ हैं और उस ब्रिज के लिए कॉन्फ़िगर किए जाने पर अब भी OpenClaw अनुमोदनों के माध्यम से
रूट हो सकते हैं।
Codex app-server आइटम सूचनाएँ उन नेटिव टूल पूर्णताओं के लिए एसिंक्रोनस
after_tool_call अवलोकन भी प्रदान करती हैं, जो पहले से नेटिव
PostToolUse रिले द्वारा कवर नहीं हैं। ये केवल टेलीमेट्री/संगतता के लिए हैं; ये
नेटिव टूल कॉल को अवरुद्ध, विलंबित या परिवर्तित नहीं कर सकते।
Compaction और LLM जीवनचक्र प्रक्षेपण Codex app-server
सूचनाओं और OpenClaw अडैप्टर स्थिति से आते हैं, नेटिव Codex हुक कमांड से नहीं।
before_compaction, after_compaction, llm_input, और llm_output
अडैप्टर-स्तरीय अवलोकन हैं, Codex के आंतरिक
अनुरोध या Compaction पेलोड की बाइट-दर-बाइट प्रतिलिपियाँ नहीं।
Codex नेटिव hook/started और hook/completed app-server सूचनाएँ
ट्रैजेक्टरी और डीबगिंग के लिए codex_app_server.hook एजेंट इवेंट के रूप में
प्रक्षेपित की जाती हैं। वे OpenClaw Plugin हुक को इनवोक नहीं करतीं।
V1 समर्थन अनुबंध
Codex रनटाइम v1 में समर्थित:
Codex रनटाइम v1 में समर्थित नहीं:
नेटिव अनुमतियाँ और MCP elicitation
PermissionRequest के लिए, नीति द्वारा निर्णय लिए जाने पर OpenClaw केवल स्पष्ट अनुमति या अस्वीकृति
निर्णय लौटाता है। कोई-निर्णय परिणाम अनुमति नहीं है: Codex
इसे हुक निर्णय का अभाव मानता है और अपने गार्जियन या उपयोगकर्ता
अनुमोदन पथ पर आगे बढ़ जाता है।
Codex app-server अनुमोदन मोड में यह नेटिव हुक डिफ़ॉल्ट रूप से शामिल नहीं होता। यह तब तक
लागू होता है, जब तक permission_request को स्पष्ट रूप से
nativeHookRelay.events में शामिल न किया जाए या कोई संगतता रनटाइम इसे स्थापित न करे।
जब कोई ऑपरेटर Codex नेटिव अनुमति अनुरोध के लिए allow-always
चुनता है, तो OpenClaw उस सटीक प्रदाता/सत्र/टूल इनपुट/cwd
फ़िंगरप्रिंट को सीमित सत्र अवधि के लिए याद रखता है। याद रखा गया निर्णय
जानबूझकर केवल सटीक मिलान पर लागू होता है: बदला हुआ कमांड, आर्ग्युमेंट, टूल पेलोड या
cwd नया अनुमोदन उत्पन्न करता है।
जब Codex _meta.codex_approval_kind को "mcp_tool_call" के रूप में चिह्नित करता है, तो Codex MCP टूल अनुमोदन elicitation
OpenClaw के Plugin अनुमोदन प्रवाह के माध्यम से रूट होते हैं। Codex
request_user_input मूल सत्र के लिए प्रदाता-निरपेक्ष Gateway प्रश्न पंजीकृत करता है।
Control UI Gateway प्रश्न कार्ड प्रस्तुत करता है, और जब चैनल उनका समर्थन करता है,
तो एकल गैर-गुप्त विकल्प टाइप किए गए चैनल बटन का उपयोग करता है। बटन टैप, Control UI उत्तर
और कतार में अगला सादा-पाठ उत्तर—सभी समान Gateway रिकॉर्ड को
हल करते हैं, जिसके बाद OpenClaw app-server उत्तर लौटाता है।
Codex स्वतः-समाधान और प्रयास निरस्तीकरण प्रतीक्षा को सीमित करते हैं और रिकॉर्ड रद्द करते हैं।
गुप्त प्रश्न पूरी तरह चेतावनी-युक्त पाठ-उत्तर पथ पर रहते हैं। अन्य MCP
elicitation अनुरोध सुरक्षित रूप से विफल होते हैं।
इन प्रॉम्प्ट को ले जाने वाले सामान्य Plugin अनुमोदन प्रवाह के लिए,
Plugin अनुमति अनुरोध देखें।
कतार दिशा-निर्देशन
सक्रिय-रन कतार स्टीयरिंग Codex app-serverturn/steer पर मैप होती है। डिफ़ॉल्ट
messages.queue.mode: "steer" के साथ, OpenClaw कॉन्फ़िगर की गई शांत अवधि के दौरान स्टीयर-मोड चैट
संदेशों को बैच करता है और उन्हें आगमन क्रम में एक turn/steer
अनुरोध के रूप में भेजता है।
Codex समीक्षा और मैन्युअल Compaction टर्न उसी टर्न में स्टीयरिंग को अस्वीकार कर सकते हैं। ऐसी
स्थिति में, OpenClaw प्रॉम्प्ट शुरू करने से पहले सक्रिय रन के समाप्त होने की प्रतीक्षा करता है।
जब संदेशों को स्टीयर करने के बजाय डिफ़ॉल्ट रूप से कतारबद्ध करना हो, तब /queue followup
या /queue collect का उपयोग करें। स्टीयरिंग कतार देखें।
Codex फ़ीडबैक अपलोड
जब नेटिव Codex हार्नेस पर किसी सत्र के लिए/diagnostics [note] स्वीकृत होता है,
तो OpenClaw प्रासंगिक Codex थ्रेड के लिए Codex app-server
feedback/upload को भी कॉल करता है, जिसमें प्रत्येक सूचीबद्ध थ्रेड के लॉग और उपलब्ध होने
पर उत्पन्न किए गए Codex उप-थ्रेड शामिल होते हैं।
अपलोड Codex के सामान्य फ़ीडबैक पथ से होकर OpenAI सर्वरों पर जाता है। यदि उस
app-server में Codex फ़ीडबैक अक्षम है, तो कमांड app-server त्रुटि लौटाता है।
पूर्ण हुए निदान उत्तर में भेजे गए थ्रेड के चैनल, OpenClaw सत्र आईडी, Codex थ्रेड आईडी
और स्थानीय codex resume <thread-id> कमांड सूचीबद्ध होते हैं।
यदि आप स्वीकृति अस्वीकार करते हैं या उसे अनदेखा करते हैं, तो OpenClaw उन Codex आईडी को
प्रिंट नहीं करता और Codex फ़ीडबैक नहीं भेजता। यह अपलोड स्थानीय Gateway निदान निर्यात का
स्थान नहीं लेता। स्वीकृति, गोपनीयता, स्थानीय बंडल और समूह-चैट व्यवहार के लिए
निदान निर्यात देखें।
/codex diagnostics [note] का उपयोग केवल तभी करें, जब आप पूर्ण Gateway निदान
बंडल के बिना वर्तमान में संलग्न थ्रेड के लिए Codex फ़ीडबैक अपलोड चाहते हों।
Compaction और ट्रांसक्रिप्ट मिरर
जब चयनित मॉडल Codex हार्नेस का उपयोग करता है, तो नेटिव थ्रेड Compaction Codex app-server के अधीन होती है। OpenClaw Codex टर्न के लिए प्रीफ़्लाइट Compaction नहीं चलाता, Codex Compaction को कॉन्टेक्स्ट-इंजन Compaction से प्रतिस्थापित नहीं करता, और नेटिव Compaction शुरू न हो पाने पर OpenClaw या सार्वजनिक OpenAI सारांश पर वापस नहीं जाता। OpenClaw चैनल इतिहास, खोज,/new,
/reset, और भविष्य में मॉडल या हार्नेस बदलने के लिए एक ट्रांसक्रिप्ट मिरर रखता है।
स्पष्ट Compaction अनुरोध, जैसे /compact या Plugin द्वारा अनुरोधित मैन्युअल
कॉम्पैक्ट संचालन, thread/compact/start के साथ नेटिव Codex Compaction शुरू करते हैं।
OpenClaw अनुरोध और साझा-क्लाइंट लीज़ को तब तक खुला रखता है, जब तक Codex मेल खाने वाला
contextCompaction पूर्णता आइटम उत्सर्जित नहीं करता, और फिर Compaction टर्न को पूर्ण
बताता है। यदि वह अंतिम टर्न कॉन्फ़िगर किए गए Compaction टाइमआउट से अधिक समय लेता है,
तो OpenClaw नेटिव टर्न इंटरप्ट का अनुरोध करता है। लीज़ और प्रति-थ्रेड Compaction फ़ेंस
तब तक बरकरार रहते हैं, जब तक Codex अंतिम स्थिति की रिपोर्ट नहीं करता या इंटरप्ट RPC की
पुष्टि नहीं करता। यदि Codex इंटरप्ट ग्रेस अवधि के भीतर पुष्टि नहीं करता, तो OpenClaw फ़ेंस
रिलीज़ करने से पहले कनेक्शन को सेवानिवृत्त कर देता है। रिमोट कनेक्शन मेल खाने वाली थ्रेड
बाइंडिंग को भी अलग कर देते हैं, ताकि बाद का कार्य किसी अपुष्ट रिमोट टर्न के साथ ओवरलैप न हो।
सेवानिवृत्त कनेक्शन पर अन्य टर्न विफल हो जाते हैं और नए क्लाइंट पर पुनः प्रयास कर सकते हैं।
क्लाइंट बंद होने, अनुरोध रद्द होने या Compaction टर्न विफल होने पर संचालन विफल लौटता है।
स्वचालित कॉन्टेक्स्ट-दबाव Compaction Codex का कार्य है; OpenClaw केवल मैन्युअल रूप से
अनुरोधित ट्रिगर के लिए नेटिव Compaction शुरू करता है।
जब कोई कॉन्टेक्स्ट इंजन Codex थ्रेड-बूटस्ट्रैप प्रोजेक्शन का अनुरोध करता है, तो OpenClaw
टूल-कॉल के नाम और आईडी, इनपुट आकार, तथा संशोधित टूल-परिणाम सामग्री को नए Codex थ्रेड
में प्रोजेक्ट करता है। वह उस प्रोजेक्शन में टूल-कॉल आर्ग्युमेंट के कच्चे मान कॉपी नहीं करता।
मिरर में उपयोगकर्ता प्रॉम्प्ट, सहायक का अंतिम टेक्स्ट और app-server द्वारा उत्सर्जित किए जाने
पर हल्के Codex रीजनिंग या योजना रिकॉर्ड शामिल होते हैं। OpenClaw नेटिव Compaction के
आरंभ और अंतिम स्थिति को रिकॉर्ड करता है, लेकिन वह मानव-पठनीय Compaction सारांश या
Compaction के बाद Codex द्वारा रखी गई प्रविष्टियों की ऑडिट-योग्य सूची उपलब्ध नहीं कराता।
चूँकि Codex कैनोनिकल नेटिव थ्रेड का स्वामी है, इसलिए tool_result_persist
Codex-नेटिव टूल परिणाम रिकॉर्ड को दोबारा नहीं लिखता। यह केवल तब लागू होता है, जब OpenClaw
किसी OpenClaw-स्वामित्व वाले सत्र ट्रांसक्रिप्ट का टूल परिणाम लिखता है।
मीडिया और डिलीवरी
OpenClaw मीडिया डिलीवरी और मीडिया प्रदाता चयन का स्वामी बना रहता है। छवि, वीडियो, संगीत, PDF, TTS और मीडिया समझ के लिएagents.defaults.mediaModels.image,
agents.defaults.mediaModels.video, pdfModel, और tts जैसी
मेल खाती प्रदाता/मॉडल सेटिंग्स का उपयोग होता है।
टेक्स्ट, छवियाँ, वीडियो, संगीत, TTS, स्वीकृतियाँ और मैसेजिंग-टूल आउटपुट सामान्य
OpenClaw डिलीवरी पथ से ही जाते रहते हैं; मीडिया जनरेशन के लिए लेगेसी रनटाइम आवश्यक नहीं
है। जब Codex किसी savedPath के साथ नेटिव छवि-जनरेशन आइटम उत्सर्जित करता है,
तो OpenClaw उसी फ़ाइल को सामान्य उत्तर-मीडिया पथ से अग्रेषित करता है, भले ही Codex टर्न
में कोई सहायक टेक्स्ट न हो।