> ## 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. # Why OpenClaw Says It Will Act but Doesn’t Complete the Task > Troubleshoot when OpenClaw promises to do something but never actually executes the task, including stale chats, missing tools, approval friction, and runtime mismatch. 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: ```bash theme={null} openclaw status ``` Then check the gateway too: ```bash theme={null} openclaw gateway status ``` If you want more detail: ```bash theme={null} 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. ## Related pages * `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`