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 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: 
openclaw status
Then check gateway status too: 
openclaw gateway status
If your setup supports JSON output and you want more detail: 
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: 
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: 
openclaw gateway restart
Then check status again: 
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: 
~/.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
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.
  • 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