OpenClaw auf eine neue Maschine migrieren

Diese Anleitung migriert ein OpenClaw-Gateway von einer Maschine auf eine andere ohne Onboarding zu wiederholen. Konzeptionell ist die Migration einfach:

State-Verzeichnis kopieren ($CLAWDBOT_STATE_DIR, Standard: ~/.clawdbot/) — enthält Config, Auth, Sessions und Kanal-State.
Workspace kopieren (Standard ~/clawd/) — enthält deine Agent-Dateien (Memory, Prompts usw.).

Es gibt aber typische Fallstricke bei Profilen, Berechtigungen und teilweisen Kopien.

Vor dem Start (was du migrierst)

1) State-Verzeichnis identifizieren

Die meisten Installationen nutzen den Standard:

State-Dir: ~/.clawdbot/

Es kann abweichen, wenn du nutzt:

--profile <name> (oft ~/.clawdbot-<profile>/)
CLAWDBOT_STATE_DIR=/some/path

Wenn unsicher, auf der alten Maschine ausführen:


openclaw status

In der Ausgabe nach CLAWDBOT_STATE_DIR / Profil suchen. Bei mehreren Gateways für jedes Profil wiederholen.

2) Workspace identifizieren

Übliche Standards:

~/clawd/ (empfohlener Workspace)
ein selbst angelegter Ordner

Im Workspace liegen Dateien wie MEMORY.md, USER.md und memory/*.md.

3) Was erhalten bleibt

Wenn du sowohl State-Dir als auch Workspace kopierst, behältst du:

Gateway-Konfiguration (openclaw.json)
Auth-Profile / API-Keys / OAuth-Tokens
Session-Verlauf + Agent-State
Kanal-State (z. B. WhatsApp-Login/Session)
Deine Workspace-Dateien (Memory, Skills-Notizen usw.)

Wenn du nur den Workspace kopierst (z. B. per Git), bleiben nicht erhalten:

Sessions
Credentials
Kanal-Logins

Diese liegen unter $CLAWDBOT_STATE_DIR.

Migrationsschritte (empfohlen)

Schritt 0 — Backup erstellen (alte Maschine)

Auf der alten Maschine zuerst das Gateway stoppen, damit Dateien beim Kopieren nicht geändert werden:


openclaw gateway stop

(Optional, aber empfohlen) State-Dir und Workspace archivieren:


# Pfade anpassen bei Profil oder eigenen Orten
cd ~
tar -czf openclaw-state.tgz .clawdbot

tar -czf clawd-workspace.tgz clawd

Bei mehreren Profilen/State-Dirs (z. B. ~/.clawdbot-main, ~/.clawdbot-work) jeweils archivieren.

Schritt 1 — OpenClaw auf der neuen Maschine installieren

Auf der neuen Maschine CLI (und bei Bedarf Node) installieren:

Siehe: Installation

In dieser Phase ist es in Ordnung, wenn das Onboarding ein frisches ~/.clawdbot/ anlegt — du überschreibst es im nächsten Schritt.

Schritt 2 — State-Dir + Workspace auf die neue Maschine kopieren

Beides kopieren:

$CLAWDBOT_STATE_DIR (Standard ~/.clawdbot/)
deinen Workspace (Standard ~/clawd/)

Übliche Wege:

Tarballs per scp übertragen und entpacken
rsync -a über SSH
externe Festplatte

Nach dem Kopieren sicherstellen:

Versteckte Verzeichnisse sind dabei (z. B. .clawdbot/)
Dateiberechtigungen passen zum Benutzer, der das Gateway ausführt

Schritt 3 — Doctor ausführen (Migrationen + Service-Reparatur)

Auf der neuen Maschine:


openclaw doctor

Doctor ist der „sichere langweilige“ Befehl. Er repariert Services, wendet Config-Migrationen an und warnt bei Abweichungen. Danach:


openclaw gateway restart
openclaw status

Typische Fallstricke (und wie du sie vermeidest)

Fallstrick: Profil- / State-Dir-Mismatch

Wenn das alte Gateway mit einem Profil (oder CLAWDBOT_STATE_DIR) lief und das neue ein anderes nutzt, können Symptome auftreten wie:

Config-Änderungen greifen nicht
Kanäle fehlen / ausgeloggt
leere Session-Historie

Lösung: Gateway/Service mit dem gleichen Profil/State-Dir wie bei der Migration starten, dann erneut:


openclaw doctor

Fallstrick: Nur `openclaw.json` kopieren

openclaw.json reicht nicht. Viele Provider speichern State unter:

$CLAWDBOT_STATE_DIR/credentials/
$CLAWDBOT_STATE_DIR/agents/<agentId>/...

Immer das gesamte Verzeichnis $CLAWDBOT_STATE_DIR migrieren.

Fallstrick: Berechtigungen / Ownership

Wenn du als root kopiert hast oder den Benutzer gewechselt hast, kann das Gateway Credentials/Sessions nicht lesen. Lösung: State-Dir und Workspace müssen dem Benutzer gehören, der das Gateway ausführt.

Fallstrick: Migration zwischen Remote-/Lokal-Modus

Wenn deine UI (WebUI/TUI) auf ein Remote-Gateway zeigt, gehört der Session-Store + Workspace dem Remote-Host.
Das Migrieren deines Laptops verschiebt den State des Remote-Gateways nicht.

Im Remote-Modus die Gateway-Host-Maschine migrieren.

Fallstrick: Secrets in Backups

$CLAWDBOT_STATE_DIR enthält Secrets (API-Keys, OAuth-Tokens, WhatsApp-Creds). Backups wie Produktions-Secrets behandeln:

verschlüsselt aufbewahren
nicht über unsichere Kanäle teilen
Keys rotieren bei Verdacht auf Kompromittierung

Verifikations-Checkliste

Auf der neuen Maschine prüfen:

openclaw status zeigt das laufende Gateway
Deine Kanäle sind weiter verbunden (z. B. WhatsApp braucht kein erneutes Pairing)
Das Dashboard öffnet sich und zeigt bestehende Sessions
Deine Workspace-Dateien (Memory, Configs) sind vorhanden