Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.claw-link.dev/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw overview illustration This is one of the most annoying failure modes because it feels like success for a second. The assistant sounds confident, says it will handle it, and then… absolutely nothing useful happens. If OpenClaw says it will do something but never actually completes the task, the issue is usually not random. It is usually one of these:
  • the current chat is stale and does not see the right tools
  • the workflow needed a tool/runtime path that is not actually available
  • the model answered conversationally instead of executing
  • an approval or permission boundary blocked the action
  • the task depended on ACP/plugin/runtime setup that is missing or misconfigured
  • the channel/session looked healthy, but routing or execution never really happened
This guide is the practical checklist for sorting those out without flailing.
Lightbulb icon Mental model: there is a difference between talking about doing work and actually having the runtime/tool path needed to do the work. This guide is about finding where that gap appears.

​
Wrench icon At a glance

  • First decide whether OpenClaw failed at execution, tool access, approval, or routing.
  • Test the same request in a fresh chat before blaming the whole install.
  • If no tool action is actually possible in the current session, OpenClaw may sound helpful while still being unable to execute.

​
What this problem usually looks like

Users usually mean one of these:
  • OpenClaw says it will do the task, but no tool call or real action follows
  • it gives a planning-style answer instead of actually acting
  • it starts sounding like it is working, then silently stops
  • it used to execute similar tasks, but now only responds conversationally
  • the task works in one chat/session but not another
Those all point to the same broad class of issue:
the assistant response layer and the actual execution layer are out of sync.

​
First: define what kind of failure this is

Before changing anything, figure out which of these buckets fits best.

​
Case 1: OpenClaw replied normally, but no action happened

Examples:
  • it says “I’ll handle that”
  • but there is no tool activity
  • no file change, no web fetch, no command, no message action, nothing

​
Case 2: the needed tools are not actually available

Examples:
  • plugin-backed tools are missing
  • ACP/runtime-dependent features do not appear
  • the current session does not expose the capability the task needs

​
Case 3: an approval or safety boundary blocked the action

Examples:
  • the task needs permission to execute or access something
  • approval was pending or never completed
  • the task required elevated/external action the runtime would not do automatically

​
Case 4: the task executed somewhere, but the result did not come back cleanly

Examples:
  • a child/agent workflow runs but no final result appears
  • execution started, then the parent session never gets the outcome
  • channel routing or session bridging is the real problem
Once you know which class you are in, the next steps get much less messy.

​
Fastest troubleshooting flow

​
1) Re-run the same request in a fresh chat

This is the fastest high-signal test. If the current chat started before:
  • a plugin was installed
  • ACPX was enabled
  • gateway config changed
  • tools were refreshed
  • the model/runtime configuration changed
…then the current session may simply not know about the newer execution path. So before you spiral:
  • open a fresh chat
  • ask for the same task again
  • compare behavior
If the fresh chat works, your install may be fine and the old chat was just stale.

​
2) Check whether the task actually needed a tool or runtime path

A lot of these failures come from this mismatch:
  • the user asked for real action
  • but the current session only had enough context to respond in words
Examples of tasks that usually need a real execution path:
  • editing files
  • browsing/fetching web pages
  • sending messages
  • running commands
  • using plugin-backed integrations
  • starting ACP/agent sessions
If the session does not actually have the needed path available, OpenClaw may still produce a plausible-sounding answer. That is not the same as being able to do the work.

​
3) Check status early

Run: 
openclaw status
Then check the gateway too: 
openclaw gateway status
If you want more detail: 
openclaw gateway status --json
You are looking for clues like:
  • gateway unhealthy
  • plugin/runtime load failure
  • config validation errors
  • stale or mismatched runtime state

​
4) If the task depended on a plugin or ACP path, verify that first

This matters a lot for tasks that involve:
  • ACP-backed sessions
  • coding-agent/runtime flows
  • plugin-backed tools
  • integration/setup paths
If that runtime path is missing, the assistant may still talk as if it can proceed, while the actual execution layer is unavailable. Useful related checks:
  • is the relevant plugin allowed?
  • did the gateway restart after config changed?
  • are you still testing in an old chat?
  • does the workflow actually require ACP/plugin support?

​
5) Check whether approvals or safety boundaries blocked the action

Sometimes the issue is not a broken runtime. It is simply that the requested action crossed a boundary that needed confirmation. Common examples:
  • shell execution that needed approval
  • external actions requiring explicit permission
  • sensitive operations that were not auto-executed
If the system surfaced a permission/approval step and it never completed, the result can look like:
“OpenClaw said it would do it, but nothing happened.”
That is not always a bug. Sometimes it is an incomplete approval flow.

​
6) Reduce the test to one concrete task

Do not retry five vague tasks at once. Pick one exact request, for example:
  • “read this file”
  • “fetch this page”
  • “edit this doc”
  • “run this command”
  • “start this ACP-backed workflow”
Then test that one task:
  1. in the current chat
  2. in a fresh chat
  3. after checking status
That gives you an actual signal instead of vibes.

​
Common root causes

​
Root cause 1: stale chat session

Symptoms:
  • old chat behaves wrong
  • new chat works
  • tools or plugin behavior differ by session
Fix:
  • start a fresh chat

​
Root cause 2: missing tool/runtime path

Symptoms:
  • assistant answers helpfully, but no real action follows
  • task required a capability the current session does not expose
Fix:
  • verify the required tool/plugin/runtime path actually exists
  • do not assume words imply execution

​
Root cause 3: approval never completed

Symptoms:
  • task needed permission
  • action did not proceed
  • user saw “about to do X” language but not the actual result
Fix:
  • complete the approval flow
  • retry the task after approval if needed

​
Root cause 4: plugin or ACP setup mismatch

Symptoms:
  • tasks that depend on ACP/plugin-backed flows quietly fail to materialize
  • the runtime path seems missing or half-configured
Fix:
  • verify plugin allowlist
  • restart gateway
  • check status
  • retry in a fresh chat

​
Root cause 5: result path/routing failure

Symptoms:
  • work appears to start elsewhere
  • no clean final result appears in the parent/session/channel
Fix:
  • inspect session/routing behavior more closely
  • reduce to a single reproducible workflow

​
A practical checklist

Use this order:

​
1. Retry in a fresh chat

​
2. Check openclaw status

​
3. Check openclaw gateway status --json

​
4. Confirm the task actually required a real execution path

​
5. Confirm the required tools/plugins/runtime are available

​
6. Check whether approvals were required but never completed

​
7. Re-test one exact task

​
How to tell whether this is really an execution problem

It is probably an execution-path problem if:
  • the answer sounds plausible but nothing concrete happens
  • the same request works in a different session
  • the task depends on tools that are missing
  • the issue began after runtime/plugin/config changes
It is probably not just “the model being weird” if the pattern is repeatable.

​
Common mistakes

​
Assuming a confident answer means execution happened

It does not.

​
Debugging only in one stale conversation

Classic mistake.

​
Mixing approval problems with runtime problems

They feel similar from the outside, but they are different.

​
Changing three things at once

That just ruins the signal.

​
Final thought

When OpenClaw says it will act but does not complete the task, the fix is usually not mystical. It is usually one of four boring things:
  1. stale chat
  2. missing tool/runtime path
  3. incomplete approval
  4. result/routing mismatch
Find which one it is first. That is how you stop debugging this like a haunted house.
  • OpenClaw Not Responding After an Update? Start Here
  • ACP Agent Configuration in OpenClaw: What Actually Needs to Be Wired
  • Why ACPX Isn’t Showing Up in OpenClaw
  • How ACP Sessions Work in OpenClaw