Gateway health
Check whether the gateway is actually running, which port it owns, and whether systemd, Docker, or a foreground process is fighting it.
Debug OpenClaw
Debug OpenClaw without guessing.
If OpenClaw half-works, randomly restarting everything usually makes the problem harder to understand. A debug session narrows the failure to gateway, auth, model, tunnel, VPS, or workspace state.
Direct answer
Debug OpenClaw
Debug OpenClaw by checking the gateway process first, then token flow, browser context, model auth, tunnel access, and the smallest reproducible failure. If you want a second pair of eyes, book a live screen-share session and we will walk the failure boundary together.
Fast triage
What we check first
Auth and tokens
Verify gateway tokens, browser storage, OpenAI/Codex auth, provider keys, and whether the model call works outside the UI.
Logs and repro path
Turn scattered symptoms into a narrow repro: command, log line, expected behavior, actual behavior, and the first failing boundary.
Tunnel and browser context
Debug SSH tunnels, Tailscale, public HTTP secure-context failures, localhost assumptions, and reverse proxy mistakes.
Model and tool calls
Separate OpenClaw failures from local model, Ollama, API quota, context, and tool-calling reliability problems.
Safe recovery
Restart only the piece that is broken, preserve project files, and leave a restart checklist for the next time it fails.
Before the call
Bring the symptoms, not the secrets
Have these ready and redact tokens before pasting logs anywhere.
- Exact error message or screenshot with tokens redacted.
- OpenClaw version, install path, OS, and whether this is local or VPS.
- How you start the gateway: command, service, Docker, or startup script.
- What changed before it broke: update, reconnect, server move, model change, or tunnel change.
- Whether the dashboard opens, chat responds, and model auth works outside OpenClaw.
Choose the right path
Related OpenClaw help
Rescue OpenClaw
Use this when the install is broken and you need a fixed-scope recovery session.
OpenClaw help
Use this when you are choosing between setup, training, troubleshooting, and architecture help.
Troubleshooting guide
Try the free guide first for gateway token, blank response, Docker, Windows, and macOS issues.
FAQ
Common questions
Can you debug OpenClaw live over screen share?
Yes. You drive the machine on screen share while we inspect gateway health, logs, token flow, tunnels, model auth, and the failing repro path.
Do you need my API keys or tokens?
No. You can type secrets yourself. We avoid collecting tokens, screenshots with credentials, or persistent access to your machine.
Is this only for developers?
No. Debug sessions are useful for anyone who has OpenClaw partly working but cannot tell whether the failure is install, gateway, auth, model, tunnel, or VPS related.
What happens if the bug cannot be fixed in one call?
You still leave with the narrowed failure boundary, the commands we ran, what changed, and the next exact recovery action.
Ready when this is worth fixing live
Book Debug Session
Book through CloudYeti. We will use the time to stabilize, isolate, or document the next exact recovery step.
Book Debug Session