OpenClaw Broken? I Fix It with Claude Code

In plain terms: I run a home server with local AI helpers (OpenClaw) that do everyday tasks. When something genuinely breaks or gets too complex for them, I bring in a stronger cloud assistant (Claude Code) on the same machine to fix it — and have it write instructions so the local helpers can handle that situation themselves in the future.

Want to implement this yourself? You don't have to follow this write-up by hand — an LLM assistant (Claude, ChatGPT, or a local model) can build the same setup on your machine. Handle the few things only you can do, then paste the prompt below and let the assistant do the rest. New to LLM assistants? Here's how to set one up (Claude Code, Cowork, Terminex, DeepSeek).

Your part — only you can do these

A Linux box already running an agent gateway like OpenClaw with local models
A Claude account or API key for Claude Code (the paid, stronger tier you reach for when it matters)

The assistant's part — delegate these

Diagnose the actual failure from logs and config instead of you guessing
Apply the durable fix (not just a restart) and verify the services come back healthy
Write the runbook/config so your local agents handle the same situation next time

Copy this prompt to start:

Fetch and read https://www.laserlloyd.com/projects/openclaw-broken-i-fix-it-with-claude-code/ — it contains the full write-up, settings, and gotchas for this project. Debug my failing local agent gateway on this machine — I'll describe the symptoms. Find the root cause and apply a durable fix, not a restart-and-hope. Verify by restarting the services, showing healthy status output, and sending one successful test message through the gateway. Then write a short runbook so my agents can catch this next time, and summarize the cause and your changes.

My local OpenClaw agents run this website, my chat app, and a pile of small automations. They handle that routine work around the clock for $0 — right up until the thing they’re running on breaks. Then I don’t ask a drowning system to save itself: I open Claude Code on the same box and let a stronger model fix it.

tl;dr

Simple, repeatable work: local OpenClaw agents. Free tokens, always on.
Truly complex or broken: Claude Code, run directly on the box that runs OpenClaw.
The important part: Claude Code doesn't just fix it — it sets things up so OpenClaw can do it (or survive it) next time.

The two-tier idea

Local models are good enough for a lot: drafting posts, watching services, injecting chat messages, running scheduled jobs. But they have a ceiling — smaller context, weaker debugging instincts, and a habit of confidently restarting things that need actual diagnosis.

The rule of thumb: if the fix is a known runbook, OpenClaw runs it. If the fix requires figuring out, that’s Claude Code.

A real example: the crash-looping gateway

One morning the OpenClaw gateway was crash-looping with nothing but:

agents.list.5: Invalid input

No agent named in the error. Restarts didn’t help — the config was being re-broken as fast as it was repaired. A local model would have restarted it in a loop forever.

Claude Code, run on the box itself, traced it: OpenClaw’s identity-reconcile step was re-reading a stale workspace file left over from an earlier cleanup and re-injecting an invalid agent definition into the live config on every start. The durable fix was three parts:

Correct the stale source file (the thing actually causing it),
Restore the clean gateway config,
Verify by running the full launch-and-restart cycle until every unit stayed up.

That’s the pattern: the visible error was in the config, but the cause was a file nobody had looked at in weeks. Diagnosis, not restarts.

“Fix it so OpenClaw can do it next time”

The second half of every Claude Code session is the part most people skip: after the fix, I have it fold the knowledge back into the local system, so the same class of problem never needs the expensive model again. In practice that means:

Runbooks the local agents can follow. Step-by-step instructions written for a smaller model — checkable steps, exact commands, hard rules. My weekly site-refresh job runs from exactly this kind of file.
Guardrails instead of vigilance. After one incident, Claude Code added a fail-closed pre-publish check to this site’s build (secret scan + content rules), so no agent — local or cloud — can push something embarrassing.
Watchdogs for the known failure modes. Timeouts tuned for slow local models, self-deleting follow-up timers for dispatched work, health checks that post to my chat app instead of failing silently.

Next time the same thing wobbles, OpenClaw handles it with free tokens, and Claude Code only gets called for the genuinely new stuff.

Why run Claude Code on the OpenClaw box?

Run on the same machine, it reads the real logs, the real config, the real service states — and verifies the fix end-to-end instead of guessing from my description. A description filtered through me is exactly how you get plausible-but-wrong fixes.

Gotchas

Don’t let the local agents fix themselves mid-incident. An agent whose own gateway is broken makes things worse. Fix from outside (Claude Code), then hand back control.
Insist on the durable fix. “Restart it” is a symptom patch. Ask explicitly for root cause, and make the assistant prove the fix survives a restart cycle.
Have it write the runbook while the context is hot. The best documentation of an incident is written by the thing that just fixed it, minutes after fixing it.
Keep secrets out of the loop. Runbooks and briefs the agents read should be secrets-free; keys live in the environment, not in prose.