docs/cli/migrate.md
openclaw migrateImport state from another agent system through a plugin-owned migration provider. Bundled providers cover Codex CLI state, Claude, and Hermes; third-party plugins can register additional providers.
<Tip> For user-facing walkthroughs, see [Migrating from Claude](/install/migrating-claude) and [Migrating from Hermes](/install/migrating-hermes). The [migration hub](/install/migrating) lists all paths. </Tip>openclaw migrate list
openclaw migrate claude --dry-run
openclaw migrate codex --dry-run
openclaw migrate codex --skill gog-vault77-google-workspace
openclaw migrate hermes --dry-run
openclaw migrate hermes
openclaw migrate apply codex --yes --skill gog-vault77-google-workspace
openclaw migrate apply codex --yes
openclaw migrate apply claude --yes
openclaw migrate apply hermes --yes
openclaw migrate apply hermes --include-secrets --yes
openclaw onboard --flow import
openclaw onboard --import-from claude --import-source ~/.claude
openclaw onboard --import-from hermes --import-source ~/.hermes
openclaw migrate is preview-first.
`openclaw migrate apply <provider>` previews the plan and prompts before changing state unless `--yes` is set. In non-interactive mode, apply requires `--yes`.
The bundled Claude provider detects Claude Code state at ~/.claude by default. Use --from <path> to import a specific Claude Code home or project root.
CLAUDE.md and .claude/CLAUDE.md into the OpenClaw agent workspace.~/.claude/CLAUDE.md appended to workspace USER.md..mcp.json, Claude Code ~/.claude.json, and Claude Desktop claude_desktop_config.json.SKILL.md.Claude hooks, permissions, environment defaults, local memory, path-scoped rules, subagents, caches, plans, and project history are preserved in the migration report or reported as manual-review items. OpenClaw does not execute hooks, copy broad allowlists, or import OAuth/Desktop credential state automatically.
The bundled Codex provider detects Codex CLI state at ~/.codex by default, or
at CODEX_HOME when that environment variable is set. Use --from <path> to
inventory a specific Codex home.
Use this provider when moving to the OpenClaw Codex harness and you want to
promote useful personal Codex CLI assets deliberately. Local Codex app-server
launches use per-agent CODEX_HOME and HOME directories, so they do not read
your personal Codex CLI state by default.
Running openclaw migrate codex in an interactive terminal previews the full
plan, then opens a checkbox selector for skill copy items before the final
apply confirmation. All skills start selected; uncheck any skill you do not want
copied into this agent. For scripted or exact runs, pass --skill <name> once
per skill, for example:
openclaw migrate codex --dry-run --skill gog-vault77-google-workspace
openclaw migrate apply codex --yes --skill gog-vault77-google-workspace
$CODEX_HOME/skills, excluding Codex's
.system cache.$HOME/.agents/skills, copied into the current
OpenClaw agent workspace when you want per-agent ownership.Codex native plugins, config.toml, and native hooks/hooks.json are not
activated automatically. Plugins may expose MCP servers, apps, hooks, or other
executable behavior, so the provider reports them for review instead of loading
them into OpenClaw. Config and hook files are copied into the migration report
for manual review.
The bundled Hermes provider detects state at ~/.hermes by default. Use --from <path> when Hermes lives elsewhere.
config.yaml.providers and custom_providers.mcp_servers or mcp.servers.SOUL.md and AGENTS.md into the OpenClaw agent workspace.memories/MEMORY.md and memories/USER.md appended to workspace memory files.SKILL.md file under skills/<name>/.skills.config..env, only with --include-secrets..env keysOPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, GOOGLE_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, XAI_API_KEY, MISTRAL_API_KEY, DEEPSEEK_API_KEY.
Hermes state that OpenClaw cannot safely interpret is copied into the migration report for manual review, but it is not loaded into live OpenClaw config or credentials. This preserves opaque or unsafe state without pretending OpenClaw can execute or trust it automatically:
plugins/sessions/logs/cron/mcp-tokens/auth.jsonstate.dbopenclaw doctor
Migration sources are plugins. A plugin declares its provider ids in openclaw.plugin.json:
{
"contracts": {
"migrationProviders": ["hermes"]
}
}
At runtime the plugin calls api.registerMigrationProvider(...). The provider implements detect, plan, and apply. Core owns CLI orchestration, backup policy, prompts, JSON output, and conflict preflight. Core passes the reviewed plan into apply(ctx, plan), and providers may rebuild the plan only when that argument is absent for compatibility.
Provider plugins can use openclaw/plugin-sdk/migration for item construction and summary counts, plus openclaw/plugin-sdk/migration-runtime for conflict-aware file copies, archive-only report copies, cached config-runtime wrappers, and migration reports.
Onboarding can offer migration when a provider detects a known source. Both openclaw onboard --flow import and openclaw setup --wizard --import-from hermes use the same plugin migration provider and still show a preview before applying.