OpenClaw auf einen neuen Rechner umziehen

Diese Anleitung zeigt dir, wie du ein OpenClaw Gateway von einem Rechner auf einen anderen migrierst — ohne das Onboarding neu durchlaufen zu müssen.

Die Migration ist im Prinzip einfach:

  • Kopiere das State-Verzeichnis ($OPENCLAW_STATE_DIR, Standard: ~/.openclaw/) — hier liegen Config, Auth, Sessions und Channel-Status.
  • Kopiere deinen Workspace (Standard: ~/.openclaw/workspace/) — hier liegen deine Agent-Dateien (Memory, Prompts, etc.).

Aber es gibt typische Stolperfallen bei Profiles, Berechtigungen und unvollständigen Kopien.

Bevor du loslegst (was du migrierst)

1) Finde dein State-Verzeichnis

Die meisten Installationen nutzen den Standard:

  • State-Verzeichnis: ~/.openclaw/

Es kann aber anders sein, wenn du Folgendes verwendest:

  • --profile <name> (wird oft zu ~/.openclaw-<profile>/)
  • OPENCLAW_STATE_DIR=/some/path

Falls du unsicher bist, führe auf dem alten Rechner aus:

openclaw status

Schau in der Ausgabe nach OPENCLAW_STATE_DIR oder Profile-Angaben. Bei mehreren Gateways wiederhole das für jedes Profile.

2) Finde deinen Workspace

Übliche Standards:

  • ~/.openclaw/workspace/ (empfohlener Workspace)
  • ein eigener Ordner, den du erstellt hast

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

3) Was wird übernommen?

Wenn du beides kopierst (State-Verzeichnis und Workspace), behältst du:

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

Wenn du nur den Workspace kopierst (z.B. via Git), gehen verloren:

  • Sessions
  • Credentials
  • Channel-Logins

Diese liegen unter $OPENCLAW_STATE_DIR.

Migrationsschritte (empfohlen)

Schritt 0 — Backup erstellen (alter Rechner)

Stoppe auf dem alten Rechner zuerst das Gateway, damit sich die Dateien während des Kopierens nicht ändern:

openclaw gateway stop

(Optional, aber empfohlen) Archiviere das State-Verzeichnis und den Workspace:

# Passe die Pfade an, falls du ein Profile oder eigene Verzeichnisse nutzt
cd ~
tar -czf openclaw-state.tgz .openclaw

tar -czf openclaw-workspace.tgz .openclaw/workspace

Bei mehreren Profiles/State-Verzeichnissen (z.B. ~/.openclaw-main, ~/.openclaw-work) archiviere jedes einzeln.

Schritt 1 — OpenClaw auf dem neuen Rechner installieren

Installiere auf dem neuen Rechner die CLI (und Node falls nötig):

Wenn das Onboarding dabei ein frisches ~/.openclaw/ erstellt, ist das OK — du überschreibst es im nächsten Schritt.

Schritt 2 — State-Verzeichnis + Workspace auf den neuen Rechner kopieren

Kopiere beides:

  • $OPENCLAW_STATE_DIR (Standard: ~/.openclaw/)
  • deinen Workspace (Standard: ~/.openclaw/workspace/)

Gängige Methoden:

  • scp für die Archive und dann entpacken
  • rsync -a über SSH
  • externe Festplatte

Nach dem Kopieren prüfe:

  • Versteckte Verzeichnisse wurden mitkopiert (z.B. .openclaw/)
  • Dateibesitzer stimmt für den User, der das Gateway ausführt

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

Auf dem neuen Rechner:

openclaw doctor

Doctor ist der “sichere, langweilige” Befehl. Er repariert Services, wendet Config-Migrationen an und warnt bei Unstimmigkeiten.

Dann:

openclaw gateway restart
openclaw status

Typische Stolperfallen (und wie du sie vermeidest)

Stolperfalle: Profile / State-Verzeichnis stimmen nicht überein

Wenn das alte Gateway mit einem Profile (oder OPENCLAW_STATE_DIR) lief und das neue Gateway ein anderes nutzt, siehst du Symptome wie:

  • Config-Änderungen werden nicht übernommen
  • Channels fehlen / sind ausgeloggt
  • leerer Session-Verlauf

Lösung: Starte das Gateway/den Service mit dem gleichen Profile/State-Verzeichnis, das du migriert hast, dann führe erneut aus:

openclaw doctor

Stolperfalle: Nur openclaw.json kopiert

openclaw.json allein reicht nicht. Viele Provider speichern Status unter:

  • $OPENCLAW_STATE_DIR/credentials/
  • $OPENCLAW_STATE_DIR/agents/<agentId>/...

Migriere immer das gesamte $OPENCLAW_STATE_DIR-Verzeichnis.

Stolperfalle: Berechtigungen / Besitzer

Wenn du als root kopiert oder den User gewechselt hast, kann das Gateway möglicherweise Credentials/Sessions nicht lesen.

Lösung: Stelle sicher, dass State-Verzeichnis + Workspace dem User gehören, der das Gateway ausführt.

Stolperfalle: Migration zwischen Remote/Local-Modus

  • Wenn deine UI (WebUI/TUI) auf ein Remote-Gateway zeigt, gehören Session-Store + Workspace dem Remote-Host.
  • Eine Migration deines Laptops verschiebt nicht den Status des Remote-Gateways.

Im Remote-Modus migriere den Gateway-Host.

Stolperfalle: Secrets in Backups

$OPENCLAW_STATE_DIR enthält Secrets (API-Keys, OAuth-Tokens, WhatsApp-Credentials). Behandle Backups wie Produktions-Secrets:

  • verschlüsselt speichern
  • nicht über unsichere Kanäle teilen
  • Keys rotieren, falls du eine Kompromittierung vermutest

Checkliste zur Verifizierung

Prüfe auf dem neuen Rechner:

  • openclaw status zeigt das Gateway als laufend
  • Deine Channels sind noch verbunden (z.B. WhatsApp braucht kein erneutes Pairing)
  • Das Dashboard öffnet sich und zeigt bestehende Sessions
  • Deine Workspace-Dateien (Memory, Configs) sind vorhanden

Verwandte Themen