🦀
Open Source · Self-Updating · Crash-Proof

Wie OpenClaw funktioniert

Ein System, das sich selbst aktualisieren und neu starten kann — ohne jemals abzustürzen. Hier für jeden verständlich erklärt.

01

Der Kern-Trick: Die Endlosschleife

Das Herzstück von OpenClaw ist ein Programm, das nie aufhört zu laufen. Es startet einen Server, wartet dann geduldig — und wenn eine Änderung kommt, fährt es nur den alten Server herunter und startet einen neuen. Das Programm selbst? Läuft die ganze Zeit weiter.

💡

Stell dir einen Wachmann vor, der nie Feierabend macht. Wenn die Eingangstür getauscht werden muss, schließt er die alte ab, öffnet die neue — und steht weiter Wache. Er selbst geht nie weg. Deshalb gibt es keinen Moment, in dem niemand aufpasst.

02

Zwei Arten sich zu aktualisieren

Je nachdem wie groß die Änderung ist, reagiert OpenClaw unterschiedlich:

Stufe 1

🔥 Hot Reload

Kleine Änderungen werden sofort im laufenden Betrieb getauscht. Der Rest merkt nichts davon.

💡

Wie eine Glühbirne wechseln — das Haus bleibt stehen.

Cron-Jobs Hooks Gmail-Watcher Einzelne Kanäle
Stufe 2

🔄 Voller Neustart

Bei tiefen Änderungen fährt der Server kontrolliert herunter und startet komplett neu.

💡

Wie das Fundament erneuern — dafür muss das Haus kurz leer sein.

Plugins Port-Änderung KI-Modell Routing
03

Das Gateway — Die Schaltzentrale

Das Gateway ist der Postbote von OpenClaw. Es nimmt Nachrichten von überall entgegen — Telegram, WhatsApp, Discord, Signal, Slack — und leitet sie an die richtige KI weiter. Die Antwort kommt denselben Weg zurück.

Architektur-Übersicht
💬 Telegram
💬 Discord
💬 WhatsApp
💬 Signal
💬 Slack
⚡ GATEWAY
Schaltzentrale
🧠 Claude
🧠 OpenAI
🧠 Andere KIs
04

Das Gateway — Im Detail

In Section 03 haben wir das Gateway als Schaltzentrale kennengelernt. Jetzt schauen wir unter die Haube — was passiert technisch, wenn das Gateway startet, wie kommunizieren die Teile, und warum ist das Ganze so robust?

🔧 Was das Gateway technisch ist

Im Kern ist das Gateway ein HTTP- und WebSocket-Server auf Port 18789. Beim Start durchläuft es eine präzise Boot-Sequenz — sieben Schritte, immer in derselben Reihenfolge:

📄 Config lesen & validieren

Aus ~/.openclaw/config.json5 — Schema-Validierung, Defaults setzen.

🧩 Plugins laden

Channel-Plugins und Erweiterungen werden via jiti dynamisch importiert.

⚙️ Runtime-State erzeugen

HTTP-Server, WebSocket-Server, Client-Set und Broadcast-Funktion werden initialisiert.

📡 Alle Channels starten

Telegram-Bot, Discord-Bot, WhatsApp-Verbindung und alle weiteren Kanäle gehen online.

🛰️ Sidecars hochfahren

Gmail-Watcher, Browser-Control, Cron-Service und Heartbeat starten als Begleitprozesse.

👁️ Config-Watcher aktivieren

chokidar überwacht die Config-Datei — Änderungen lösen Hot Reload oder Restart aus.

🚦 Signal-Handler registrieren

SIGTERM, SIGINT und SIGUSR1 werden abgefangen — für sauberes Herunterfahren und Restart.

🔌 Kommunikation — HTTP + WebSocket

Das Gateway spricht zwei Protokolle — je nach Anwendungsfall:

HTTP

🌐 REST-APIs

Für externe Integrationen und Tools:

  • POST /v1/chat/completions — OpenAI-kompatibel
  • POST /v1/responses — OpenResponses API
  • Control-UI — Browser-Dashboard
WebSocket

⚡ Echtzeit-Herzstück

Für alle verbundenen Clients:

  • CLI-Client → sendet Befehle als JSON-RPC
  • macOS-App → zeigt Chat-UI
  • iOS/Android-Nodes → bekommen Events
  • Browser-WebChat → Echtzeit-Streaming

Jeder Client authentifiziert sich beim Verbinden:

Client-Authentifizierung
{
  role: "operator" | "node",
  scopes: ["operator.admin", ...],
  clientId: "cli-abc123"
}

Das RPC-System umfasst ~60+ Methoden in 10 Kategorien:

🤖 Agent
💬 Chat
📡 Channels
⚙️ Config
Cron
📱 Nodes
🗂️ Sessions
💚 Health
📤 Send
🛠️ Skills

Request-Flow — jede Anfrage durchläuft vier Stufen:

🔑 Autorisierung

Hat der Client die nötigen Scopes für diese Methode?

🔍 Handler-Lookup

Die RPC-Methode wird auf die passende Handler-Funktion gemappt.

⚡ Ausführung

Der Handler ruft den Agent-Runner auf — die KI beginnt zu arbeiten.

📢 Broadcast

Streaming-Events gehen an alle verbundenen Clients in Echtzeit.

📡 Der Channel-Manager

Der ChannelManager verwaltet den Lebenszyklus jedes Channel-Accounts. Er sorgt dafür, dass Telegram, Discord, WhatsApp & Co. sauber starten und stoppen können — unabhängig voneinander.

Channel-Manager Architektur
📋 ChannelManager
channelStores: Map
aborts · tasks · runtimes
startAccount()
stopAccount()
AbortController

Standardisiertes Plugin-Interface: Jedes Channel-Plugin implementiert startAccount(), stopAccount(), listAccountIds() und isEnabled(). Ein AbortController pro Channel ermöglicht sauberes Herunterfahren — auch mitten im Betrieb.

🔄 Der Restart-Loop

Die eigentliche Magie des Gateways steckt in ~15 Zeilen Code. Ein elegantes Pattern, das den Server am Leben hält:

restart-loop.ts — Das Herzstück
while (true) {
  server = await params.start();       // 1. Server hochfahren

  await new Promise((resolve) => {
    restartResolver = resolve;          // 2. Warten... (hängt hier)
  });

  // 3. Promise aufgelöst → Schleife dreht sich
  // 4. Neuer Server mit frischer Config
}

Wie wird das Promise aufgelöst? Durch Unix-Signale:

SIGTERM / SIGINT
stop process.exit(0)
SIGUSR1
restartResolver() neue Schleife
💡

Wie einen Browser-Tab neu laden, statt den ganzen Browser zu schließen. Die Adressleiste bleibt offen — nur der Inhalt wird frisch geladen.

📢 Die Broadcast-Funktion

Das Gateway hält ein Set aller verbundenen WebSocket-Clients. Über die Broadcast-Funktion werden Events an alle gleichzeitig verteilt:

Event-Typen

📡 Was wird gebroadcastet?

  • broadcast("health", ...) — Systemstatus
  • broadcast("chat", ...) — Chat-Events
  • broadcast("shutdown", ...) — Herunterfahren
Shutdown

🔌 Graceful Disconnect

Bei Shutdown: Close-Code 1012 ("Service Restart") + erwartete Restart-Zeit. Clients können automatisch reconnecten.

🏗️ Warum das so gut funktioniert

Acht Architektur-Prinzipien machen das Gateway robust, zuverlässig und wartbar:

01

♻️ Kein Prozess-Exit bei Restart

while(true) + Promise-basiertes Pausieren — der Prozess läuft einfach weiter.

02

🧹 Sauberes Herunterfahren

AbortController pro Channel + 5-Sekunden-Timeout garantieren geordneten Shutdown.

03

🧩 Isolierte Subsysteme

Jeder Channel, Cron, Gmail, Browser — alles eigenständig. Ein Fehler reißt nicht alles mit.

04

🎯 Intelligentes Reload

Config-Diff bestimmt: Hot Reload oder voller Restart? Nur so viel wie nötig.

05

💾 Zustandserhaltung

Ein Restart-Sentinel speichert den Kontext — nach dem Neustart geht es nahtlos weiter.

06

📢 Client-Benachrichtigung

WebSocket-Broadcast + Close-Code 1012 — Clients wissen sofort Bescheid.

07

🔒 Einzige Instanz

Eine Lock-Datei verhindert Doppelstart — es läuft immer genau ein Gateway.

08

🔑 Autorisierung

Scope-basiertes Berechtigungssystem — jeder Client kann nur das, was er darf.

„Das Gateway ist kein simpler HTTP-Server — es ist ein Betriebssystem für KI-Kommunikation."

05

Der Weg einer Nachricht

Was passiert, wenn du z.B. in Telegram eine Nachricht schreibst?

📱 Du schreibst eine Nachricht

In Telegram, WhatsApp, Discord oder einem anderen Messenger.

📥 Bot empfängt sie

Der jeweilige Kanal-Bot nimmt die Nachricht und bringt sie in ein einheitliches Format — egal woher sie kommt.

🔀 Routing: Wer ist zuständig?

Das System entscheidet automatisch: Welche KI soll antworten? Das lässt sich pro User, Gruppe oder Kanal einstellen.

📂 Chat-Verlauf wird geladen

Die KI lädt euren bisherigen Gesprächsverlauf — damit sie weiß, worüber ihr schon geredet habt.

🧠 Die KI denkt nach

Claude, ChatGPT oder eine andere KI erstellt die Antwort. Dabei kann sie auch Tools nutzen — z.B. im Internet suchen oder Bilder erstellen.

📤 Antwort kommt zurück

Die Antwort geht denselben Weg zurück und landet bei dir als normale Chat-Nachricht.

06

Warum das nicht abstürzt

OpenClaw hat 6 Sicherheitsnetze eingebaut:

📝

Atomares Speichern

Einstellungen werden erst in eine Temp-Datei geschrieben, dann umbenannt. So gibt es nie eine halb fertige Datei.

Prüfung vorher

Ungültige Einstellungen werden sofort erkannt und ignoriert — sie kommen nie ins laufende System.

🧩

Isolierte Bausteine

Wenn ein Teil kaputt geht (z.B. der Gmail-Watcher), laufen alle anderen Teile ganz normal weiter.

💾

Neustart-Gedächtnis

Vor dem Neustart merkt sich das System genau, wo es war — danach macht es exakt dort weiter.

🔒

Nur einer gleichzeitig

Eine Sperr-Datei stellt sicher, dass nie versehentlich zwei Instanzen parallel laufen.

⏱️

5-Sekunden-Fenster

Neustarts müssen vorher genehmigt werden und haben nur 5 Sekunden Zeit — kein unkontrolliertes Neustarten möglich.

OpenClaw ist wie ein Motor, der nie ausgeht. Kleine Änderungen werden im Betrieb getauscht, große führen zu einem kontrollierten Neustart — aber der Motor selbst läuft immer weiter. Das Ergebnis: Ein System, das sich selbst aktualisieren kann, ohne jemals abzustürzen.