openclaw migrate

Importieren Sie State aus einem anderen Agent-System über einen Plugin-eigenen Migrations-Provider. Gebündelte Provider decken Codex CLI-State, Claude und Hermes ab; Drittanbieter-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

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

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ii0tZnJvbSA8cGF0aA " type="string"> Überschreibt das Quell-State-Verzeichnis. Hermes verwendet standardmäßig ~/.hermes.

OPENCLAW_DOCS_MARKER:paramOpen:IHBhdGg9Ii0tcGx1Z2luIDxuYW1l " type="string"> Wählt ein Codex-Plugin-Installationselement nach Plugin-Name oder Element-ID aus. Wiederholen Sie das Flag, um mehrere Codex-Plugins zu migrieren. Wenn es weggelassen wird, zeigen interaktive Codex-Migrationen eine native Codex-Plugin-Checkbox-Auswahl, und nicht interaktive Migrationen behalten alle geplanten Plugins bei. Dies gilt nur für quellinstallierte openai-curated Codex-Plugins, die vom Codex-App-Server-Inventar erkannt wurden.

Sicherheitsmodell

openclaw migrate arbeitet nach dem Prinzip Vorschau zuerst.

Claude-Provider

Der gebündelte Claude-Provider erkennt Claude Code-State standardmäßig unter ~/.claude. Verwenden Sie --from <path>, um ein bestimmtes Claude Code-Home oder Projekt-Root zu importieren.

Was Claude importiert

• Projekt-CLAUDE.md und .claude/CLAUDE.md in den OpenClaw-Agent-Arbeitsbereich.
• Benutzer-~/.claude/CLAUDE.md, angehängt an die Arbeitsbereichsdatei USER.md.
• MCP-Serverdefinitionen aus Projekt-.mcp.json, Claude Code-~/.claude.json und Claude Desktop-claude_desktop_config.json.
• Claude-Skill-Verzeichnisse, die SKILL.md enthalten.
• Claude-Befehls-Markdown-Dateien, konvertiert in OpenClaw-Skills nur mit manueller Ausführung.

Archiv- und manuell zu prüfender State

Claude-Hooks, Berechtigungen, Umgebungsstandards, lokaler Memory, pfadbezogene Regeln, Subagents, Caches, Pläne und Projekthistorie werden im Migrationsbericht beibehalten oder als manuell zu prüfende Elemente gemeldet. OpenClaw führt Hooks nicht aus, kopiert keine breiten Allowlists und importiert OAuth-/Desktop-Anmeldedaten-State nicht automatisch.

Codex-Provider

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

Verwenden Sie diesen Provider, wenn Sie zum OpenClaw Codex-Harness wechseln und nützliche persönliche Codex CLI-Assets gezielt übernehmen möchten. Lokale Codex-App-Server-Starts verwenden ein agentenspezifisches CODEX_HOME, lesen daher standardmäßig nicht Ihr persönliches ~/.codex. Das normale Prozess-HOME wird weiterhin vererbt, sodass Codex gemeinsame $HOME/.agents/*-Skills/Plugin-Marktplatzeinträge sehen kann und Subprozesse Benutzer-Home-Konfiguration und Tokens finden können.

Das Ausführen von openclaw migrate codex in einem interaktiven Terminal zeigt zuerst den vollständigen Plan in der Vorschau an und öffnet dann Checkbox-Auswahlen vor der abschließenden Anwende-Bestätigung. Skill- Kopierelemente werden zuerst abgefragt. Verwenden Sie Toggle all on oder Toggle all off für Massen- auswahl. Drücken Sie die Leertaste, um Zeilen umzuschalten, oder Enter, um die hervorgehobene Zeile zu aktivieren und fortzufahren. Geplante Skills sind anfangs aktiviert, konfliktbehaftete Skills anfangs deaktiviert, und Skip for now überspringt Skill-Kopien für diesen Lauf, fährt aber dennoch mit der Plugin- Auswahl fort. Wenn quellinstallierte kuratierte Codex-Plugins migrierbar sind und --plugin nicht angegeben wurde, fragt die Migration anschließend nach der nativen Codex-Plugin- Aktivierung nach Plugin-Name. Plugin-Elemente sind anfangs aktiviert, sofern die Zielkonfiguration des OpenClaw Codex-Plugins dieses Plugin noch nicht enthält. Vorhandene Ziel-Plugins sind anfangs deaktiviert und zeigen einen Konflikthinweis wie conflict: plugin exists; wählen Sie Toggle all off, um in diesem Lauf keine nativen Codex- Plugins zu migrieren, oder Skip for now, um vor dem Anwenden zu stoppen. Für geskriptete oder exakte Läufe übergeben Sie --skill <name> einmal pro Skill, zum Beispiel:

openclaw migrate codex --dry-run --skill gog-vault77-google-workspaceopenclaw migrate apply codex --yes --skill gog-vault77-google-workspace

Verwenden Sie --plugin <name>, um die native Codex-Plugin-Migration nicht interaktiv auf ein oder mehrere quellinstallierte kuratierte Plugins zu begrenzen:

openclaw migrate codex --dry-run --plugin google-calendaropenclaw migrate apply codex --yes --plugin google-calendar

Was Codex importiert

• Codex CLI-Skill-Verzeichnisse unter $CODEX_HOME/skills, mit Ausnahme des .system-Caches von Codex.
• Persönliche AgentSkills unter $HOME/.agents/skills, kopiert in den aktuellen OpenClaw-Agent-Arbeitsbereich, wenn Sie agentenspezifische Ownership wünschen.
• Quellinstallierte openai-curated Codex-Plugins, die über Codex- App-Server-plugin/list erkannt wurden. Die Planung liest plugin/read für jedes aktivierte installierte Plugin. App-gestützte Plugins erfordern, dass die Kontoantwort des Codex-Quell-App-Servers ein ChatGPT-Abonnementkonto ist; nicht-ChatGPT- oder fehlende Kontoantworten werden mit codex_subscription_required übersprungen. Standardmäßig ruft die Migration kein Quell-app/list auf, sodass app-gestützte Plugins, die das Konto-Gate bestehen, ohne Verifizierung der Barrierefreiheit der Quell-App geplant werden, und Transportfehler bei der Kontoabfrage mit codex_account_unavailable übersprungen werden. Übergeben Sie --verify-plugin-apps, wenn die Migration einen frischen Quell- app/list-Snapshot erzwingen und erfordern soll, dass jede eigene App vorhanden, aktiviert und zugänglich ist, bevor die native Aktivierung geplant wird. In diesem Modus fallen Transportfehler bei der Kontoabfrage auf die Verifizierung des Quell-App-Inventars zurück. Der Quell-App-Inventar-Snapshot wird für den aktuellen Prozess im Speicher gehalten; er wird nicht in die Migrationsausgabe oder Zielkonfiguration geschrieben. Deaktivierte Plugins, nicht lesbare Plugin-Details, durch Abonnement beschränkte Quellkonten sowie, wenn Verifizierung angefordert wurde, fehlende Apps, deaktivierte Apps, unzugängliche Apps oder Fehler im Quell-App-Inventar werden zu manuell übersprungenen Elementen mit typisierten Gründen statt zu Zielkonfigurationseinträgen. Anwenden ruft App-Server-plugin/install für jedes ausgewählte berechtigte Plugin auf, selbst wenn der Ziel-App-Server dieses Plugin bereits als installiert und aktiviert meldet. Migrierte Codex-Plugins sind nur in Sitzungen nutzbar, die das native Codex-Harness auswählen; sie werden nicht für OpenClaw-Provider-Läufe, ACP-Konversationsbindungen oder andere Harnesses bereitgestellt.

Manuell zu prüfender Codex-State

Codex-config.toml, native hooks/hooks.json, nicht kuratierte Marktplätze, gecachte Plugin-Bundles, die keine quellinstallierten kuratierten Plugins sind, und quellinstallierte Plugins, die das Quellabonnement-Gate nicht bestehen, werden nicht automatisch aktiviert. Wenn --verify-plugin-apps gesetzt ist, werden Plugins, die das Quell-App-Inventar- Gate nicht bestehen, ebenfalls übersprungen. Sie werden in den Migrationsbericht kopiert oder dort zur manuellen Prüfung gemeldet.

Für migrierte quellinstallierte kuratierte Plugins schreibt Anwenden:

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

Migration schreibt niemals plugins["*"] und speichert niemals lokale Marketplace-Cache-Pfade. Fehler bei Source-seitigen Subscriptions werden bei manuellen Elementen mit typisierten Gründen gemeldet, etwa codex_subscription_required, codex_account_unavailable, plugin_disabled oder plugin_read_unavailable. Mit --verify-plugin-apps können Source-App-Inventarfehler auch als app_inaccessible, app_disabled, app_missing oder app_inventory_unavailable erscheinen. Übersprungene Plugins werden nicht in die Zielkonfiguration geschrieben. Auth-required-Installationen auf Zielseite werden beim betroffenen Plugin-Element mit status: "skipped", reason: "auth_required" und bereinigten App-IDs gemeldet. Ihre expliziten Konfigurationseinträge werden deaktiviert geschrieben, bis Sie sie erneut autorisieren und aktivieren. Andere Installationsfehler sind elementbezogene error-Ergebnisse.

Wenn das Codex-App-Server-Plugin-Inventar während der Planung nicht verfügbar ist, greift die Migration auf zwischengespeicherte Bundle-Hinweiselemente zurück, statt die gesamte Migration fehlschlagen zu lassen.

Hermes-Provider

Der gebündelte Hermes-Provider erkennt den Zustand standardmäßig unter ~/.hermes. Verwenden Sie --from <path>, wenn Hermes anderswo liegt.

Was Hermes importiert

• Standardmodellkonfiguration aus config.yaml.
• Konfigurierte Modell-Provider und benutzerdefinierte OpenAI-kompatible Endpunkte aus providers und custom_providers.
• MCP-Serverdefinitionen aus mcp_servers oder mcp.servers.
• SOUL.md und AGENTS.md in den OpenClaw-Agent-Arbeitsbereich.
• memories/MEMORY.md und memories/USER.md, angehängt an Arbeitsbereich-Speicherdateien.
• Standards der Speicherkonfiguration für OpenClaw-Dateispeicher sowie Archiv- oder manuelle Review-Elemente für externe Speicher-Provider wie Honcho.
• Skills, die eine SKILL.md-Datei unter skills/<name>/ enthalten.
• Skill-spezifische Konfigurationswerte aus skills.config.
• OpenCode-OpenAI-OAuth-Anmeldedaten aus OpenCode auth.json, wenn die interaktive Migration von Anmeldedaten akzeptiert wird oder wenn --include-secrets gesetzt ist. Hermes-auth.json-OAuth-Einträge sind Legacy-Zustand, der für manuelle OpenAI-Neuautorisierung oder Doctor-Reparatur gemeldet wird.
• Unterstützte API-Schlüssel und Tokens aus Hermes .env und OpenCode auth.json, wenn die interaktive Migration von Anmeldedaten akzeptiert wird oder wenn --include-secrets gesetzt 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
• 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

Nur-Archiv-Zustand

Hermes-Zustand, den OpenClaw nicht sicher interpretieren kann, wird zur manuellen Prüfung in den Migrationsbericht kopiert, aber nicht in die aktive OpenClaw-Konfiguration oder in Anmeldedaten geladen. Dadurch bleibt undurchsichtiger oder unsicherer Zustand erhalten, ohne vorzugeben, dass OpenClaw ihn automatisch ausführen oder ihm vertrauen kann:

• plugins/
• sessions/
• logs/
• cron/
• mcp-tokens/
• state.db

Nach dem Anwenden

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. Core besitzt CLI-Orchestrierung, Backup-Richtlinie, Prompts, JSON-Ausgabe und Konflikt-Preflight. Core übergibt den geprüften Plan an apply(ctx, plan), und Provider dürfen den Plan nur dann neu erstellen, wenn dieses Argument aus Kompatibilitätsgründen fehlt.

Provider-Plugins können openclaw/plugin-sdk/migration für Elementerstellung und Zusammenfassungszähler sowie openclaw/plugin-sdk/migration-runtime für konfliktbewusste Dateikopien, reine Archivberichtskopien, zwischengespeicherte Config-Runtime-Wrapper und Migrationsberichte verwenden.

Onboarding-Integration

Onboarding kann 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-Migrationsprovider und zeigen vor dem Anwenden weiterhin eine Vorschau an.

Verwandt

• Migration von Hermes: benutzerorientierte Anleitung.
• Migration von Claude: benutzerorientierte Anleitung.
• Migration: OpenClaw auf einen neuen Rechner verschieben.
• Doctor: Integritätsprüfung nach dem Anwenden einer Migration.
• Plugins: Plugin-Installation und Registrierung.