Skip to Content
👋 Willkommen bei HowToUseOpenClaw Schnellstart
GatewayFehlerbehebung

Fehlerbehebung 🔧

Gateway startet nicht oder unautorisiert? Hier anfangen. Wenn OpenClaw sich falsch verhält, so behebst du es. Für eine schnelle Triage-Rezeptur zuerst die FAQ Erste 60 Sekunden. Diese Seite geht tiefer auf Laufzeitfehler und Diagnostik ein. Anbieter-spezifische Shortcuts: /channels/troubleshooting

Status & Diagnostik

Schnelle Triage-Befehle (in Reihenfolge):

BefehlWas du erfährstWann nutzen
openclaw statusLokale Zusammenfassung: OS + Update, Gateway-Erreichbarkeit/Modus, Service, Agenten/Sitzungen, Provider-Config-StatusErster Check, schneller Überblick
openclaw status --allVollständige lokale Diagnose (nur lesen, einfügbar, relativ sicher) inkl. Log-TailWenn du einen Debug-Report teilen musst
openclaw status --deepFührt Gateway-Health-Checks aus (inkl. Provider-Probes; erfordert erreichbares Gateway)Wenn „konfiguriert“ nicht „funktioniert“ heißt
openclaw gateway probeGateway-Discovery + Erreichbarkeit (lokal + Remote-Ziele)Wenn du vermutest, das falsche Gateway zu prüfen
openclaw channels status --probeFragt das laufende Gateway nach Kanalstatus (und optional Probes)Wenn Gateway erreichbar ist, Kanäle sich aber falsch verhalten
openclaw gateway statusSupervisor-Status (launchd/systemd/schtasks), Laufzeit-PID/Exit, letzter Gateway-FehlerWenn der Service „geladen“ aussieht, aber nichts läuft
openclaw logs --followLive-Logs (bester Indikator für Laufzeitprobleme)Wenn du den tatsächlichen Fehlergrund brauchst

Ausgabe teilen: Bevorzuge openclaw status --all (redigiert Tokens). Wenn du openclaw status einfügst, setze zuerst CLAWDBOT_SHOW_SECRETS=0 (Token-Vorschau). Siehe auch Health-Checks und Logging.

Häufige Probleme

No API key found for provider “anthropic”

Das bedeutet: Der Auth-Speicher des Agenten ist leer oder Anthropic-Credentials fehlen. Auth ist pro Agent, ein neuer Agent übernimmt die Keys des Hauptagenten nicht. Möglichkeiten:

  • Onboarding erneut ausführen und Anthropic für diesen Agenten wählen.
  • Oder einen Setup-Token auf dem Gateway-Host einfügen:
openclaw models auth setup-token --provider anthropic
  • Oder auth-profiles.json vom Hauptagenten-Verzeichnis ins neue Agenten-Verzeichnis kopieren.

Prüfen:

openclaw models status

OAuth token refresh failed (Anthropic Claude subscription)

Der gespeicherte Anthropic-OAuth-Token ist abgelaufen und die Aktualisierung ist fehlgeschlagen. Bei einer Claude-Abo-Nutzung (ohne API-Key) ist der zuverlässigste Fix, auf einen Claude-Code-Setup-Token zu wechseln und ihn auf dem Gateway-Host einzufügen. Empfohlen (Setup-Token):

# Auf dem Gateway-Host ausführen (Setup-Token einfügen) openclaw models auth setup-token --provider anthropic openclaw models status

Falls du den Token woanders erzeugt hast:

openclaw models auth paste-token --provider anthropic openclaw models status

Mehr Details: Anthropic und OAuth.

Control UI schlägt über HTTP fehl („device identity required“ / „connect failed“)

Wenn du das Dashboard über reines HTTP öffnest (z. B. http://<lan-ip>:18789/ oder http://<tailscale-ip>:18789/), läuft der Browser in einem unsicheren Kontext und blockiert WebCrypto, daher kann keine Geräteidentität erzeugt werden. Fix:

  • HTTPS bevorzugen über Tailscale Serve.
  • Oder lokal auf dem Gateway-Host öffnen: http://127.0.0.1:18789/.
  • Bei HTTP: gateway.controlUi.allowInsecureAuth: true setzen und Gateway-Token nutzen (nur Token; keine Geräteidentität/Pairing). Siehe Control UI.

CI Secrets Scan Failed

detect-secrets hat neue Kandidaten gefunden, die noch nicht in der Baseline sind. Folge Secret scanning.

Service installiert, aber nichts läuft

Wenn der Gateway-Service installiert ist, der Prozess aber sofort beendet wird, kann der Service „geladen“ erscheinen, obwohl nichts läuft. Prüfen:

openclaw gateway status openclaw doctor

Doctor/Service zeigt Laufzeitstatus (PID/letzter Exit) und Log-Hinweise. Logs:

  • Bevorzugt: openclaw logs --follow
  • Datei-Logs (immer): /tmp/openclaw/openclaw-YYYY-MM-DD.log (oder deine konfigurierte logging.file)
  • macOS LaunchAgent (falls installiert): $CLAWDBOT_STATE_DIR/logs/gateway.log und gateway.err.log
  • Linux systemd (falls installiert): journalctl --user -u openclaw-gateway[-<profile>].service -n 200 --no-pager
  • Windows: schtasks /Query /TN "OpenClaw Gateway (<profile>)" /V /FO LIST

Mehr Logging:

  • Datei-Log-Detail erhöhen (persistiertes JSONL):
{ "logging": { "level": "debug" } }
  • Konsolen-Ausführlichkeit erhöhen (nur TTY-Ausgabe):
{ "logging": { "consoleLevel": "debug", "consoleStyle": "pretty" } }
  • Kurztipp: --verbose betrifft nur die Konsolen-Ausgabe. Datei-Logs steuert weiterhin logging.level.

Siehe /logging für Formate, Config und Zugriff.

„Gateway start blocked: set gateway.mode=local“

Die Config existiert, aber gateway.mode ist nicht gesetzt (oder nicht local), daher weigert sich das Gateway zu starten. Fix (empfohlen):

  • Assistenten ausführen und Gateway-Laufmodus auf Local setzen:
openclaw configure
  • Oder direkt setzen:
openclaw config set gateway.mode local

Falls du ein Remote-Gateway betreiben willst:

  • Remote-URL setzen und gateway.mode=remote beibehalten:
openclaw config set gateway.mode remote openclaw config set gateway.remote.url "wss://gateway.example.com"

Nur Ad-hoc/Entwicklung: --allow-unconfigured übergeben, um das Gateway ohne gateway.mode=local zu starten. Noch keine Config-Datei? openclaw setup ausführen für eine Starter-Config, dann Gateway erneut starten.

Service-Umgebung (PATH + Laufzeit)

Der Gateway-Service läuft mit minimalem PATH, um Shell-/Manager-Ballast zu vermeiden:

  • macOS: /opt/homebrew/bin, /usr/local/bin, /usr/bin, /bin
  • Linux: /usr/local/bin, /usr/bin, /bin

Version-Manager (nvm/fnm/volta/asdf) und Package-Manager (pnpm/npm) sind bewusst ausgeschlossen, weil der Service deine Shell-Init nicht lädt. Laufzeitvariablen wie DISPLAY gehören in ~/.clawdbot/.env (wird vom Gateway früh geladen). Exec auf host=gateway übernimmt deinen Login-Shell-PATH in die Exec-Umgebung; fehlende Tools bedeuten meist, dass deine Shell-Init sie nicht exportiert (oder tools.exec.pathPrepend setzen). Siehe /tools/exec. WhatsApp- und Telegram-Kanäle benötigen Node; Bun wird nicht unterstützt. Wenn dein Service mit Bun oder version-verwaltetem Node-Pfad installiert wurde, openclaw doctor ausführen für die Migration zu einer System-Node-Installation.

Skill fehlt API-Key in Sandbox

Symptom: Skill funktioniert auf dem Host, schlägt in der Sandbox mit fehlendem API-Key fehl. Grund: Sandboxed Exec läuft in Docker und erbt nicht die Host-process.env. Fix:

  • agents.defaults.sandbox.docker.env setzen (oder pro Agent agents.list[].sandbox.docker.env)
  • oder den Key in dein Custom-Sandbox-Image einbacken
  • dann openclaw sandbox recreate --agent <id> (oder --all) ausführen

Service läuft, aber Port lauscht nicht

Wenn der Service running meldet, aber nichts auf dem Gateway-Port lauscht, hat das Gateway vermutlich den Bind verweigert. Was „running“ hier bedeutet

  • Runtime: running heißt, dein Supervisor (launchd/systemd/schtasks) hält den Prozess für aktiv.
  • RPC probe heißt, die CLI konnte sich tatsächlich mit dem Gateway-WebSocket verbinden und status aufrufen.
  • Immer Probe target: + Config (service): als „was haben wir wirklich versucht?“-Zeilen vertrauen.

Prüfen:

  • gateway.mode muss local sein für openclaw gateway und den Service.
  • Bei gateway.mode=remote nutzt die CLI standardmäßig eine Remote-URL. Der Service kann lokal laufen, die CLI prüft aber vielleicht den falschen Ort. openclaw gateway status zeigt den aufgelösten Port + Probe-Ziel des Service (oder --url übergeben).
  • openclaw gateway status und openclaw doctor zeigen den letzten Gateway-Fehler aus den Logs, wenn der Service running aussieht, der Port aber geschlossen ist.
  • Non-Loopback-Binds (lan/tailnet/custom oder auto wenn Loopback nicht verfügbar) benötigen Auth: gateway.auth.token (oder CLAWDBOT_GATEWAY_TOKEN).
  • gateway.remote.token gilt nur für Remote-CLI-Aufrufe; er aktiviert nicht die lokale Auth.
  • gateway.token wird ignoriert; nutze gateway.auth.token.

Wenn openclaw gateway status Config-Mismatch zeigt

  • Config (cli): ... und Config (service): ... sollten normal übereinstimmen.
  • Wenn nicht, bearbeitest du fast sicher eine Config, während der Service eine andere nutzt.
  • Fix: openclaw gateway install --force erneut ausführen mit demselben --profile / CLAWDBOT_STATE_DIR, den der Service nutzen soll.

Wenn openclaw gateway status Service-Config-Probleme meldet

  • Die Supervisor-Config (launchd/systemd/schtasks) fehlt aktuelle Defaults.
  • Fix: openclaw doctor ausführen zum Aktualisieren (oder openclaw gateway install --force für komplette Neuaufschreibung).

Wenn „Last gateway error:“ „refusing to bind … without auth“ erwähnt

  • Du hast gateway.bind auf einen Non-Loopback-Modus gesetzt (lan/tailnet/custom oder auto wenn Loopback nicht verfügbar), aber keine Auth konfiguriert.
  • Fix: gateway.auth.mode + gateway.auth.token setzen (oder CLAWDBOT_GATEWAY_TOKEN exportieren) und Service neu starten.

Wenn openclaw gateway status bind=tailnet sagt, aber kein Tailnet-Interface gefunden wurde

  • Das Gateway wollte an eine Tailscale-IP (100.64.0.0/10) binden, aber auf dem Host wurde keine gefunden.
  • Fix: Tailscale auf dieser Maschine starten (oder gateway.bind auf loopback/lan ändern).

Wenn „Probe note:“ sagt, die Probe nutzt Loopback

  • Das ist bei bind=lan erwartbar: Das Gateway lauscht auf 0.0.0.0 (alle Interfaces), Loopback sollte lokal weiter verbinden.
  • Für Remote-Clients echte LAN-IP (nicht 0.0.0.0) plus Port nutzen und Auth konfigurieren.

Address Already in Use (Port 18789)

Etwas lauscht bereits auf dem Gateway-Port. Prüfen:

openclaw gateway status

Zeigt die Listener und wahrscheinliche Ursachen (Gateway läuft schon, SSH-Tunnel). Bei Bedarf Service stoppen oder anderen Port wählen.

Extra Workspace Folders Detected

Nach Upgrade von älteren Installationen kann ~/openclaw noch auf der Disk sein. Mehrere Workspace-Verzeichnisse können zu verwirrender Auth oder State-Drift führen, weil nur ein Workspace aktiv ist. Fix: Einen aktiven Workspace behalten und den Rest archivieren/entfernen. Siehe Agent workspace.

Main-Chat läuft in Sandbox-Workspace

Symptome: pwd oder Datei-Tools zeigen ~/.clawdbot/sandboxes/..., obwohl du den Host-Workspace erwartet hast. Grund: agents.defaults.sandbox.mode: "non-main" hängt an session.mainKey (Standard "main"). Gruppen-/Kanal-Sitzungen nutzen eigene Keys und werden als non-main behandelt, bekommen also Sandbox-Workspaces. Fix-Optionen:

  • Host-Workspaces für einen Agenten: agents.list[].sandbox.mode: "off" setzen.
  • Host-Workspace-Zugriff in der Sandbox: workspaceAccess: "rw" für diesen Agenten setzen.

„Agent was aborted“

Der Agent wurde mitten in der Antwort unterbrochen. Ursachen:

  • Nutzer hat stop, abort, esc, wait oder exit gesendet
  • Timeout überschritten
  • Prozess abgestürzt

Fix: Einfach eine weitere Nachricht senden. Die Sitzung geht weiter.

„Agent failed before reply: Unknown model: anthropic/claude-haiku-3-5“

OpenClaw lehnt ältere/unsichere Modelle bewusst ab (besonders solche mit höherer Prompt-Injection-Anfälligkeit). Bei diesem Fehler wird der Modellname nicht mehr unterstützt. Fix:

  • Ein aktuelles Modell des Providers wählen und Config oder Modell-Alias anpassen.
  • Bei Unsicherheit, welche Modelle verfügbar sind: openclaw models list oder openclaw models scan ausführen und ein unterstütztes wählen.
  • Gateway-Logs für den genauen Fehlergrund prüfen.

Siehe auch: Models CLI und Model providers.

Nachrichten lösen nichts aus

Check 1: Ist der Absender in der Allowlist?

openclaw status

In der Ausgabe nach AllowFrom: ... schauen. Check 2: Bei Gruppenchats: Ist Mention erforderlich?

# Die Nachricht muss mentionPatterns oder explizite Mentions matchen; Defaults stehen in channel groups/guilds. # Multi-Agent: `agents.list[].groupChat.mentionPatterns` überschreibt globale Muster. grep -n "agents\\|groupChat\\|mentionPatterns\\|channels\\.whatsapp\\.groups\\|channels\\.telegram\\.groups\\|channels\\.imessage\\.groups\\|channels\\.discord\\.guilds" \ "${CLAWDBOT_CONFIG_PATH:-$HOME/.clawdbot/openclaw.json}"

Check 3: Logs prüfen

openclaw logs --follow # oder für schnelle Filter: tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | grep "blocked\\|skip\\|unauthorized"

Pairing-Code kommt nicht an

Bei dmPolicy = pairing sollten unbekannte Sender einen Code erhalten; ihre Nachricht wird bis zur Freigabe ignoriert. Check 1: Wartet bereits eine Anfrage?

openclaw pairing list <channel>

Ausstehende DM-Pairing-Anfragen sind standardmäßig auf 3 pro Kanal begrenzt. Ist die Liste voll, erzeugen neue Anfragen keinen Code, bis eine freigegeben oder abgelaufen ist. Check 2: Wurde die Anfrage erstellt, aber keine Antwort gesendet?

openclaw logs --follow | grep "pairing request"

Check 3: Bestätigen, dass dmPolicy für diesen Kanal nicht open/allowlist ist.

Image + Mention funktioniert nicht

Bekanntes Problem: Bei nur einer Erwähnung und einem Bild (ohne weiteren Text) liefert WhatsApp manchmal keine Mention-Metadaten. Workaround: Etwas Text zur Erwähnung hinzufügen:

  • @clawd + Bild
  • @clawd check this + Bild

Sitzung wird nicht fortgesetzt

Check 1: Liegt die Sitzungsdatei vor?

ls -la ~/.clawdbot/agents/<agentId>/sessions/

Check 2: Ist das Reset-Fenster zu kurz?

{ "session": { "reset": { "mode": "daily", "atHour": 4, "idleMinutes": 10080 // 7 Tage } } }

Check 3: Hat jemand /new, /reset oder einen Reset-Trigger gesendet?

Agent-Timeouts

Standard-Timeout ist 30 Minuten. Für lange Aufgaben:

{ "reply": { "timeoutSeconds": 3600 // 1 Stunde } }

Oder das process-Tool für lange Befehle im Hintergrund nutzen.

WhatsApp getrennt

# Lokalen Status prüfen (Creds, Sitzungen, queued Events) openclaw status # Laufendes Gateway + Kanäle prüfen (WA-Verbindung + Telegram + Discord APIs) openclaw status --deep # Kürzliche Verbindungs-Events anzeigen openclaw logs --limit 200 | grep "connection\\|disconnect\\|logout"

Fix: Verbindet sich meist automatisch wieder, sobald das Gateway läuft. Wenn es hängt: Gateway-Prozess neu starten (wie auch immer du ihn überwachst) oder manuell mit ausführlicher Ausgabe starten:

openclaw gateway --verbose

Bei Logout / Unlink:

openclaw channels logout trash "${CLAWDBOT_STATE_DIR:-$HOME/.clawdbot}/credentials" # falls logout nicht sauber aufräumen kann openclaw channels login --verbose # QR erneut scannen

Medienversand schlägt fehl

Check 1: Ist der Dateipfad gültig?

ls -la /path/to/your/image.jpg

Check 2: Ist die Datei zu groß?

  • Bilder: max. 6 MB
  • Audio/Video: max. 16 MB
  • Dokumente: max. 100 MB

Check 3: Medien-Logs prüfen

grep "media\\|fetch\\|download" "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | tail -20

Hoher Speicherverbrauch

OpenClaw hält Konversationsverlauf im Speicher. Fix: Regelmäßig neu starten oder Sitzungslimits setzen:

{ "session": { "historyLimit": 100 // Max. Nachrichten behalten } }

Allgemeine Fehlerbehebung

„Gateway startet nicht — Konfiguration ungültig“

OpenClaw startet nicht mehr, wenn die Config unbekannte Keys, fehlerhafte Werte oder ungültige Typen enthält. Das ist absichtlich für Sicherheit. Mit Doctor beheben:

openclaw doctor openclaw doctor --fix

Hinweise:

  • openclaw doctor meldet jeden ungültigen Eintrag.
  • openclaw doctor --fix wendet Migrationen/Reparaturen an und schreibt die Config neu.
  • Diagnose-Befehle wie openclaw logs, openclaw health, openclaw status, openclaw gateway status und openclaw gateway probe laufen auch bei ungültiger Config.

„All models failed“ — was zuerst prüfen?

  • Credentials für den/die genutzten Provider vorhanden (Auth-Profile + Env-Vars).
  • Modell-Routing: agents.defaults.model.primary und Fallbacks bestätigen, dass es Modelle sind, auf die du Zugriff hast.
  • Gateway-Logs in /tmp/openclaw/… für den genauen Provider-Fehler.
  • Modell-Status: /model status (Chat) oder openclaw models status (CLI).

Ich laufe mit meiner privaten WhatsApp-Nummer — warum ist Self-Chat komisch?

Self-Chat-Modus aktivieren und die eigene Nummer in die Allowlist aufnehmen:

{ channels: { whatsapp: { selfChatMode: true, dmPolicy: "allowlist", allowFrom: ["+15555550123"] } } }

Siehe WhatsApp-Setup.

WhatsApp hat mich ausgeloggt. Wie re-auth?

Login-Befehl erneut ausführen und QR-Code scannen:

openclaw channels login

Build-Fehler auf main — was ist der Standard-Fix-Pfad?

  1. git pull origin main && pnpm install
  2. openclaw doctor
  3. GitHub-Issues oder Discord durchsuchen
  4. Vorübergehend: älteren Commit auschecken

npm install schlägt fehl (allow-build-scripts / fehlendes tar oder yargs). Was tun?

Bei Installation aus dem Quellcode den Package-Manager des Repos nutzen: pnpm (bevorzugt). Das Repo deklariert packageManager: "pnpm@…". Typische Wiederherstellung:

git status # sicherstellen, dass du im Repo-Root bist pnpm install pnpm build openclaw doctor openclaw gateway restart

Grund: pnpm ist der konfigurierte Package-Manager für dieses Repo.

Wie wechsle ich zwischen Git- und npm-Installation?

Den Website-Installer nutzen und die Installationsmethode per Flag wählen. Er aktualisiert vor Ort und schreibt den Gateway-Service auf die neue Installation um. Wechsel zu Git-Installation:

curl -fsSL https://molt.bot/install.sh | bash -s -- --install-method git --no-onboard

Wechsel zu npm global:

curl -fsSL https://molt.bot/install.sh | bash

Hinweise:

  • Der Git-Flow rebased nur bei sauberem Repo. Änderungen vorher committen oder stashen.
  • Nach dem Wechsel ausführen:
openclaw doctor openclaw gateway restart

Telegram Block-Streaming trennt Text nicht zwischen Tool-Aufrufen. Warum?

Block-Streaming sendet nur abgeschlossene Textblöcke. Typische Gründe für eine einzige Nachricht:

  • agents.defaults.blockStreamingDefault steht noch auf "off".
  • channels.telegram.blockStreaming ist auf false gesetzt.
  • channels.telegram.streamMode ist partial oder block und Draft-Streaming ist aktiv (privater Chat + Topics). Draft-Streaming deaktiviert in dem Fall Block-Streaming.
  • Deine minChars-/Coalesce-Einstellungen sind zu hoch, Blöcke werden zusammengeführt.
  • Das Modell emittiert einen großen Textblock (keine Mid-Reply-Flush-Punkte).

Fix-Checkliste:

  1. Block-Streaming-Einstellungen unter agents.defaults setzen, nicht im Root.
  2. channels.telegram.streamMode: "off" setzen für echte Multi-Message-Block-Antworten.
  3. Kleinere Chunk-/Coalesce-Schwellen beim Debuggen nutzen.

Siehe Streaming.

Discord antwortet auf meinem Server nicht, obwohl requireMention: false. Warum?

requireMention steuert Mention-Gating nur nach dem Allowlist-Check des Kanals. Standardmäßig ist channels.discord.groupPolicy allowlist, Guilds müssen explizit aktiviert werden. Bei channels.discord.guilds.<guildId>.channels sind nur die gelisteten Kanäle erlaubt; weglassen erlaubt alle Kanäle der Guild. Fix-Checkliste:

  1. channels.discord.groupPolicy: "open" setzen oder einen Guild-Allowlist-Eintrag (und optional Kanal-Allowlist) hinzufügen.
  2. Numerische Kanal-IDs in channels.discord.guilds.<guildId>.channels nutzen.
  3. requireMention: false unter channels.discord.guilds setzen (global oder pro Kanal). Top-Level channels.discord.requireMention ist kein unterstützter Key.
  4. Sicherstellen, dass der Bot Message Content Intent und Kanalberechtigungen hat.
  5. openclaw channels status --probe für Audit-Hinweise ausführen.

Docs: Discord, Channels-Fehlerbehebung.

Cloud Code Assist API-Fehler: invalid tool schema (400). Was tun?

Fast immer ein Tool-Schema-Kompatibilitätsproblem. Der Cloud Code Assist-Endpunkt akzeptiert nur eine Teilmenge von JSON Schema. OpenClaw bereinigt/normalisiert Tool-Schemas in aktuellem main, der Fix ist aber noch nicht im letzten Release (Stand 13. Januar 2026). Fix-Checkliste:

  1. OpenClaw aktualisieren:

    • Wenn du aus dem Quellcode laufen kannst: main pullen und Gateway neu starten.
    • Sonst auf das nächste Release warten, das den Schema-Scrubber enthält.
  2. Nicht unterstützte Keywords vermeiden: anyOf/oneOf/allOf, patternProperties, additionalProperties, minLength, maxLength, format usw.

  3. Bei eigenen Tools: Top-Level-Schema als type: "object" mit properties und einfachen Enums halten.

Siehe Tools und TypeBox-Schemas.

macOS-spezifische Probleme

App stürzt beim Erteilen von Berechtigungen (Sprache/Mikro) ab

Die App verschwindet oder zeigt „Abort trap 6“, wenn du bei einer Privacy-Abfrage auf „Erlauben“ klickst. Fix 1: TCC-Cache zurücksetzen

tccutil reset All bot.molt.mac.debug

Fix 2: Neue Bundle-ID erzwingen
Wenn Zurücksetzen nicht hilft, BUNDLE_ID in scripts/package-mac-app.sh ändern (z. B. Suffix .test), dann neu bauen. macOS behandelt die App dann als neue App.

Gateway hängt bei „Starting…“

Die App verbindet sich mit einem lokalen Gateway auf Port 18789. Wenn es hängen bleibt: Fix 1: Supervisor stoppen (bevorzugt)
Wenn das Gateway von launchd überwacht wird, bringt das Töten der PID nur einen Neustart. Zuerst den Supervisor stoppen:

openclaw gateway status openclaw gateway stop # Oder: launchctl bootout gui/$UID/bot.molt.gateway (ersetze durch bot.molt.<profile>; Legacy com.clawdbot.* funktioniert noch)

Fix 2: Port belegt (Listener finden)

lsof -nP -iTCP:18789 -sTCP:LISTEN

Bei unüberwachtem Prozess zuerst graceful stop, dann eskalieren:

kill -TERM <PID> sleep 1 kill -9 <PID> # letztes Mittel

Fix 3: CLI-Installation prüfen
Sicherstellen, dass die globale openclaw-CLI installiert ist und zur App-Version passt:

openclaw --version npm install -g openclaw@<version>

Debug-Modus

Ausführliches Logging aktivieren:

# Trace-Logging in der Config aktivieren: # ${CLAWDBOT_CONFIG_PATH:-$HOME/.clawdbot/openclaw.json} -> { logging: { level: "trace" } } # # Dann verbose-Befehle ausführen, um Debug-Ausgabe nach stdout zu spiegeln: openclaw gateway --verbose openclaw channels login --verbose

Log-Speicherorte

LogSpeicherort
Gateway-Datei-Logs (strukturiert)/tmp/openclaw/openclaw-YYYY-MM-DD.log (oder logging.file)
Gateway-Service-Logs (Supervisor)macOS: $CLAWDBOT_STATE_DIR/logs/gateway.log + gateway.err.log (Standard: ~/.clawdbot/logs/...; Profile: ~/.clawdbot-<profile>/logs/...). Linux: journalctl --user -u openclaw-gateway[-<profile>].service -n 200 --no-pager. Windows: schtasks /Query /TN "OpenClaw Gateway (<profile>)" /V /FO LIST
Sitzungsdateien$CLAWDBOT_STATE_DIR/agents/<agentId>/sessions/
Media-Cache$CLAWDBOT_STATE_DIR/media/
Credentials$CLAWDBOT_STATE_DIR/credentials/

Health-Check

# Supervisor + Probe-Ziel + Config-Pfade openclaw gateway status # Inkl. System-Scans (Legacy/Extra-Services, Port-Listener) openclaw gateway status --deep # Ist das Gateway erreichbar? openclaw health --json # Bei Fehlschlag mit Verbindungsdetails erneut ausführen: openclaw health --verbose # Lauscht etwas auf dem Standard-Port? lsof -nP -iTCP:18789 -sTCP:LISTEN # Kürzliche Aktivität (RPC-Log-Tail) openclaw logs --follow # Fallback wenn RPC down tail -20 /tmp/openclaw/openclaw-*.log

Alles zurücksetzen

Radikale Option:

openclaw gateway stop # Bei sauberer Neuinstallation: # openclaw gateway uninstall trash "${CLAWDBOT_STATE_DIR:-$HOME/.clawdbot}" openclaw channels login # WhatsApp erneut pairen openclaw gateway restart # oder: openclaw gateway

⚠️ Dabei gehen alle Sitzungen verloren und WhatsApp muss erneut gepairt werden.

Hilfe holen

  1. Zuerst Logs prüfen: /tmp/openclaw/ (Standard: openclaw-YYYY-MM-DD.log, oder deine logging.file)
  2. Bestehende Issues auf GitHub durchsuchen
  3. Neues Issue mit:
    • OpenClaw-Version
    • Relevanten Log-Ausschnitten
    • Schritten zur Reproduktion
    • Deiner Config (Secrets redigieren!)

„Hast du schon aus- und wieder eingeschaltet?“ — Jede IT-Person irgendwann 🦞🔧

Browser startet nicht (Linux)

Bei "Failed to start Chrome CDP on port 18800": Wahrscheinlichste Ursache: Snap-gepacktes Chromium unter Ubuntu. Schneller Fix: Google Chrome stattdessen installieren:

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo dpkg -i google-chrome-stable_current_amd64.deb

Dann in der Config setzen:

{ "browser": { "executablePath": "/usr/bin/google-chrome-stable" } }

Vollständige Anleitung: Siehe browser-linux-troubleshooting

Zuletzt aktualisiert am: