Fehlerbehebung

​

Befehlsabfolge

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

• openclaw gateway status zeigt Runtime: running, Connectivity probe: ok und eine Capability: ...-Zeile.
• openclaw doctor meldet keine blockierenden Konfigurations- oder Dienstprobleme.
• openclaw channels status --probe zeigt den aktuellen Transportstatus pro Konto und, sofern unterstützt, works oder audit ok.

​

Nach einem Update

openclaw status --all
openclaw update status --json
openclaw gateway status --deep
openclaw doctor --fix
openclaw gateway restart

• Update restart in openclaw status / openclaw status --all. Ausstehende oder fehlgeschlagene Übergaben enthalten den als Nächstes auszuführenden Befehl.
• plugin load failed: dependency tree corrupted; run openclaw doctor --fix unter „Kanäle“: Die Kanalkonfiguration ist noch vorhanden, aber die Plugin-Registrierung ist fehlgeschlagen, bevor der Kanal geladen werden konnte.
• Provider-401-Fehler nach erneuter Authentifizierung: openclaw doctor --fix sucht nach veralteten agentenspezifischen OAuth-Authentifizierungsschatten und entfernt alte Kopien, damit alle Agenten das aktuelle gemeinsame Profil auflösen.

​

Uneinheitliche Installationen und Schutz vor neuerer Konfiguration

which openclaw
openclaw --version
openclaw gateway status --deep
openclaw config get meta.lastTouchedVersion

openclaw gateway install --force
openclaw gateway restart

​

Protokollabweichung nach einem Rollback

openclaw --version
which -a openclaw
openclaw gateway status --deep
openclaw doctor --deep
openclaw logs --follow

• protocol mismatch ... client=... v<version> min=<n> max=<n> expected=<n> in den Gateway-Protokollen.
• Established clients: in openclaw gateway status --deep oder Gateway clients in openclaw doctor --deep: aktive TCP-Clients, die mit dem Gateway-Port verbunden sind, einschließlich PIDs und Befehlszeilen, sofern das Betriebssystem dies zulässt.
• Ein Clientprozess, dessen Befehlszeile auf die neuere OpenClaw-Installation oder den Wrapper verweist, von dem das Rollback durchgeführt wurde.

1. Beenden Sie den von gateway status --deep angezeigten veralteten OpenClaw-Clientprozess oder starten Sie ihn neu.
2. Starten Sie Apps oder Wrapper neu, die OpenClaw einbetten: lokale Dashboards, Editoren, App-Server-Hilfsprogramme oder langlebige openclaw logs --follow-Shells.
3. Führen Sie openclaw gateway status --deep oder openclaw doctor --deep erneut aus und vergewissern Sie sich, dass die PID des veralteten Clients nicht mehr vorhanden ist.

​

Skill-Symlink wegen Pfadüberschreitung übersprungen

Übersprungener Skill-Pfad außerhalb seines konfigurierten Stammverzeichnisses: ... reason=symlink-escape

ls -l ~/.agents/skills/<name>
realpath ~/.agents/skills/<name>
openclaw config get skills.load

{
  skills: {
    load: {
      extraDirs: ["~/Projects/manager/skills"],
      allowSymlinkTargets: ["~/Projects/manager/skills"],
    },
  },
}

• Skills-Konfiguration
• Konfigurationsbeispiele

​

Für Anthropic 429 ist bei langem Kontext zusätzliche Nutzung erforderlich

openclaw logs --follow
openclaw models status
openclaw config get agents.defaults.models

• Das ausgewählte Anthropic-Modell ist ein allgemein verfügbares Claude-4.x-Modell mit 1M-Unterstützung (Opus 4.6/4.7/4.8, Sonnet 4.6), oder die Modellkonfiguration enthält noch das veraltete params.context1m: true.
• Die aktuellen Anthropic-Anmeldedaten sind nicht für die Nutzung langer Kontexte berechtigt.
• Anfragen schlagen nur bei langen Sitzungen oder Modellläufen fehl, die den 1M-Kontextpfad benötigen.

• Anthropic
• Token-Nutzung und Kosten
• Warum erhalte ich HTTP 429 von Anthropic?

​

Blockierte 403-Antworten von Upstream-Diensten

openclaw status
openclaw gateway status
openclaw logs --follow

• Mehrere Modelle desselben Providers schlagen auf dieselbe Weise fehl.
• HTML oder generischer Sicherheitstext anstelle eines normalen Provider-API-Fehlers.
• Providerseitige Sicherheitsereignisse zum selben Anfragezeitpunkt.
• Eine sehr kleine direkte curl-Prüfung ist erfolgreich, während normale SDK-förmige Anfragen fehlschlagen.

• OpenAI-kompatible Endpunkte
• Provider-Konfiguration
• Protokolle

​

Lokales OpenAI-kompatibles Backend besteht direkte Prüfungen, aber Agentenläufe schlagen fehl

• curl ... /v1/models funktioniert.
• Sehr kleine direkte /v1/chat/completions-Aufrufe funktionieren.
• OpenClaw-Modellläufe schlagen nur bei normalen Agentenzügen fehl.

curl http://127.0.0.1:1234/v1/models
curl http://127.0.0.1:1234/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"<id>","messages":[{"role":"user","content":"hi"}],"stream":false}'
openclaw infer model run --model <provider/model> --prompt "hi" --json
openclaw logs --follow

• Kleine direkte Aufrufe sind erfolgreich, OpenClaw-Läufe schlagen jedoch nur bei größeren Prompts fehl.
• model_not_found- oder 404-Fehler, obwohl direktes /v1/chat/completions mit derselben unveränderten Modell-ID funktioniert.
• Backend-Fehler, laut denen messages[].content eine Zeichenfolge erwartet.
• Zeitweilige incomplete turn detected ... stopReason=stop payloads=0-Warnungen bei einem OpenAI-kompatiblen lokalen Backend.
• Backend-Abstürze, die nur bei einer größeren Anzahl von Prompt-Tokens oder vollständigen Prompts der Agentenlaufzeit auftreten.

• Konfiguration
• Lokale Modelle
• OpenAI-kompatible Endpunkte

​

Keine Antworten

openclaw status
openclaw channels status --probe
openclaw pairing list --channel <channel> [--account <id>]
openclaw config get channels
openclaw logs --follow

• Ausstehendes Pairing für DM-Absender.
• Erwähnungssperre in Gruppen (requireMention, mentionPatterns).
• Nicht übereinstimmende Kanal-/Gruppen-Zulassungslisten.

• drop guild message (mention required → Gruppennachricht wird bis zu einer Erwähnung ignoriert.
• pairing request → Absender benötigt eine Genehmigung.
• blocked / allowlist → Absender/Kanal wurde durch eine Richtlinie herausgefiltert.

• Fehlerbehebung für Kanäle
• Gruppen
• Pairing

​

Konnektivität der Dashboard-Steuerungsoberfläche

openclaw gateway status
openclaw status
openclaw logs --follow
openclaw doctor
openclaw gateway status --json

• Korrekte Prüf-URL und Dashboard-URL.
• Nicht übereinstimmender Authentifizierungsmodus bzw. Token zwischen Client und Gateway.
• Verwendung von HTTP, obwohl eine Geräteidentität erforderlich ist.

openclaw gateway restart
lsof -i :18789
curl http://127.0.0.1:18789

​

Schnellübersicht der Authentifizierungsdetailcodes

openclaw --version
openclaw doctor
openclaw gateway status

• Sitzungen mit Token gekoppelter Geräte können nur ihr eigenes Gerät verwalten, sofern der Aufrufer nicht zusätzlich über operator.admin verfügt.
• openclaw devices rotate --scope ... kann nur Operator-Scopes anfordern, über die die Aufrufersitzung bereits verfügt.

• Konfiguration (Gateway-Authentifizierungsmodi)
• Steuerungsoberfläche
• Geräte
• Remotezugriff
• Authentifizierung über vertrauenswürdigen Proxy

​

Gateway-Dienst wird nicht ausgeführt

openclaw gateway status
openclaw status
openclaw logs --follow
openclaw doctor
openclaw gateway status --deep   # auch Dienste auf Systemebene prüfen

• Runtime: stopped mit Hinweisen zum Beenden.
• Nicht übereinstimmende Dienstkonfiguration (Config (cli) gegenüber Config (service)).
• Port-/Listener-Konflikte.
• Zusätzliche launchd-/systemd-/schtasks-Installationen bei Verwendung von --deep.
• Other gateway-like services detected (best effort)-Bereinigungshinweise.

• Hintergrundausführung und Prozesswerkzeug
• Konfiguration
• Doctor

​

Das macOS-Gateway reagiert ohne Meldung nicht mehr und setzt den Betrieb fort, sobald Sie das Dashboard verwenden

ls ~/.openclaw/logs/stability/ | tail -5
openclaw gateway stability --bundle latest
pmset -g log | grep -iE "sleep|wake|maintenance" | tail -50
launchctl print gui/$UID/ai.openclaw.gateway | grep -E "state|last exit|runs"

• Ein oder mehrere *-uncaught_exception.json-Bundles in ~/.openclaw/logs/stability/, bei denen error.code auf einen vorübergehenden Netzwerkcode wie ENETDOWN, ENETUNREACH, EHOSTUNREACH oder ECONNREFUSED gesetzt ist.
• pmset -g log-Zeilen wie Entering Sleep state due to 'Maintenance Sleep' oder en0 driver is slow (msg: WillChangeState to 0), die zeitlich mit den Abstürzen übereinstimmen. Power Nap / Maintenance Sleep versetzt den WLAN-Treiber kurzzeitig in Zustand 0; jeder ausgehende connect(), der in dieses Zeitfenster fällt, kann mit ENETDOWN fehlschlagen, selbst wenn der Host ansonsten über vollständige Netzwerkkonnektivität verfügt.
• launchctl print-Ausgabe, die state = not running mit mehreren kürzlichen runs und einem Exit-Code zeigt, insbesondere wenn zwischen dem Absturz und dem nächsten Start etwa eine Stunde statt nur wenige Sekunden liegt. macOS launchd wendet nach einer Serie von Abstürzen eine undokumentierte Schutzsperre für Neustarts an, durch die KeepAlive=true möglicherweise nicht mehr berücksichtigt wird, bis ein externer Auslöser wie eine interaktive Anmeldung, eine Dashboard-Verbindung oder launchctl kickstart die Sperre wieder aktiviert.

• Ein Stabilitäts-Bundle, dessen error.code den Wert ENETDOWN oder einen verwandten Code enthält und dessen Aufrufstapel auf Node net lookupAndConnect / Socket.connect verweist. OpenClaw 2026.5.26 und neuere Versionen klassifizieren diese als harmlose vorübergehende Netzwerkfehler, sodass sie nicht mehr bis zum obersten Handler für nicht abgefangene Fehler weitergegeben werden. Wenn Sie eine ältere Version verwenden, führen Sie zuerst ein Upgrade durch.
• Lange Ruhephasen, die in dem Moment enden, in dem Sie eine Verbindung zur Control UI herstellen oder sich per SSH am Host anmelden: Die für Benutzer sichtbare Aktivität reaktiviert die Neustartsperre von launchd, nicht eine Aktion des Dashboards am Gateway.
• Der Zähler runs steigt im Laufe des Tages, ohne dass eine entsprechende received SIG*; shutting down-Zeile in ~/Library/Logs/openclaw/gateway.log vorhanden ist: Bei ordnungsgemäßem Herunterfahren wird ein Signal protokolliert, bei vorübergehenden Abstürzen nicht.

1. Führen Sie ein Upgrade des Gateways durch, wenn Sie eine Version vor 2026.5.26 verwenden. Nach dem Upgrade werden zukünftige ENETDOWN-Fehler als Warnungen protokolliert, statt den Prozess zu beenden.
2. Reduzieren Sie die Aktivität des Wartungsruhezustands auf Mac-mini-/Desktop-Hosts, die als dauerhaft verfügbare Server betrieben werden sollen:
   sudo pmset -a sleep 0 disksleep 0 standby 0 powernap 0
   
   Dadurch wird die zugrunde liegende Treiberunterbrechung deutlich reduziert, jedoch nicht vollständig beseitigt. Unabhängig von diesen Flags kann das System weiterhin einige Wartungsruhezustände für TCP-Keepalive und die mDNS-Wartung ausführen.
3. Fügen Sie einen Verfügbarkeits-Watchdog hinzu, damit eine zukünftige Absturzserie, die von launchd angehalten wird, schnell erkannt wird:
   # Beispiel für eine launchd-fähige Verfügbarkeitsprüfung, geeignet für einen 5-minütigen Cron oder LaunchAgent
   state=$(launchctl print gui/$UID/ai.openclaw.gateway 2>/dev/null | awk -F'= ' '/state =/ {print $2; exit}')
   if [ "$state" != "running" ]; then
     launchctl kickstart -k gui/$UID/ai.openclaw.gateway
   fi
   
   Ziel ist es, die Neustartsperre extern zu reaktivieren. KeepAlive=true allein reicht unter macOS nach einer Absturzserie nicht aus.

• Hinweise zur macOS-Plattform
• Protokollierung
• Doctor

​

macOS-launchd-Supervisorschleife mit doppelten Gateway-/Node-LaunchAgents

for i in 1 2 3 4; do
  ps aux | grep 'openclaw.*index.js' | grep -v grep | awk '{print $2}'
  sleep 10
done

openclaw gateway status --deep
openclaw node status
launchctl print gui/$UID/ai.openclaw.gateway | grep -E 'state|last exit|runs'
tail -n 80 ~/Library/Logs/openclaw/gateway.log

• Mehr als eine Gateway-PID während der 30-sekündigen Stichprobe statt eines stabilen Prozesses.
• EADDRINUSE, another gateway instance is already listening oder wiederholte Neustart-/Übergabezeilen in gateway.log.
• Sowohl ~/Library/LaunchAgents/ai.openclaw.gateway.plist als auch ~/Library/LaunchAgents/ai.openclaw.node.plist sind gleichzeitig auf einem Host geladen, auf dem nur ein verwalteter Gateway-Dienst ausgeführt werden sollte.

1. Wenn auf diesem Host nur der Gateway-Dienst ausgeführt werden soll, entfernen Sie den verwalteten Node- Dienst über OpenClaw. Überspringen Sie diesen Schritt, wenn Sie den Node- Dienst aktiv für Remote-Node-Funktionen verwenden. Durch seine Deinstallation werden diese Funktionen auf diesem Host beendet:
   openclaw node uninstall
   
2. Installieren Sie einen persistenten Gateway-Wrapper, der die geerbten launchd- Markierungen löscht, bevor OpenClaw gestartet wird. Verwenden Sie die unterstützte Option --wrapper; bearbeiten Sie nicht die generierte Datei unter ~/.openclaw/service-env/, da diese Datei bei der Neuinstallation des Dienstes, bei Updates und bei Reparaturen durch Doctor neu generiert wird:
   mkdir -p ~/.local/bin
   cat >~/.local/bin/openclaw-launchd-workaround <<'EOF'
   #!/bin/sh
   set -eu
   unset OPENCLAW_LAUNCHD_LABEL LAUNCH_JOB_LABEL LAUNCH_JOB_NAME XPC_SERVICE_NAME || true
   exec openclaw "$@"
   EOF
   chmod 700 ~/.local/bin/openclaw-launchd-workaround
   
   openclaw gateway install \
     --wrapper ~/.local/bin/openclaw-launchd-workaround \
     --force
   
   gateway install behält den Wrapper-Pfad über erzwungene Neuinstallationen, Updates und Reparaturen durch Doctor hinweg bei.
3. Überprüfen Sie, ob der Gateway stabil ist und RPC bereitstellt, statt lediglich auf Verbindungen zu warten:
   openclaw gateway status --deep --require-rpc
   
   for i in 1 2 3 4; do
     ps aux | grep 'openclaw.*index.js' | grep -v grep | awk '{print $2}'
     sleep 10
   done
   
   Die PID-Stichprobe sollte einen einzelnen stabilen Prozess statt einer wechselnden Gruppe von PIDs zeigen, und die eingehende Kanalauslieferung sollte fortgesetzt werden.
4. Entfernen Sie nach dem Upgrade auf eine Version, in der die zugrunde liegende Schleife aus zwei LaunchAgents behoben ist, die Problemumgehung und installieren Sie den normalen verwalteten Dienst erneut:
   OPENCLAW_WRAPPER= openclaw gateway install --force
   rm ~/.local/bin/openclaw-launchd-workaround
   

• Hinweise zur macOS-Plattform
• Doctor
• Gateway-CLI

​

Gateway wird bei hoher Speicherauslastung beendet

openclaw gateway status --deep
openclaw logs --follow
openclaw gateway stability --bundle latest
openclaw gateway diagnostics export

• Reason: diagnostic.memory.pressure.critical im neuesten Stabilitäts-Bundle.
• Memory pressure: mit critical/rss_threshold, critical/heap_threshold oder critical/rss_growth.
• V8 heap:-Werte nahe am Heap-Limit.
• Largest session files:-Einträge wie agents/<agent>/sessions/<session>.jsonl oder sessions/<session>.jsonl.
• Linux-cgroup-Speicherzähler, wenn der Gateway in einem Container oder einem Dienst mit Speicherbegrenzung ausgeführt wird.

• critical memory pressure bundle written erscheint kurz vor dem Neustart → OpenClaw hat vor dem OOM ein Stabilitäts-Bundle erfasst. Untersuchen Sie es mit openclaw gateway stability --bundle latest.
• memory pressure: level=critical erscheint in den Gateway-Protokollen → OpenClaw hat kritischen Speicherdruck erkannt und die verfügbaren prozessinternen Speicherdaten aufgezeichnet.
• Largest session files: verweist auf einen sehr großen, redigierten Transkriptpfad → Reduzieren Sie den gespeicherten Sitzungsverlauf, untersuchen Sie das Sitzungswachstum oder verschieben Sie alte Transkripte aus dem aktiven Speicher, bevor Sie neu starten.
• Die von V8 heap: verwendeten Bytes liegen nahe am Heap-Limit → Reduzieren Sie zuerst den Prompt-/Sitzungsdruck oder die Anzahl gleichzeitiger Aufgaben. Prüfen Sie bei einem verwalteten Dienst Gateway heap: in openclaw gateway status. Wenn dort not set angegeben ist, generieren Sie alte Dienstmetadaten mit openclaw gateway install --force neu. NODE_OPTIONS aus der Shell-Umgebung wird absichtlich ignoriert. Verwenden Sie eine explizite Heap-Überschreibung auf Supervisor-Ebene erst, nachdem Sie die dauerhafte Arbeitslast bestätigt und ausreichend Spielraum für nativen Speicher eingeplant haben.
• Memory pressure: critical/rss_growth → Der Speicher ist innerhalb eines einzelnen Abtastintervalls schnell angewachsen. Prüfen Sie die neuesten Protokolle auf einen großen Import, unkontrollierte Tool-Ausgaben, wiederholte Wiederholungsversuche oder eine Reihe in die Warteschlange gestellter Agentenaufgaben.
• In den Protokollen erscheint kritischer Speicherdruck, aber es ist kein Bundle vorhanden → Erfassen Sie nach dem Ereignis openclaw gateway diagnostics export, um die verfügbaren Betriebsnachweise zu sichern.

• Gateway-Integrität
• Diagnoseexport
• Sitzungen

​

Gateway hat eine ungültige Konfiguration abgelehnt

openclaw logs --follow
openclaw config file
openclaw config validate
openclaw doctor

• Invalid config at ...
• config reload skipped (invalid config): ...
• Config write rejected: ...
• Eine mit einem Zeitstempel versehene openclaw.json.rejected.*-Datei neben der aktiven Konfiguration.
• Eine mit einem Zeitstempel versehene openclaw.json.clobbered.*-Datei, wenn doctor --fix eine fehlerhafte direkte Bearbeitung repariert hat.
• OpenClaw behält für jeden Konfigurationspfad die neuesten 32 .clobbered.*-Dateien bei und rotiert ältere Dateien.

CONFIG="$(openclaw config file)"
ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | head
diff -u "$CONFIG" "$(ls -t "$CONFIG".clobbered.* 2>/dev/null | head -n 1)"
openclaw config validate
openclaw doctor

• Konfiguration
• Konfiguration: Hot Reload
• Konfiguration: strikte Validierung
• Doctor

​

Warnungen bei Gateway-Prüfungen

openclaw gateway probe
openclaw gateway probe --json
openclaw gateway probe --ssh user@gateway-host

• warnings[].code und primaryTargetId in der JSON-Ausgabe.
• Ob sich die Warnung auf den SSH-Fallback, mehrere Gateways, fehlende Scopes oder nicht aufgelöste Authentifizierungsreferenzen bezieht.

• SSH tunnel failed to start; falling back to direct probes. → Die SSH-Einrichtung ist fehlgeschlagen, der Befehl hat jedoch weiterhin direkte konfigurierte bzw. Loopback-Ziele versucht.
• multiple reachable gateway identities detected → Verschiedene Gateways haben geantwortet oder OpenClaw konnte nicht nachweisen, dass es sich bei den erreichbaren Zielen um dasselbe Gateway handelt. Ein SSH-Tunnel, eine Proxy-URL oder eine konfigurierte Remote-URL zum selben Gateway wird als ein Gateway mit mehreren Transportwegen behandelt, selbst wenn sich die Transport-Ports unterscheiden.
• Read-probe diagnostics are limited by gateway scopes (missing operator.read) → Die Verbindung wurde hergestellt, aber der Detail-RPC ist durch Scopes eingeschränkt; koppeln Sie die Geräteidentität oder verwenden Sie Zugangsdaten mit operator.read.
• Gateway accepted the WebSocket connection, but follow-up read diagnostics failed → Die Verbindung wurde hergestellt, aber für den vollständigen Satz diagnostischer RPCs trat eine Zeitüberschreitung oder ein Fehler auf. Behandeln Sie dies als erreichbares Gateway mit eingeschränkter Diagnosefunktion; vergleichen Sie connect.ok und connect.rpcOk in der Ausgabe von --json.
• Capability: pairing-pending oder gateway closed (1008): pairing required → Das Gateway hat geantwortet, aber dieser Client muss weiterhin gekoppelt bzw. genehmigt werden, bevor ein normaler Bedienerzugriff möglich ist.
• Nicht aufgelöster gateway.auth.*- / gateway.remote.*-SecretRef-Warntext → Das Authentifizierungsmaterial war in diesem Befehlspfad für das fehlgeschlagene Ziel nicht verfügbar.

• Gateway
• Mehrere Gateways auf demselben Host
• Remote-Zugriff

​

Kanal verbunden, aber Nachrichten werden nicht übertragen

openclaw channels status --probe
openclaw pairing list --channel <channel> [--account <id>]
openclaw status --deep
openclaw logs --follow
openclaw config get channels

• DM-Richtlinie (pairing, allowlist, open, disabled).
• Gruppen-Zulassungsliste und Anforderungen an Erwähnungen.
• Fehlende API-Berechtigungen/Scopes des Kanals.

• mention required → Die Nachricht wurde aufgrund der Richtlinie für Gruppenerwähnungen ignoriert.
• pairing / Spuren ausstehender Genehmigungen → Der Absender ist nicht genehmigt.
• missing_scope, not_in_channel, Forbidden, 401/403 → Problem mit der Kanalauthentifizierung oder den Kanalberechtigungen.

• Fehlerbehebung für Kanäle
• Discord
• Telegram
• WhatsApp

​

Cron- und Heartbeat-Zustellung

openclaw cron status
openclaw cron list
openclaw cron runs --id <jobId> --limit 20
openclaw system heartbeat last
openclaw logs --follow

• Cron ist aktiviert und der nächste Aktivierungszeitpunkt ist vorhanden.
• Status im Verlauf der Auftragsausführungen (ok, skipped, error).
• Gründe für das Überspringen des Heartbeats (quiet-hours, requests-in-flight, cron-in-progress, lanes-busy, alerts-disabled, empty-heartbeat-file).

• Heartbeat
• Geplante Aufgaben
• Geplante Aufgaben: Fehlerbehebung

​

Node gekoppelt, Tool schlägt fehl

openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>
openclaw logs --follow
openclaw status

• Node ist mit den erwarteten Funktionen online.
• Betriebssystemberechtigungen für Kamera, Mikrofon, Standort und Bildschirm.
• Status der Ausführungsgenehmigungen und der Zulassungsliste.

• NODE_BACKGROUND_UNAVAILABLE → Die Node-App muss sich im Vordergrund befinden.
• *_PERMISSION_REQUIRED / LOCATION_PERMISSION_REQUIRED → Fehlende Betriebssystemberechtigung.
• SYSTEM_RUN_DENIED: approval required → Die Ausführungsgenehmigung steht aus.
• SYSTEM_RUN_DENIED: allowlist miss → Der Befehl wurde durch die Zulassungsliste blockiert.

• Ausführungsgenehmigungen
• Fehlerbehebung für Nodes
• Nodes

​

Browser-Tool schlägt fehl

openclaw browser status
openclaw browser start --browser-profile openclaw
openclaw browser profiles
openclaw logs --follow
openclaw doctor

• Ob plugins.allow festgelegt ist und browser enthält.
• Gültiger Pfad zur ausführbaren Browserdatei.
• Erreichbarkeit des CDP-Profils.
• Lokale Chrome-Verfügbarkeit für existing-session- / user-Profile.

• Browser (von OpenClaw verwaltet)
• Fehlerbehebung für Browser

​

Wenn nach einem Upgrade plötzlich etwas nicht mehr funktioniert

openclaw gateway status
openclaw config get gateway.mode
openclaw config get gateway.remote.url
openclaw config get gateway.auth.mode

openclaw config get gateway.bind
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw gateway status
openclaw logs --follow

openclaw devices list
openclaw pairing list --channel <channel> [--account <id>]
openclaw logs --follow
openclaw doctor

openclaw gateway install --force
openclaw gateway restart

• Authentifizierung
• Hintergrundausführung und Prozesswerkzeug
• Node-Kopplung

​

Verwandte Themen

• Doctor
• Häufig gestellte Fragen
• Gateway-Betriebshandbuch