Start here

सामान्य समस्या निवारण

यदि आपके पास केवल 2 मिनट हैं, तो इस पेज को ट्रायेज के मुख्य प्रवेश-द्वार के रूप में उपयोग करें।

पहले 60 सेकंड

इस सटीक क्रम को इसी क्रम में चलाएँ:

bash

openclaw statusopenclaw status --allopenclaw gateway probeopenclaw gateway statusopenclaw doctoropenclaw channels status --probeopenclaw logs --follow

एक पंक्ति में अच्छा आउटपुट:

openclaw status → कॉन्फ़िगर किए गए चैनल दिखाता है और कोई स्पष्ट auth त्रुटि नहीं होती।
openclaw status --all → पूरी रिपोर्ट मौजूद और साझा करने योग्य होती है।
openclaw gateway probe → अपेक्षित gateway लक्ष्य पहुँचा जा सकता है (Reachable: yes)। Capability: ... बताता है कि probe कौन-सा auth स्तर सिद्ध कर सका, और Read probe: limited - missing scope: operator.read घटे हुए diagnostics हैं, connect विफलता नहीं।
openclaw gateway status → Runtime: running, Connectivity probe: ok, और एक विश्वसनीय Capability: ... पंक्ति। यदि आपको read-scope RPC प्रमाण भी चाहिए, तो --require-rpc उपयोग करें।
openclaw doctor → कोई अवरोधक config/service त्रुटियाँ नहीं।
openclaw channels status --probe → पहुँच योग्य gateway लाइव per-account transport स्थिति और probe/audit परिणाम जैसे works या audit ok लौटाता है; यदि gateway पहुँचा नहीं जा सकता, तो command config-only सारांशों पर fallback करता है।
openclaw logs --follow → स्थिर गतिविधि, कोई दोहराती fatal त्रुटियाँ नहीं।

Assistant सीमित लगता है या tools गायब हैं

यदि assistant फ़ाइलों का निरीक्षण नहीं कर सकता, commands नहीं चला सकता, browser automation का उपयोग नहीं कर सकता, या अपेक्षित tools नहीं देख सकता, तो पहले effective tool profile जाँचें:

bash

openclaw statusopenclaw status --allopenclaw doctor

सामान्य कारण:

tools.profile: "messaging" chat-only agents के लिए जानबूझकर सीमित है।
tools.profile: "coding" repository, file, shell, और runtime workflows के लिए सामान्य profile है।
tools.profile: "full" सबसे व्यापक tool set उजागर करता है और इसे केवल trusted operator-controlled agents तक सीमित रखना चाहिए।
Per-agent agents.list[].tools overrides किसी एक agent के लिए root profile को सीमित या विस्तारित कर सकते हैं।

root या per-agent tool profile बदलें, फिर Gateway को restart या reload करें और openclaw status --all फिर चलाएँ। profile model और allow/deny overrides के लिए Tools देखें।

Anthropic long context 429

यदि आपको यह दिखे: HTTP 429: rate_limit_error: Extra usage is required for long context requests, तो /gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context पर जाएँ।

स्थानीय OpenAI-compatible backend सीधे काम करता है लेकिन OpenClaw में विफल होता है

यदि आपका स्थानीय या self-hosted /v1 backend छोटे direct /v1/chat/completions probes का उत्तर देता है लेकिन openclaw infer model run या सामान्य agent turns पर विफल होता है:

यदि त्रुटि में messages[].content के string की अपेक्षा करने का उल्लेख है, तो models.providers.<provider>.models[].compat.requiresStringContent: true सेट करें।
यदि backend अभी भी केवल OpenClaw agent turns पर विफल होता है, तो models.providers.<provider>.models[].compat.supportsTools: false सेट करें और फिर प्रयास करें।
यदि बहुत छोटे direct calls अभी भी काम करते हैं लेकिन बड़े OpenClaw prompts backend को crash कर देते हैं, तो शेष समस्या को upstream model/server सीमा मानें और deep runbook में जारी रखें: /gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail

Plugin install missing openclaw extensions के साथ विफल होता है

यदि install package.json missing openclaw.extensions के साथ विफल होता है, तो plugin package एक पुराने shape का उपयोग कर रहा है जिसे OpenClaw अब स्वीकार नहीं करता।

plugin package में ठीक करें:

package.json में openclaw.extensions जोड़ें।
entries को built runtime files पर point करें (आमतौर पर ./dist/index.js)।
plugin को फिर publish करें और openclaw plugins install <package> फिर चलाएँ।

उदाहरण:

json

{  "name": "@openclaw/my-plugin",  "version": "1.2.3",  "openclaw": {    "extensions": ["./dist/index.js"]  }}

संदर्भ: Plugin architecture

Install policy plugin installs या updates को block करती है

यदि update पूरा हो जाता है लेकिन plugins पुराने, disabled हैं, या ऐसे messages दिखाते हैं blocked by install policy, install policy failed closed, या Disabled "<plugin>" after plugin update failure, तो security.installPolicy जाँचें।

Install policy plugin installs और updates पर चलती है। OpenClaw-owned plugin versions सामान्यतः OpenClaw release के साथ आगे बढ़ते हैं, इसलिए OpenClaw update को post-update sync के दौरान matching @openclaw/* plugin updates की भी आवश्यकता हो सकती है।

इन व्यापक policy shapes से बचें, जब तक आप matching upgrade rule भी maintain नहीं करते:

OpenClaw-owned plugins को किसी एक सटीक पुराने version पर freeze करना, जैसे केवल @openclaw/*@2026.5.3 allow करना।
केवल source kind के आधार पर block करना, जैसे हर npm, network, या request.mode: "update" plugin request।
policy command को optional मानना। जब security.installPolicy enabled होता है, तो missing, slow, unreadable, या permission-blocked policy executable fail closed करता है।
policy request के openclawVersion और plugin candidate metadata पर विचार किए बिना plugin versions approve करना।

सुरक्षित policy rules trusted OpenClaw-owned plugin updates को allow करते हैं जब candidate मौजूदा OpenClaw host के साथ compatible हो, बजाय किसी single release को हमेशा के लिए pin करने के। यदि आप default रूप से npm को block करते हैं, तो उपयोग किए जाने वाले trusted @openclaw/* plugin packages या plugin ids के लिए narrow exception बनाएँ। यदि आप install और update requests में अंतर करते हैं, तो वही trust rule request.mode: "update" पर लागू करें।

Recovery:

bash

openclaw doctor --deepopenclaw plugins update --allopenclaw status --all

यदि policy जानबूझकर strict है, तो trusted OpenClaw upgrade window के लिए उसे relax करें, openclaw plugins update --all फिर चलाएँ, फिर stricter rule restore करें। यदि update failure के बाद plugin disabled हुआ था, तो उसका निरीक्षण करें और update सफल होने के बाद ही उसे re-enable करें:

bash

openclaw plugins inspect <plugin-id> --runtime --jsonopenclaw plugins enable <plugin-id>

संदर्भ: Operator install policy

Plugin मौजूद है लेकिन suspicious ownership से blocked है

यदि openclaw doctor, setup, या startup warnings यह दिखाएँ:

text

blocked plugin candidate: suspicious ownership (... uid=1000, expected uid=0 or root)plugin present but blocked

तो plugin files उस process से अलग Unix user के स्वामित्व में हैं जो उन्हें load कर रहा है। plugin config न हटाएँ। file ownership ठीक करें या OpenClaw को उसी user के रूप में चलाएँ जो state directory का owner है।

Docker installs सामान्यतः node (uid 1000) के रूप में चलते हैं। default Docker setup के लिए, host bind mounts ठीक करें:

bash

sudo chown -R 1000:1000 /path/to/openclaw-config /path/to/openclaw-workspaceopenclaw doctor --fix

यदि आप जानबूझकर OpenClaw को root के रूप में चलाते हैं, तो managed plugin root को root ownership में ठीक करें:

bash

sudo chown -R root:root /path/to/openclaw-config/npmopenclaw doctor --fix

गहरे docs:

Decision tree

flowchart TD
  A[OpenClaw काम नहीं कर रहा है] --> B{सबसे पहले क्या टूटता है}
  B --> C[कोई replies नहीं]
  B --> D[Dashboard या Control UI connect नहीं होगा]
  B --> E[Gateway start नहीं होगा या service चल नहीं रही]
  B --> F[Channel connect होता है लेकिन messages flow नहीं करते]
  B --> G[Cron या heartbeat fire नहीं हुआ या deliver नहीं हुआ]
  B --> H[Node paired है लेकिन camera canvas screen exec विफल होता है]
  B --> I[Browser tool विफल होता है]

  C --> C1[/No replies section/]
  D --> D1[/Control UI section/]
  E --> E1[/Gateway section/]
  F --> F1[/Channel flow section/]
  G --> G1[/Automation section/]
  H --> H1[/Node tools section/]
  I --> I1[/Browser section/]

कोई replies नहीं

bash

openclaw statusopenclaw gateway statusopenclaw channels status --probeopenclaw pairing list --channel <channel> [--account <id>]openclaw logs --follow

अच्छा आउटपुट ऐसा दिखता है:

Runtime: running
Connectivity probe: ok
Capability: read-only, write-capable, या admin-capable
आपका channel transport connected दिखाता है और, जहाँ supported हो, channels status --probe में works या audit ok
Sender approved दिखता है (या DM policy open/allowlist है)

सामान्य log signatures:

drop guild message (mention required → mention gating ने Discord में message block किया।
pairing request → sender unapproved है और DM pairing approval की प्रतीक्षा कर रहा है।
channel logs में blocked / allowlist → sender, room, या group filtered है।

Deep pages:

Dashboard या Control UI connect नहीं होगा

bash

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

अच्छा आउटपुट ऐसा दिखता है:

Dashboard: http://... openclaw gateway status में दिखता है
Connectivity probe: ok
Capability: read-only, write-capable, या admin-capable
logs में कोई auth loop नहीं

सामान्य log signatures:

device identity required → HTTP/non-secure context device auth पूरा नहीं कर सकता।
origin not allowed → browser Origin Control UI gateway target के लिए allowed नहीं है।
retry hints (canRetryWithDeviceToken=true) के साथ AUTH_TOKEN_MISMATCH → एक trusted device-token retry स्वतः हो सकता है।
वह cached-token retry paired device token के साथ stored cached scope set को reuse करता है। explicit deviceToken / explicit scopes callers अपना requested scope set बनाए रखते हैं।
async Tailscale Serve Control UI path पर, same {scope, ip} के failed attempts failure record करने से पहले serialized होते हैं, इसलिए दूसरा concurrent bad retry पहले से ही retry later दिखा सकता है।
localhost browser origin से too many failed authentication attempts (retry later) → उसी Origin से repeated failures temporary रूप से locked out हैं; दूसरा localhost origin अलग bucket उपयोग करता है।
उस retry के बाद repeated unauthorized → गलत token/password, auth mode mismatch, या stale paired device token।
gateway connect failed: → UI गलत URL/port को target कर रहा है या gateway unreachable है।

Deep pages:

Gateway start नहीं होगा या service installed है लेकिन चल नहीं रही

bash

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

अच्छा आउटपुट ऐसा दिखता है:

Service: ... (loaded)
Runtime: running
Connectivity probe: ok
Capability: read-only, write-capable, या admin-capable

सामान्य log signatures:

Gateway start blocked: set gateway.mode=local या existing config is missing gateway.mode → gateway mode remote है, या config file में local-mode stamp गायब है और उसे repair किया जाना चाहिए।
refusing to bind gateway ... without auth → valid gateway auth path (token/password, या configured होने पर trusted-proxy) के बिना non-loopback bind।
another gateway instance is already listening या EADDRINUSE → port पहले से लिया गया है।

Deep pages:

Channel कनेक्ट होता है लेकिन संदेश प्रवाहित नहीं होते

bash

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

अच्छा आउटपुट ऐसा दिखता है:

चैनल ट्रांसपोर्ट कनेक्टेड है।
पेयरिंग/allowlist जांचें पास होती हैं।
जहां आवश्यक है, mentions पहचाने जाते हैं।

सामान्य लॉग संकेत:

mention required → समूह mention gating ने प्रोसेसिंग ब्लॉक की।
pairing / pending → DM भेजने वाले को अभी स्वीकृति नहीं मिली है।
not_in_channel, missing_scope, Forbidden, 401/403 → चैनल अनुमति टोकन समस्या।

गहरे पेज:

Cron या heartbeat फायर नहीं हुआ या डिलीवर नहीं हुआ

bash

openclaw statusopenclaw gateway statusopenclaw cron statusopenclaw cron listopenclaw cron runs --id <jobId> --limit 20openclaw logs --follow

अच्छा आउटपुट ऐसा दिखता है:

cron.status सक्षम दिखाता है, अगले wake के साथ।
cron runs हाल की ok प्रविष्टियां दिखाता है।
Heartbeat सक्षम है और active hours के बाहर नहीं है।

सामान्य लॉग संकेत:

cron: scheduler disabled; jobs will not run automatically → cron अक्षम है।
heartbeat skipped with reason=quiet-hours → कॉन्फिगर किए गए active hours के बाहर।
heartbeat skipped with reason=empty-heartbeat-file → HEARTBEAT.md मौजूद है लेकिन उसमें केवल खाली, टिप्पणी, हेडर, fence, या empty-checklist scaffolding है।
heartbeat skipped with reason=no-tasks-due → HEARTBEAT.md task mode सक्रिय है लेकिन किसी भी task interval का समय अभी नहीं हुआ है।
heartbeat skipped with reason=alerts-disabled → सभी heartbeat visibility अक्षम है (showOk, showAlerts, और useIndicator सभी बंद हैं)।
requests-in-flight → main lane व्यस्त; heartbeat wake स्थगित किया गया।
unknown accountId → heartbeat डिलीवरी लक्ष्य अकाउंट मौजूद नहीं है।

गहरे पेज:

Node पेयर है लेकिन tool camera canvas screen exec विफल होता है

bash

openclaw statusopenclaw gateway statusopenclaw nodes statusopenclaw nodes describe --node <idOrNameOrIp>openclaw logs --follow

अच्छा आउटपुट ऐसा दिखता है:

Node node भूमिका के लिए कनेक्टेड और पेयर के रूप में सूचीबद्ध है।
जिस कमांड को आप invoke कर रहे हैं उसके लिए capability मौजूद है।
tool के लिए अनुमति स्थिति granted है।

सामान्य लॉग संकेत:

NODE_BACKGROUND_UNAVAILABLE → node ऐप को foreground में लाएं।
*_PERMISSION_REQUIRED → OS अनुमति अस्वीकृत/अनुपस्थित थी।
SYSTEM_RUN_DENIED: approval required → exec approval लंबित है।
SYSTEM_RUN_DENIED: allowlist miss → कमांड exec allowlist में नहीं है।

गहरे पेज:

Exec अचानक approval मांगता है

bash

openclaw config get tools.exec.hostopenclaw config get tools.exec.securityopenclaw config get tools.exec.askopenclaw gateway restart

क्या बदला:

अगर tools.exec.host unset है, तो default auto है।
sandbox runtime सक्रिय होने पर host=auto sandbox में resolve होता है, अन्यथा gateway में।
host=auto केवल routing है; no-prompt "YOLO" व्यवहार gateway/node पर security=full और ask=off से आता है।
gateway और node पर, unset tools.exec.security default रूप से full होता है।
unset tools.exec.ask default रूप से off होता है।
परिणाम: अगर आपको approvals दिख रहे हैं, तो किसी host-local या per-session policy ने exec को मौजूदा defaults से कड़ा कर दिया है।

वर्तमान default no-approval व्यवहार restore करें:

bash

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

अधिक सुरक्षित विकल्प:

अगर आप केवल स्थिर host routing चाहते हैं, तो सिर्फ tools.exec.host=gateway सेट करें।
अगर आप host exec चाहते हैं लेकिन allowlist misses पर फिर भी review चाहते हैं, तो security=allowlist के साथ ask=on-miss उपयोग करें।
अगर आप चाहते हैं कि host=auto वापस sandbox में resolve हो, तो sandbox mode सक्षम करें।

सामान्य लॉग संकेत:

Approval required. → कमांड /approve ... का इंतजार कर रहा है।
SYSTEM_RUN_DENIED: approval required → node-host exec approval लंबित है।
exec host=sandbox requires a sandbox runtime for this session → implicit/explicit sandbox selection, लेकिन sandbox mode बंद है।

गहरे पेज:

Browser tool विफल होता है

bash

openclaw statusopenclaw gateway statusopenclaw browser statusopenclaw logs --followopenclaw doctor

अच्छा आउटपुट ऐसा दिखता है:

Browser status running: true और चुना हुआ browser/profile दिखाता है।
openclaw शुरू होता है, या user local Chrome tabs देख सकता है।

सामान्य लॉग संकेत:

unknown command "browser" या unknown command 'browser' → plugins.allow सेट है और उसमें browser शामिल नहीं है।
Failed to start Chrome CDP on port → local browser launch विफल हुआ।
browser.executablePath not found → configured binary path गलत है।
browser.cdpUrl must be http(s) or ws(s) → configured CDP URL unsupported scheme उपयोग करता है।
browser.cdpUrl has invalid port → configured CDP URL में खराब या out-of-range port है।
No Chrome tabs found for profile="user" → Chrome MCP attach profile में कोई open local Chrome tabs नहीं हैं।
Remote CDP for profile "<name>" is not reachable → configured remote CDP endpoint इस host से reachable नहीं है।
Browser attachOnly is enabled ... not reachable या Browser attachOnly is enabled and CDP websocket ... is not reachable → attach-only profile में कोई live CDP target नहीं है।
attach-only या remote CDP profiles पर stale viewport / dark-mode / locale / offline overrides → active control session बंद करने और gateway restart किए बिना emulation state release करने के लिए openclaw browser stop --browser-profile <name> चलाएं।

गहरे पेज:

सामान्य समस्या निवारण

पहले 60 सेकंड

Assistant सीमित लगता है या tools गायब हैं

Anthropic long context 429

स्थानीय OpenAI-compatible backend सीधे काम करता है लेकिन OpenClaw में विफल होता है

Plugin install missing openclaw extensions के साथ विफल होता है

Install policy plugin installs या updates को block करती है

Plugin मौजूद है लेकिन suspicious ownership से blocked है

Decision tree

संबंधित

On this page

Molty