एंट्री पॉइंट्स
- Gateway RPC:
agentऔरagent.wait. - CLI:
agentcommand.
यह कैसे काम करता है (high-level)
agentRPC params validate करता है, session resolve करता है (sessionKey/sessionId), session metadata persist करता है, और तुरंत{ runId, acceptedAt }लौटाता है।agentCommandagent चलाता है:- model + thinking/verbose/trace defaults resolve करता है
- skills snapshot load करता है
runEmbeddedAgent(OpenClaw agent runtime) call करता है- अगर embedded loop lifecycle end/error emit नहीं करता, तो lifecycle end/error emit करता है
runEmbeddedAgent:- per-session + global queues के जरिए runs serialize करता है
- model + auth profile resolve करता है और OpenClaw session बनाता है
- runtime events subscribe करता है और assistant/tool deltas stream करता है
- timeout enforce करता है -> सीमा पार होने पर run abort करता है
- Codex app-server turns के लिए, terminal event से पहले app-server progress produce करना बंद करने वाले accepted turn को abort करता है
- payloads + usage metadata लौटाता है
subscribeEmbeddedAgentSessionagent runtime events को OpenClawagentstream से bridge करता है:- tool events =>
stream: "tool" - assistant deltas =>
stream: "assistant" - lifecycle events =>
stream: "lifecycle"(phase: "start" | "end" | "error")
- tool events =>
agent.waitwaitForAgentRunका उपयोग करता है:runIdके लिए lifecycle end/error का इंतजार करता है{ status: ok|error|timeout, startedAt, endedAt, error? }लौटाता है
Queueing + concurrency
- Runs प्रति session key (session lane) serialize होते हैं और optional रूप से global lane से गुजरते हैं।
- यह tool/session races को रोकता है और session history को consistent रखता है।
- Messaging channels queue modes (steer/followup/collect/interrupt) चुन सकते हैं जो इस lane system को feed करते हैं। देखें Command Queue.
- Transcript writes भी session file पर session write lock से protected होते हैं। Lock
process-aware और file-based है, इसलिए यह उन writers को पकड़ता है जो in-process queue को bypass करते हैं या
दूसरे process से आते हैं। Session transcript writers session busy report करने से पहले
session.writeLock.acquireTimeoutMsतक wait करते हैं; default60000ms है। - Session write locks default रूप से non-reentrant होते हैं। यदि कोई helper एक logical writer को preserve करते हुए
जानबूझकर same lock की acquisition nest करता है, तो उसे स्पष्ट रूप से
allowReentrant: trueके साथ opt in करना होगा।
Session + workspace preparation
- Workspace resolve और create किया जाता है; sandboxed runs sandbox workspace root पर redirect हो सकते हैं।
- Skills load किए जाते हैं (या snapshot से reused) और env तथा prompt में inject किए जाते हैं।
- Bootstrap/context files resolve किए जाते हैं और system prompt report में inject किए जाते हैं।
- Session write lock acquire किया जाता है; streaming से पहले
SessionManageropen और prepare किया जाता है। किसी भी बाद के transcript rewrite, compaction, या truncation path को transcript file open या mutate करने से पहले वही lock लेना होगा।
Prompt assembly + system prompt
- System prompt OpenClaw के base prompt, skills prompt, bootstrap context, और per-run overrides से बनाया जाता है।
- Model-specific limits और compaction reserve tokens enforce किए जाते हैं।
- Model क्या देखता है, इसके लिए System prompt देखें।
Hook points (जहां आप intercept कर सकते हैं)
OpenClaw में दो hook systems हैं:- Internal hooks (Gateway hooks): commands और lifecycle events के लिए event-driven scripts.
- Plugin hooks: agent/tool lifecycle और gateway pipeline के अंदर extension points.
Internal hooks (Gateway hooks)
agent:bootstrap: system prompt finalize होने से पहले bootstrap files बनाते समय चलता है। Bootstrap context files add/remove करने के लिए इसका उपयोग करें।- Command hooks:
/new,/reset,/stop, और अन्य command events (Hooks doc देखें)।
Plugin hooks (agent + gateway lifecycle)
ये agent loop या gateway pipeline के अंदर चलते हैं:before_model_resolve: model resolution से पहले provider/model को deterministically override करने के लिए pre-session (कोईmessagesनहीं) चलता है।before_prompt_build: prompt submission से पहलेprependContext,systemPrompt,prependSystemContext, याappendSystemContextinject करने के लिए session load के बाद (messagesके साथ) चलता है। Per-turn dynamic text के लिएprependContextऔर stable guidance के लिए system-context fields का उपयोग करें, जिन्हें system prompt space में रहना चाहिए।before_agent_start: legacy compatibility hook जो किसी भी phase में चल सकता है; ऊपर दिए explicit hooks को prefer करें।before_agent_reply: inline actions के बाद और LLM call से पहले चलता है, जिससे कोई Plugin turn claim कर सकता है और synthetic reply लौटा सकता है या turn को पूरी तरह silence कर सकता है।agent_end: completion के बाद final message list और run metadata inspect करें।before_compaction/after_compaction: compaction cycles observe या annotate करें।before_tool_call/after_tool_call: tool params/results intercept करें।before_install: operator install policy चलने के बाद staged skill या Plugin install material inspect करें, जब Plugin hooks current OpenClaw process में loaded हों।tool_result_persist: tool results को OpenClaw-owned session transcript में लिखे जाने से पहले synchronously transform करें।message_received/message_sending/message_sent: inbound + outbound message hooks.session_start/session_end: session lifecycle boundaries.gateway_start/gateway_stop: gateway lifecycle events.
before_tool_call:{ block: true }terminal है और lower-priority handlers को रोकता है।before_tool_call:{ block: false }no-op है और prior block clear नहीं करता।before_install:{ block: true }terminal है और lower-priority handlers को रोकता है।before_install:{ block: false }no-op है और prior block clear नहीं करता।- Operator-owned install allow/block decisions के लिए
before_installनहीं,security.installPolicyउपयोग करें, जिन्हें CLI install और update paths cover करने चाहिए। message_sending:{ cancel: true }terminal है और lower-priority handlers को रोकता है।message_sending:{ cancel: false }no-op है और prior cancel clear नहीं करता।
Streaming + partial replies
- Assistant deltas agent runtime से stream किए जाते हैं और
assistantevents के रूप में emit होते हैं। - Block streaming partial replies को
text_endयाmessage_endपर emit कर सकती है। - Reasoning streaming अलग stream के रूप में या block replies के रूप में emit की जा सकती है।
- Chunking और block reply behavior के लिए Streaming देखें।
Tool execution + messaging tools
- Tool start/update/end events
toolstream पर emit होते हैं। - Tool results logging/emitting से पहले size और image payloads के लिए sanitized होते हैं।
- Messaging tool sends duplicate assistant confirmations suppress करने के लिए tracked होते हैं।
Reply shaping + suppression
- Final payloads इनसे assemble होते हैं:
- assistant text (और optional reasoning)
- inline tool summaries (जब verbose + allowed हो)
- model error होने पर assistant error text
- Exact silent token
NO_REPLY/no_replyoutgoing payloads से filtered होता है। - Messaging tool duplicates final payload list से remove किए जाते हैं।
- यदि कोई renderable payloads नहीं बचते और tool errored होता है, तो fallback tool error reply emit होता है (जब तक messaging tool पहले ही user-visible reply send न कर चुका हो)।
Compaction + retries
- Auto-compaction
compactionstream events emit करता है और retry trigger कर सकता है। - Retry पर, duplicate output से बचने के लिए in-memory buffers और tool summaries reset किए जाते हैं।
- Compaction pipeline के लिए Compaction देखें।
Event streams (आज)
lifecycle:subscribeEmbeddedAgentSessionद्वारा emit होता है (और fallback के रूप मेंagentCommandद्वारा)assistant: agent runtime से streamed deltastool: agent runtime से streamed tool events
Chat channel handling
- Assistant deltas chat
deltamessages में buffered होते हैं। - lifecycle end/error पर chat
finalemit होता है।
Timeouts
agent.waitdefault: 30s (सिर्फ wait).timeoutMsparam override करता है।- Agent runtime:
agents.defaults.timeoutSecondsdefault 172800s (48 hours);runEmbeddedAgentabort timer में enforced. - Cron runtime: isolated agent-turn
timeoutSecondscron के स्वामित्व में है। Scheduler execution शुरू होने पर वह timer start करता है, configured deadline पर underlying run abort करता है, फिर timeout record करने से पहले bounded cleanup चलाता है ताकि stale child session lane को stuck न रख सके। - Session liveness diagnostics: diagnostics enabled होने पर,
diagnostics.stuckSessionWarnMsलंबेprocessingsessions को classify करता है जिनमें कोई observed reply, tool, status, block, या ACP progress नहीं है। Active embedded runs, model calls, और tool callssession.long_runningके रूप में report होते हैं; owned silent model calls भीdiagnostics.stuckSessionAbortMsतकsession.long_runningरहते हैं ताकि slow या non-streaming providers को बहुत जल्दी stalled report न किया जाए। Recent progress के बिना active worksession.stalledके रूप में report होता है; owned model calls abort threshold पर या उसके बादsession.stalledमें switch करते हैं, और ownerless stale model/tool activity को long-running के रूप में hidden नहीं किया जाता।session.stuckrecoverable stale session bookkeeping के लिए reserved है, जिसमें stale ownerless model/tool activity वाले idle queued sessions शामिल हैं। Stale session bookkeeping recovery gates pass होने के तुरंत बाद affected session lane release करता है; stalled embedded runs केवलdiagnostics.stuckSessionAbortMs(default: कम से कम 5 minutes और warning threshold का 3x) के बाद abort-drained होते हैं ताकि queued work merely slow runs को काटे बिना resume कर सके। Recovery structured requested/completed outcomes emit करता है, और diagnostic state को idle केवल तब mark किया जाता है जब वही processing generation अभी भी current हो। Repeatedsession.stuckdiagnostics back off करते हैं जबकि session unchanged रहता है। - Model idle timeout: OpenClaw model request को abort करता है जब idle window से पहले कोई response chunks नहीं आते।
models.providers.<id>.timeoutSecondsslow local/self-hosted providers के लिए इस idle watchdog को extend करता है, लेकिन यह अभी भी किसी loweragents.defaults.timeoutSecondsया run-specific timeout से bounded होता है क्योंकि वे पूरे agent run को control करते हैं। अन्यथा OpenClaw configured होने परagents.defaults.timeoutSecondsउपयोग करता है, default रूप से 120s पर capped. Explicit model या agent timeout के बिना Cron-triggered cloud model runs वही default idle watchdog उपयोग करते हैं; explicit cron run timeout के साथ, cloud model stream stalls 60s पर capped होते हैं ताकि configured model fallbacks outer cron deadline से पहले चल सकें। Cron-triggered local या self-hosted model runs implicit watchdog disable करते हैं जब तक explicit timeout configured न हो, और explicit cron run timeouts local/self-hosted providers के लिए idle window बने रहते हैं, इसलिए slow local providers कोmodels.providers.<id>.timeoutSecondsset करना चाहिए। - Provider HTTP request timeout:
models.providers.<id>.timeoutSecondsउस provider के model HTTP fetches पर apply होता है, जिसमें connect, headers, body, SDK request timeout, total guarded-fetch abort handling, और model stream idle watchdog शामिल हैं। Whole agent runtime timeout बढ़ाने से पहले slow local/self-hosted providers जैसे Ollama के लिए इसका उपयोग करें, और जब model request को longer run करने की जरूरत हो तो agent/runtime timeout कम से कम उतना high रखें।
जहां चीजें जल्दी समाप्त हो सकती हैं
- एजेंट टाइमआउट (abort)
- AbortSignal (cancel)
- Gateway डिस्कनेक्ट या RPC टाइमआउट
agent.waitटाइमआउट (केवल प्रतीक्षा, एजेंट को रोकता नहीं)
संबंधित
- टूल्स — उपलब्ध एजेंट टूल्स
- Hooks — एजेंट lifecycle इवेंट्स से ट्रिगर होने वाली event-driven स्क्रिप्ट्स
- Compaction — लंबी बातचीत का सारांश कैसे बनाया जाता है
- Exec अनुमोदन — shell commands के लिए अनुमोदन गेट्स
- सोच — सोच/रीजनिंग स्तर का कॉन्फ़िगरेशन