openclaw migrate

Importieren Sie den Zustand aus einem anderen Agentensystem über einen Plugin-eigenen Migrations-Provider. Die gebündelten Provider unterstützen Claude, Codex CLI und Hermes; Plugins können zusätzliche Provider registrieren.

Befehle

openclaw migrate listopenclaw migrate claude --dry-runopenclaw migrate codex --dry-runopenclaw migrate codex --skill gog-vault77-google-workspaceopenclaw migrate codex --plugin google-calendar --dry-runopenclaw migrate codex --plugin google-calendar --verify-plugin-apps --dry-runopenclaw migrate hermes --dry-runopenclaw migrate hermesopenclaw migrate apply codex --yes --skill gog-vault77-google-workspaceopenclaw migrate apply codex --yes --plugin google-calendaropenclaw migrate apply codex --yesopenclaw migrate apply claude --yesopenclaw migrate apply hermes --yesopenclaw migrate apply hermes --include-secrets --yesopenclaw onboard --flow importopenclaw onboard --import-from claude --import-source ~/.claudeopenclaw onboard --import-from hermes --import-source ~/.hermes

Die Ausführung von openclaw migrate <provider> ohne weitere Flags plant die Migration, zeigt eine Vorschau an und fordert (in einer TTY) vor der Anwendung zur Bestätigung auf. openclaw migrate plan <provider> und openclaw migrate apply <provider> teilen Vorschau und Anwendung in separate Unterbefehle mit denselben Flags auf.

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ijxwcm92aWRlcg " type="string"> Name eines registrierten Migrations-Providers, beispielsweise hermes. Führen Sie openclaw migrate list aus, um die installierten Provider anzuzeigen.

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ii0tZnJvbSA8cGF0aA " type="string"> Überschreibt das Quellzustandsverzeichnis. Hermes berücksichtigt $HERMES_HOME und das aktive Profil und verwendet anschließend den Plattformstandard (~/.hermes oder %LOCALAPPDATA%\hermes). Codex verwendet standardmäßig ~/.codex (oder $CODEX_HOME), Claude standardmäßig ~/.claude.

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ii0tcGx1Z2luIDxuYW1l " type="string"> Wählt anhand des Plugin-Namens oder der Element-ID ein zu installierendes Codex-Plugin-Element aus. Wiederholen Sie das Flag, um mehrere Codex-Plugins zu migrieren. Wenn es weggelassen wird, zeigen interaktive Codex-Migrationen eine native Auswahl für Codex-Plugins mit Kontrollkästchen an; nicht interaktive Migrationen behalten alle geplanten Plugins bei. Gilt nur für aus dem Quellcode installierte openai-curated-Codex-Plugins, die vom Inventar des Codex-App-Servers erkannt wurden.

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ii0tYmFja3VwLW91dHB1dCA8cGF0aA " type="string"> Pfad oder Verzeichnis des Sicherungsarchivs vor der Migration. Wird an openclaw backup create weitergegeben.

Sicherheitsmodell

openclaw migrate folgt dem Prinzip „Vorschau zuerst“.

Claude-Provider

Der gebündelte Claude-Provider erkennt den Zustand von Claude Code standardmäßig unter ~/.claude. Verwenden Sie --from <path>, um ein bestimmtes Claude-Code-Stammverzeichnis oder Projektstammverzeichnis zu importieren.

Was Claude importiert

• Automatisch gespeicherten Claude-Code-Arbeitsspeicher im Markdown-Format aus ~/.claude/projects/*/memory und einem benutzerkonfigurierten autoMemoryDirectory, kopiert unter memory/imports/claude-code/ für den indizierten Abruf.
• Projektdateien CLAUDE.md und .claude/CLAUDE.md in den OpenClaw-Agenten-Arbeitsbereich (AGENTS.md).
• Benutzerdatei ~/.claude/CLAUDE.md, angehängt an USER.md im Arbeitsbereich.
• MCP-Serverdefinitionen aus dem Projekt .mcp.json, aus Claude Code ~/.claude.json (einschließlich der projektspezifischen Einträge) und aus Claude Desktop claude_desktop_config.json.
• Claude-Skill-Verzeichnisse, die SKILL.md enthalten (Benutzerverzeichnis ~/.claude/skills und Projektverzeichnis .claude/skills).
• Claude-Befehlsdateien im Markdown-Format (Benutzerdateien unter ~/.claude/commands und Projektdateien unter .claude/commands), die in OpenClaw-Skills ausschließlich zur manuellen Ausführung umgewandelt werden.

Archivierter und manuell zu prüfender Zustand

Claude-Hooks, Berechtigungen, Standardwerte für Umgebungsvariablen, Projektdatei CLAUDE.local.md, .claude/rules, Benutzer- und Projektverzeichnisse agents/ sowie der Projektverlauf (projects, cache, plans unter ~/.claude) werden im Migrationsbericht beibehalten oder als manuell zu prüfende Elemente gemeldet. OpenClaw führt Hooks nicht aus, kopiert keine umfassenden Positivlisten und importiert den OAuth-/Desktop-Anmeldedatenzustand nicht automatisch.

Codex-Provider

Der gebündelte Codex-Provider erkennt den Zustand der Codex CLI standardmäßig unter ~/.codex oder unter CODEX_HOME, wenn diese Umgebungsvariable gesetzt ist. Verwenden Sie --from <path>, um ein bestimmtes Codex-Stammverzeichnis zu inventarisieren.

Verwenden Sie diesen Provider beim Wechsel zur OpenClaw-Codex-Ausführungsumgebung, wenn Sie nützliche persönliche Ressourcen der Codex CLI bewusst übernehmen möchten. Lokale Starts des Codex-App-Servers verwenden ein agentenspezifisches CODEX_HOME und lesen daher standardmäßig nicht Ihr persönliches ~/.codex. Der normale Prozess HOME wird weiterhin übernommen, sodass Codex auf gemeinsame Skills und Plugin-Marktplatzeinträge unter $HOME/.agents/* zugreifen kann und Unterprozesse Konfigurationen und Tokens im Benutzerverzeichnis finden können.

Wenn openclaw migrate codex in einem interaktiven Terminal ausgeführt wird, zeigt es zunächst eine Vorschau des vollständigen Plans und öffnet anschließend vor der abschließenden Anwendungsbestätigung Auswahllisten mit Kontrollkästchen. Zuerst wird zur Auswahl der zu kopierenden Skill-Elemente aufgefordert. Verwenden Sie Toggle all on oder Toggle all off für die Massenauswahl. Drücken Sie die Leertaste, um Zeilen umzuschalten, oder die Eingabetaste, um die hervorgehobene Zeile zu aktivieren und fortzufahren. Geplante Skills sind anfangs ausgewählt, Skills mit Konflikten sind anfangs nicht ausgewählt und Skip for now überspringt das Kopieren von Skills für diesen Durchlauf, setzt den Vorgang jedoch mit der Plugin-Auswahl fort. Wenn aus dem Quellcode installierte, kuratierte Codex-Plugins migriert werden können und --plugin nicht angegeben wurde, fordert die Migration anschließend anhand des Plugin-Namens zur nativen Aktivierung der Codex-Plugins auf. Plugin-Elemente sind anfangs ausgewählt, sofern das jeweilige Plugin nicht bereits in der Zielkonfiguration für OpenClaw-Codex-Plugins vorhanden ist. Vorhandene Ziel-Plugins sind anfangs nicht ausgewählt und zeigen einen Konflikthinweis wie conflict: plugin exists; wählen Sie Toggle all off, um in diesem Durchlauf keine nativen Codex-Plugins zu migrieren, oder Skip for now, um den Vorgang vor der Anwendung abzubrechen.

Wählen Sie für skriptgesteuerte oder exakt festgelegte Durchläufe ausdrücklich einen oder mehrere Skills beziehungsweise Plugins aus:

openclaw migrate codex --dry-run --skill gog-vault77-google-workspaceopenclaw migrate apply codex --yes --skill gog-vault77-google-workspaceopenclaw migrate codex --dry-run --plugin google-calendaropenclaw migrate apply codex --yes --plugin google-calendar

Was Codex importiert

• Konsolidierte Codex-Dateien MEMORY.md und memory_summary.md aus $CODEX_HOME/memories, kopiert unter memory/imports/codex/ für den indizierten Abruf. Unverarbeiteter Rollout-Arbeitsspeicher wird nicht importiert.
• Skill-Verzeichnisse der Codex CLI unter $CODEX_HOME/skills, mit Ausnahme des .system-Caches von Codex.
• Persönliche AgentSkills unter $HOME/.agents/skills, kopiert in den aktuellen OpenClaw-Agenten-Arbeitsbereich, damit sie dem jeweiligen Agenten zugeordnet sind.
• Aus dem Quellcode installierte openai-curated-Codex-Plugins, die über plugin/list des Codex-App-Servers erkannt werden. Bei der Planung wird plugin/read für jedes aktivierte installierte Plugin gelesen.

Für die Migration App-gestützter Plugins gelten zusätzliche Voraussetzungen:

• App-gestützte Plugins setzen voraus, dass das Konto des Codex-App-Servers der Quelle ein ChatGPT-Abonnementkonto ist. Antworten mit einem anderen Konto als ChatGPT oder ohne Konto werden mit codex_subscription_required übersprungen.
• Standardmäßig ruft die Migration app/list der Quelle nicht auf. Daher werden App-gestützte Plugins, welche die Kontoprüfung bestehen, ohne Prüfung der App-Erreichbarkeit in der Quelle eingeplant; Transportfehler bei der Kontoabfrage führen mit codex_account_unavailable zum Überspringen.
• Übergeben Sie --verify-plugin-apps, um einen neuen app/list-Schnappschuss der Quelle zu erzwingen und vor der Planung der nativen Aktivierung zu verlangen, dass jede eigene App vorhanden, aktiviert und erreichbar ist. In diesem Modus wird bei Transportfehlern der Kontoabfrage stattdessen die Überprüfung des App-Inventars der Quelle durchgeführt. Der Schnappschuss wird nur für den aktuellen Prozess im Arbeitsspeicher aufbewahrt und niemals in die Migrationsausgabe oder Zielkonfiguration geschrieben.

Deaktivierte Plugins, nicht lesbare Plugin-Details, durch ein Abonnement eingeschränkte Quellkonten und – wenn --verify-plugin-apps gesetzt ist – fehlende, deaktivierte oder nicht erreichbare Apps werden anstelle von Einträgen in der Zielkonfiguration als manuell zu prüfende, übersprungene Elemente mit typisierten Gründen behandelt. Bei der Anwendung wird für jedes ausgewählte geeignete Plugin plugin/install des App-Servers aufgerufen, selbst wenn der Ziel-App-Server dieses Plugin bereits als installiert und aktiviert meldet. Migrierte Codex-Plugins können nur in Sitzungen verwendet werden, die die native Codex-Ausführungsumgebung auswählen; sie stehen weder OpenClaw-Provider-Läufen noch ACP-Konversationsbindungen oder anderen Ausführungsumgebungen zur Verfügung.

Manuell zu prüfender Codex-Zustand

Codex config.toml, native hooks/hooks.json, nicht kuratierte Marketplaces, zwischengespeicherte Plugin-Bundles, die keine aus dem Quellcode installierten kuratierten Plugins sind, sowie aus dem Quellcode installierte Plugins, die die Quellabonnement-Prüfung nicht bestehen, werden nicht automatisch aktiviert. Wenn --verify-plugin-apps festgelegt ist, werden Plugins, die die App-Bestandsprüfung der Quelle nicht bestehen, ebenfalls übersprungen. Alle diese Elemente werden zur manuellen Prüfung kopiert oder im Migrationsbericht aufgeführt.

Für migrierte, aus dem Quellcode installierte kuratierte Plugins werden folgende Schreibvorgänge ausgeführt:

• plugins.entries.codex.enabled: true
• plugins.entries.codex.config.codexPlugins.enabled: true
• plugins.entries.codex.config.codexPlugins.allow_destructive_actions: true
• ein expliziter Plugin-Eintrag mit marketplaceName: "openai-curated" und pluginName für jedes ausgewählte Plugin

Die Migration schreibt niemals plugins["*"] und speichert niemals lokale Marketplace-Cache-Pfade.

Übersprungene Plugins werden nicht in die Zielkonfiguration geschrieben. Quellseitige Abonnementfehler werden bei manuellen Elementen mit typisierten Gründen gemeldet: codex_subscription_required, codex_account_unavailable, plugin_disabled oder plugin_read_unavailable. Mit --verify-plugin-apps können Fehler der App-Bestandsprüfung der Quelle auch als app_inaccessible, app_disabled, app_missing oder app_inventory_unavailable erscheinen. Zielseitige Installationen, die eine Authentifizierung erfordern, werden beim betroffenen Plugin-Element mit status: "skipped", reason: "auth_required" und bereinigten App-Kennungen gemeldet; ihre expliziten Konfigurationseinträge werden deaktiviert geschrieben, bis Sie sie erneut autorisieren und aktivieren. Andere Installationsfehler werden als elementspezifische error-Ergebnisse gemeldet.

Wenn der Plugin-Bestand des Codex-App-Servers während der Planung nicht verfügbar ist, greift die Migration auf Hinweise zu zwischengespeicherten Bundles zurück, anstatt die gesamte Migration fehlschlagen zu lassen.

Hermes-Provider

Der gebündelte Hermes-Provider folgt $HERMES_HOME und dem aktiven Profil und verwendet anschließend den Plattformstandard (~/.hermes oder %LOCALAPPDATA%\hermes). Verwenden Sie --from <path>, um die Erkennung zu überschreiben.

Was Hermes importiert

• Standardmodellkonfiguration aus config.yaml.
• Konfigurierte Modell-Provider und benutzerdefinierte OpenAI-kompatible Endpunkte aus model, providers und custom_providers.
• MCP-Serverdefinitionen aus mcp_servers oder mcp.servers. Exakte OpenClaw-Zuordnungen decken das standardmäßige Streamable-HTTP-Routing, den OAuth-Berechtigungsumfang, die boolesche TLS-Verifizierung, separate Pfade für Clientzertifikat und -schlüssel sowie die Hermes-Richtlinie für native Tools, Ressourcen-Tools und Prompt-Tools ab. Nicht unterstützte, ausschließlich Hermes-spezifische Laufzeit- oder Anmeldedatenfelder werden zur manuellen Prüfung gemeldet.
• SOUL.md und AGENTS.md in den OpenClaw-Agenten-Workspace.
• memories/MEMORY.md und memories/USER.md werden an Workspace-Arbeitsspeicherdateien angehängt. Ausschließlich für den Arbeitsspeicher bestimmte Oberflächen (die Arbeitsspeicherseite des Onboardings und die Importseite für Arbeitsspeicher in der Control UI) kopieren diese Dateien stattdessen unter memory/imports/hermes/, damit sie indexiert abgerufen werden können, ohne den bestehenden Workspace-Arbeitsspeicher zu verändern.
• Standardwerte der Arbeitsspeicherkonfiguration für den OpenClaw-Dateiarbeitsspeicher sowie Archiv- oder manuell zu prüfende Elemente für externe Arbeitsspeicher-Provider wie Honcho.
• Skills, die irgendwo unter skills/ eine SKILL.md-Datei enthalten; verschachtelte Skills werden in das Skill-Verzeichnis des Workspace übertragen.
• Skillspezifische Konfigurationswerte aus skills.config.
• Aktuelle Hermes-OAuth-Anmeldedaten für OpenAI Codex und OpenCode-OAuth-Anmeldedaten für OpenAI, wenn die interaktive Migration von Anmeldedaten akzeptiert wird oder --include-secrets festgelegt ist. Hermes und OpenClaw dürfen nicht dieselbe importierte Refresh-Berechtigung verwenden.
• Unterstützte API-Schlüssel und Token aus Hermes .env und OpenCode auth.json, wenn die interaktive Migration von Anmeldedaten akzeptiert wird oder --include-secrets festgelegt ist.

Unterstützte .env-Schlüssel

AI_GATEWAY_API_KEY, ALIBABA_API_KEY, ANTHROPIC_API_KEY, ARCEEAI_API_KEY, CEREBRAS_API_KEY, CHUTES_API_KEY, CLOUDFLARE_AI_GATEWAY_API_KEY, COPILOT_GITHUB_TOKEN, DASHSCOPE_API_KEY, DEEPINFRA_API_KEY, DEEPSEEK_API_KEY, FIREWORKS_API_KEY, GEMINI_API_KEY, GH_TOKEN, GITHUB_TOKEN, GLM_API_KEY, GOOGLE_API_KEY, GROQ_API_KEY, HF_TOKEN, HUGGINGFACE_HUB_TOKEN, KILOCODE_API_KEY, KIMICODE_API_KEY, KIMI_API_KEY, KIMI_CODING_API_KEY, MINIMAX_API_KEY, MINIMAX_CODING_API_KEY, MISTRAL_API_KEY, MODELSTUDIO_API_KEY, MOONSHOT_API_KEY, NVIDIA_API_KEY, OPENAI_API_KEY, OPENCODE_API_KEY, OPENCODE_GO_API_KEY, OPENCODE_ZEN_API_KEY, OPENROUTER_API_KEY, QIANFAN_API_KEY, QWEN_API_KEY, TOGETHER_API_KEY, VENICE_API_KEY, XAI_API_KEY, XIAOMI_API_KEY, ZAI_API_KEY, Z_AI_API_KEY.

Reiner Archivzustand

Hermes-Zustände, die OpenClaw nicht sicher interpretieren kann, werden zur manuellen Prüfung in den Migrationsbericht kopiert, aber nicht in die aktive OpenClaw-Konfiguration oder in Anmeldedaten geladen. Dazu gehören plugins/, sessions/, logs/, cron/, mcp-tokens/, plans/, workspace/, skins/, kanban/, Kopplungs-/Plattformzustand, Gateway-Routing-/Prozesszustand und die erkannten Hermes-SQLite-Datenbanken.

Nach der Anwendung

openclaw doctor

Plugin-Vertrag

Migrationsquellen sind Plugins. Ein Plugin deklariert seine Provider-IDs in openclaw.plugin.json:

{  "contracts": {    "migrationProviders": ["hermes"]  }}

Zur Laufzeit ruft das Plugin api.registerMigrationProvider(...) auf. Der Provider implementiert detect, plan und apply. Der Core ist für die CLI-Orchestrierung, Sicherungsrichtlinie, Prompts, JSON-Ausgabe und Konfliktvorprüfung zuständig. Der Core übergibt den geprüften Plan an apply(ctx, plan), und Provider dürfen den Plan aus Kompatibilitätsgründen nur dann neu erstellen, wenn dieses Argument fehlt. Migrationselemente können applyPhase: "after-promotion" für externe Aktivierungseffekte festlegen, die das Onboarding aufschieben muss, bis die bereitgestellten lokalen Daten dauerhaft veröffentlicht wurden. Diese Provider müssen deferredApply: { retrySafe: true } deklarieren und jeden aufgeschobenen Effekt so gestalten, dass er nach einem unterbrochenen Prozess sicher erneut ausgeführt werden kann; das Onboarding lehnt nicht deklarierte aufgeschobene Effekte ab. Eine idempotente wirkungslose Operation sollte ein nicht veränderndes Element mit deferredCompletion: true zurückgeben, damit die Wiederherstellung es als abgeschlossen erfassen kann. Das eigenständige openclaw migrate wendet weiterhin den vollständigen Plan über seinen normalen, durch Sicherungen abgesicherten Ablauf an.

Provider-Plugins können openclaw/plugin-sdk/migration für die Erstellung von Elementen und Zusammenfassungszahlen sowie openclaw/plugin-sdk/migration-runtime für konfliktbewusste Dateikopien, reine Archivkopien für Berichte, zwischengespeicherte Konfigurations-Laufzeit-Wrapper und Migrationsberichte verwenden.

Onboarding-Integration

Das Onboarding kann eine Migration anbieten, wenn ein Provider eine bekannte Quelle erkennt. Sowohl openclaw onboard --flow import als auch openclaw setup --wizard --import-from hermes verwenden denselben Plugin-Migrations-Provider und zeigen vor der Anwendung weiterhin eine Vorschau an. Anders als bei der eigenständigen Migration stellt der Onboarding-Pfad für ein frisches Ziel lokale Artefakte und importierte Anmeldedaten bereit, überprüft oder repariert die importierte Inferenz innerhalb der Bereitstellungsumgebung und überführt anschließend den Workspace- und Agentenzustand, bevor die Konfiguration festgeschrieben wird. Ein Hochstufungsjournal im Modus 0600 ermöglicht es dem nächsten Durchlauf, eine unterbrochene Veröffentlichung einschließlich aller aufgeschobenen externen Aktivierungen abzuschließen oder zurückzusetzen, ohne importierte lokale Daten erneut anzuwenden.

Verwandte Themen

• Migration von Hermes: benutzerorientierte Anleitung.
• Migration von Claude: benutzerorientierte Anleitung.
• Migration: OpenClaw auf einen neuen Computer verschieben.
• Doctor: Integritätsprüfung nach der Anwendung einer Migration.
• Plugins: Installation und Registrierung von Plugins.