* feat(codex): add native plugin config schema * feat(codex): add native plugin inventory activation * feat(codex): configure native plugin apps for threads * feat(codex): enforce plugin elicitation policy * feat(codex): migrate native plugins * docs(codex): document native plugin support * fix(codex): harden plugin migration refresh * fix(codex): satisfy plugin activation lint * fix: stabilize codex plugin app config * fix: address codex plugin review feedback * fix: key codex plugin app cache by websocket credentials * fix: keep codex plugin app fingerprints stable * fix: refresh codex plugin cache test fixtures * fix: refresh plugin app readiness after activation * fix: support remote codex plugin activation * fix: recover plugin app bindings after cache refresh * fix: force codex app refresh after plugin activation * fix: recover partial codex plugin app bindings * fix: sync codex plugin selection config * fix: keep codex plugin activation fail closed * fix: align codex plugin protocol types with main * fix: refresh partial codex plugin app bindings * fix: key codex app cache by env api key * fix: skip failed codex plugin migration config * test: update codex prompt snapshots * fix: fail closed on missing codex app inventory entries * fix(codex): enforce native plugin policy gates * fix(codex): normalize native plugin policy types * fix(codex): fail closed on plugin refresh errors * fix(codex): use native plugin destructive policy * fix(codex): key plugin cache by api-key profiles * fix(codex): drop unshipped plugin fingerprint compat * fix(codex): let native app policy gate plugin tools * fix(codex): allow open-world plugin app tools * fix(codex): revalidate native plugin app bindings * fix(codex): preserve plugin binding on recheck failure * docs(codex): clarify plugin harness scope * fix(codex): return activation report state exhaustively * test(codex): refresh prompt snapshots after rebase * fix(codex): match namespaced plugin ids
12 KiB
summary, read_when, title
| summary | read_when | title | ||
|---|---|---|---|---|
| CLI reference for `openclaw migrate` (import state from another agent system) |
|
Migrate |
openclaw migrate
Import 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.
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.Commands
openclaw migrate list
openclaw migrate claude --dry-run
openclaw migrate codex --dry-run
openclaw migrate codex --skill gog-vault77-google-workspace
openclaw migrate codex --plugin google-calendar --dry-run
openclaw migrate hermes --dry-run
openclaw migrate hermes
openclaw migrate apply codex --yes --skill gog-vault77-google-workspace
openclaw migrate apply codex --yes --plugin google-calendar
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
Safety model
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`.
Apply creates and verifies an OpenClaw backup before applying the migration. If no local OpenClaw state exists yet, the backup step is skipped and the migration can continue. To skip a backup when state exists, pass both `--no-backup` and `--force`.
Apply refuses to continue when the plan has conflicts. Review the plan, then rerun with `--overwrite` if replacing existing targets is intentional. Providers may still write item-level backups for overwritten files in the migration report directory.
Secrets are never imported by default. Use `--include-secrets` to import supported credentials.
Claude provider
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.
What Claude imports
- Project
CLAUDE.mdand.claude/CLAUDE.mdinto the OpenClaw agent workspace. - User
~/.claude/CLAUDE.mdappended to workspaceUSER.md. - MCP server definitions from project
.mcp.json, Claude Code~/.claude.json, and Claude Desktopclaude_desktop_config.json. - Claude skill directories that include
SKILL.md. - Claude command Markdown files converted into OpenClaw skills with manual invocation only.
Archive and manual-review state
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.
Codex provider
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. Use Toggle all on or Toggle all off for bulk selection;
planned skills start checked, conflict skills start unchecked, and Skip for now
leaves skills unchanged without applying. 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
Use --plugin <name> to limit native Codex plugin migration to one or more
source-installed curated plugins:
openclaw migrate codex --dry-run --plugin google-calendar
openclaw migrate apply codex --yes --plugin google-calendar
What Codex imports
- Codex CLI skill directories under
$CODEX_HOME/skills, excluding Codex's.systemcache. - Personal AgentSkills under
$HOME/.agents/skills, copied into the current OpenClaw agent workspace when you want per-agent ownership. - Source-installed
openai-curatedCodex plugins discovered through Codex app-serverplugin/list. Apply calls app-serverplugin/installfor each selected plugin, even if the target app-server already reports that plugin as installed and enabled. Migrated Codex plugins are usable only in sessions that select the native Codex harness; they are not exposed to Pi, normal OpenAI provider runs, ACP conversation bindings, or other harnesses.
Manual-review Codex state
Codex config.toml, native hooks/hooks.json, non-curated marketplaces, and
cached plugin bundles that are not source-installed curated plugins are not
activated automatically. They are copied or reported in the migration report for
manual review.
For migrated source-installed curated plugins, apply writes:
plugins.entries.codex.enabled: trueplugins.entries.codex.config.codexPlugins.enabled: trueplugins.entries.codex.config.codexPlugins.allow_destructive_actions: false- one explicit plugin entry with
marketplaceName: "openai-curated"andpluginNamefor each selected plugin
Migration never writes plugins["*"] and never stores local marketplace cache
paths. Auth-required installs are reported on the affected plugin item with
status: "skipped", reason: "auth_required", and sanitized app identifiers.
Their explicit config entries are written disabled until you reauthorize and
enable them. Other install failures are item-scoped error results.
If Codex app-server plugin inventory is unavailable during planning, migration falls back to cached bundle advisory items instead of failing the whole migration.
Hermes provider
The bundled Hermes provider detects state at ~/.hermes by default. Use --from <path> when Hermes lives elsewhere.
What Hermes imports
- Default model configuration from
config.yaml. - Configured model providers and custom OpenAI-compatible endpoints from
providersandcustom_providers. - MCP server definitions from
mcp_serversormcp.servers. SOUL.mdandAGENTS.mdinto the OpenClaw agent workspace.memories/MEMORY.mdandmemories/USER.mdappended to workspace memory files.- Memory config defaults for OpenClaw file memory, plus archive or manual-review items for external memory providers such as Honcho.
- Skills that include a
SKILL.mdfile underskills/<name>/. - Per-skill config values from
skills.config. - Supported API keys from
.env, only with--include-secrets.
Supported .env keys
OPENAI_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.
Archive-only state
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.db
After applying
openclaw doctor
Plugin contract
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 integration
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.
Related
- Migrating from Hermes: user-facing walkthrough.
- Migrating from Claude: user-facing walkthrough.
- Migrating: move OpenClaw to a new machine.
- Doctor: health check after applying a migration.
- Plugins: plugin install and registration.