Before you reinstall OpenClaw, check the boring failure points.
Most broken agent setups are not mysterious. They usually fail at service state, auth routing, channels, tools, memory, update drift, or one bad assumption hiding upstream in the logs.
Independent operator guidance. Not official OpenClaw support. Do not send secrets.
The rule: prove the layer before you blame the agent.
When OpenClaw or a Hermes migration is stuck, do not start by randomly editing prompts, deleting memory, rotating credentials, or reinstalling. Walk the stack in order and collect safe evidence.
OpenClaw Rescue Checklist
Confirm the actual runtime and version
Do not assume the shell, service, and UI are pointing at the same install.
- Run
openclaw status. - Note host OS, workspace path, runtime version, and active model.
- Look for split installs, legacy paths, stale sessions, or PATH weirdness.
Check gateway/service health first
If the gateway is down or unhealthy, model and channel debugging is noise.
- Run
openclaw gateway status. - Confirm expected port, service state, and restart behavior.
- Do not restart blindly if you have local hotfixes or active jobs.
Separate model failure from agent failure
A dead provider, bad auth profile, or exhausted model can look like a broken agent.
- Run
openclaw models status. - Check default model, fallback model, and provider auth state.
- Watch for 401/403/429 errors and mismatched model aliases.
Probe channels independently
Telegram/Discord/WhatsApp routing can fail even when the core agent works.
- Check channel config and delivery logs.
- Run the relevant channel probe if available.
- Distinguish inbound receipt from outbound reply delivery.
Inspect approval/tool-call blockers
Sometimes the agent is waiting on approval or blocked by tool policy, not broken.
- Look for pending approvals, denied commands, sandbox restrictions, or missing tool permissions.
- Check whether browser, cron, exec, or messaging tools are available in that session.
Find the first real error in logs
The last error is often just the symptom. The first error usually explains the cascade.
- Collect a short log excerpt around the first failure.
- Redact secrets before sharing.
- Preserve timestamps and command/output pairs.
Check memory and workspace drift
Huge, contradictory, or stale memory files can poison continuity and make the system feel haunted.
- Review key startup files and project handoffs.
- Check whether old Windows/Linux paths or archived sessions are still referenced.
- Do not delete memory blindly. Compact or handoff instead.
Verify browser/session assumptions
A logged-out browser profile or broken frontend assets can block posting, Gumroad, Gmail, or social work.
- Confirm the correct browser profile is running.
- Check snapshots/console errors before assuming login failure.
- Use shared/visible browser only when human login state matters.
Check cron and background jobs
Missed scheduled tasks may be scheduler, session-target, delivery, or login-state problems.
- List cron jobs and recent run history.
- Confirm whether jobs target main, isolated, current, or a named session.
- Do not emulate reminders with shell sleep loops.
Identify update drift and local hotfixes
Package updates can overwrite local runtime patches; old hotfixes can also break newer versions.
- Check recent updates and local modifications.
- Look for backups beside patched files.
- Do not update just because an update exists.
For Hermes migrations, dry-run before moving state
Migrations fail hardest when memory, prompts, secrets, and workspaces are mixed without a plan.
- Separate durable memory from session noise.
- Do not copy browser profiles, raw OAuth artifacts, or secrets casually.
- Keep a rollback path.
Decide the fix path from evidence
The correct answer may be DIY, guided setup, done-for-you rescue, or upstream issue reporting.
- Rank findings by severity and confidence.
- Fix P0 blockers before cosmetic cleanup.
- Write down what not to touch yet.
Want me to review the redacted bundle?
If you are stuck and want a structured diagnosis, the OpenClaw Rescue Audit turns this checklist into a severity-ranked report with a risk scorecard, confidence labels, and a fix-first path.
- $149 founding beta
- 48-hour target after complete redacted intake
- No secrets, no production access required
- Independent audit, not official OpenClaw support
Best fit
This is for builders/operators who can run basic commands and send redacted diagnostic outputs, but need a second set of structured eyes on what to fix first.
It is not a replacement for official support, security review, or guaranteed upstream bug fixes.