> ## 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 Not Responding After an Update? Start Here > Troubleshoot OpenClaw when it stops responding after an update, including stale sessions, gateway reloads, and config drift. OpenClaw overview illustration *Post-update problems are frustrating because they make you doubt everything at once: the install, the config, the gateway, the current chat, your own memory, and possibly the phase of the moon.* If OpenClaw stopped responding properly after an update, the good news is that this is usually **not** a random failure. The bad news is that “not responding” can mean a few different things: * the assistant replies strangely but does not actually do the task * tools that used to appear are now missing * plugin-backed features stopped surfacing * the gateway is running with stale or invalid config * the current chat is stuck with an old runtime/tool catalog * a version change introduced a config mismatch This guide is the fastest practical checklist to narrow it down. > Refresh icon > > **Do this early:** after an update, test the same task in a **fresh chat** before assuming the install is broken. Stale sessions fake a lot of post-update bugs. ## Refresh icon At a glance * Define what “not responding” actually means in your case before changing things blindly. * Check `openclaw status` and `openclaw gateway status` early. * After updates, always retry in a **fresh chat** to rule out stale session state. ## First: define what “not responding” means in your case Before changing anything, identify which of these fits best: ### Case 1: OpenClaw replies, but does not actually act Example: * it says it will do something * but no tool action follows * or it answers vaguely instead of executing the task ### Case 2: tools or plugin-backed behavior disappeared Example: * ACPX-related tools are gone * ClawLink or other plugin tools no longer show up * exec/runtime tools are suddenly missing ### Case 3: the gateway or runtime seems unhealthy Example: * requests fail * plugin state looks wrong * runtime behavior changed immediately after the update ### Case 4: the problem started after upgrading or rolling back across versions That raises the odds of config compatibility issues. Once you know which bucket you are in, troubleshooting gets much less messy. ## Fastest troubleshooting flow Use this in order. ## 1) Check basic status first Run: ```bash theme={null} openclaw status ``` Then check gateway status too: ```bash theme={null} openclaw gateway status ``` If your setup supports JSON output and you want more detail: ```bash theme={null} openclaw gateway status --json ``` You are looking for clues like: * config validation failures * plugin/runtime load problems * unhealthy gateway state * obvious errors introduced by the update ## 2) Start a fresh chat before assuming the update is broken This is one of the most common post-update gotchas. Even if the update succeeded, the **current conversation** may still reflect the old tool/runtime catalog. So if features disappeared or behavior feels stale: * start a new chat * retry the same task there If the new chat works, the update may have been fine and the old session was just stale. ## 3) If plugin-backed features disappeared, verify plugin state Updates can expose plugin/config assumptions that were previously hidden. Check whether: * the plugin is still allowed by the current config * the gateway reloaded after the update * the runtime is actually surfacing the expected tools * your current chat predates the updated runtime state For ACP-related behavior specifically, check whether ACPX is still enabled if your workflow depends on it. A common command pattern is: ```bash theme={null} openclaw gateway status --json ``` If you intentionally manage a plugin allowlist, confirm it still contains what you expect. ## 4) Restart the gateway cleanly If the update changed config, plugins, or runtime behavior, do not just keep poking the old process. Restart the gateway: ```bash theme={null} openclaw gateway restart ``` Then check status again: ```bash theme={null} openclaw gateway status --json ``` ## 5) Check for config/binary mismatch This is especially important if the problem began after: * rolling back * upgrading across a feature boundary * testing a newer release and then reverting Typical symptom: * a new version wrote config that an older version does not understand * startup or validation now fails * plugin/runtime references no longer match the running binary One common example is ACPX-related config left behind after rollback. If that sounds like your issue, inspect: ```text theme={null} ~/.openclaw/openclaw.json ``` Look for config entries that may not match the version now running. ## 6) Re-test one concrete task, not five vague ones Pick a single task that clearly used to work. Examples: * a plugin-backed tool lookup * an ACP-related workflow * a simple status-dependent task Then retry it in a fresh chat after the status check and gateway restart. That gives you a clean before/after signal. ## Common post-update failure patterns ## Pattern 1: stale session after update Symptoms: * old chat behaves oddly * new chat behaves normally Fix: * start a fresh chat ## Pattern 2: plugin allowlist or runtime state changed Symptoms: * tools disappeared * plugin-backed flows stopped appearing Fix: * verify plugin config * restart gateway * retest in a fresh chat ## Pattern 3: config validation failure after rollback Symptoms: * update or rollback happened recently * gateway status shows validation failure * startup mentions missing or unsupported plugin/runtime entries Fix: * inspect `~/.openclaw/openclaw.json` * remove or adjust incompatible config * restart gateway ## Pattern 4: “it says it will act, but nothing happens” Symptoms: * model responds conversationally * expected tool action never happens Possible causes: * tool/runtime catalog is stale * plugin is missing * gateway state is unhealthy * the task now routes differently after the update Fix: * check status * restart gateway * start a fresh chat * retry one specific task ## If ACP-related behavior broke after the update That usually points to one of these: * ACPX is no longer loaded * current session is stale * config changed but gateway did not reload * version mismatch after upgrade/rollback In that case, also check: * `How to enable the ACPX plugin in OpenClaw` * `How to fix “acpx plugin not found” after rolling back OpenClaw` * `How ACP sessions work in OpenClaw` ## Common mistakes ### Troubleshooting only in the same old chat That tells you less than you think. ### Skipping status checks and jumping straight to random edits Fast way to create a second problem. ### Assuming every post-update issue is a model issue Sometimes it is just plugin/runtime state. ### Forgetting that rollback problems are often config problems Very common. ## Minimal recovery checklist If you want the shortest version, do this: 1. run `openclaw status` 2. run `openclaw gateway status --json` 3. restart with `openclaw gateway restart` 4. start a fresh chat 5. retry one known task 6. inspect `~/.openclaw/openclaw.json` if rollback/version mismatch is suspected ## Final thought When OpenClaw seems unresponsive after an update, the fastest way out is usually not deeper guesswork. It is checking four boring things in order: * status * gateway reload * fresh session * config/version mismatch That catches a lot of post-update weirdness before it turns into a three-hour debugging spiral. ## Related pages * `How to fix “acpx plugin not found” after rolling back OpenClaw` * `How to enable the ACPX plugin in OpenClaw` * `Why ACPX isn’t showing up in OpenClaw` * `How ACP sessions work in OpenClaw`