Persönliches OpenClaw-Gateway einrichten: Installation, Onboarding und Dashboard

OpenClaw ist ein selbst gehostetes Multikanal-Gateway für KI-Agenten. Ein einzelner Gateway-Prozess bildet die Steuerungsebene für Sitzungen, Kanal-Plugins und Werkzeuge. Sie kommunizieren über Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo oder weitere Kanal-Plugins und erhalten Agentenantworten, ohne Ihren Arbeitsalltag einem gehosteten Chatbot-Dienst zu überlassen.

Dokumentation: docs.openclaw.ai. Website: openclaw.ai. Lizenz: MIT; offen entwickelt gemeinsam mit der gemeinnützigen OpenClaw Foundation.

Dieser Artikel führt Sie durch die Einrichtung eines persönlichen Gateways. Die nächsten Artikel behandeln Allowlists und Pairing sowie Skills, Heartbeat und Freigaben. Wann OpenClaw oder Hermes besser passt, erläutert der Vergleich nach Aufgabe.

Ein frisch installiertes Gateway mit aktivierten Werkzeugen verfügt über weitreichende Berechtigungen. Shell-, Datei- und Browserfunktionen können es einer fremden Person, die den Bot anschreiben darf, ermöglichen, unsichere Aktionen zu veranlassen. Schließen Sie die Installation ab und richten Sie anschließend Allowlists und Pairing ein, bevor Sie einen öffentlich erreichbaren Kanal verbinden oder Werkzeuge mit erhöhten Berechtigungen freischalten. Beachten Sie den Sicherheitsleitfaden von OpenClaw.

Funktionsweise des Gateways

Chat-Apps + Plugins → Gateway → Agentensitzung / Werkzeuge
                    ↘ Control UI (Browser)
                    ↘ CLI

Das Gateway ist die maßgebliche Steuerungsinstanz für Sitzungen, Weiterleitung und Kanalverbindungen. Die browserbasierte Control UI dient dem Chat, der Konfiguration und der Sitzungsverwaltung. Die Konfiguration liegt standardmäßig unter ~/.openclaw/openclaw.json.

OpenClaw ist keine mandantenfähige Sicherheitsgrenze für einander nicht vertrauende Personen, die sich einen Agenten teilen. Das dokumentierte Vertrauensmodell sieht pro Gateway eine Grenze mit einem vertrauenswürdigen Betreiber vor. Betreiben Sie unterschiedliche Vertrauensbereiche als separate Gateways, idealerweise unter getrennten Betriebssystemkonten oder auf getrennten Hosts.

Node-Versionsanforderungen

Die aktuelle Dokumentation zur Node-Installation verlangt Node 22.22.3+, 24.15+ oder 25.9+ (damit ist Node 26 eingeschlossen). Node 26 ist die dokumentierte standardmäßige und empfohlene Laufzeitumgebung; Node 23 wird nicht unterstützt. Die Mindestversionen ändern sich. Prüfen Sie daher am Installationstag erneut Getting Started und die Node-Seite, statt einen älteren Stand zu übernehmen.

Installieren und Onboarding abschließen

Folgen Sie dem aktuellen Ablauf unter Getting Started:

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

onboard --install-daemon führt die geführte Einrichtung aus und installiert das Gateway als Daemon. Dadurch läuft es entsprechend dem Dienstmodell Ihrer Plattform auch nach Abmeldung oder Neustart weiter.

Sie benötigen für den gewählten Anbieter einen API-Schlüssel oder eine lokale Modellkonfiguration. Verwenden Sie für jeden Bot mit Werkzeugzugriff vorzugsweise ein leistungsfähiges Modell der aktuellen Generation. Schwächere Modelle lassen sich leichter durch Social Engineering zu einer unsicheren Werkzeugnutzung verleiten (Sicherheitsempfehlung).

Führen Sie nach dem Onboarding openclaw security audit aus und verwenden Sie --deep, sobald Sie für eine aktive Prüfung bereit sind. Beheben Sie Befunde zum eingehenden Zugriff und zur Netzwerkfreigabe, bevor Sie die Installation für den persönlichen Produktivbetrieb einsetzen.

Control UI öffnen

Standardmäßiges lokales Dashboard:

http://127.0.0.1:18789/

Oder:

openclaw dashboard

Nutzen Sie die UI, um eine erste Nachricht zu senden, Sitzungen zu prüfen und zu bestätigen, dass das Gateway läuft. Beschränken Sie die Control UI auf Loopback, sofern Sie nicht bewusst einen authentifizierten Fernzugriff eingerichtet haben. Tailscale und verwandte Muster beschreibt OpenClaw in den Hinweisen zum Fernzugriff. Machen Sie :18789 nicht ohne Authentifizierung im WAN erreichbar.

Zur gehärteten Ausgangskonfiguration aus der Sicherheitsdokumentation gehören gateway.mode: "local", bind: "loopback" und Token-Authentifizierung für das Gateway. Starten Sie geschlossen und öffnen Sie den Zugriff nur bewusst.

Konfigurationsort und Backups

Standardkonfiguration: ~/.openclaw/openclaw.json. Zugangsdaten und Pairing-Zustand liegen ebenfalls unter ~/.openclaw/. Vor Experimenten:

1. Kopieren Sie die Konfigurationsdatei in ein datiertes Backup außerhalb des Sync-Ordners, den Sie mit einem Team teilen.
2. Notieren Sie Ihre Node-Version (node -v) neben dem Backup.
3. Stellen Sie nach einer fehlerhaften Änderung am Fernzugriff das Backup wieder her und starten Sie den Daemon neu, statt bei offenen Kanälen am laufenden System zu debuggen.

Checken Sie keine echten Tokens in Git ein. Hinterlegen Sie eine geschwärzte Beispielkonfiguration in Ihrem Betriebshandbuch, wenn mehrere Personen die Struktur kennen müssen.

Häufige Installationsfallen

Bevorzugen Sie im Zweifel die offiziellen Einstiege Getting Started und Fehlerbehebung gegenüber Ratschlägen aus Foren.

Anbieter- und Modellkonfiguration

Während des Onboardings konfigurieren Sie für den Agenten entweder einen API-Schlüssel eines Cloud-Anbieters oder eine lokale beziehungsweise OpenAI-kompatible Basis-URL. Praktische Regeln:

• Verwenden Sie bei aktivierten Werkzeugen das leistungsfähigste aktuelle Modell, das Sie bezahlen oder selbst hosten möchten. Die Sicherheitsdokumentation von OpenClaw empfiehlt für Bots mit Werkzeugzugriff ausdrücklich moderne Modelle, die robust gegenüber manipulativen Anweisungen sind.
• Wenden Sie bei einem lokalen Endpunkt dieselbe Disziplin für private Netze und Authentifizierung an wie bei lokalen OpenAI-kompatiblen Endpunkten für n8n.
• Halten Sie Schlüssel aus Chatprotokollen und eingecheckten Konfigurationsbeispielen heraus.

Sie können die Modellwahl später verfeinern. Verschieben Sie Pairing und Allowlists nicht, während Sie mit Modellen experimentieren.

Daemon, Updates und Doctor

--install-daemon ist wichtig: Ein an ein Terminal gebundenes Gateway endet mit dem Terminal oder der SSH-Sitzung. Der Dienstmanager der Plattform kann das Gateway dagegen bei einer Anmeldung oder nach einem Neustart starten beziehungsweise neu starten. Ein Laptop im Ruhezustand kann dennoch keine Nachrichten verarbeiten. Verwenden Sie den Aktualisierungsweg der gewählten Installationsmethode und vermischen Sie nicht unbedacht die Zustände verschiedener Paketmanager. Führen Sie nach einem Upgrade die unterstützten Diagnosen aus:

openclaw doctor --fix   # when docs recommend it for config/monitor drift
openclaw security audit

Lesen Sie die Versionshinweise, wenn Sie mehrere Hauptversionen von Node oder OpenClaw überspringen. Prüfen Sie den Port der Control UI und die Authentifizierungseinstellungen nach jedem Versuch mit Fernzugriff erneut.

Erster Kanal mit überschaubarem Aufwand

Telegram ist oft der schnellste Kanal für einen persönlichen Smoke-Test. Für diesen Pfad:

1. Erstellen Sie das Bot-Token gemäß den aktuellen OpenClaw-Anweisungen für Telegram.
2. Verwenden Sie für einen Bot mit einer verantwortlichen Person vorzugsweise dmPolicy: "allowlist" und tragen Sie Ihre eindeutige numerische Telegram-Benutzer-ID in allowFrom ein.
3. Der standardmäßige pairing-Ablauf bleibt für das Onboarding gültig. Wenn Sie ihn nutzen, genehmigen Sie sich selbst mit openclaw pairing list telegram und openclaw pairing approve telegram <code>.
4. Behandeln Sie Pairing eng begrenzt: Es gewährt nur den Zugriff per Direktnachricht. Wenn noch keine für Befehle verantwortliche Person definiert ist, kann die erste genehmigte Paarung auch commands.ownerAllowFrom initialisieren. Die Gruppenautorisierung richtet sich weiterhin nach ausdrücklichen Allowlists in der Konfiguration.
5. Sperren Sie Gruppen für den ersten Funktionstest. Wenn Sie später eine Gruppe aktivieren, tragen Sie ihre stabile Gruppenchat-ID unter channels.telegram.groups ein, belassen Sie Absender-IDs in allowFrom oder groupAllowFrom und behalten Sie requireMention: true bei.

Gehärtete Ausgangskonfiguration für Telegram, abgeleitet aus der aktuellen Kanaldokumentation und der aktuellen Oberfläche für Ausführungsrichtlinien. Ersetzen Sie die beispielhafte Absender-ID und halten Sie die aktuelle Dokumentation geöffnet:

{
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: 'allowlist',
      allowFrom: ['123456789'],
      groupPolicy: 'allowlist',
      groups: {},
    },
  },
  session: { dmScope: 'per-channel-peer' },
  gateway: {
    mode: 'local',
    bind: 'loopback',
    auth: { mode: 'token', token: 'replace-with-a-secret-reference' },
  },
  tools: {
    profile: 'messaging',
    deny: [
      'group:automation',
      'group:runtime',
      'group:fs',
      'sessions_spawn',
      'sessions_send',
    ],
    fs: { workspaceOnly: true },
    exec: { mode: 'deny' },
    elevated: { enabled: false },
  },
}

Details und Fehlermodi beschreibt der Artikel Allowlists und Pairing.

Ablauf für den Funktionstest

1. Öffnen Sie http://127.0.0.1:18789/ und senden Sie „ping“ an sich selbst in der Control UI.
2. Bestätigen Sie, dass eine Sitzung erscheint und das Modell antwortet.
3. Verbinden Sie einen Kanal für Direktnachrichten und bestätigen Sie, dass Ihre ausdrücklich in die Allowlist aufgenommene primäre Identität den Agenten anschreiben kann. Wenn Sie bewusst Pairing testen, genehmigen Sie diese Identität zuerst.
4. Senden Sie eine Nachricht von einer zweiten Identität, die Sie kontrollieren. Bestätigen Sie mit dmPolicy: "allowlist", dass sie blockiert wird. Wenn Sie pairing testen, lassen Sie deren Anfrage ungenehmigt und bestätigen Sie, dass sie keinen Agentenlauf mit Werkzeugzugriff starten kann.
5. Führen Sie openclaw security audit aus und beheben Sie alle Befunde, die als open+tools oder public bind markiert sind.

Wenn Schritt 4 unsicher fehlschlägt und der unbekannte Absender einen vollständigen Agentenlauf mit Werkzeugzugriff erhält, stoppen Sie. Korrigieren Sie die DM-Richtlinie, bevor Sie weitere Integrationen einrichten.

Einordnung gegenüber n8n und Hermes

Die Systeme können nebeneinander eingesetzt werden. Eine mögliche Evaluierungsarchitektur nutzt n8n für geplante Prüfungen, Hermes für Aufgaben mit Ermessensspielraum und OpenClaw mit einer engen Allowlist für den Bereitschaftschat. Hermes bietet einen OpenAI-kompatiblen API-Server und einen separaten Webhook-Adapter für signierte Ereignisse. Wählen und dokumentieren Sie einen dieser Verträge, statt beide als austauschbar zu behandeln.

Die NemoClaw-Plattformunterstützungsmatrix von NVIDIA beschreibt eine separate, auf OpenShell basierende Alpha-Vorabversion. Sie kennzeichnet die Agentenpfade für OpenClaw und Hermes derzeit als getestet; für Plattform, Inferenz und Bereitstellung gelten jeweils eigene Einschränkungen. NemoClaw ist keine Voraussetzung für diese Laptop-Einrichtung, und NVIDIA bietet keine Produktions-SLA.

Persönliche Setup-Checkliste

• Unterstützte Node-Version installiert
• Offizielles Installationsprogramm oder ein anderer dokumentierter Installationspfad erfolgreich ausgeführt
• openclaw onboard --install-daemon abgeschlossen
• Control UI öffnet auf 127.0.0.1:18789
• openclaw security audit geprüft
• Erster Kanal nutzt eine explizite DM-Allowlist oder bewusst genehmigtes Pairing; Gruppenautorisierung ist separat
• Keine WAN-Bindung an Gateway- oder Modellports
• Anbieterschlüssel als Geheimnisse gespeichert, nicht im Chatverlauf
• Zweite Testidentität erreicht Tools vor Freigabe nicht

Kanalverläufe, Anhänge und Werkzeugausgaben können im Gateway-Zustand unter ~/.openclaw gespeichert werden. Behandeln Sie dieses Verzeichnis wie ein Postfach und einen Zugangsdaten-Speicher: Verwenden Sie Festplattenverschlüsselung und restriktive Dateiberechtigungen. Synchronisieren Sie das Zustandsverzeichnis nur nach einer bewussten Entscheidung mit gemeinsam genutzten Cloud-Ordnern.

Was am Ende des ersten Tages erreicht sein sollte

Sie können das Dashboard öffnen, sich selbst eine Direktnachricht senden und eine Sitzung sehen. Fertig sind Sie erst, wenn Pairing und Allowlists eingerichtet sind und Sie verstehen, welche Tools der Agent aufrufen kann. Eine Einrichtung ohne Sicherheitsprüfung ist nur eine Demo.

Nächster Schritt: Begrenzen Sie Identitäten und Gruppen. Fügen Sie anschließend Skills und Heartbeat mit restriktiven Richtlinien für Shell- und Browseraktionen hinzu.