Skip to main content

​
openclaw cron

Gateway शेड्यूलर के लिए Cron जॉब प्रबंधित करें।
सभी उपलब्ध कमांड देखने के लिए openclaw cron --help चलाएँ। अवधारणात्मक मार्गदर्शिका के लिए Cron जॉब देखें।
सभी Cron परिवर्तन (add/create, update/edit, remove, run) के लिए operator.admin आवश्यक है। कमांड-पेलोड रन एजेंट के tools.exec टूल कॉल के रूप में नहीं, बल्कि सीधे Gateway प्रक्रिया में निष्पादित होते हैं; मॉडल को दिखाई देने वाले exec टूल अब भी tools.exec.* और exec अनुमोदनों द्वारा नियंत्रित होते हैं।

​
जॉब तुरंत बनाएँ

openclaw cron create, openclaw cron add का उपनाम है। नई जॉब के लिए पहले शेड्यूल और फिर प्रॉम्प्ट रखें:
जब जॉब को पूर्ण पेलोड किसी चैट लक्ष्य तक पहुँचाने के बजाय POST करना हो, तो --webhook <url> का उपयोग करें:
OpenClaw Cron के भीतर बिना कोई पृथक एजेंट/मॉडल रन शुरू किए चलने वाली नियतात्मक शेल-शैली की जॉब के लिए --command का उपयोग करें:
--command <shell>, argv: ["sh", "-lc", <shell>] संग्रहीत करता है। सटीक argv निष्पादन के लिए --command-argv '["node","scripts/report.mjs"]' का उपयोग करें। कमांड जॉब stdout/stderr कैप्चर करती हैं, सामान्य Cron इतिहास दर्ज करती हैं और आउटपुट को पृथक जॉब के समान announce, webhook या none डिलीवरी मोड के माध्यम से रूट करती हैं। केवल NO_REPLY प्रिंट करने वाली कमांड का आउटपुट रोक दिया जाता है।

​
सत्र

--session, main, isolated, current या session:<id> स्वीकार करता है।
  • main एजेंट के मुख्य सत्र से जुड़ता है।
  • isolated प्रत्येक रन के लिए नई ट्रांसक्रिप्ट और सत्र आईडी बनाता है।
  • current निर्माण के समय सक्रिय सत्र से जुड़ता है।
  • session:<id> किसी स्पष्ट स्थायी सत्र कुंजी से जुड़ा रहता है।
पृथक रन परिवेशी वार्तालाप संदर्भ को रीसेट करते हैं। नए रन के लिए चैनल और समूह रूटिंग, भेजने/कतार नीति, उन्नत विशेषाधिकार, मूल स्रोत और ACP रनटाइम बाइंडिंग रीसेट हो जाती हैं। सुरक्षित प्राथमिकताएँ और उपयोगकर्ता द्वारा स्पष्ट रूप से चुने गए मॉडल या प्रमाणीकरण ओवरराइड अलग-अलग रन में जारी रह सकते हैं।

​
डिलीवरी

openclaw cron list और openclaw cron show <job-id> निर्धारित डिलीवरी रूट का पूर्वावलोकन दिखाते हैं। channel: "last" के लिए पूर्वावलोकन दिखाता है कि रूट मुख्य या वर्तमान सत्र से निर्धारित हुआ है, अथवा सुरक्षित रूप से विफल होगा। प्रदाता-उपसर्ग वाले लक्ष्य अनिर्धारित घोषणा चैनलों की अस्पष्टता दूर कर सकते हैं। उदाहरण के लिए, जब delivery.channel छोड़ा गया हो या last हो, तब to: "telegram:123" Telegram चुनता है। केवल लोड किए गए Plugin द्वारा घोषित उपसर्ग ही प्रदाता चयनकर्ता होते हैं। यदि delivery.channel स्पष्ट रूप से दिया गया है, तो उपसर्ग उस चैनल से मेल खाना चाहिए; to: "telegram:123" के साथ channel: "whatsapp" अस्वीकार कर दिया जाता है। imessage: और sms: जैसे सेवा उपसर्ग चैनल के स्वामित्व वाले लक्ष्य सिंटैक्स बने रहते हैं।
पृथक cron add जॉब में डिफ़ॉल्ट रूप से --announce डिलीवरी होती है। आउटपुट को आंतरिक रखने के लिए --no-deliver का उपयोग करें। --deliver, --announce के बहिष्कृत उपनाम के रूप में उपलब्ध है।

​
डिलीवरी का स्वामित्व

पृथक Cron चैट डिलीवरी एजेंट और रनर के बीच साझा होती है:
  • चैट रूट उपलब्ध होने पर एजेंट message टूल का उपयोग करके सीधे भेज सकता है।
  • announce अंतिम उत्तर को फ़ॉलबैक के रूप में केवल तभी पहुँचाता है, जब एजेंट ने निर्धारित लक्ष्य पर सीधे नहीं भेजा हो।
  • webhook पूर्ण पेलोड को किसी URL पर पोस्ट करता है।
  • none रनर की फ़ॉलबैक डिलीवरी अक्षम करता है।
Webhook डिलीवरी सेट करने के लिए cron add|create --webhook <url> या cron edit <job-id> --webhook <url> का उपयोग करें। --webhook को --announce, --no-deliver, --channel, --to, --thread-id या --account जैसे चैट डिलीवरी फ़्लैग के साथ न जोड़ें। cron edit <job-id>, --clear-channel, --clear-to, --clear-thread-id और --clear-account के माध्यम से अलग-अलग डिलीवरी रूटिंग फ़ील्ड हटा सकता है (हर एक को उसके संबंधित सेट फ़्लैग के साथ जोड़ने पर अस्वीकार कर दिया जाता है)। --no-deliver केवल रनर की फ़ॉलबैक डिलीवरी अक्षम करता है, जबकि ये संग्रहीत फ़ील्ड को हटा देते हैं, ताकि जॉब अपने रूट के उस भाग को फिर से डिफ़ॉल्ट मानों से निर्धारित करे। --announce अंतिम उत्तर के लिए रनर की फ़ॉलबैक डिलीवरी है। --no-deliver उस फ़ॉलबैक को अक्षम करता है, लेकिन चैट रूट उपलब्ध होने पर एजेंट का message टूल नहीं हटाता। सक्रिय चैट से बनाए गए रिमाइंडर फ़ॉलबैक घोषणा डिलीवरी के लिए लाइव चैट डिलीवरी लक्ष्य सुरक्षित रखते हैं। आंतरिक सत्र कुंजियाँ लोअरकेस में हो सकती हैं; Matrix रूम आईडी जैसे केस-संवेदी प्रदाता आईडी के लिए उन्हें सत्य स्रोत के रूप में उपयोग न करें।

​
विफलता डिलीवरी

विफलता सूचनाएँ इस क्रम में निर्धारित होती हैं:
  1. जॉब पर delivery.failureDestination।
  2. वैश्विक cron.failureDestination।
  3. जॉब का प्राथमिक घोषणा लक्ष्य (जब ऊपर दिए गए दोनों में से कोई भी ठोस गंतव्य निर्धारित नहीं करता)।
मुख्य-सत्र जॉब केवल तभी delivery.failureDestination का उपयोग कर सकती हैं, जब प्राथमिक डिलीवरी मोड webhook हो। पृथक जॉब इसे सभी मोड में स्वीकार करती हैं।
पृथक Cron रन, रन-स्तरीय एजेंट विफलताओं को जॉब त्रुटि मानते हैं, भले ही कोई उत्तर पेलोड उत्पन्न न हो; इसलिए मॉडल/प्रदाता विफलताएँ फिर भी त्रुटि गणना बढ़ाती हैं और विफलता सूचनाएँ ट्रिगर करती हैं। कमांड Cron जॉब पृथक एजेंट टर्न शुरू नहीं करती हैं। शून्य एग्ज़िट कोड ok दर्ज करता है; गैर-शून्य एग्ज़िट, सिग्नल, टाइमआउट या बिना-आउटपुट टाइमआउट error दर्ज करता है और समान विफलता सूचना पथ ट्रिगर कर सकता है। यदि कोई पृथक रन पहले मॉडल अनुरोध से पहले टाइमआउट हो जाता है, तो openclaw cron show और openclaw cron runs में setup timed out before runner start जैसी चरण-विशिष्ट त्रुटि या अंतिम ज्ञात स्टार्टअप चरण बताने वाला रुकावट संदेश शामिल होता है (उदाहरण के लिए context-engine)। CLI-आधारित प्रदाताओं के लिए प्री-मॉडल वॉचडॉग बाहरी CLI टर्न शुरू होने तक सक्रिय रहता है, इसलिए सत्र खोज, हुक, प्रमाणीकरण, प्रॉम्प्ट और CLI सेटअप में रुकावटें प्री-मॉडल Cron विफलताओं के रूप में रिपोर्ट होती हैं।

​
शेड्यूलिंग

​
एकबारगी जॉब

--at <datetime> एकबारगी रन शेड्यूल करता है। ऑफ़सेट-रहित दिनांक-समय को UTC माना जाता है, जब तक कि आप --tz <iana> भी न दें, जो दिए गए समय क्षेत्र में दीवार-घड़ी के समय की व्याख्या करता है।
एकबारगी जॉब सफल होने के बाद डिफ़ॉल्ट रूप से हट जाती हैं। उन्हें सुरक्षित रखने के लिए --keep-after-run का उपयोग करें।

​
आवर्ती जॉब

लगातार त्रुटियों के बाद आवर्ती जॉब घातांकीय पुनः प्रयास बैकऑफ़ का उपयोग करती हैं: 30s, 1m, 5m, 15m, 60m। अगले सफल रन के बाद शेड्यूल सामान्य हो जाता है। छोड़े गए रन को निष्पादन त्रुटियों से अलग ट्रैक किया जाता है। वे पुनः प्रयास बैकऑफ़ को प्रभावित नहीं करते, लेकिन openclaw cron edit <job-id> --failure-alert-include-skipped के माध्यम से विफलता अलर्ट में बार-बार छोड़े गए रन की सूचनाएँ शामिल की जा सकती हैं। स्थानीय रूप से कॉन्फ़िगर किए गए मॉडल प्रदाता (लूपबैक, निजी नेटवर्क या .local पर आधार URL) को लक्षित करने वाली पृथक जॉब के लिए Cron एजेंट टर्न शुरू करने से पहले हल्की प्रदाता पूर्व-जाँच चलाता है: api: "ollama" प्रदाताओं की जाँच /api/tags पर होती है; अन्य स्थानीय OpenAI-संगत प्रदाताओं (api: "openai-completions", जैसे vLLM, SGLang, LM Studio) की जाँच /models पर होती है। यदि एंडपॉइंट तक नहीं पहुँचा जा सकता, तो रन को skipped के रूप में दर्ज करके बाद के शेड्यूल पर पुनः प्रयास किया जाता है; पहुँच-योग्यता परिणाम प्रत्येक एंडपॉइंट के लिए 5 मिनट तक कैश किया जाता है, ताकि एक ही स्थानीय सर्वर का उपयोग करने वाली कई जॉब बार-बार जाँच करके उस पर अनावश्यक भार न डालें। Cron जॉब, लंबित रनटाइम स्थिति और रन इतिहास साझा SQLite स्थिति डेटाबेस में रहते हैं। पुराने jobs.json, <name>-state.json और runs/*.jsonl फ़ाइलों को एक बार आयात करके .migrated प्रत्यय के साथ पुनः नामित किया जाता है। आयात के बाद JSON फ़ाइलें संपादित करने के बजाय openclaw cron add|edit|remove से शेड्यूल संपादित करें।

​
मैन्युअल रन

openclaw cron run <job-id> डिफ़ॉल्ट रूप से बलपूर्वक रन करता है और मैन्युअल रन कतारबद्ध होते ही वापस लौटता है। सफल प्रतिक्रियाओं में { ok: true, enqueued: true, runId } शामिल होता है। बाद के परिणाम की जाँच करने के लिए लौटाए गए runId का उपयोग करें:
जब किसी स्क्रिप्ट को तब तक अवरुद्ध रहना हो, जब तक वही कतारबद्ध रन अंतिम स्थिति दर्ज न कर दे, तो --wait जोड़ें:
--wait के साथ CLI पहले फिर भी cron.run कॉल करता है, फिर लौटाए गए runId के लिए cron.runs को पोल करता है। कमांड केवल तभी 0 के साथ बाहर निकलती है, जब रन ok स्थिति में समाप्त होता है। रन के error या skipped के साथ समाप्त होने, Gateway प्रतिक्रिया में runId शामिल न होने या --wait-timeout की समय-सीमा समाप्त होने पर यह गैर-शून्य कोड के साथ बाहर निकलती है (डिफ़ॉल्ट 10m, डिफ़ॉल्ट रूप से प्रत्येक 2s पर पोलिंग)। --poll-interval शून्य से अधिक होना चाहिए।
जब मैन्युअल कमांड को केवल जॉब के वर्तमान में नियत होने पर चलाना हो, तब --due का उपयोग करें। यदि --due --wait कोई रन कतारबद्ध नहीं करता, तो कमांड पोलिंग करने के बजाय सामान्य रन-न-होने वाली प्रतिक्रिया लौटाती है।

​
मॉडल

cron add|edit --model <ref> जॉब के लिए अनुमत मॉडल चुनता है। cron add|edit --fallbacks <list> प्रत्येक जॉब के लिए फ़ॉलबैक मॉडल सेट करता है, उदाहरण के लिए --fallbacks openrouter/gpt-4.1-mini,openai/gpt-5; बिना फ़ॉलबैक वाला सख्त रन चलाने के लिए --fallbacks "" दें। cron edit <job-id> --clear-fallbacks प्रत्येक जॉब का फ़ॉलबैक ओवरराइड हटाता है। cron edit <job-id> --clear-model प्रत्येक जॉब का मॉडल ओवरराइड हटा देता है, ताकि जॉब सामान्य Cron मॉडल-चयन प्राथमिकता का पालन करे (संग्रहीत Cron-सत्र ओवरराइड मौजूद होने पर वह, अन्यथा एजेंट/डिफ़ॉल्ट मॉडल); इसे --model के साथ नहीं जोड़ा जा सकता। cron add|edit --thinking <level> प्रत्येक जॉब के लिए विचार ओवरराइड सेट करता है; cron edit <job-id> --clear-thinking इसे हटा देता है, ताकि जॉब सामान्य Cron विचार प्राथमिकता का पालन करे, और इसे --thinking के साथ नहीं जोड़ा जा सकता।
यदि मॉडल अनुमत नहीं है या निर्धारित नहीं किया जा सकता, तो Cron जॉब के एजेंट या डिफ़ॉल्ट मॉडल चयन पर फ़ॉलबैक करने के बजाय स्पष्ट सत्यापन त्रुटि के साथ रन को विफल कर देता है।
Cron --model एक जॉब प्राथमिक मॉडल है, चैट-सत्र /model ओवरराइड नहीं। इसका अर्थ है:
  • चुना गया जॉब मॉडल विफल होने पर भी कॉन्फ़िगर किए गए मॉडल फ़ॉलबैक लागू होते हैं।
  • मौजूद होने पर प्रत्येक जॉब का पेलोड fallbacks कॉन्फ़िगर की गई फ़ॉलबैक सूची को प्रतिस्थापित करता है।
  • प्रत्येक जॉब की खाली फ़ॉलबैक सूची (जॉब पेलोड/API में --fallbacks "" या fallbacks: []) Cron रन को सख्त बनाती है।
  • जब किसी जॉब में --model हो, लेकिन कोई फ़ॉलबैक सूची कॉन्फ़िगर न हो, तो OpenClaw स्पष्ट खाली फ़ॉलबैक ओवरराइड पास करता है, ताकि एजेंट का प्राथमिक मॉडल छिपे हुए पुनः प्रयास लक्ष्य के रूप में न जोड़ा जाए।
  • स्थानीय-प्रदाता पूर्व-जाँच किसी Cron रन को skipped चिह्नित करने से पहले कॉन्फ़िगर किए गए फ़ॉलबैक की जाँच करती है।
openclaw doctor उन जॉब की रिपोर्ट करता है जिनमें payload.model पहले से सेट है, जिसमें प्रदाता नेमस्पेस की संख्या और agents.defaults.model से असंगतियाँ शामिल हैं। लाइव चैट और शेड्यूल की गई जॉब के बीच प्रमाणीकरण, प्रदाता या बिलिंग व्यवहार अलग दिखने पर इस जाँच का उपयोग करें।

​
पृथक Cron मॉडल प्राथमिकता

पृथक Cron सक्रिय मॉडल को इस क्रम में निर्धारित करता है:
  1. Gmail-हुक ओवरराइड।
  2. प्रत्येक जॉब का --model।
  3. संग्रहीत Cron-सत्र मॉडल ओवरराइड (जब उपयोगकर्ता ने कोई मॉडल चुना हो)।
  4. एजेंट या डिफ़ॉल्ट मॉडल चयन।

​
तेज़ मोड

अलग Cron फास्ट मोड समाधान किए गए लाइव मॉडल चयन का अनुसरण करता है। मॉडल कॉन्फ़िगरेशन params.fastMode डिफ़ॉल्ट रूप से लागू होता है, लेकिन संग्रहीत सत्र का fastMode ओवरराइड फिर भी कॉन्फ़िगरेशन पर प्राथमिकता पाता है। जब समाधान किया गया मोड auto होता है, तो कटऑफ़ चयनित मॉडल के params.fastAutoOnSeconds मान का उपयोग करता है, जिसका डिफ़ॉल्ट 60 सेकंड है।

​
लाइव मॉडल स्विच के पुनः प्रयास

यदि कोई अलग रन LiveSessionModelSwitchError फेंकता है, तो Cron पुनः प्रयास करने से पहले सक्रिय रन के लिए स्विच किए गए प्रदाता और मॉडल (और मौजूद होने पर स्विच किए गए प्रमाणीकरण प्रोफ़ाइल ओवरराइड) को बनाए रखता है। बाहरी पुनः प्रयास लूप प्रारंभिक प्रयास के बाद दो स्विच पुनः प्रयासों तक सीमित रहता है, फिर अनंत लूप में चलने के बजाय निरस्त हो जाता है।

​
रन आउटपुट और अस्वीकृतियाँ

​
पुराने अभिस्वीकृति संदेशों का दमन

अलग Cron टर्न पुराने, केवल अभिस्वीकृति वाले उत्तरों को दबाते हैं। यदि पहला परिणाम केवल अंतरिम स्थिति अपडेट है और अंतिम उत्तर के लिए कोई वंशज उप-एजेंट रन उत्तरदायी नहीं है, तो Cron डिलीवरी से पहले वास्तविक परिणाम के लिए एक बार फिर प्रॉम्प्ट करता है।

​
मौन टोकन का दमन

यदि कोई अलग Cron रन केवल मौन टोकन (NO_REPLY या no_reply) लौटाता है, तो Cron प्रत्यक्ष आउटबाउंड डिलीवरी और फ़ॉलबैक कतारबद्ध सारांश पथ दोनों को दबा देता है, इसलिए चैट में कुछ भी वापस पोस्ट नहीं होता।

​
संरचित अस्वीकृतियाँ

अलग Cron रन एम्बेड किए गए रन से संरचित निष्पादन-अस्वीकृति मेटाडेटा (SYSTEM_RUN_DENIED या INVALID_REQUEST कोड वाली घातक exec-tool त्रुटियाँ) को आधिकारिक अस्वीकृति संकेत के रूप में उपयोग करते हैं। वे उन node-host UNAVAILABLE रैपर का भी सम्मान करते हैं, जो इनमें से किसी एक कोड वाली नेस्टेड संरचित त्रुटि को समाहित करते हैं। Cron अंतिम आउटपुट के गद्य या अनुमोदन जैसे दिखने वाले अस्वीकार वाक्यांशों को अस्वीकृति के रूप में वर्गीकृत नहीं करता, जब तक कि एम्बेड किया गया रन संरचित अस्वीकृति मेटाडेटा भी प्रदान न करे, इसलिए सामान्य सहायक पाठ को अवरुद्ध कमांड नहीं माना जाता। cron list और रन इतिहास अवरुद्ध कमांड को ok के रूप में रिपोर्ट करने के बजाय अस्वीकृति का कारण दिखाते हैं।

​
अवधारण

अवधारण व्यवहार:
  • cron.sessionRetention (डिफ़ॉल्ट 24h, या अक्षम करने के लिए false) पूर्ण हो चुके अलग रन सत्रों को छाँटता है।
  • रन इतिहास प्रत्येक Cron जॉब के लिए नवीनतम 2000 टर्मिनल पंक्तियाँ रखता है। खोई हुई पंक्तियाँ मानक 24-घंटे की खोए हुए कार्य की सफ़ाई अवधि बनाए रखती हैं।

​
पुराने जॉब माइग्रेट करना

यदि आपके पास मौजूदा डिलीवरी और स्टोर प्रारूप से पहले के Cron जॉब हैं, तो openclaw doctor --fix चलाएँ। Doctor पुराने Cron फ़ील्ड (jobId, schedule.cron, पुराने threadId सहित शीर्ष-स्तरीय डिलीवरी फ़ील्ड, पेलोड provider डिलीवरी उपनाम) को सामान्यीकृत करता है और उस कॉन्फ़िगरेशन कुंजी को हटाने से पहले notify: true Webhook फ़ॉलबैक जॉब को सेवानिवृत्त कच्चे cron.webhook मान से स्पष्ट Webhook डिलीवरी में माइग्रेट करता है। जो जॉब पहले से चैट में घोषणा करते हैं, वे उस डिलीवरी को बनाए रखते हैं और उन्हें पूर्णता Webhook गंतव्य मिलता है। पुराने Webhook के बिना, माइग्रेशन लक्ष्य न रखने वाले जॉब से निष्क्रिय शीर्ष-स्तरीय notify मार्कर हटा दिया जाता है (मौजूदा डिलीवरी अपरिवर्तित रहती है), इसलिए doctor --fix अब उनके बारे में बार-बार चेतावनी नहीं देता।

​
सामान्य संपादन

संदेश बदले बिना डिलीवरी सेटिंग अपडेट करें:
किसी अलग जॉब के लिए डिलीवरी अक्षम करें:
किसी अलग जॉब के लिए हल्का बूटस्ट्रैप संदर्भ सक्षम करें:
किसी विशिष्ट चैनल पर घोषणा करें:
Telegram फ़ोरम विषय पर घोषणा करें:
हल्के बूटस्ट्रैप संदर्भ वाला अलग जॉब बनाएँ:
--light-context केवल अलग एजेंट-टर्न जॉब पर लागू होता है। Cron रन के लिए, हल्का मोड पूर्ण वर्कस्पेस बूटस्ट्रैप सेट इंजेक्ट करने के बजाय बूटस्ट्रैप संदर्भ को खाली रखता है। सटीक argv, cwd, env, stdin और आउटपुट सीमाओं वाला कमांड जॉब बनाएँ:

​
सामान्य व्यवस्थापक कमांड

मैन्युअल रन और निरीक्षण:
openclaw cron list डिफ़ॉल्ट रूप से सक्षम जॉब दिखाता है। अक्षम जॉब शामिल करने के लिए --all पास करें, या केवल वे जॉब दिखाने के लिए --agent <id> पास करें जिनकी प्रभावी सामान्यीकृत एजेंट आईडी मेल खाती है; संग्रहीत एजेंट आईडी के बिना जॉब को कॉन्फ़िगर किया गया डिफ़ॉल्ट एजेंट माना जाता है। openclaw cron get <job-id> संग्रहीत जॉब JSON सीधे लौटाता है। जब आपको डिलीवरी-रूट पूर्वावलोकन वाला मानव-पठनीय दृश्य चाहिए, तब cron show <job-id> का उपयोग करें। cron list --json और cron show <job-id> --json प्रत्येक जॉब में शीर्ष-स्तरीय status फ़ील्ड शामिल करते हैं, जिसकी गणना enabled, state.runningAtMs और state.lastRunStatus से की जाती है। मान: disabled, running, ok, error, skipped, या idle। JSON स्थिति प्रामाणिक और बिना सजावट के रहती है, ताकि बाहरी टूलिंग जॉब की स्थिति को दोबारा व्युत्पन्न किए बिना पढ़ सके; मानव-पठनीय आउटपुट दोहराई गई error स्थितियों को विफलता गणना से सजा सकता है। cron runs प्रविष्टियों में इच्छित Cron लक्ष्य, समाधान किया गया लक्ष्य, message-tool प्रेषण, फ़ॉलबैक उपयोग और डिलीवर की गई स्थिति सहित डिलीवरी निदान शामिल होते हैं। प्रति-जॉब निजी स्क्रैच (Heartbeat जाँच-सूचियाँ और समान निगरानी संदर्भ):
स्क्रैच साझा स्थिति डेटाबेस में संग्रहीत होता है, 256 KiB तक सीमित होता है और cron list/cron get/cron runs आउटपुट में कभी शामिल नहीं किया जाता। लेखन को कमांड प्रारंभ होने पर पढ़े गए संशोधन के विरुद्ध तुलना-और-स्वैप से सुरक्षित किया जाता है; इसके बजाय कोई स्पष्ट संशोधन पिन करने के लिए --expected-revision <n> पास करें। Heartbeat मॉनिटर स्क्रैच का उपयोग कैसे करते हैं, इसके लिए Heartbeat देखें। एजेंट और सत्र को पुनः लक्षित करना:
एजेंट-टर्न जॉब में --agent छोड़े जाने पर openclaw cron add चेतावनी देता है और डिफ़ॉल्ट एजेंट (main) का उपयोग करता है। किसी विशिष्ट एजेंट को पिन करने के लिए निर्माण के समय --agent <id> पास करें। डिलीवरी समायोजन:

​
संबंधित