FAQ

Festegefahren? Der schnellste Weg: Fehlerbehebung bei Laufzeitproblemen, dann hierher zurück für „Wie mache ich …“ und Konzepte. Kurze Antworten zu lokalem Dev, VPS, Multi-Agent, OAuth/API-Keys, Model-Failover. Vollständige Konfigurationsreferenz: Gateway-Konfiguration.

Inhaltsverzeichnis

Erste 60 Sekunden, wenn etwas kaputt ist

Schneller Status (erste Prüfung)


openclaw status

Kurze lokale Übersicht: OS + Update, Gateway/Service-Erreichbarkeit, Agents/Sessions, Provider-Config + Laufzeitprobleme (wenn Gateway erreichbar). 2. Teilbarer Bericht (sicher zum Teilen)


openclaw status --all

Nur-Lese-Diagnose mit Log-Auszug (Tokens zensiert). 3. Daemon + Port-Status


openclaw gateway status

Zeigt Supervisor-Laufzeit vs. RPC-Erreichbarkeit, die Prüf-URL und welche Config der Service vermutlich nutzt. 4. Tiefenprüfungen


openclaw status --deep

Führt Gateway-Health-Checks und Provider-Prüfungen aus (erfordert erreichbares Gateway). Siehe Health. 5. Neuestes Log verfolgen


openclaw logs --follow

Wenn RPC ausfällt, als Fallback:


tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Datei-Logs sind getrennt von Service-Logs; siehe Logging und Fehlerbehebung. 6. Doctor ausführen (Reparaturen)


openclaw doctor

Repariert/migriert Config/State und führt Health-Checks aus. Siehe Doctor. 7. Gateway-Snapshot


openclaw health --json
openclaw health --verbose   # shows the target URL + config path on errors

Fordert vom laufenden Gateway einen vollständigen Snapshot an (nur WebSocket). Siehe Health.

Schnellstart und Erstinstallation

Ich stecke fest – was ist der schnellste Weg raus?

Nutze einen lokalen KI-Agenten, der deine Maschine sehen kann. Das ist weit effektiver, als in Discord zu fragen, weil die meisten „Ich stecke fest“-Fälle lokale Config- oder Umgebungsprobleme sind, die entfernte Helfer nicht prüfen können.

Claude Code: https://www.anthropic.com/claude-code/
OpenAI Codex: https://openai.com/codex/

Diese Tools können das Repo lesen, Befehle ausführen, Logs prüfen und bei der Behebung deines Setups (PATH, Dienste, Berechtigungen, Auth-Dateien) helfen. Gib ihnen den vollständigen Source-Checkout über die hackbare (Git-)Installation:


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

Damit wird OpenClaw aus einem Git-Checkout installiert, sodass der Agent Code und Doku lesen und die exakte Version nachvollziehen kann. Später kannst du mit erneutem Installer-Aufruf ohne --install-method git wieder auf Stable wechseln. Tipp: Bitte den Agenten, die Lösung zu planen und zu überwachen (Schritt für Schritt), und führe nur die notwendigen Befehle aus. So bleiben Änderungen klein und besser nachvollziehbar. Bei echtem Bug oder Fix: GitHub-Issue oder PR: https://github.com/openclaw/openclaw/issues https://github.com/openclaw/openclaw/pulls . Starte mit diesen Befehlen (Ausgaben beim Fragen teilen):


openclaw status
openclaw models status
openclaw doctor

Was sie tun:

openclaw status: kurzer Überblick über Gateway-/Agent-Status und Basis-Config.
openclaw models status: prüft Provider-Auth und Modell-Verfügbarkeit.
openclaw doctor: validiert und repariert häufige Config-/State-Probleme.

Weitere nützliche CLI-Checks: openclaw status --all, openclaw logs --follow, openclaw gateway status, openclaw health --verbose.Schneller Debug-Loop: Erste 60 Sekunden, wenn etwas kaputt ist. Install-Doku: Installation, Installer-Flags, Aktualisieren.

Was ist die empfohlene Art, OpenClaw zu installieren und einzurichten

Das Repo empfiehlt, aus den Quellen zu laufen und den Onboarding-Assistenten zu nutzen:


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

Der Assistent kann UI-Assets automatisch bauen. Nach dem Onboarding läuft das Gateway typischerweise auf Port 18789. Aus den Quellen (Contributors/Dev):


git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
pnpm ui:build # auto-installs UI deps on first run
openclaw onboard

Wenn du noch keine globale Installation hast, starte es mit pnpm openclaw onboard.

Wie öffne ich das Dashboard nach dem Onboarding

Der Assistent öffnet nach dem Onboarding deinen Browser mit einer tokenisierten Dashboard-URL und gibt den vollständigen Link (mit Token) in der Zusammenfassung aus. Lass den Tab offen; wenn er nicht gestartet ist, kopiere die ausgegebene URL auf derselben Maschine. Tokens bleiben lokal auf deinem Host – es wird nichts aus dem Browser abgerufen.

Wie authentifiziere ich das Dashboard (Token) auf Localhost vs. Remote

Localhost (gleiche Maschine):

Öffne http://127.0.0.1:18789/.
Wenn nach Auth gefragt wird, führe openclaw dashboard aus und nutze den tokenisierten Link (?token=...).
Der Token entspricht gateway.auth.token (bzw. CLAWDBOT_GATEWAY_TOKEN) und wird von der UI nach dem ersten Laden gespeichert.

Nicht auf Localhost:

Tailscale Serve (empfohlen): Bind auf Loopback belassen, openclaw gateway --tailscale serve ausführen, https://<magicdns>/ öffnen. Wenn gateway.auth.allowTailscale true ist, erfüllen Identity-Header die Auth (kein Token).
Tailnet-Bind: openclaw gateway --bind tailnet --token "<token>" ausführen, http://<tailscale-ip>:18789/ öffnen, Token in den Dashboard-Einstellungen einfügen.
SSH-Tunnel: ssh -N -L 18789:127.0.0.1:18789 user@host, dann http://127.0.0.1:18789/?token=... aus openclaw dashboard öffnen.

Siehe Dashboard und Web-Oberflächen für Bind-Modi und Auth-Details.

Welche Laufzeit brauche ich

Node >= 22 ist erforderlich. pnpm wird empfohlen. Bun wird für das Gateway nicht empfohlen.

Läuft es auf dem Raspberry Pi

Ja. Das Gateway ist schlank – die Doku nennt 512 MB–1 GB RAM, 1 Core und etwa 500 MB Platz als ausreichend für den persönlichen Gebrauch; ein Raspberry Pi 4 kann es betreiben. Für mehr Puffer (Logs, Medien, andere Dienste) sind 2 GB empfohlen, aber kein hartes Minimum. Tipp: Ein kleiner Pi/VPS kann das Gateway hosten, und du kannst Nodes auf Laptop/Handy koppeln für lokalen Bildschirm/Kamera/Canvas oder Befehlsausführung. Siehe Nodes.

Tipps für Raspberry-Pi-Installationen

Kurzfassung: Es funktioniert, aber mit Ecken und Kanten.

Nutze ein 64-Bit-OS und halte Node >= 22.
Bevorzuge die hackbare (Git-)Installation, damit du Logs siehst und schnell aktualisieren kannst.
Starte ohne Channels/Skills und füge sie nacheinander hinzu.
Bei seltsamen Binary-Problemen steckt meist ein ARM-Kompatibilitäts-Thema dahinter.

Doku: Linux, Installation.

Es hängt bei „Wake up my friend“ / Onboarding schlüpft nicht. Was tun?

Dieser Bildschirm setzt voraus, dass das Gateway erreichbar und authentifiziert ist. Die TUI sendet beim ersten Schlüpfen automatisch „Wake up, my friend!“. Wenn du diese Zeile siehst ohne Antwort und die Tokens bei 0 bleiben, ist der Agent nie gelaufen.

Gateway neu starten:


openclaw gateway restart

Status und Auth prüfen:


openclaw status
openclaw models status
openclaw logs --follow

Wenn es weiter hängt, ausführen:


openclaw doctor

Wenn das Gateway remote ist, stelle sicher, dass Tunnel/Tailscale-Verbindung stehen und die UI auf das richtige Gateway zeigt. Siehe Remote-Zugriff.

Kann ich mein Setup auf einen neuen Rechner (z. B. Mac mini) umziehen, ohne Onboarding neu zu machen?

Ja. Kopiere das State-Verzeichnis und den Workspace, dann einmal Doctor ausführen. So bleibt dein Bot „genau derselbe“ (Speicher, Session-Verlauf, Auth, Channel-State), solange du beide Orte kopierst:

OpenClaw auf der neuen Maschine installieren.
$CLAWDBOT_STATE_DIR (Standard: ~/.clawdbot) von der alten Maschine kopieren.
Deinen Workspace kopieren (Standard: ~/clawd).
openclaw doctor ausführen und den Gateway-Service neu starten.

Damit bleiben Config, Auth-Profile, WhatsApp-Creds, Sessions und Speicher erhalten. Im Remote-Modus gehören Session-Store und Workspace dem Gateway-Host. Wichtig: Wenn du nur deinen Workspace nach GitHub commitest/pushst, sicherst du Speicher + Bootstrap-Dateien, aber nicht Session-Verlauf oder Auth. Die liegen unter ~/.clawdbot/ (z. B. ~/.clawdbot/agents/<agentId>/sessions/). Siehe: Migration, Wo OpenClaw seine Daten speichert, Agent-Workspace, Doctor, Remote-Modus.

Wo sehe ich, was in der neuesten Version neu ist?

Sieh in das GitHub-Changelog:

https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md Die neuesten Einträge stehen oben. Wenn der oberste Abschnitt Unreleased ist, ist der nächste datierte Abschnitt die zuletzt ausgelieferte Version. Einträge sind nach Highlights, Changes und Fixes gruppiert (plus Doku/andere Abschnitte bei Bedarf).

Ich kann docs.openclaw nicht aufrufen (SSL-Fehler). Was tun?

Some Comcast/Xfinity connections incorrectly block docs.molt.bot via Xfinity Advanced Security. Disable it or allowlist docs.molt.bot, then retry. More detail: Troubleshooting. Bitte melde es hier, damit wir es freischalten können: https://spa.xfinity.com/check_url_status . Wenn du die Seite weiterhin nicht erreichst, liegt die Doku gespiegelt auf GitHub: https://github.com/openclaw/openclaw/tree/main/docs

Was ist der Unterschied zwischen Stable und Beta?

Stable and beta are npm dist‑tags, not separate code lines:

latest = stable
beta = early build for testing

We ship builds to beta, test them, and once a build is solid we promote dieselbe Version nach latest. Daher können beta und stable auf die gleiche Version zeigen. Änderungen anzeigen:

https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md

Wie installiere ich die Beta-Version, und was ist der Unterschied zwischen Beta und Dev?

Beta ist der npm-Dist-Tag beta (kann mit latest übereinstimmen).

Dev ist die laufende Spitze von main (Git); bei Veröffentlichung nutzt es den npm-Dist-Tag dev. One-Liner (macOS/Linux):


curl -fsSL --proto '=https' --tlsv1.2 https://molt.bot/install.sh | bash -s -- --beta


curl -fsSL --proto '=https' --tlsv1.2 https://molt.bot/install.sh | bash -s -- --install-method git

Windows-Installer (PowerShell): https://molt.bot/install.ps1 Mehr Details: Entwicklungs-Kanäle und Installer-Flags.

Wie lange dauern Installation und Onboarding normalerweise?

Grober Richtwert:

Installation: 2–5 Minuten
Onboarding: 5–15 Minuten, je nach Anzahl konfigurierter Channels/Modelle

Wenn es hängt: Installer hängt und den schnellen Debug-Loop unter Ich stecke fest.

Wie teste ich die neuesten Bits?

Zwei Wege:

Dev-Kanal (Git-Checkout):


openclaw update --channel dev

Wechselt auf den Branch main und aktualisiert aus den Quellen.

Hackbare Installation (über die Installer-Seite):


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

Damit hast du ein lokales Repo zum Bearbeiten und Aktualisieren per Git. Für einen sauberen Klon von Hand:


git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build

Doku: Update, Entwicklungs-Kanäle, Installation.

Installer hängt – wie bekomme ich mehr Feedback?

Installer mit ausführlicher Ausgabe erneut ausführen:


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

Beta-Install mit ausführlicher Ausgabe:


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

Für eine hackbare (Git-)Installation:


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

Weitere Optionen: Installer-Flags.

Windows-Install meldet „git not found“ oder „openclaw not recognized“

Zwei häufige Windows-Probleme:1) npm error spawn git / git not found

Git for Windows installieren und git in die PATH aufnehmen.
PowerShell schließen und neu öffnen, dann den Installer erneut ausführen.

2) openclaw wird nach der Installation nicht erkannt

Der globale npm-bin-Ordner steht nicht in der PATH.
PATH prüfen:


npm config get prefix

Sicherstellen, dass <prefix>\\bin in der PATH steht (oft %AppData%\\npm).
Nach PATH-Änderung PowerShell schließen und neu öffnen.

Für die unkomplizierteste Windows-Einrichtung WSL2 statt nativer Windows-Installation nutzen. Doku: Windows (WSL).

Die Doku hat meine Frage nicht beantwortet – wie bekomme ich eine bessere Antwort?

Nutze die hackbare (Git-)Installation, damit du Quellcode und Doku lokal hast; frage dann deinen Bot (oder Claude/Codex) aus genau diesem Ordner, damit er das Repo lesen und präzise antworten kann.


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

Mehr Details: Installation und Installer-Flags.

Wie installiere ich OpenClaw unter Linux?

Kurz: Linux-Anleitung befolgen, dann den Onboarding-Assistenten ausführen.

Linux-Schnellpfad + Service-Install: Linux.
Vollständige Anleitung: Erste Schritte.
Installer + Updates: Installation & Updates.

Wie installiere ich OpenClaw auf einem VPS?

Jeder Linux-VPS funktioniert. Auf dem Server installieren, dann per SSH/Tailscale das Gateway erreichen. Anleitungen: exe.dev, Hetzner, Fly.io.

Remote-Zugriff: Gateway Remote.

Wo sind die Cloud-/VPS-Installationsanleitungen?

Wir führen einen Hosting-Hub mit den gängigen Anbietern. Einen auswählen und der Anleitung folgen:

VPS-Hosting (alle Anbieter an einem Ort)
Fly.io
Hetzner
exe.dev

So funktioniert es in der Cloud: Das Gateway läuft auf dem Server, du erreichst es vom Laptop/Handy über die Control-UI (oder Tailscale/SSH). State und Workspace liegen auf dem Server – den Host als Single Source of Truth behandeln und sichern. Du kannst Nodes (Mac/iOS/Android/headless) mit dem Cloud-Gateway koppeln für lokalen Bildschirm/Kamera/Canvas oder Befehle auf dem Laptop, während das Gateway in der Cloud bleibt. Hub: Plattformen. Remote-Zugriff: Gateway Remote. Nodes: Nodes, Nodes CLI.

Kann ich Clawd bitten, sich selbst zu aktualisieren?

Kurz: möglich, aber nicht empfohlen. Der Update-Ablauf kann das Gateway neu starten (dabei geht die aktive Session verloren), kann einen sauberen Git-Checkout erfordern und nach Bestätigung fragen. Besser: Updates als Betreiber in einer Shell ausführen. CLI nutzen:


openclaw update
openclaw update status
openclaw update --channel stable|beta|dev
openclaw update --tag <dist-tag|version>
openclaw update --no-restart

Falls du es vom Agenten automatisieren musst:


openclaw update --yes --no-restart
openclaw gateway restart

Doku: Update, Aktualisieren.

Was macht der Onboarding-Assistent konkret?

openclaw onboard ist der empfohlene Einrichtungsweg. Im lokalen Modus führt er dich durch:

Modell-/Auth-Einrichtung (Anthropic-Setup-Token für Claude-Abos empfohlen, OpenAI Codex OAuth unterstützt, API-Keys optional, LM Studio lokale Modelle unterstützt)
Workspace-Pfad + Bootstrap-Dateien
Gateway-Einstellungen (Bind/Port/Auth/Tailscale)
Provider (WhatsApp, Telegram, Discord, Mattermost (Plugin), Signal, iMessage)
Daemon-Install (LaunchAgent unter macOS; systemd-Benutzer-Unit unter Linux/WSL2)
Health-Checks und Skills-Auswahl

Es warnt auch, wenn das konfigurierte Modell unbekannt ist oder Auth fehlt.

Brauche ich ein Claude- oder OpenAI-Abo, um das zu betreiben?

Nein. Du kannst OpenClaw mit API-Keys (Anthropic/OpenAI/andere) oder mit nur lokalen Modellen betreiben, damit deine Daten auf dem Gerät bleiben. Abos (Claude Pro/Max oder OpenAI Codex) sind optionale Wege, diese Provider zu authentifizieren. Doku: Anthropic, OpenAI, Lokale Modelle, Modelle.

Kann ich Claude Max ohne API-Key nutzen?

Ja. Du kannst dich mit einem Setup-Token statt eines API-Keys authentifizieren. Das ist der Abo-Weg. Claude-Pro-/Max-Abos enthalten keinen API-Key; für Abo-Konten ist das der richtige Weg. Wichtig: Du musst bei Anthropic prüfen, ob diese Nutzung laut Abo und AGB erlaubt ist. Für den explizitesten, unterstützten Weg einen Anthropic-API-Key verwenden.

Wie funktioniert die Anthropic-Setup-Token-Authentifizierung?

claude setup-token erzeugt einen Token-String über die Claude-Code-CLI (nicht in der Web-Konsole). Du kannst es auf beliebigen Rechnern ausführen. Im Assistenten Anthropic token (paste setup-token) wählen oder mit openclaw models auth paste-token --provider anthropic einfügen. Der Token wird als Auth-Profil für den anthropic-Provider gespeichert und wie ein API-Key verwendet (kein Auto-Refresh). Mehr: OAuth.

Wo finde ich einen Anthropic-Setup-Token?

Er steht nicht in der Anthropic-Konsole. Der Setup-Token wird von der Claude-Code-CLI auf beliebigen Rechnern erzeugt:


claude setup-token

Den ausgegebenen Token kopieren, dann im Assistenten Anthropic token (paste setup-token) wählen. Auf dem Gateway-Host: openclaw models auth setup-token --provider anthropic. Wenn du claude setup-token woanders ausgeführt hast, auf dem Gateway-Host mit openclaw models auth paste-token --provider anthropic einfügen. Siehe Anthropic.

Wird Claude-Abo-Auth (Claude Code OAuth) unterstützt?

Ja – über Setup-Token. OpenClaw nutzt keine Claude-Code-CLI-OAuth-Tokens mehr; Setup-Token oder Anthropic-API-Key verwenden. Token beliebig erzeugen und auf dem Gateway-Host einfügen. Siehe Anthropic und OAuth. Hinweis: Der Zugriff per Claude-Abo unterliegt den Anthropic-AGB. Für Produktion oder Multi-User sind API-Keys meist die sicherere Wahl.

Warum sehe ich „HTTP 429: rate_limit_error“ von Anthropic?

Das bedeutet, dein Anthropic-Kontingent/Rate-Limit ist für das aktuelle Fenster aufgebraucht. Bei Claude-Abo (Setup-Token oder Claude-Code-OAuth): warten, bis das Fenster zurückgesetzt wird, oder Plan upgraden. Bei Anthropic-API-Key: in der Anthropic-Konsole Nutzung/Abrechnung prüfen und Limits anheben. Tipp: Ein Fallback-Modell setzen, damit OpenClaw weiter antworten kann, wenn ein Provider rate-limited ist. Siehe Modelle und OAuth.

Wird AWS Bedrock unterstützt?

Ja – über den Amazon Bedrock (Converse)-Provider von pi ai mit manueller Config. AWS-Credentials/Region auf dem Gateway-Host bereitstellen und einen Bedrock-Provider-Eintrag in der Modell-Config hinzufügen. Siehe Amazon Bedrock und Modellanbieter. Bei bevorzugtem Managed-Key-Flow ist ein OpenAI-kompatibler Proxy vor Bedrock weiterhin eine gültige Option.

Wie funktioniert Codex-Auth?

OpenClaw unterstützt OpenAI Code (Codex) per OAuth (ChatGPT-Anmeldung). Der Assistent kann den OAuth-Flow ausführen und setzt bei Bedarf das Standardmodell auf openai-codex/gpt-5.2. Siehe Modell-Provider und Assistent.

Wird OpenAI-Abo-Auth (Codex OAuth) unterstützt?

Ja. OpenClaw unterstützt OpenAI Code (Codex) Abo-OAuth vollständig. Der Onboarding-Assistent kann den OAuth-Flow für dich ausführen. Siehe OAuth, Modell-Provider und Assistent.

Wie richte ich Gemini-CLI-OAuth ein?

Gemini CLI nutzt einen Plugin-Auth-Flow, keine Client-ID oder Secret in openclaw.json. Schritte:

Plugin aktivieren: openclaw plugins enable google-gemini-cli-auth
Anmelden: openclaw models auth login --provider google-gemini-cli --set-default

Damit werden OAuth-Tokens in Auth-Profilen auf dem Gateway-Host gespeichert. Details: Modell-Provider.

Ist ein lokales Modell für lockere Chats OK?

In der Regel nein. OpenClaw braucht großen Kontext und starke Safety; kleine Karten kürzen ab und lecken. Wenn unbedingt nötig: die größte MiniMax-M2.1-Build lokal laufen lassen (LM Studio), siehe Lokale Modelle. Kleinere/quantisierte Modelle erhöhen das Prompt-Injection-Risiko – siehe Sicherheit.

Wie halte ich Hosted-Model-Traffic in einer bestimmten Region?

Region-feste Endpoints wählen. OpenRouter bietet US-gehostete Optionen für MiniMax, Kimi und GLM; die US-Variante wählen, damit Daten in der Region bleiben. Anthropic/OpenAI weiterhin daneben listen mit models.mode: "merge", damit Fallbacks verfügbar bleiben und der gewählte Regional-Provider respektiert wird.

Muss ich einen Mac Mini kaufen, um das zu installieren?

Nein. OpenClaw läuft unter macOS oder Linux (Windows über WSL2). Ein Mac mini ist optional – manche nutzen ihn als Dauerläufer, ein kleiner VPS, Heimserver oder Raspberry-Pi-Klasse reicht aber auch. Einen Mac brauchst du nur für reine macOS-Tools. Für iMessage kannst du das Gateway unter Linux betreiben und imsg auf einem beliebigen Mac per SSH ausführen, indem du channels.imessage.cliPath auf einen SSH-Wrapper zeigst. Für andere reine macOS-Tools: Gateway auf einem Mac betreiben oder einen macOS-Node koppeln. Doku: iMessage, Nodes, Mac Remote-Modus.

Brauche ich einen Mac mini für iMessage-Support?

You need some macOS device signed into Messages. It does not have to be a Mac mini - any Mac works. OpenClaw’s iMessage integrations run on macOS (BlueBubbles or imsg), while the Gateway can run elsewhere.Common setups:

Gateway unter Linux/VPS, channels.imessage.cliPath auf einen SSH-Wrapper zeigen, der imsg auf dem Mac ausführt.
Alles auf dem Mac laufen lassen für die einfachste Single-Machine-Einrichtung.

Doku: iMessage, BlueBubbles, Mac Remote-Modus.

Wenn ich einen Mac mini für OpenClaw kaufe – kann ich ihn mit meinem MacBook Pro verbinden?

Ja. Der Mac mini kann das Gateway betreiben, und dein MacBook Pro kann sich als Node (Begleitgerät) verbinden. Nodes betreiben kein Gateway – sie bieten zusätzliche Funktionen wie Bildschirm/Kamera/Canvas und system.run auf dem Gerät. Übliches Muster:

Gateway auf dem Mac mini (Dauerbetrieb).
MacBook Pro läuft mit der macOS-App oder als Node-Host und koppelt mit dem Gateway.
openclaw nodes status / openclaw nodes list zum Anzeigen nutzen.

Doku: Nodes, Nodes CLI.

Kann ich Bun verwenden?

Bun wird nicht empfohlen. Es gibt Laufzeit-Bugs, besonders mit WhatsApp und Telegram. Für stabile Gateways Node verwenden. Wenn du trotzdem mit Bun experimentieren willst, nur auf einem Nicht-Produktions-Gateway ohne WhatsApp/Telegram.

Telegram: Was gehört in allowFrom?

channels.telegram.allowFrom is the human sender’s Telegram user ID (numeric, recommended) or @username. It is not the bot username.Safer (no third-party bot):

Deinem Bot eine DM schicken, dann openclaw logs --follow ausführen und from.id auslesen.

Offizielle Bot-API:

Deinem Bot eine DM schicken, dann https://api.telegram.org/bot<bot_token>/getUpdates aufrufen und message.from.id auslesen.

Drittanbieter (weniger privat):

DM @userinfobot or @getidsbot.

Siehe Telegram.

Können mehrere Personen eine WhatsApp-Nummer mit verschiedenen OpenClaws nutzen?

Ja, über Multi-Agent-Routing. Jedem Absender seine WhatsApp-DM zuordnen (Peer kind: "dm", Sender E.164 z. B. +15551234567) an eine andere agentId binden, damit jede Person eigenen Workspace und Session-Store hat. Antworten kommen weiter vom gleichen WhatsApp-Konto; die DM-Zugriffskontrolle (channels.whatsapp.dmPolicy / channels.whatsapp.allowFrom) ist pro WhatsApp-Konto global. Siehe Multi-Agent-Routing und WhatsApp.

Kann ich einen „Schnell-Chat“-Agenten und einen „Opus für Coding“-Agenten betreiben?

Ja. Multi-Agent-Routing nutzen: jedem Agenten ein eigenes Standardmodell geben, dann eingehende Routen (Provider-Account oder konkrete Peers) den Agenten zuordnen. Beispiel-Config in Multi-Agent-Routing. Siehe auch Modelle und Konfiguration.

Funktioniert Homebrew unter Linux?

Ja. Homebrew unterstützt Linux (Linuxbrew). Schnelle Einrichtung:


/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
brew install <formula>

Wenn OpenClaw über systemd läuft, muss die Service-PATH /home/linuxbrew/.linuxbrew/bin (oder dein Brew-Prefix) enthalten, damit mit brew installierte Tools in Non-Login-Shells gefunden werden. Neuere Builds hängen unter Linux bei systemd-Services außerdem gängige User-Bin-Verzeichnisse voran (z. B. ~/.local/bin, ~/.npm-global/bin, ~/.local/share/pnpm, ~/.bun/bin) und berücksichtigen PNPM_HOME, NPM_CONFIG_PREFIX, BUN_INSTALL, VOLTA_HOME, ASDF_DATA_DIR, NVM_DIR und FNM_DIR, wenn gesetzt.

Was ist der Unterschied zwischen Hackable-(Git)-Install und npm-Install?

Hackable (git) install: full source checkout, editable, best for contributors. You run builds locally and can patch code/docs.
npm install: globale CLI-Installation, kein Repo, am besten für „einfach laufen lassen“. Updates kommen über npm-Dist-Tags.

Doku: Erste Schritte, Aktualisieren.

Kann ich später zwischen npm- und Git-Install wechseln?

Ja. Die andere Variante installieren, dann Doctor ausführen, damit der Gateway-Service auf den neuen Einstiegspunkt zeigt. Das löscht deine Daten nicht – es ändert nur die OpenClaw-Code-Installation. Dein State (~/.clawdbot) und Workspace (~/clawd) bleiben unberührt. Von npm → Git:


git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
openclaw doctor
openclaw gateway restart

Von Git → npm:


npm install -g openclaw@latest
openclaw doctor
openclaw gateway restart

Doctor erkennt eine Abweichung beim Gateway-Service-Einstiegspunkt und bietet an, die Service-Config anzupassen (bei Automatisierung --repair nutzen). Backup-Tipps: siehe Backup-Strategie.

Soll ich das Gateway auf dem Laptop oder auf einem VPS betreiben?

Kurz: für 24/7-Zuverlässigkeit einen VPS nutzen. Für geringste Reibung und wenn Schlaf/Neustarts okay sind, lokal laufen lassen. Laptop (lokales Gateway)

Vorteile: keine Serverkosten, direkter Zugriff auf lokale Dateien, sichtbares Browser-Fenster.
Nachteile: Schlaf/Netzausfall = Trennung, OS-Updates/Neustarts unterbrechen, Rechner muss wach bleiben.

VPS / Cloud

Vorteile: immer an, stabiles Netz, keine Laptop-Schlaf-Probleme, einfacher Dauerbetrieb.
Nachteile: oft headless (Screenshots nutzen), nur Remote-Dateizugriff, Updates per SSH.

OpenClaw-Hinweis: WhatsApp/Telegram/Slack/Mattermost (Plugin)/Discord laufen gut vom VPS. Der eigentliche Kompromiss ist Headless-Browser vs. sichtbares Fenster. Siehe Browser. Empfohlen: VPS, wenn du zuvor Gateway-Trennungen hattest. Lokal gut, wenn du den Mac aktiv nutzt und lokalen Dateizugriff oder UI-Automatisierung mit sichtbarem Browser willst.

Wie wichtig ist es, OpenClaw auf einer dedizierten Maschine zu betreiben?

Nicht zwingend, aber für Zuverlässigkeit und Isolation empfohlen.

Dedizierter Host (VPS/Mac mini/Pi): Dauerbetrieb, weniger Schlaf/Neustart-Unterbrechungen, klarere Rechte, einfacher am Laufen zu halten.
Gemeinsamer Laptop/Desktop: völlig in Ordnung zum Testen und aktiven Nutzen, aber mit Pausen bei Schlaf oder Updates.

Wenn du beides willst: Gateway auf einem dedizierten Host, Laptop als Node für lokale Bildschirm-/Kamera-/Exec-Tools koppeln. Siehe Nodes. Sicherheitshinweise: Sicherheit.

Was sind die minimalen VPS-Anforderungen und die empfohlene OS?

OpenClaw ist schlank. Für ein einfaches Gateway + einen Chat-Channel:

Absolutes Minimum: 1 vCPU, 1 GB RAM, ~500 MB Platte.
Empfohlen: 1–2 vCPU, 2 GB RAM oder mehr für Puffer (Logs, Medien, mehrere Channels). Node-Tools und Browser-Automatisierung können ressourcenhungrig sein.

OS: Ubuntu LTS (oder ein anderes aktuelles Debian/Ubuntu) verwenden. Der Linux-Installationsweg ist dort am besten getestet. Doku: Linux, VPS-Hosting.

Kann ich OpenClaw in einer VM betreiben, und was sind die Anforderungen?

Ja. Eine VM wie einen VPS behandeln: sie muss dauerhaft laufen, erreichbar sein und genug RAM für das Gateway und die aktivierten Channels haben. Grober Richtwert:

Absolutes Minimum: 1 vCPU, 1 GB RAM.
Empfohlen: 2 GB RAM oder mehr bei mehreren Channels, Browser-Automatisierung oder Medien-Tools.
OS: Ubuntu LTS oder ein anderes aktuelles Debian/Ubuntu.

Unter Windows ist WSL2 die einfachste VM-artige Einrichtung und hat die beste Tool-Kompatibilität. Siehe Windows, VPS-Hosting. Bei macOS in einer VM: macOS-VM.

Was ist OpenClaw?

Was ist OpenClaw in einem Absatz?

OpenClaw ist ein persönlicher KI-Assistent, den du auf deinen eigenen Geräten betreibst. Er antwortet in den Messaging-Oberflächen, die du schon nutzt (WhatsApp, Telegram, Slack, Mattermost (Plugin), Discord, Google Chat, Signal, iMessage, WebChat), und kann auf unterstützten Plattformen auch Voice und einen live Canvas nutzen. Das Gateway ist die dauerlaufende Steuerungsebene; der Assistent ist das Produkt.

Was ist der Value Proposition?

OpenClaw ist kein „einfach nur ein Claude-Wrapper“. Es ist eine Local-First-Steuerungsebene, mit der du einen leistungsfähigen Assistenten auf deiner eigenen Hardware betreiben kannst – erreichbar aus den Chat-Apps, die du schon nutzt, mit stateful Sessions, Speicher und Tools, ohne die Kontrolle über deine Abläufe an ein gehostetes SaaS abzugeben. Kurzüberblick:

Deine Geräte, deine Daten: Gateway betreiben, wo du willst (Mac, Linux, VPS), Workspace und Session-Verlauf lokal halten.
Echte Kanäle, kein Web-Sandbox: WhatsApp/Telegram/Slack/Discord/Signal/iMessage usw., plus Mobile-Voice und Canvas auf unterstützten Plattformen.
Modell-unabhängig: Anthropic, OpenAI, MiniMax, OpenRouter usw. nutzen, mit Routing und Failover pro Agent.
Nur-lokal-Option: lokale Modelle laufen lassen, sodass alle Daten auf deinem Gerät bleiben können, wenn du willst.
Multi-Agent-Routing: getrennte Agenten pro Kanal, Konto oder Aufgabe, jeweils mit eigenem Workspace und Defaults.
Open Source und erweiterbar: inspizieren, erweitern und selbst hosten ohne Vendor Lock-in.

Doku: Gateway, Kanäle, Multi-Agent, Speicher.

Ich habe es gerade eingerichtet – was soll ich zuerst tun?

Gute erste Projekte:

Eine Website bauen (WordPress, Shopify oder eine einfache statische Seite).
Einen Mobile-App-Prototyp (Gliederung, Screens, API-Plan).
Dateien und Ordner ordnen (Aufräumen, Benennen, Taggen).
Gmail anbinden und Zusammenfassungen oder Follow-ups automatisieren.

Es bewältigt große Aufgaben, funktioniert aber am besten, wenn du sie in Phasen aufteilst und Sub-Agenten für parallele Arbeit nutzt.

Was sind die fünf wichtigsten Alltags-Anwendungsfälle für OpenClaw?

Typische Alltags-Nutzen:

Persönliche Briefings: Zusammenfassungen von Posteingang, Kalender und relevanten News.
Recherche und Entwürfe: schnelle Recherche, Zusammenfassungen und erste Entwürfe für E-Mails oder Docs.
Erinnerungen und Follow-ups: Cron- oder Heartbeat-gesteuerte Nudges und Checklisten.
Browser-Automatisierung: Formulare ausfüllen, Daten sammeln, Web-Aufgaben wiederholen.
Geräteübergreifende Koordination: Aufgabe vom Handy schicken, Gateway auf dem Server ausführen lassen, Ergebnis im Chat zurückbekommen.

Kann OpenClaw bei Lead-Gen, Outreach, Ads und Blogs für ein SaaS helfen?

Ja für Recherche, Qualifizierung und Entwürfe. Es kann Seiten scannen, Shortlists erstellen, Prospects zusammenfassen und Outreach- oder Ad-Text-Entwürfe schreiben. Bei Outreach- oder Ad-Kampagnen einen Menschen in der Schleife lassen. Spam vermeiden, lokale Gesetze und Plattform-Richtlinien beachten, alles vor dem Versand prüfen. Das sicherste Muster: OpenClaw entwerfen lassen, du genehmigst. Doku: Sicherheit.

Was sind die Vorteile gegenüber Claude Code für Web-Entwicklung?

OpenClaw ist ein persönlicher Assistent und Koordinationsschicht, kein IDE-Ersatz. Claude Code oder Codex für die schnellste direkte Coding-Schleife im Repo nutzen. OpenClaw nutzen, wenn du dauerhaften Speicher, geräteübergreifenden Zugriff und Tool-Orchestrierung willst. Vorteile:

Persistenter Speicher + Workspace über Sessions hinweg
Multi-Plattform-Zugriff (WhatsApp, Telegram, TUI, WebChat)
Tool-Orchestrierung (Browser, Dateien, Planung, Hooks)
Dauerlaufendes Gateway (auf VPS betreiben, von überall interagieren)
Nodes für lokalen Browser/Bildschirm/Kamera/Exec

Showcase: https://molt.bot/showcase

Skills und Automatisierung

Wie passe ich Skills an, ohne das Repo zu verunreinigen?

Verwaltete Overrides nutzen statt die Repo-Kopie zu bearbeiten. Änderungen in ~/.clawdbot/skills/<name>/SKILL.md ablegen (oder einen Ordner über skills.load.extraDirs in ~/.clawdbot/openclaw.json hinzufügen). Reihenfolge: <workspace>/skills > ~/.clawdbot/skills > gebündelt – verwaltete Overrides gewinnen ohne Git zu verändern. Nur upstream-taugliche Änderungen gehören ins Repo und gehen als PRs raus.

Kann ich Skills aus einem eigenen Ordner laden?

Ja. Zusätzliche Verzeichnisse über skills.load.extraDirs in ~/.clawdbot/openclaw.json hinzufügen (niedrigste Priorität). Standard-Priorität bleibt: <workspace>/skills → ~/.clawdbot/skills → gebündelt → skills.load.extraDirs. clawdhub installiert standardmäßig nach ./skills, was OpenClaw als <workspace>/skills behandelt.

Wie kann ich für verschiedene Aufgaben verschiedene Modelle nutzen?

Aktuell unterstützte Muster:

Cron-Jobs: isolierte Jobs können pro Job ein model-Override setzen.
Sub-Agenten: Aufgaben an getrennte Agenten mit unterschiedlichen Standardmodellen routen.
On-Demand-Wechsel: /model nutzen, um das aktuelle Session-Modell jederzeit zu wechseln.

Siehe Cron-Jobs, Multi-Agent-Routing und Slash-Befehle.

Der Bot friert bei schwerer Arbeit ein – wie lade ich das aus?

Sub-Agenten für lange oder parallele Aufgaben nutzen. Sub-Agenten laufen in eigener Session, liefern eine Zusammenfassung und halten den Haupt-Chat reaktionsfähig. Den Bot bitten: „spawn a sub-agent for this task“ oder /subagents nutzen. Im Chat /status nutzen, um zu sehen, was das Gateway gerade macht (und ob es beschäftigt ist). Token-Tipp: Lange Aufgaben und Sub-Agenten verbrauchen beide Tokens. Bei Kostenbedenken ein günstigeres Modell für Sub-Agenten über agents.defaults.subagents.model setzen. Doku: Sub-Agenten.

Cron oder Erinnerungen feuern nicht – was soll ich prüfen?

Cron läuft im Gateway-Prozess. Wenn das Gateway nicht dauerhaft läuft, werden geplante Jobs nicht ausgeführt. Checkliste:

Prüfen, dass Cron aktiviert ist (cron.enabled) und CLAWDBOT_SKIP_CRON nicht gesetzt ist.
Prüfen, dass das Gateway 24/7 läuft (kein Schlaf/Neustarts).
Zeitzone des Jobs prüfen (--tz vs. Host-Zeitzone).

Debug:


openclaw cron run <jobId> --force
openclaw cron runs --id <jobId> --limit 50

Doku: Cron-Jobs, Cron vs. Heartbeat.

Wie installiere ich Skills unter Linux?

ClawdHub (CLI) nutzen oder Skills in deinen Workspace legen. Die macOS-Skills-UI ist unter Linux nicht verfügbar. Skills durchstöbern unter https://clawdhub.com . ClawdHub-CLI installieren (einen Paketmanager wählen):


npm i -g clawdhub


pnpm add -g clawdhub

Kann OpenClaw Aufgaben geplant oder dauerhaft im Hintergrund ausführen?

Ja. Den Gateway-Scheduler nutzen:

Cron-Jobs für geplante oder wiederkehrende Aufgaben (überleben Neustarts).
Heartbeat für periodische „Haupt-Session“-Prüfungen.
Isolierte Jobs für autonome Agenten, die Zusammenfassungen posten oder in Chats liefern.

Doku: Cron-Jobs, Cron vs. Heartbeat, Heartbeat.Kann ich reine Apple-/macOS-Skills von Linux aus nutzen? Nicht direkt. macOS skills are gated by metadata.openclaw.os plus required binaries, and skills only appear in the system prompt when they are eligible on the Gateway host. On Linux, darwin-only skills (like imsg, apple-notes, apple-reminders) will not load unless you override the gating.You have three supported patterns:Option A - run the Gateway on a Mac (simplest).

Gateway dort betreiben, wo die macOS-Binaries existieren, dann von Linux aus im Remote-Modus oder über Tailscale verbinden. Die Skills laden normal, weil der Gateway-Host macOS ist. Option B – macOS-Node nutzen (ohne SSH).

Gateway unter Linux betreiben, einen macOS-Node (Menüleisten-App) koppeln und Node Run Commands auf dem Mac auf „Always Ask“ oder „Always Allow“ setzen. OpenClaw kann reine macOS-Skills als verfügbar behandeln, wenn die erforderlichen Binaries auf dem Node existieren. Der Agent führt diese Skills über das nodes-Tool aus. Bei „Always Ask“ fügt die Bestätigung „Always Allow“ im Prompt den Befehl zur Allowlist hinzu. Option C – macOS-Binaries per SSH proxy (fortgeschritten).

Gateway unter Linux lassen, die erforderlichen CLI-Binaries aber auf SSH-Wrapper zeigen, die auf einem Mac laufen. Dann den Skill so überschreiben, dass Linux erlaubt ist, damit er verfügbar bleibt.

Create an SSH wrapper for the binary (example: imsg):


#!/usr/bin/env bash
set -euo pipefail
exec ssh -T user@mac-host /opt/homebrew/bin/imsg "$@"

Wrapper auf dem Linux-Host in die PATH legen (z. B. ~/bin/imsg).
Skill-Metadaten (Workspace oder ~/.clawdbot/skills) überschreiben, damit Linux erlaubt ist:


   ---
name: imsg
description: iMessage/SMS CLI for listing chats, history, watch, and sending.
metadata: {"openclaw":{"os":["darwin","linux"],"requires":{"bins":["imsg"]}}}
   ---

Neue Session starten, damit der Skills-Snapshot aktualisiert wird.

Für iMessage kannst du channels.imessage.cliPath auch auf einen SSH-Wrapper zeigen (OpenClaw braucht nur stdio). Siehe iMessage.

Gibt es eine Notion- oder HeyGen-Integration?

Derzeit nicht eingebaut. Optionen:

Eigener Skill / Plugin: am besten für zuverlässigen API-Zugriff (Notion/HeyGen haben APIs).
Browser-Automatisierung: funktioniert ohne Code, ist aber langsamer und fehleranfälliger.

Wenn du Kontext pro Kunde halten willst (Agentur-Workflows), ein einfaches Muster:

Eine Notion-Seite pro Kunde (Kontext + Präferenzen + aktive Arbeit).
Den Agenten bitten, diese Seite zu Sessionbeginn zu laden.

Für eine native Integration: Feature-Request öffnen oder einen Skill für diese APIs bauen. Skills installieren:


clawdhub install <skill-slug>
clawdhub update --all

ClawdHub installiert in ./skills unter dem aktuellen Verzeichnis (oder nutzt deinen konfigurierten OpenClaw-Workspace); OpenClaw behandelt das beim nächsten Session-Start als <workspace>/skills. Für geteilte Skills über Agenten: in ~/.clawdbot/skills/<name>/SKILL.md ablegen. Einige Skills erwarten per Homebrew installierte Binaries; unter Linux Linuxbrew (siehe Homebrew-Linux-FAQ oben). Siehe Skills und ClawdHub.

Wie installiere ich die Chrome-Erweiterung für Browser-Übernahme?

Den eingebauten Installer nutzen, dann die entpackte Erweiterung in Chrome laden:


openclaw browser extension install
openclaw browser extension path

Dann in Chrome → chrome://extensions → „Entwicklermodus“ aktivieren → „Entpackt laden“ → diesen Ordner wählen. Vollständige Anleitung (inkl. Remote-Gateway + Sicherheitshinweise): Chrome-Erweiterung. Läuft das Gateway auf derselben Maschine wie Chrome (Standard-Setup), brauchst du in der Regel nichts Zusätzliches. Läuft das Gateway woanders: auf dem Browser-Rechner einen Node-Host starten, damit das Gateway Browser-Aktionen proxyen kann. Du musst weiterhin auf den Erweiterungs-Button im zu steuernden Tab klicken (es hängt sich nicht automatisch an).

Sandbox und Speicher

Gibt es ein eigenes Sandboxing-Dokument?

Ja. Siehe Sandboxing. Für Docker-spezifische Einrichtung (vollständiges Gateway in Docker oder Sandbox-Images) siehe Docker.DMs privat, Gruppen öffentlich in Sandbox mit einem Agenten Ja – wenn dein privater Traffic DMs und der öffentliche Gruppen sind. agents.defaults.sandbox.mode: "non-main" setzen, damit Gruppen-/Kanal-Sessions (non-main Keys) in Docker laufen, die Haupt-DM-Session aber on-host bleibt. Dann über tools.sandbox.tools einschränken, welche Tools in sandboxed Sessions verfügbar sind. Setup + Beispiel-Config: Gruppen: persönliche DMs + öffentliche Gruppen. Config-Referenz: Gateway-Konfiguration.

Wie binde ich einen Host-Ordner in die Sandbox ein?

agents.defaults.sandbox.docker.binds auf ["host:path:mode"] setzen (z. B. "/home/user/src:/src:ro"). Globale und per-Agent-Binds werden zusammengeführt; per-Agent-Binds werden bei scope: "shared" ignoriert. :ro für sensible Daten nutzen; Binds umgehen die Sandbox-Dateisystem-Grenzen. Siehe Sandboxing und Sandbox vs. Tool Policy vs. Elevated für Beispiele und Sicherheitshinweise.

Wie funktioniert der Speicher?

OpenClaw-Speicher sind Markdown-Dateien im Agent-Workspace:

Tägliche Notizen in memory/YYYY-MM-DD.md
Kuratierte Langzeit-Notizen in MEMORY.md (nur Haupt-/private Sessions)

OpenClaw führt außerdem einen stillen Pre-Compaction-Memory-Flush aus, damit das Modell vor der Auto-Kompaktion dauerhafte Notizen schreibt. Das läuft nur, wenn der Workspace beschreibbar ist (read-only-Sandboxen überspringen es). Siehe Speicher.

Der Speicher vergisst ständig – wie mache ich es dauerhaft?

Den Bot bitten, die Tatsache in den Speicher zu schreiben. Langzeit-Notizen gehören in MEMORY.md, kurzfristiger Kontext in memory/YYYY-MM-DD.md. Das ist noch ein Bereich, den wir verbessern. Es hilft, das Modell daran zu erinnern, Erinnerungen zu speichern; es weiß, was zu tun ist. Wenn es weiter vergisst, prüfen, ob das Gateway bei jedem Lauf denselben Workspace nutzt. Doku: Speicher, Agent-Workspace.

Braucht die semantische Speichersuche einen OpenAI-API-Key?

Nur wenn du OpenAI-Embeddings nutzt. Codex OAuth deckt Chat/Completions ab und gibt keinen Embeddings-Zugriff, daher hilft Anmeldung mit Codex (OAuth oder Codex-CLI-Login) nicht für semantische Speichersuche. OpenAI-Embeddings brauchen einen echten API-Key (OPENAI_API_KEY oder models.providers.openai.apiKey). Wenn du keinen Provider explizit setzt, wählt OpenClaw automatisch einen Provider, sobald ein API-Key aufgelöst werden kann (Auth-Profile, models.providers.*.apiKey oder Env-Vars). Bevorzugt wird OpenAI, wenn ein OpenAI-Key auflöst, sonst Gemini bei Gemini-Key. Sind keine Keys vorhanden, bleibt die Speichersuche deaktiviert, bis du sie konfigurierst. Bei konfiguriertem und vorhandenem lokalem Modellpfad bevorzugt OpenClaw local. Für rein lokale Nutzung memorySearch.provider = "local" setzen (optional memorySearch.fallback = "none"). Für Gemini-Embeddings memorySearch.provider = "gemini" setzen und GEMINI_API_KEY (oder memorySearch.remote.apiKey) angeben. Unterstützt werden OpenAI-, Gemini- oder lokale Embedding-Modelle – siehe Speicher für die Einrichtung.

Bleibt der Speicher für immer? Was sind die Grenzen?

Speicherdateien liegen auf der Platte und bleiben bestehen, bis du sie löschst. Die Grenze ist dein Speicherplatz, nicht das Modell. Der Session-Kontext ist weiterhin durch das Modell-Kontextfenster begrenzt, lange Gespräche können komprimiert oder gekürzt werden. Daher gibt es die Speichersuche – sie holt nur die relevanten Teile zurück in den Kontext. Doku: Speicher, Kontext.

Wo Dinge auf der Festplatte liegen

Werden alle mit OpenClaw genutzten Daten lokal gespeichert?

Nein – der OpenClaw-State ist lokal, aber externe Dienste sehen weiterhin, was du an sie sendest.

Standardmäßig lokal: Sessions, Speicherdateien, Config und Workspace liegen auf dem Gateway-Host (`~/.clawdbot` + dein Workspace-Verzeichnis).
Remote nötig: Nachrichten an Modellanbieter (Anthropic/OpenAI usw.) gehen an deren APIs; Chat-Plattformen (WhatsApp/Telegram/Slack usw.) speichern Nachrichtendaten auf ihren Servern.
Du kontrollierst den Footprint: Lokale Modelle halten Prompts auf deiner Maschine, Kanal-Traffic geht aber weiter über die Server des Kanals.

Siehe: Agent-Workspace, Speicher.

Wo speichert OpenClaw seine Daten?

Alles liegt unter $CLAWDBOT_STATE_DIR (Standard: ~/.clawdbot):

Pfad	Zweck
`$CLAWDBOT_STATE_DIR/openclaw.json`	Haupt-Config (JSON5)
`$CLAWDBOT_STATE_DIR/credentials/oauth.json`	Legacy-OAuth-Import (beim ersten Nutzen in Auth-Profile kopiert)
`$CLAWDBOT_STATE_DIR/agents/<agentId>/agent/auth-profiles.json`	Auth-Profile (OAuth + API-Keys)
`$CLAWDBOT_STATE_DIR/agents/<agentId>/agent/auth.json`	Laufzeit-Auth-Cache (automatisch verwaltet)
`$CLAWDBOT_STATE_DIR/credentials/`	Provider-State (z. B. `whatsapp/<accountId>/creds.json`)
`$CLAWDBOT_STATE_DIR/agents/`	Pro-Agent-State (agentDir + Sessions)
`$CLAWDBOT_STATE_DIR/agents/<agentId>/sessions/`	Konversationsverlauf & State (pro Agent)
`$CLAWDBOT_STATE_DIR/agents/<agentId>/sessions/sessions.json`	Session-Metadaten (pro Agent)

Veralteter Single-Agent-Pfad: ~/.clawdbot/agent/* (wird von openclaw doctor migriert). Dein Workspace (AGENTS.md, Speicherdateien, Skills usw.) ist getrennt und wird über agents.defaults.workspace konfiguriert (Standard: ~/clawd).

Wo sollen AGENTS.md / SOUL.md / USER.md / MEMORY.md liegen?

Diese Dateien liegen im Agent-Workspace, nicht in ~/.clawdbot.

Workspace (per agent): AGENTS.md, SOUL.md, IDENTITY.md, USER.md, MEMORY.md (or memory.md), memory/YYYY-MM-DD.md, optional HEARTBEAT.md.
State-Verzeichnis (~/.clawdbot): Config, Credentials, Auth-Profile, Sessions, Logs und geteilte Skills (~/.clawdbot/skills).

Standard-Workspace ist ~/clawd, konfigurierbar über:


{
  agents: { defaults: { workspace: "~/clawd" } }
}

Vergisst der Bot nach einem Neustart: prüfen, ob das Gateway bei jedem Start denselben Workspace nutzt (im Remote-Modus gilt der Workspace des Gateway-Hosts, nicht dein Laptop). Tipp: Für dauerhaftes Verhalten oder Präferenzen den Bot bitten, in AGENTS.md oder MEMORY.md zu schreiben, statt sich auf den Chat-Verlauf zu verlassen. Siehe Agent-Workspace und Speicher.

Was ist die empfohlene Backup-Strategie?

Deinen Agent-Workspace in ein privates Git-Repo legen und privat sichern (z. B. GitHub privat). So erfasst du Speicher + AGENTS-/SOUL-/USER-Dateien und kannst den „Kopf“ des Assistenten später wiederherstellen. Nichts unter ~/.clawdbot committen (Credentials, Sessions, Tokens). Für eine vollständige Wiederherstellung Workspace und State-Verzeichnis getrennt sichern (siehe Migrations-Frage oben). Doku: Agent-Workspace.

Wie deinstalliere ich OpenClaw vollständig?

Siehe die Anleitung: Deinstallation.

Können Agenten außerhalb des Workspaces arbeiten?

Ja. Der Workspace ist das Standard-CWD und Speicher-Anker, kein hartes Sandbox. Relative Pfade werden im Workspace aufgelöst; absolute Pfade können andere Host-Orte erreichen, wenn Sandboxing nicht aktiv ist. Bei Isolationsbedarf agents.defaults.sandbox oder pro-Agent-Sandbox-Einstellungen nutzen. Soll ein Repo das Standard-Arbeitsverzeichnis sein, workspace des Agenten auf die Repo-Wurzel setzen. Das OpenClaw-Repo ist nur Quellcode; den Workspace getrennt halten, außer du willst den Agenten bewusst darin arbeiten lassen. Beispiel (Repo als Standard-CWD):


{
  agents: {
    defaults: {
      workspace: "~/Projects/my-repo"
    }
  }
}

Ich bin im Remote-Modus – wo liegt der Session-Store?

Der Session-Zustand gehört dem Gateway-Host. Im Remote-Modus liegt der relevante Session-Store auf der Remote-Maschine, nicht auf deinem Laptop. Siehe Session-Verwaltung.

Konfigurations-Grundlagen

In welchem Format ist die Config, und wo liegt sie?

OpenClaw liest eine optionale JSON5-Config aus $CLAWDBOT_CONFIG_PATH (Standard: ~/.clawdbot/openclaw.json):


$CLAWDBOT_CONFIG_PATH

Fehlt die Datei, werden sichere Defaults genutzt (inkl. Standard-Workspace ~/clawd).

Ich habe gateway.bind auf „lan“ (oder „tailnet“) gesetzt – jetzt hört nichts / die UI meldet „unauthorized“

Bindings außerhalb von Loopback erfordern Auth. gateway.auth.mode und gateway.auth.token konfigurieren (oder CLAWDBOT_GATEWAY_TOKEN setzen).


{
  gateway: {
    bind: "lan",
    auth: {
      mode: "token",
      token: "replace-me"
    }
  }
}

Hinweise:

gateway.remote.token gilt nur für Remote-CLI-Aufrufe; es aktiviert keine lokale Gateway-Auth.
Die Control-UI authentifiziert sich über connect.params.auth.token (in App/UI-Einstellungen gespeichert). Tokens nicht in URLs legen.

Warum brauche ich jetzt einen Token auf Localhost?

Der Assistent erzeugt standardmäßig einen Gateway-Token (auch bei Loopback), damit lokale WS-Clients sich authentifizieren müssen. So können andere lokale Prozesse das Gateway nicht aufrufen. Token in die Control-UI-Einstellungen (oder deine Client-Config) einfügen, um zu verbinden. Wenn du wirklich offenes Loopback willst, gateway.auth aus der Config entfernen. Doctor kann jederzeit einen Token erzeugen: openclaw doctor --generate-gateway-token.

Muss ich nach Config-Änderung neu starten?

Das Gateway beobachtet die Config und unterstützt Hot-Reload:

gateway.reload.mode: "hybrid" (Standard): sichere Änderungen per Hot-Apply, bei kritischen Neustart
hot, restart, off werden ebenfalls unterstützt

Wie aktiviere ich Web-Suche (und Web-Fetch)?

web_fetch funktioniert ohne API-Key. web_search braucht einen Brave-Search-API-Key. Empfohlen: openclaw configure --section web ausführen, um ihn in tools.web.search.apiKey zu speichern. Alternative per Umgebung: BRAVE_API_KEY für den Gateway-Prozess setzen.


{
  tools: {
    web: {
      search: {
        enabled: true,
        apiKey: "BRAVE_API_KEY_HERE",
        maxResults: 5
      },
      fetch: {
        enabled: true
      }
    }
  }
}

Hinweise:

Bei Allowlists web_search/web_fetch oder group:web hinzufügen.
web_fetch ist standardmäßig aktiv (außer explizit deaktiviert).
Daemons lesen Umgebungsvariablen aus ~/.clawdbot/.env (oder der Service-Umgebung).

Doku: Web-Tools.

Wie betreibe ich ein zentrales Gateway mit spezialisierten Workern auf mehreren Geräten?

Übliches Muster: ein Gateway (z. B. Raspberry Pi) plus Nodes und Agenten:

Gateway (zentral): besitzt Kanäle (Signal/WhatsApp), Routing und Sessions.
Nodes (Geräte): Macs/iOS/Android verbinden sich als Peripherie und stellen lokale Tools bereit (system.run, canvas, camera).
Agents (Worker): getrennte „Gehirne“/Workspaces für spezielle Rollen (z. B. „Hetzner-Ops“, „Persönliche Daten“).
Sub-Agenten: Hintergrundarbeit von einem Haupt-Agenten, wenn du Parallelität willst.
TUI: mit dem Gateway verbinden und Agenten/Sessions wechseln.

Doku: Nodes, Remote-Zugriff, Multi-Agent-Routing, Sub-Agenten, TUI.

Kann der OpenClaw-Browser headless laufen?

Ja. Es ist eine Config-Option:


{
  browser: { headless: true },
  agents: {
    defaults: {
      sandbox: { browser: { headless: true } }
    }
  }
}

Standard ist false (headful). Headless löst auf einigen Seiten eher Anti-Bot-Prüfungen aus. Siehe Browser. Headless nutzt die gleiche Chromium-Engine und funktioniert für die meisten Automatisierungen (Formulare, Klicks, Scraping, Logins). Die Hauptunterschiede:

Kein sichtbares Browserfenster (bei Bedarf Screenshots nutzen).
Einige Seiten sind bei Headless-Automatisierung strenger (CAPTCHAs, Anti-Bot). Z. B. blockiert X/Twitter oft Headless-Sessions.

Wie nutze ich Brave für die Browser-Steuerung?

browser.executablePath auf deine Brave-Binary (oder einen anderen Chromium-basierten Browser) setzen und das Gateway neu starten. Vollständige Config-Beispiele in Browser.

Remote-Gateways + Nodes

Wie verbreiten sich Befehle zwischen Telegram, Gateway und Nodes?

Telegram messages are handled by the gateway. The gateway runs the agent and only then calls nodes over the Gateway WebSocket when a node tool is needed:Telegram → Gateway → Agent → node.* → Node → Gateway → TelegramNodes don’t see inbound provider traffic; they only receive node RPC calls.

Wie kann mein Agent auf meinen Rechner zugreifen, wenn das Gateway remote gehostet wird?

Kurz: deinen Rechner als Node koppeln. Das Gateway läuft woanders, kann aber node.*-Tools (screen, camera, system) auf deiner lokalen Maschine über den Gateway-WebSocket aufrufen. Typisches Setup:

Gateway auf dem Dauerläufer-Host (VPS/Heimserver) betreiben.
Gateway-Host und deinen Rechner im gleichen Tailnet haben.
Sicherstellen, dass der Gateway-WS erreichbar ist (Tailnet-Bind oder SSH-Tunnel).
Die macOS-App lokal öffnen und im Modus Remote über SSH (oder direkt Tailnet) verbinden, damit sie sich als Node registrieren kann.
Den Node auf dem Gateway genehmigen:


openclaw nodes pending
openclaw nodes approve <requestId>

Keine separate TCP-Bridge nötig; Nodes verbinden sich über den Gateway-WebSocket. Sicherheitshinweis: Ein gekoppelter macOS-Node erlaubt system.run auf dieser Maschine. Nur Geräte koppeln, denen du vertraust, und Sicherheit beachten. Doku: Nodes, Gateway-Protokoll, macOS Remote-Modus, Sicherheit.

Tailscale ist verbunden, aber ich bekomme keine Antworten – was tun?

Grundlagen prüfen:

Gateway läuft: openclaw gateway status
Gateway-Health: openclaw status
Channel-Health: openclaw channels status

Dann Auth und Routing prüfen:

Bei Tailscale Serve sicherstellen, dass gateway.auth.allowTailscale korrekt gesetzt ist.
Bei Verbindung per SSH-Tunnel prüfen, dass der lokale Tunnel steht und auf den richtigen Port zeigt.
Prüfen, dass deine Allowlists (DM oder Gruppe) deinen Account enthalten.

Doku: Tailscale, Remote-Zugriff, Channels.

Können zwei OpenClaws miteinander reden (lokal + VPS)?

Ja. Es gibt keine eingebaute „Bot-zu-Bot“-Brücke, aber du kannst sie zuverlässig aufsetzen:Einfachste Variante: einen normalen Chat-Kanal nutzen, den beide Bots erreichen (Telegram/Slack/WhatsApp). Bot A an Bot B schicken lassen, Bot B antwortet wie gewohnt.CLI-Brücke (allgemein): ein Skript ausführen, das das andere Gateway mit openclaw agent --message ... --deliver aufruft und einen Chat anspricht, in dem der andere Bot lauscht. Ist ein Bot auf einem Remote-VPS, die CLI per SSH/Tailscale auf dieses Gateway zeigen (siehe Remote-Zugriff). Beispiel (von einer Maschine aus, die das Ziel-Gateway erreichen kann):


openclaw agent --message "Hello from local bot" --deliver --channel telegram --reply-to <chat-id>

Tipp: eine Absicherung einbauen, damit die beiden Bots nicht endlos loopen (nur bei Erwähnung, Kanal-Allowlists oder „nicht auf Bot-Nachrichten antworten“). Doku: Remote-Zugriff, Agent-CLI, Agent send.

Brauche ich separate VPS für mehrere Agenten?

Nein. Ein Gateway kann mehrere Agenten hosten, jeweils mit eigenem Workspace, Modell-Standards und Routing. Das ist das übliche Setup und deutlich günstiger und einfacher als ein VPS pro Agent. Separate VPS nur bei harter Isolation (Sicherheitsgrenzen) oder sehr unterschiedlichen Configs, die du nicht teilen willst. Ansonsten ein Gateway behalten und mehrere Agenten oder Sub-Agenten nutzen.

Bringt es etwas, einen Node auf meinem Laptop zu nutzen statt SSH vom VPS?

Ja – Nodes sind der Standardweg, um deinen Laptop von einem Remote-Gateway aus zu erreichen, und sie bieten mehr als Shell-Zugriff. Das Gateway läuft unter macOS/Linux (Windows über WSL2) und ist schlank (ein kleiner VPS oder Raspberry-Pi-Klasse reicht; 4 GB RAM genügen), typisch ist also ein Dauerläufer-Host plus dein Laptop als Node.

Kein eingehendes SSH nötig. Nodes verbinden sich ausgehend mit dem Gateway-WebSocket und nutzen Geräte-Pairing.
Sicherere Ausführungssteuerung. system.run wird durch Node-Allowlists/Genehmigungen auf dem Laptop begrenzt.
Mehr Geräte-Tools. Nodes stellen neben system.run auch canvas, camera und screen bereit.
Lokale Browser-Automatisierung. Gateway auf VPS, Chrome lokal laufen lassen und Steuerung per Chrome-Erweiterung + Node-Host auf dem Laptop weiterleiten.

SSH ist für Ad-hoc-Shell-Zugriff in Ordnung; für dauerhafte Agent-Workflows und Geräte-Automatisierung sind Nodes einfacher. Doku: Nodes, Nodes-CLI, Chrome-Erweiterung.

Soll ich auf einem zweiten Laptop installieren oder nur einen Node hinzufügen?

Wenn du auf dem zweiten Laptop nur lokale Tools (screen/camera/exec) brauchst, ihn als Node hinzufügen. So bleibt ein einziges Gateway und doppelte Config entfällt. Lokale Node-Tools sind derzeit nur unter macOS; die Ausweitung auf andere OS ist geplant. Ein zweites Gateway nur bei harter Isolation oder zwei vollständig getrennten Bots installieren. Doku: Nodes, Nodes-CLI, Mehrere Gateways.

Laufen auf Nodes ein Gateway-Service?

Nein. Pro Host sollte nur ein Gateway laufen, außer du betreibst bewusst isolierte Profile (siehe Mehrere Gateways). Nodes sind Peripheriegeräte, die sich mit dem Gateway verbinden (iOS/Android-Nodes oder macOS „Node-Modus“ in der Menüleisten-App). Für Headless-Node-Hosts und CLI-Steuerung: Node-Host-CLI. Für Änderungen an gateway, discovery und canvasHost ist ein vollständiger Neustart nötig.

Gibt es einen API-/RPC-Weg, die Config anzuwenden?

Ja. config.apply validiert und schreibt die vollständige Config und startet das Gateway im Zuge der Aktion neu.

config.apply hat meine Config gelöscht – wie stelle ich sie wieder her und vermeide das?

config.apply ersetzt die gesamte Config. Bei einem partiellen Objekt wird alles andere entfernt. Wiederherstellung:

Aus Backup wiederherstellen (Git oder kopierte ~/.clawdbot/openclaw.json).
Ohne Backup: openclaw doctor erneut ausführen und Channels/Modelle neu konfigurieren.
Wenn unerwartet: Bug melden und letzte bekannte Config oder ein Backup beifügen.
Ein lokaler Coding-Agent kann oft aus Logs oder Verlauf eine funktionierende Config rekonstruieren.

Vermeiden:

Für kleine Änderungen openclaw config set nutzen.
Für interaktive Bearbeitung openclaw configure nutzen.

Doku: Config, Configure, Doctor.

Was ist eine minimale „saubere“ Config für die erste Installation?


{
  agents: { defaults: { workspace: "~/clawd" } },
  channels: { whatsapp: { allowFrom: ["+15555550123"] } }
}

Damit wird dein Workspace gesetzt und eingeschränkt, wer den Bot auslösen kann.

Wie richte ich Tailscale auf einem VPS ein und verbinde mich von meinem Mac?

Minimale Schritte:

Auf dem VPS installieren und anmelden


curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Auf deinem Mac installieren und anmelden
- Tailscale-App nutzen und im gleichen Tailnet anmelden.
MagicDNS aktivieren (empfohlen)
- In der Tailscale-Admin-Konsole MagicDNS aktivieren, damit der VPS einen stabilen Namen hat.
Tailnet-Hostnamen nutzen
- SSH: ssh user@your-vps.tailnet-xxxx.ts.net
- Gateway-WS: ws://your-vps.tailnet-xxxx.ts.net:18789

Wenn du die Control-UI ohne SSH willst, auf dem VPS Tailscale Serve nutzen:


openclaw gateway --tailscale serve

Das Gateway bleibt an Loopback gebunden und exponiert HTTPS über Tailscale. Siehe Tailscale.

Wie verbinde ich einen Mac-Node mit einem Remote-Gateway (Tailscale Serve)?

Serve exponiert die Gateway Control-UI + WS. Nodes verbinden sich über denselben Gateway-WS-Endpunkt. Empfohlenes Setup:

Sicherstellen, dass VPS und Mac im gleichen Tailnet sind.
Die macOS-App im Remote-Modus nutzen (SSH-Ziel kann der Tailnet-Hostname sein). Die App tunnelt den Gateway-Port und verbindet sich als Node.
Den Node auf dem Gateway genehmigen:


openclaw nodes pending
openclaw nodes approve <requestId>

Doku: Gateway-Protokoll, Discovery, macOS Remote-Modus.

Umgebungsvariablen und .env-Laden

Wie lädt OpenClaw Umgebungsvariablen?

OpenClaw liest Umgebungsvariablen aus dem Parent-Prozess (Shell, launchd/systemd, CI usw.) und lädt zusätzlich:

.env aus dem aktuellen Arbeitsverzeichnis
eine globale Fallback-.env aus ~/.clawdbot/.env (also $CLAWDBOT_STATE_DIR/.env)

Keine der .env-Dateien überschreibt bestehende Umgebungsvariablen. Du kannst auch Inline-Env-Vars in der Config definieren (werden nur angewendet, wenn sie im Prozess-Env fehlen):


{
  env: {
    OPENROUTER_API_KEY: "sk-or-...",
    vars: { GROQ_API_KEY: "gsk-..." }
  }
}

Siehe Umgebung für vollständige Priorität und Quellen.

Ich habe das Gateway über den Service gestartet – meine Umgebungsvariablen sind weg. Was tun?

Two common fixes:

Put the missing keys in ~/.clawdbot/.env so they’re picked up even when the service doesn’t inherit your shell env.
Enable shell import (opt‑in convenience):


{
  env: {
    shellEnv: {
      enabled: true,
      timeoutMs: 15000
    }
  }
}

Damit wird deine Login-Shell ausgeführt und nur fehlende erwartete Keys importiert (überschreibt nie). Entsprechende Umgebungsvariablen: CLAWDBOT_LOAD_SHELL_ENV=1, CLAWDBOT_SHELL_ENV_TIMEOUT_MS=15000.

Ich habe COPILOT_GITHUB_TOKEN gesetzt, aber „models status“ zeigt „Shell env: off“. Warum?

openclaw models status reports whether shell env import is enabled. “Shell env: off” does not mean your env vars are missing - it just means OpenClaw won’t load your login shell automatically.If the Gateway runs as a service (launchd/systemd), it won’t inherit your shell environment. Fix by doing one of these:

Put the token in ~/.clawdbot/.env:


COPILOT_GITHUB_TOKEN=...

Or enable shell import (env.shellEnv.enabled: true).
Or add it to your config env block (applies only if missing).

Dann das Gateway neu starten und erneut prüfen:


openclaw models status

Copilot-Tokens werden aus COPILOT_GITHUB_TOKEN (auch GH_TOKEN / GITHUB_TOKEN) gelesen. Siehe Modell-Provider und Umgebung.

Sessions & mehrere Chats

Wie starte ich eine neue Unterhaltung?

/new oder /reset als eigenständige Nachricht senden. Siehe Session-Verwaltung.

Setzen sich Sessions automatisch zurück, wenn ich nie /new sende?

Ja. Sessions laufen nach session.idleMinutes (Standard 60) ab. Die nächste Nachricht startet eine neue Session-ID für diesen Chat-Key. Das löscht keine Transkripte – es beginnt nur eine neue Session.


{
  session: {
    idleMinutes: 240
  }
}

Gibt es eine Möglichkeit, ein Team aus OpenClaws zu machen – ein CEO und viele Agenten?

Ja, über Multi-Agent-Routing und Sub-Agenten. Du kannst einen Koordinator-Agenten und mehrere Worker-Agenten mit eigenen Workspaces und Modellen anlegen. Das ist aber eher ein spannendes Experiment. Es verbraucht viele Tokens und ist oft weniger effizient als ein Bot mit getrennten Sessions. Unser typisches Modell: ein Bot, mit dem du sprichst, mit verschiedenen Sessions für parallele Arbeit. Dieser Bot kann bei Bedarf auch Sub-Agenten spawnen. Doku: Multi-Agent-Routing, Sub-Agenten, Agents-CLI.

Warum wurde der Kontext mitten in der Aufgabe gekürzt – wie verhindere ich das?

Der Session-Kontext ist durch das Modell-Fenster begrenzt. Lange Chats, große Tool-Ausgaben oder viele Dateien können Kompaktierung oder Kürzung auslösen. Was hilft:

Den Bot bitten, den aktuellen Stand zusammenzufassen und in eine Datei zu schreiben.
Vor langen Aufgaben /compact nutzen, bei Themenwechsel /new.
Wichtigen Kontext im Workspace halten und den Bot bitten, ihn zurückzulesen.
Sub-Agenten für lange oder parallele Arbeit nutzen, damit der Haupt-Chat kleiner bleibt.
Ein Modell mit größerem Kontextfenster wählen, wenn das oft vorkommt.

Wie setze ich OpenClaw vollständig zurück, lasse es aber installiert?

Den Reset-Befehl nutzen:


openclaw reset

Vollständiger Reset ohne Interaktion:


openclaw reset --scope full --yes --non-interactive

Dann Onboarding erneut ausführen:


openclaw onboard --install-daemon

Hinweise:

Der Onboarding-Assistent bietet auch Reset, wenn er eine bestehende Config sieht. Siehe Assistent.
Bei Profilen (--profile / CLAWDBOT_PROFILE) jedes State-Verzeichnis zurücksetzen (Standard: ~/.clawdbot-<profile>).
Dev-Reset: openclaw gateway --dev --reset (nur Dev; löscht Dev-Config + Credentials + Sessions + Workspace).

Ich bekomme „context too large“-Fehler – wie setze ich zurück oder komprimiere?

Eine der folgenden Optionen nutzen:

Compact (behält die Unterhaltung, fasst ältere Züge zusammen):


/compact

oder /compact <Anweisungen> um die Zusammenfassung zu steuern.

Reset (neue Session-ID für denselben Chat-Key):


/new
/reset

Wenn es weiter vorkommt:

Session Pruning aktivieren oder anpassen (agents.defaults.contextPruning), um alte Tool-Ausgaben zu kürzen.
Ein Modell mit größerem Kontextfenster nutzen.

Doku: Kompaktierung, Session Pruning, Session-Verwaltung.

Warum sehe ich „LLM request rejected: messages.N.content.X.tool_use.input: Field required“?

Das ist ein Provider-Validierungsfehler: Das Modell hat einen tool_use-Block ohne das erforderliche input ausgegeben. Meist ist die Session-Historie veraltet oder beschädigt (oft nach langen Threads oder Tool/Schema-Änderung). Lösung: neue Session mit /new starten (eigenständige Nachricht).

Warum bekomme ich alle 30 Minuten Heartbeat-Nachrichten?

Heartbeats laufen standardmäßig alle 30 Min. Anpassen oder deaktivieren:


{
  agents: {
    defaults: {
      heartbeat: {
        every: "2h"   // or "0m" to disable
      }
    }
  }
}

Wenn HEARTBEAT.md existiert aber effektiv leer ist (nur Leerzeilen und Markdown-Überschriften wie # Heading), überspringt OpenClaw den Heartbeat-Lauf, um API-Aufrufe zu sparen. Fehlt die Datei, läuft der Heartbeat trotzdem und das Modell entscheidet. Per-Agent-Overrides über agents.list[].heartbeat. Doku: Heartbeat.

Muss ich ein „Bot-Konto“ zu einer WhatsApp-Gruppe hinzufügen?

Nein. OpenClaw läuft auf deinem eigenen Konto – bist du in der Gruppe, sieht OpenClaw sie. Standardmäßig sind Gruppenantworten blockiert, bis du Absender erlaubst (groupPolicy: "allowlist"). Soll nur du Gruppenantworten auslösen können:


{
  channels: {
    whatsapp: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["+15551234567"]
    }
  }
}

Wie bekomme ich die JID einer WhatsApp-Gruppe?

Option 1 (am schnellsten): Logs verfolgen und eine Testnachricht in der Gruppe senden:


openclaw logs --follow --json

Nach chatId (oder from) suchen, das auf @g.us endet, z. B. 1234567890-1234567890@g.us. Option 2 (wenn bereits konfiguriert/allowlisted): Gruppen aus der Config auflisten:


openclaw directory groups list --channel whatsapp

Doku: WhatsApp, Directory, Logs.

Warum antwortet OpenClaw in einer Gruppe nicht?

Zwei häufige Ursachen:

Mention-Gating ist an (Standard). Du musst den Bot @erwähnen (oder mentionPatterns entsprechen).
Du hast channels.whatsapp.groups ohne "*" konfiguriert und die Gruppe ist nicht in der Allowlist.

Siehe Gruppen und Gruppennachrichten.

Teilen Gruppen/Threads den Kontext mit DMs?

Direktchats landen standardmäßig in der Haupt-Session. Gruppen/Channels haben eigene Session-Keys; Telegram-Themen und Discord-Threads sind getrennte Sessions. Siehe Gruppen und Gruppennachrichten.

Wie viele Workspaces und Agenten kann ich anlegen?

Keine harten Grenzen. Dutzende (sogar Hunderte) sind möglich, aber beachten:

Plattenwachstum: Sessions + Transkripte liegen unter ~/.clawdbot/agents/<agentId>/sessions/.
Token-Kosten: mehr Agenten bedeuten mehr parallele Modellnutzung.
Betriebsaufwand: Auth-Profile, Workspaces und Channel-Routing pro Agent.

Tipps:

Pro Agent einen aktiven Workspace halten (agents.defaults.workspace).
Alte Sessions ausdünnen (JSONL oder Store-Einträge löschen), wenn die Platte wächst.
openclaw doctor nutzen, um verwaiste Workspaces und Profil-Abweichungen zu finden.

Kann ich mehrere Bots/Chats gleichzeitig betreiben (z. B. Slack), und wie richte ich das ein?

Ja. Multi-Agent-Routing nutzen, um mehrere isolierte Agenten zu betreiben und eingehende Nachrichten nach Kanal/Konto/Peer zu routen. Slack wird als Kanal unterstützt und kann an bestimmte Agenten gebunden werden. Browser-Zugriff ist mächtig, aber nicht „alles, was ein Mensch kann“ – Anti-Bot, CAPTCHAs und MFA können Automatisierung blockieren. Für zuverlässige Browser-Steuerung die Chrome-Erweiterung als Relay auf der Maschine nutzen, die den Browser ausführt (Gateway kann woanders laufen). Empfohlenes Setup:

Immer-an Gateway-Host (VPS/Mac mini).
Ein Agent pro Rolle (Bindings).
Slack-Kanal(e) an diese Agenten gebunden.
Lokaler Browser per Extension-Relay (oder Node) bei Bedarf.

Doku: Multi-Agent-Routing, Slack, Browser, Chrome-Erweiterung, Nodes.

Modelle: Standard, Auswahl, Aliase, Wechsel

Was ist das „Standardmodell“?

Das Standardmodell von OpenClaw ist das, was du setzt als:


agents.defaults.model.primary

Modelle werden als provider/model referenziert (z. B. anthropic/claude-opus-4-5). Wenn du den Provider weglässt, nimmt OpenClaw derzeit anthropic als temporären Fallback an – du solltest aber explizit provider/model setzen.

Welches Modell empfehlt ihr?

Empfohlenes Standardmodell: anthropic/claude-opus-4-5.

Gute Alternative: anthropic/claude-sonnet-4-5.

Zuverlässig (weniger Charakter): openai/gpt-5.2 – fast so gut wie Opus, weniger Persönlichkeit.

Budget: zai/glm-4.7. MiniMax M2.1 hat eine eigene Doku: MiniMax und Lokale Modelle. Faustregel: für anspruchsvolle Arbeit das beste Modell, das du dir leisten kannst, für Routine-Chat oder Zusammenfassungen ein günstigeres. Du kannst Modelle pro Agent routen und Sub-Agenten nutzen, um lange Aufgaben zu parallelisieren (jeder Sub-Agent verbraucht Tokens). Siehe Modelle und Sub-Agenten. Wichtiger Hinweis: schwächere/überquantisierte Modelle sind anfälliger für Prompt-Injection und unsicheres Verhalten. Siehe Sicherheit. Mehr Kontext: Modelle.

Kann ich Self-Hosted-Modelle (llama.cpp, vLLM, Ollama) nutzen?

Ja. Stellt dein lokaler Server eine OpenAI-kompatible API bereit, kannst du einen benutzerdefinierten Provider darauf zeigen. Ollama wird direkt unterstützt und ist der einfachste Weg. Sicherheitshinweis: Kleinere oder stark quantisierte Modelle sind anfälliger für Prompt-Injection. Wir empfehlen große Modelle für Bots mit Tools. Bei kleinen Modellen: Sandboxing und strenge Tool-Allowlists aktivieren. Doku: Ollama, Lokale Modelle, Modellanbieter, Sicherheit, Sandboxing.

Wie wechsle ich das Modell, ohne meine Config zu löschen?

Modell-Befehle nutzen oder nur die model-Felder bearbeiten. Vollständige Config-Ersetzungen vermeiden. Sichere Optionen:

/model im Chat (schnell, pro Session)
openclaw models set ... (aktualisiert nur die Modell-Config)
openclaw configure --section models (interaktiv)
agents.defaults.model in ~/.clawdbot/openclaw.json bearbeiten

config.apply mit einem Teilobjekt vermeiden, außer du willst die gesamte Config ersetzen. Bei überschriebener Config: aus Backup wiederherstellen oder openclaw doctor erneut ausführen. Doku: Modelle, Configure, Config, Doctor.

Welche Modelle nutzen Clawd, Flawd und Krill?

Clawd + Flawd: Anthropic Opus (anthropic/claude-opus-4-5) – siehe Anthropic.
Krill: MiniMax M2.1 (minimax/MiniMax-M2.1) – siehe MiniMax.

Wie wechsle ich das Modell im laufenden Betrieb (ohne Neustart)?

Den Befehl /model als eigenständige Nachricht nutzen:


/model sonnet
/model haiku
/model opus
/model gpt
/model gpt-mini
/model gemini
/model gemini-flash

Verfügbare Modelle mit /model, /model list oder /model status anzeigen. /model (und /model list) zeigt eine kompakte nummerierte Auswahl. Nach Nummer wählen:


/model 3

Du kannst auch ein bestimmtes Auth-Profil für den Provider erzwingen (pro Session):


/model opus@anthropic:default
/model opus@anthropic:work

Tipp: /model status zeigt, welcher Agent aktiv ist, welche auth-profiles.json genutzt wird und welches Auth-Profil als nächstes versucht wird. Außerdem werden der konfigurierte Provider-Endpoint (baseUrl) und API-Modus (api) angezeigt, sofern vorhanden. Profil wieder lösen: /model ohne @profile-Suffix erneut ausführen:


/model anthropic/claude-opus-4-5

Zurück zum Standard: in /model wählen (oder /model <default provider/model> senden). Mit /model status prüfen, welches Auth-Profil aktiv ist.

Kann ich GPT 5.2 für Alltagsaufgaben und Codex 5.2 für Coding nutzen?

Ja. Eines als Standard setzen und bei Bedarf wechseln:

Quick switch (per session):/model gpt-5.2 for daily tasks, /model gpt-5.2-codex for coding.
Default + switch: set agents.defaults.model.primary to openai-codex/gpt-5.2, then switch to openai-codex/gpt-5.2-codex when coding (or the other way around).
Sub-agents: route coding tasks to sub-agents with a different default model.

Siehe Modelle und Slash-Befehle.

Warum sehe ich „Model … is not allowed“ und dann keine Antwort?

Ist agents.defaults.models gesetzt, wird es zur Allowlist für /model und Session-Overrides. Ein Modell außerhalb der Liste führt zu:


Model "provider/model" is not allowed. Use /model to list available models.

That error is returned instead of a normal reply. Fix: add the model to agents.defaults.models, remove the allowlist, or pick a model from /model list.

Warum sehe ich „Unknown model: minimax/MiniMax-M2.1“?

Das bedeutet, der Provider ist nicht konfiguriert (keine MiniMax-Provider-Config oder Auth-Profil gefunden), das Modell kann nicht aufgelöst werden. Eine Korrektur dafür ist in 2026.1.12 (zum Schreibzeitpunkt noch nicht veröffentlicht). Checkliste:

Upgrade to 2026.1.12 (or run from source main), then restart the gateway.
Make sure MiniMax is configured (wizard or JSON), or that a MiniMax API key exists in env/auth profiles so the provider can be injected.
Use the exact model id (case‑sensitive): minimax/MiniMax-M2.1 or minimax/MiniMax-M2.1-lightning.
Run:


openclaw models list

and pick from the list (or /model list in chat).

Siehe MiniMax und Modelle.

Kann ich MiniMax als Standard und OpenAI für komplexe Aufgaben nutzen?

Ja. MiniMax als Standard setzen und Modelle pro Session bei Bedarf wechseln. Fallbacks are for errors, not “hard tasks,” so use /model or a separate agent.Option A: switch per session


{
  env: { MINIMAX_API_KEY: "sk-...", OPENAI_API_KEY: "sk-..." },
  agents: {
    defaults: {
      model: { primary: "minimax/MiniMax-M2.1" },
      models: {
        "minimax/MiniMax-M2.1": { alias: "minimax" },
        "openai/gpt-5.2": { alias: "gpt" }
      }
    }
  }
}

Then:


/model gpt

Option B: separate agents

Agent A default: MiniMax
Agent B default: OpenAI
Route by agent or use /agent to switch

Doku: Modelle, Multi-Agent-Routing, MiniMax, OpenAI.

Sind opus / sonnet / gpt eingebaute Shortcuts?

Ja. OpenClaw liefert einige Standard-Shortcuts (nur angewendet, wenn das Modell in agents.defaults.models existiert):

opus → anthropic/claude-opus-4-5
sonnet → anthropic/claude-sonnet-4-5
gpt → openai/gpt-5.2
gpt-mini → openai/gpt-5-mini
gemini → google/gemini-3-pro-preview
gemini-flash → google/gemini-3-flash-preview

Setzt du einen eigenen Alias mit demselben Namen, gewinnt dein Wert.

Wie definiere/überschreibe ich Modell-Shortcuts (Aliase)?

Aliase kommen aus agents.defaults.models.<modelId>.alias. Beispiel:


{
  agents: {
    defaults: {
      model: { primary: "anthropic/claude-opus-4-5" },
      models: {
        "anthropic/claude-opus-4-5": { alias: "opus" },
        "anthropic/claude-sonnet-4-5": { alias: "sonnet" },
        "anthropic/claude-haiku-4-5": { alias: "haiku" }
      }
    }
  }
}

Dann löst /model sonnet (oder /<alias> wo unterstützt) auf diese Modell-ID auf.

Wie füge ich Modelle von anderen Anbietern (z. B. OpenRouter, Z.AI) hinzu?

OpenRouter (pay‑per‑token; many models):


{
  agents: {
    defaults: {
      model: { primary: "openrouter/anthropic/claude-sonnet-4-5" },
      models: { "openrouter/anthropic/claude-sonnet-4-5": {} }
    }
  },
  env: { OPENROUTER_API_KEY: "sk-or-..." }
}

Z.AI (GLM models):


{
  agents: {
    defaults: {
      model: { primary: "zai/glm-4.7" },
      models: { "zai/glm-4.7": {} }
    }
  },
  env: { ZAI_API_KEY: "..." }
}

Verweist du auf einen Provider/Modell, dessen Provider-Key fehlt, erhältst du einen Laufzeit-Auth-Fehler (z. B. No API key found for provider "zai"). No API key found for provider after adding a new agent: Das bedeutet meist, der neue Agent hat einen leeren Auth-Store. Auth ist pro Agent und wird gespeichert in:


~/.clawdbot/agents/<agentId>/agent/auth-profiles.json

Abhilfe:

openclaw agents add <id> ausführen und Auth im Assistenten konfigurieren.
Oder auth-profiles.json vom Haupt-Agenten aus dessen agentDir in die agentDir des neuen Agenten kopieren.

Nicht dieselbe agentDir für mehrere Agenten wiederverwenden – das führt zu Auth-/Session-Kollisionen.

Modell-Failover und „Alle Modelle fehlgeschlagen“

Wie funktioniert Failover?

Failover läuft in zwei Stufen:

Auth-Profil-Rotation innerhalb desselben Providers.
Modell-Failover auf das nächste Modell in agents.defaults.model.fallbacks.

Cooldowns gelten für fehlschlagende Profile (exponentieller Backoff), sodass OpenClaw weiter antworten kann, wenn ein Provider rate-limited oder vorübergehend ausgefallen ist.

Was bedeutet dieser Fehler?


No credentials found for profile "anthropic:default"

Das System hat versucht, das Auth-Profil anthropic:default zu nutzen, konnte dafür aber keine Credentials im erwarteten Auth-Store finden.

Checkliste: „No credentials found for profile anthropic:default“

Prüfen, wo Auth-Profile liegen (neue vs. Legacy-Pfade)
- Aktuell: ~/.clawdbot/agents/<agentId>/agent/auth-profiles.json
- Legacy: ~/.clawdbot/agent/* (Migration mit openclaw doctor)
Prüfen, ob die Umgebungsvariable vom Gateway geladen wird
- Wenn du ANTHROPIC_API_KEY in der Shell setzt, das Gateway aber über systemd/launchd startest, erbt es die Variable ggf. nicht. In ~/.clawdbot/.env eintragen oder env.shellEnv aktivieren.
Sicherstellen, dass du den richtigen Agenten bearbeitest
- Bei Multi-Agent-Setups kann es mehrere auth-profiles.json-Dateien geben.
Modell-/Auth-Status prüfen
- openclaw models status ausführen, um konfigurierte Modelle und Provider-Auth zu sehen.

Checkliste: No credentials found for profile anthropic Der Lauf ist auf ein Anthropic-Auth-Profil festgelegt, das Gateway findet es aber nicht im Auth-Store.

Setup-Token nutzen
- claude setup-token ausführen, dann mit openclaw models auth setup-token --provider anthropic einfügen.
- Wurde der Token auf einer anderen Maschine erstellt: openclaw models auth paste-token --provider anthropic.
Stattdessen API-Key nutzen
- ANTHROPIC_API_KEY in ~/.clawdbot/.env auf dem Gateway-Host eintragen.
- Eine feste Reihenfolge entfernen, die ein fehlendes Profil erzwingt:


openclaw models auth order clear --provider anthropic

Stelle sicher, dass du Befehle auf dem Gateway-Host ausführst
- Im Remote-Modus liegen Auth-Profile auf der Gateway-Maschine, nicht auf deinem Laptop.

Warum hat es auch Google Gemini versucht und ist fehlgeschlagen?

Wenn deine Modell-Config Google Gemini als Fallback enthält (oder du auf eine Gemini-Kurzform umgestellt hast), versucht OpenClaw es beim Modell-Failover. Ohne konfigurierte Google-Credentials siehst du No API key found for provider "google". Abhilfe: entweder Google-Auth hinterlegen oder Google-Modelle in agents.defaults.model.fallbacks / Aliase entfernen bzw. vermeiden, damit der Failover nicht dorthin geht. LLM request rejected message thinking signature required google antigravity: Ursache: Die Session-Historie enthält Thinking-Blöcke ohne Signatur (oft nach abgebrochenem/teilweisem Stream). Google Antigravity verlangt Signaturen für Thinking-Blöcke. Abhilfe: OpenClaw entfernt inzwischen unsignierte Thinking-Blöcke für Google Antigravity Claude. Wenn es weiter auftritt, starte eine neue Session oder setze /thinking off für diesen Agenten.

Auth-Profile: was sie sind und wie man sie verwaltet

Siehe auch: OAuth-Konzepte (OAuth-Flows, Token-Speicherung, Multi-Account-Muster)

Was ist ein Auth-Profil?

Ein Auth-Profil ist ein benannter Credential-Eintrag (OAuth oder API-Key) für einen Provider. Profile liegen in:


~/.clawdbot/agents/<agentId>/agent/auth-profiles.json

Was sind typische Profil-IDs?

OpenClaw nutzt providerpräfixierte IDs wie:

anthropic:default (üblich, wenn keine E-Mail-Identität existiert)
anthropic:<email> für OAuth-Identitäten
selbst gewählte IDs (z. B. anthropic:work)

Kann ich steuern, welches Auth-Profil zuerst versucht wird?

Ja. Die Config unterstützt optionale Metadaten für Profile und eine Reihenfolge pro Provider (auth.order.<provider>). Dabei werden keine Geheimnisse gespeichert; es werden IDs auf Provider/Modus abgebildet und die Rotationsreihenfolge festgelegt. OpenClaw kann ein Profil vorübergehend überspringen, wenn es in einer kurzen Cooldown (Rate-Limits/Timeouts/Auth-Fehler) oder einem längeren disabled-Zustand (Abrechnung/unzureichende Credits) ist. Zum Prüfen: openclaw models status --json und auth.unusableProfiles prüfen. Tuning: auth.cooldowns.billingBackoffHours*. Du kannst auch eine pro Agent geltende Reihenfolge (gespeichert in dessen auth-profiles.json) per CLI setzen:


# Defaults to the configured default agent (omit --agent)
openclaw models auth order get --provider anthropic

# Lock rotation to a single profile (only try this one)
openclaw models auth order set --provider anthropic anthropic:default

# Or set an explicit order (fallback within provider)
openclaw models auth order set --provider anthropic anthropic:work anthropic:default

# Clear override (fall back to config auth.order / round-robin)
openclaw models auth order clear --provider anthropic

Für einen bestimmten Agenten:


openclaw models auth order set --provider anthropic --agent main anthropic:default

OAuth vs. API-Key – was ist der Unterschied?

OpenClaw unterstützt beides:

OAuth nutzt oft Abo-Zugang (wo anwendbar).
API-Keys nutzen Pay-per-Token-Abrechnung.

Der Assistent unterstützt ausdrücklich Anthropic Setup-Token und OpenAI Codex OAuth und kann API-Keys für dich speichern.

Gateway: Ports, „bereits läuft“ und Remote-Modus

Welchen Port nutzt das Gateway?

gateway.port steuert den einzigen gemultiplexten Port für WebSocket + HTTP (Control-UI, Hooks usw.). Reihenfolge:


--port > CLAWDBOT_GATEWAY_PORT > gateway.port > default 18789

Warum zeigt „openclaw gateway status“ Runtime: running, aber RPC probe: failed?

„Running“ ist die Sicht des Supervisors (launchd/systemd/schtasks). Der RPC-Probe ist die CLI, die sich tatsächlich zum Gateway-WebSocket verbindet und status aufruft. Nutze openclaw gateway status und vertraue diesen Zeilen:

Probe target: (die vom Probe genutzte URL)
Listening: (was tatsächlich am Port gebunden ist)
Last gateway error: (häufige Ursache, wenn der Prozess läuft, aber der Port nicht hört)

Warum zeigen „openclaw gateway status“ Config (cli) und Config (service) unterschiedlich?

Du bearbeitest eine Config-Datei, während der Service eine andere nutzt (oft --profile- / CLAWDBOT_STATE_DIR-Abweichung). Abhilfe:


openclaw gateway install --force

Führe das in derselben --profile-Umgebung aus, die der Service nutzen soll.

Was bedeutet „another gateway instance is already listening“?

OpenClaw erzwingt eine Laufzeit-Sperre, indem der WebSocket-Listener sofort beim Start gebunden wird (Standard ws://127.0.0.1:18789). Schlägt das Binden mit EADDRINUSE fehl, wird GatewayLockError geworfen (anderer Instance hört bereits). Abhilfe: andere Instance stoppen, Port freigeben oder mit openclaw gateway --port <port> starten.

Wie betreibe ich OpenClaw im Remote-Modus (Client verbindet sich mit einem Gateway woanders)?

Setze gateway.mode: "remote" und verweise auf eine entfernte WebSocket-URL, optional mit Token/Passwort:


{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://gateway.tailnet:18789",
      token: "your-token",
      password: "your-password"
    }
  }
}

Hinweise:

openclaw gateway startet nur, wenn gateway.mode local ist (oder du das Override-Flag übergibst).
Die macOS-App beobachtet die Config-Datei und wechselt live den Modus, wenn sich diese Werte ändern.

Die Control-UI meldet „unauthorized“ (oder verbindet ständig neu). Was tun?

Dein Gateway läuft mit aktivierter Auth (gateway.auth.*), die UI sendet aber keinen passenden Token/kein Passwort. Fakten (aus dem Code):

Die Control-UI speichert den Token im Browser unter localStorage-Key openclaw.control.settings.v1.
Die UI kann ?token=... (und/oder ?password=...) einmal übernehmen und entfernt es danach aus der URL.

Abhilfe:

Am schnellsten: openclaw dashboard (gibt tokenisierten Link aus + kopiert, versucht zu öffnen; zeigt SSH-Hinweis bei Headless).
Noch keinen Token: openclaw doctor --generate-gateway-token.
Remote: zuerst Tunnel: ssh -N -L 18789:127.0.0.1:18789 user@host, dann http://127.0.0.1:18789/?token=... öffnen.
Auf dem Gateway-Host gateway.auth.token (oder CLAWDBOT_GATEWAY_TOKEN) setzen.
In den Control-UI-Einstellungen denselben Token einfügen (oder mit einmaligem ?token=...-Link aktualisieren).
Immer noch fest? openclaw status --all ausführen und Fehlerbehebung folgen. Siehe Dashboard für Auth-Details.

Ich habe gateway.bind: „tailnet“ gesetzt – es kann nicht binden / nichts hört

tailnet-Bind wählt eine Tailscale-IP aus deinen Netzwerkschnittstellen (100.64.0.0/10). Ist die Maschine nicht in Tailscale (oder die Schnittstelle down), gibt es nichts zum Binden. Abhilfe:

Tailscale auf diesem Host starten (damit eine 100.x-Adresse existiert), oder
Auf gateway.bind: "loopback" / "lan" wechseln.

Hinweis: tailnet ist explizit. auto bevorzugt Loopback; nutze gateway.bind: "tailnet" für reinen Tailnet-Bind.

Kann ich mehrere Gateways auf demselben Host betreiben?

In der Regel nein – ein Gateway kann mehrere Messaging-Kanäle und Agenten betreiben. Mehrere Gateways nur bei Redundanz (z. B. Rettungs-Bot) oder harter Isolation. Ja, aber du musst isolieren:

CLAWDBOT_CONFIG_PATH (Config pro Instance)
CLAWDBOT_STATE_DIR (State pro Instance)
agents.defaults.workspace (Workspace-Isolation)
gateway.port (eindeutige Ports)

Schnelle Einrichtung (empfohlen):

Pro Instance openclaw --profile <name> … (erzeugt ~/.clawdbot-<name>).
In jeder Profil-Config einen eigenen gateway.port setzen (oder --port bei manuellen Läufen).
Pro Profil Service installieren: openclaw --profile <name> gateway install.

Profile hängen auch an Service-Namen an (bot.molt.<profile>; Legacy com.clawdbot.*, openclaw-gateway-<profile>.service, OpenClaw Gateway (<profile>)). Vollständige Anleitung: Mehrere Gateways.

Was bedeuten „invalid handshake“ / Code 1008?

Das Gateway ist ein WebSocket-Server und erwartet als erste Nachricht einen connect-Frame. Bei etwas anderem schließt es die Verbindung mit Code 1008 (Policy-Verletzung). Häufige Ursachen:

Du hast die HTTP-URL im Browser geöffnet (http://...) statt in einem WS-Client.
Falscher Port oder Pfad.
Proxy oder Tunnel hat Auth-Header entfernt oder eine Nicht-Gateway-Anfrage gesendet.

Schnelle Abhilfe:

WS-URL nutzen: ws://<host>:18789 (oder wss://... bei HTTPS).
WS-Port nicht in einem normalen Browser-Tab öffnen.
Bei aktivierter Auth Token/Passwort im connect-Frame mitsenden.

Bei Nutzung von CLI oder TUI sollte die URL so aussehen:


openclaw tui --url ws://<host>:18789 --token <token>

Protokoll-Details: Gateway-Protokoll.

Logging und Debugging

Wo sind die Logs?

File logs (structured):


/tmp/openclaw/openclaw-YYYY-MM-DD.log

Einen festen Pfad kannst du über logging.file setzen. Die Datei-Log-Stufe steuert logging.level. Die Konsolen-Ausführlichkeit steuern --verbose und logging.consoleLevel. Schnellster Log-Tail:


openclaw logs --follow

Service-/Supervisor-Logs (wenn das Gateway über launchd/systemd läuft):

macOS: $CLAWDBOT_STATE_DIR/logs/gateway.log und gateway.err.log (Standard: ~/.clawdbot/logs/...; Profile nutzen ~/.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

Mehr dazu: Fehlerbehebung.

Wie starte/stoppe/starte ich den Gateway-Service neu?

Nutze die Gateway-Helfer:


openclaw gateway status
openclaw gateway restart

Läuft das Gateway manuell, kann openclaw gateway --force den Port zurückholen. Siehe Gateway.

Ich habe mein Terminal unter Windows geschlossen – wie starte ich OpenClaw neu?

Es gibt zwei Windows-Installationsmodi: 1) WSL2 (empfohlen): Das Gateway läuft unter Linux. PowerShell öffnen, WSL starten, dann neu starten:


wsl
openclaw gateway status
openclaw gateway restart

Wenn du den Service nie installiert hast, starte ihn im Vordergrund:


openclaw gateway run

2) Native Windows (nicht empfohlen): Das Gateway läuft direkt unter Windows. PowerShell öffnen und ausführen:


openclaw gateway status
openclaw gateway restart

Bei manuellem Lauf (ohne Service) nutzen:


openclaw gateway run

Doku: Windows (WSL2), Gateway-Service-Runbook.

Das Gateway läuft, aber Antworten kommen nie – was soll ich prüfen?

Mit einer schnellen Health-Prüfung starten:


openclaw status
openclaw models status
openclaw channels status
openclaw logs --follow

Häufige Ursachen:

Modell-Auth auf dem Gateway-Host nicht geladen (prüfe models status).
Kanal-Pairing/Allowlist blockiert Antworten (Kanal-Config + Logs prüfen).
WebChat/Dashboard ohne passenden Token geöffnet.

Bei Remote: prüfen, ob Tunnel/Tailscale-Verbindung steht und das Gateway-WebSocket erreichbar ist. Doku: Kanäle, Fehlerbehebung, Remote-Zugriff.

„Disconnected from gateway: no reason“ – was tun?

Das bedeutet meist, die UI hat die WebSocket-Verbindung verloren. Prüfen:

Läuft das Gateway? openclaw gateway status
Ist das Gateway gesund? openclaw status
Hat die UI den richtigen Token? openclaw dashboard
Bei Remote: steht der Tunnel-/Tailscale-Link?

Dann Logs verfolgen:


openclaw logs --follow

Doku: Dashboard, Remote-Zugriff, Fehlerbehebung.

Telegram setMyCommands schlägt mit Netzwerkfehlern fehl – was prüfen?

Mit Logs und Kanal-Status starten:


openclaw channels status
openclaw channels logs --channel telegram

Bei VPS oder hinter Proxy: prüfen, ob ausgehendes HTTPS erlaubt ist und DNS funktioniert. Ist das Gateway remote, Logs auf dem Gateway-Host prüfen. Doku: Telegram, Kanal-Fehlerbehebung.

Die TUI zeigt keine Ausgabe – was prüfen?

Zuerst prüfen, ob das Gateway erreichbar ist und der Agent laufen kann:


openclaw status
openclaw models status
openclaw logs --follow

In der TUI /status nutzen für den aktuellen Zustand. Erwartest du Antworten in einem Chat-Kanal, stelle /deliver on. Doku: TUI, Slash-Befehle.

Wie stoppe ich das Gateway vollständig und starte es dann neu?

Wenn du den Service installiert hast:


openclaw gateway stop
openclaw gateway start

Das stoppt/startet den überwachten Service (launchd unter macOS, systemd unter Linux). Nutze das, wenn das Gateway im Hintergrund als Daemon läuft. Läuft es im Vordergrund, mit Ctrl‑C stoppen, dann:


openclaw gateway run

Doku: Gateway-Service-Runbook.

ELI5: openclaw gateway restart vs. openclaw gateway

openclaw gateway restart: startet den Hintergrund-Service neu (launchd/systemd).
openclaw gateway: führt das Gateway im Vordergrund für diese Terminal-Session aus.

Bei installiertem Service die Gateway-Befehle nutzen. openclaw gateway nutzen für einen einmaligen Vordergrund-Lauf.

Was ist der schnellste Weg zu mehr Details, wenn etwas fehlschlägt?

Gateway mit --verbose starten für mehr Konsolen-Detail. Anschließend die Log-Datei auf Kanal-Auth, Modell-Routing und RPC-Fehler prüfen.

Medien & Anhänge

Mein Skill hat ein Bild/PDF erzeugt, aber nichts wurde gesendet

Ausgehende Anhänge vom Agenten müssen eine Zeile MEDIA:<pfad-oder-url> enthalten (eigene Zeile). Siehe OpenClaw-Assistenten-Setup und Agent send. CLI-Versand:


openclaw message send --target +15555550123 --message "Here you go" --media /path/to/file.png

Außerdem prüfen:

Der Zielkanal unterstützt ausgehende Medien und wird nicht von Allowlists blockiert.
Die Datei liegt innerhalb der Größenlimits des Anbieters (Bilder werden auf max. 2048px skaliert).

Siehe Bilder.

Sicherheit und Zugriffskontrolle

Ist es sicher, OpenClaw für eingehende DMs zu exponieren?

Eingehende DMs als nicht vertrauenswürdige Eingabe behandeln. Die Standardeinstellungen sind auf Risikominderung ausgelegt:

Standard auf DM-fähigen Kanälen ist Pairing:
- Unbekannte Absender erhalten einen Pairing-Code; der Bot verarbeitet ihre Nachricht nicht.
- Freigabe: openclaw pairing approve <channel> <code>
- Ausstehende Anfragen sind auf 3 pro Kanal begrenzt; bei fehlendem Code: openclaw pairing list <channel> prüfen.
Öffentliche DMs erfordern explizites Opt-in (dmPolicy: "open" und Allowlist "*").

openclaw doctor ausführen, um riskante DM-Richtlinien anzuzeigen.

Ist Prompt-Injection nur bei öffentlichen Bots ein Thema?

Nein. Prompt-Injection betrifft nicht vertrauenswürdige Inhalte, nicht nur wer dem Bot DMs schicken kann. Liest dein Assistent externe Inhalte (Web-Suche/-Fetch, Browser-Seiten, E-Mails, Docs, Anhänge, eingefügte Logs), können darin Anweisungen stecken, die das Modell kapern wollen. Das kann auch passieren, wenn nur du der Absender bist. Das größte Risiko besteht bei aktivierten Tools: Das Modell kann dazu gebracht werden, Kontext abzuziehen oder Tools in deinem Namen aufzurufen. Risiko begrenzen durch:

einen nur lesenden oder tool-deaktivierten „Reader“-Agenten zum Zusammenfassen nicht vertrauenswürdiger Inhalte
web_search / web_fetch / browser für Tool-Agenten aus lassen
Sandboxing und strenge Tool-Allowlists

Details: Sicherheit.

Soll mein Bot eine eigene E-Mail / ein eigenes GitHub-Konto / eine eigene Nummer haben?

Ja, für die meisten Setups. Den Bot mit getrennten Konten und Nummern zu isolieren verringert den Schaden bei Problemen und erleichtert das Rotieren von Credentials oder Widerrufen von Zugriff ohne Auswirkung auf deine privaten Konten. Klein anfangen: Nur den nötigen Tools und Konten Zugriff geben und bei Bedarf erweitern. Doku: Sicherheit, Pairing.

Kann ich ihm Autonomie über meine SMS geben – und ist das sicher?

Wir empfehlen keine volle Autonomie über deine persönlichen Nachrichten. Das sicherste Muster:

DMs im Pairing-Modus oder enger Allowlist halten.
Eine eigene Nummer oder Konto nutzen, wenn es in deinem Namen schreiben soll.
Entwurf erstellen lassen, dann vor dem Senden freigeben.

Zum Experimentieren ein dediziertes Konto nutzen und isoliert halten. Siehe Sicherheit.

Kann ich günstigere Modelle für persönliche Assistenten-Aufgaben nutzen?

Ja, wenn der Agent nur Chat ist und die Eingabe vertrauenswürdig. Kleinere Modelle sind anfälliger für Instruction-Hijacking; sie für Tool-Agenten oder bei nicht vertrauenswürdigen Inhalten vermeiden. Bei kleinerem Modell: Tools einschränken und in einer Sandbox laufen lassen. Siehe Sicherheit.

Ich habe /start in Telegram ausgeführt, aber keinen Pairing-Code bekommen

Pairing-Codes werden nur gesendet, wenn ein unbekannter Absender den Bot anschreibt und dmPolicy: "pairing" aktiv ist. /start allein erzeugt keinen Code. Ausstehende Anfragen prüfen:


openclaw pairing list telegram

Für sofortigen Zugriff deine Sender-ID in die Allowlist aufnehmen oder dmPolicy: "open" für dieses Konto setzen.

WhatsApp: Schreibt es meinen Kontakten? Wie funktioniert Pairing?

Nein. Standard-WasApp-DM-Richtlinie ist Pairing. Unbekannte Absender erhalten nur einen Pairing-Code, ihre Nachricht wird nicht verarbeitet. OpenClaw antwortet nur auf Chats, die es erhält, oder auf explizite Sends von dir. Pairing freigeben mit:


openclaw pairing approve whatsapp <code>

Ausstehende Anfragen auflisten:


openclaw pairing list whatsapp

Assistenten-Abfrage zur Telefonnummer: Sie dient dazu, deine Allowlist/Owner zu setzen, damit deine eigenen DMs erlaubt sind. Sie wird nicht für Auto-Versand genutzt. Bei persönlicher WhatsApp-Nummer diese Nummer nutzen und channels.whatsapp.selfChatMode aktivieren.

Chat-Befehle, Aufgaben abbrechen und „es hört nicht auf“

Wie verhindere ich, dass interne Systemnachrichten im Chat erscheinen?

Die meisten internen oder Tool-Nachrichten erscheinen nur, wenn verbose oder reasoning für diese Session aktiv ist. Abhilfe im Chat, wo es auftritt:


/verbose off
/reasoning off

Wenn es weiter stört: Session-Einstellungen in der Control-UI prüfen und verbose auf inherit setzen. Außerdem prüfen, ob kein Bot-Profil mit verboseDefault: on in der Config genutzt wird. Doku: Thinking und verbose, Sicherheit.

Wie stoppe/breche ich eine laufende Aufgabe ab?

Einen davon als eigenständige Nachricht senden (ohne Slash):


stop
abort
esc
wait
exit
interrupt

Das sind Abbruch-Trigger (keine Slash-Befehle). Bei Hintergrundprozessen (vom Exec-Tool) kannst du den Agenten bitten, auszuführen:


process action:kill sessionId:XXX

Überblick Slash-Befehle: Slash-Befehle. Die meisten Befehle müssen als eigenständige Nachricht mit / gesendet werden; einige Shortcuts (z. B. /status) funktionieren auch inline für erlaubte Absender.

Wie sende ich eine Discord-Nachricht von Telegram? („Cross-context messaging denied“)

OpenClaw blockiert anbieterübergreifende Nachrichten standardmäßig. Ist ein Tool-Aufruf an Telegram gebunden, wird nicht an Discord gesendet, außer du erlaubst es ausdrücklich. Anbieterübergreifende Nachrichten für den Agenten aktivieren:


{
  agents: {
    defaults: {
      tools: {
        message: {
          crossContext: {
            allowAcrossProviders: true,
            marker: { enabled: true, prefix: "[from {channel}] " }
          }
        }
      }
    }
  }
}

Nach Config-Änderung das Gateway neu starten. Soll es nur für einen Agenten gelten, unter agents.list[].tools.message setzen.

Warum wirkt es, als ignoriere der Bot Schnellfeuer-Nachrichten?

Der Queue-Modus steuert, wie neue Nachrichten mit einem laufenden Lauf interagieren. Mit /queue den Modus wechseln:

steer – neue Nachrichten lenken die aktuelle Aufgabe um
followup – Nachrichten nacheinander abarbeiten
collect – Nachrichten sammeln und einmal antworten (Standard)
steer-backlog – jetzt steuern, dann Backlog abarbeiten
interrupt – aktuellen Lauf abbrechen und neu starten

Für Followup-Modi kannst du Optionen wie debounce:2s cap:25 drop:summarize setzen.

Die exakte Frage aus Screenshot/Chat-Log beantworten

F: „Was ist das Standardmodell für Anthropic mit API-Key?“ A: Bei OpenClaw sind Credentials und Modellauswahl getrennt. ANTHROPIC_API_KEY setzen (oder einen Anthropic-API-Key in Auth-Profilen speichern) aktiviert die Authentifizierung; das tatsächliche Standardmodell ist das, was du in agents.defaults.model.primary konfigurierst (z. B. anthropic/claude-sonnet-4-5 oder anthropic/claude-opus-4-5). Bei No credentials found for profile "anthropic:default" hat das Gateway keine Anthropic-Credentials in der erwarteten auth-profiles.json des laufenden Agenten gefunden.

Immer noch fest? Frage in Discord oder öffne eine GitHub-Diskussion .