OpenClaw and Claude Code

People who arrive at OpenClaw from Claude Code usually want two things: to keep what they built there, and to know whether the two tools compete or fit together. The docs answer the first with a bundled migration provider that reads local Claude state, previews every item before touching anything, and redacts secrets in the plan and the report. The second answer is simpler: OpenClaw is a Gateway with channels and an always-on agent, Claude Code is a terminal coding tool, and the migration exists because the same person often has both. Here is what moves, what does not, and the order the docs recommend.

Two ways to run it

• The onboarding wizard offers Claude when it detects local Claude state, or you point it at a source directory explicitly; onboarding imports need a fresh OpenClaw setup, so reset config, credentials, sessions and the workspace first if you already have state.
• The migrate command, for scripted or repeatable runs: a dry run first, then apply with a yes flag, and a from flag when the source is a specific Claude Code home or project root.
• Without a source, OpenClaw inspects the default Claude Code home, its state file, and the Claude Desktop MCP config on macOS; with a project root it reads only that project’s files and never your global home.

What gets imported

Instructions and memory: a project CLAUDE.md is copied or appended into the workspace AGENTS.md, and the user-level one into USER.md. MCP servers: definitions from the project mcp file, the Claude Code state file and the Claude Desktop config. Skills and commands: skills with a SKILL.md are copied into the workspace skills directory, and command Markdown files become OpenClaw skills that the model cannot invoke on its own.

OpenClaw refuses to execute hooks, trust permission allowlists, or decode opaque OAuth and Desktop credential state automatically.

What stays archive-only

• Claude hooks, permissions and broad tool allowlists, and environment defaults.
• The local CLAUDE.local.md file and the rules directory.
• Claude subagents, caches, plans and project history.
• Claude Desktop extensions and credentials stored by the operating system.

Those are copied into the migration report for manual review and never loaded into the live config; the docs say to move what you need by hand after reading the archive. OpenClaw with Claude is the separate question of running Claude models inside OpenClaw, and OpenClaw skills explained explains what the imported skills become.

The recommended order

Preview the plan, which lists changes, conflicts and skipped items; apply with the backup OpenClaw creates and verifies first; run the doctor; restart the Gateway and check status. Apply refuses to continue when the plan reports a conflict, and the overwrite flag is for when replacing the target is intentional; a skill about to be overwritten is backed up first and the path recorded in the report. OpenClaw and MCP servers covers what happens to the imported servers next.

On Diali

Diali assistants start with a workspace, so the useful part of a Claude migration is the text: your instructions, your skills and the MCP servers you trust, which you bring into the dashboard rather than through a terminal import. Hosted OpenClaw on Diali is the assistant.

• Preview first; secrets are redacted in the plan and the report.
• Instructions, MCP servers, skills and commands move; hooks and permissions do not.
• Doctor, restart, status: the same three steps as every other change.