OpenClaw already ships with a repair workflow. The practical question is when to trust it. Use doctor for config normalization, stale state cleanup, and safe restart suggestions, then verify the system instead of assuming the repair worked.
Quick answer
Run openclaw doctor --repair or openclaw doctor --fix, then verify the gateway, models, and logs before you call the issue closed.
Command line steps
1. Run doctor in repair mode
This applies recommended fixes instead of only describing them.
BASH
$openclaw doctor --repair
2. Use the non-interactive path for scripted recoveries
This is the version you want for headless or repeatable repair flows.
BASH
$openclaw doctor --repair --non-interactive
3. Verify the service after repair
A successful doctor run still needs a final status and log check.
BASH
$openclaw gateway status --require-rpc
openclaw models status
openclaw logs --follow
What to check if it still fails
- If doctor keeps rewriting the same keys, the config is probably being reintroduced from an older snippet or automation step.
- If you need stronger repairs, add
--forceonly after you understand what custom service state may be overwritten. - If the gateway token is missing, doctor can regenerate one with
openclaw doctor --generate-gateway-token.