Git checkout and global OpenClaw disagree after an accidental update

Troubleshooting
, , , ,
1

Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from July 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

I have used an OpenClaw Git checkout with pnpm install and pnpm build for a while. After accidentally running the normal updater, the Gateway reports running but agents fail before replying. I am unsure whether to repair this installation or start over.

2

Preserve the state and inventory both execution paths first:

openclaw --version
pnpm openclaw --version
which -a openclaw
git status --short --branch
git log -1 --decorate --oneline
pnpm openclaw update status --json
pnpm openclaw gateway status --deep
pnpm openclaw logs --follow

The generic reply failure is only a wrapper. A clean install could erase useful evidence and is unnecessary until the actual failure is known.

3

The reports showed multiple independent problems: the bare CLI and pnpm openclaw were different versions, some effective bindings did not match the loaded agent roster, and the shared state database reported an I/O warning. Use only the checkout CLI while diagnosing. Validate configuration, check free space and filesystem health, and run SQLite integrity checks read-only. Do not delete SQLite, WAL, or SHM files.

4

The agents still exist and their workspace folders are present. Why would the validator say the bindings refer to missing agents?

5

A workspace folder does not define the effective agent ID. Compare each binding’s agentId with the IDs loaded from the active config. If they already match, the issue may be config layering or schema drift rather than deleted agents.

Create a verified backup before any repair. Run openclaw doctor --fix only from the intended current installation, then revalidate. If the database reports a noncanonical schema, stop and use the supported inspect or recovery path instead of hand-editing tables.

6

I tried the safe repair later, but the Gateway still failed its health checks. I still want the simplest way back to a working setup.

7

At that point the clean path is evidence first: align the CLI and service versions, capture the first fatal Gateway log, and remove only configuration that names unavailable plugins. Preserve the state directory and verified backup.