To migrate agent memory and rules from OpenClaw to Claude Code, review the source material, extract the knowledge and instructions worth retaining, and validate the resulting behavior in Claude Code. Treat this as a controlled transfer of context, with runtime settings handled separately.
OpenClaw’s documented migration provider imports local Claude state into OpenClaw. Its instruction conversion, secret redaction, preview, and verification features describe that direction. They do not establish a reverse importer.
There is a second scope limitation: Anthropic’s memory help article is cited for memory imports and Markdown exports, but the available evidence does not establish a Claude Code-specific procedure for importing OpenClaw state. It also describes memory imports as experimental, with no assurance that every imported memory will be incorporated. Treat memory transfer and runtime configuration as separate tasks.
The workflow below is a recommended manual migration process. It supplies review and acceptance criteria; destination paths, configuration syntax, and automated conversion remain unverified.
What is portable, and what needs rebuilding?
OpenClaw stores user preferences and project context in Markdown files, according to its memory overview. Review that text for transfer, then separately check how Claude Code will receive and use it.
Separate the migration into two tracks:
- Knowledge and intent: current project facts, useful preferences, and operating instructions that can be reviewed and rewritten as text.
- Runtime behavior: commands, skills, hooks, permissions, and automations whose operation depends on the destination environment.
The first track is a candidate for manual transfer. The second needs an explicit compatibility decision. The evidence documents OpenClaw importing Claude Code skills and commands into its own format; it does not establish that those converted artifacts can be imported back unchanged.
Do not assume that conversation history, every remembered fact, or the complete original runtime state must accompany the move. Select what the new setup needs to do its work.
Back up the source and build an inventory
Before editing, retain a recoverable copy of the source material and record the destination’s starting state. Keep the backup separate from the sanitized material intended for transfer. A backup may still contain information that should never enter the destination.
Inventory each candidate item with its source, purpose, current owner, and proposed disposition. Useful dispositions are retain, rewrite, rebuild, exclude, and defer pending verification. Record why an item received that disposition so a later reviewer can distinguish an intentional omission from an oversight.
Work from that inventory rather than copying a whole memory directory and sorting it afterward. This creates a review point before information crosses into the new setup.
Classify by type, scope, sensitivity, and portability
For each item, answer four questions:
- Type: Is it a fact, a preference, an instruction, or an executable workflow?
- Scope: Does it belong to one project, several projects, or the individual user?
- Sensitivity: Does it contain credentials, private prompts, personal information, or proprietary payloads?
- Portability: Can its intent survive as text, or does it require a particular tool or runtime feature?
A project fact and a rule about how to act should receive different treatment. Facts need accuracy checks and a record of when they were verified. Rules need clear conditions and observable behavior. Executable workflows need destination-specific verification before use.
Keep uncertain items out of the initial migration. Document the uncertainty and revisit it when the missing information is available.
Choose a destination for each category
Use the following as a planning map, not a verified conversion specification:
| Source category | Recommended destination or action | What to verify |
|---|---|---|
| Durable project knowledge | Maintained project documentation | Accuracy, ownership, and how Claude Code will access it |
| Project operating instructions | Reviewed project instructions | The supported instruction mechanism and intended scope |
| User preferences | A supported destination mechanism for personal context | Availability, loading behavior, and whether the preference belongs across projects |
| Skills and commands | Rebuild or adapt individually | Destination format, dependencies, and behavior |
| Hooks, permissions, and automations | Reconfigure only after compatibility review | Supported mechanism and actual execution boundaries |
| Secrets or sensitive payloads | Exclude from transferred memory and instruction text | That the reviewed transfer contains no sensitive content |
| Uncertain or unsupported items | Retain in a deferred inventory | What evidence would permit a safe transfer |
OpenClaw’s migration documentation describes copying project instructions from CLAUDE.md to AGENTS.md when moving from Claude Code to OpenClaw. That documented conversion does not establish that reversing the copy restores the original behavior.
Verify how the destination loads project instructions before placing the reviewed text there.
Translate rules into testable instructions
Preserve the purpose of a rule while removing references that depend on the old environment. A useful instruction identifies when it applies, what action is expected, and what result would demonstrate compliance.
Review every retained rule for scope and conflicts. A personal preference should not quietly become a requirement for all collaborators. A project rule should not spread into unrelated projects. Where two instructions disagree, choose a current, reviewed policy and document the decision rather than carrying both forward.
Remove duplicate instructions and vague wording. Keep facts separate from behavioral requirements so that updating a project detail does not require rewriting its operating policy.
Put durable knowledge in maintainable documentation
For stable project context, create or update documentation with an owner and a review date. Retain the information needed to understand the project, and remove stale details that no longer affect current work.
Document the migrated setup itself: the source inventory, the destination chosen for each retained category, exclusions, unresolved compatibility questions, and validation results. Keep that record free of the sensitive content it describes. An exclusion record should explain the category and reason without reproducing the excluded secret or private payload.
Check that Claude Code can access the documentation in the intended workflow. Automatic discovery of every project document is not established here.
Rebuild commands and automation deliberately
Treat each executable or tool-dependent item as a separate implementation task. Identify its trigger, dependencies, expected action, and required permissions before adapting it.
Do not carry an unsupported setting into a configuration file merely because its name looks familiar. When no supported equivalent is established, mark the feature as deferred or replace the workflow with a reviewed manual step. Record the resulting gap so users know which behavior has not been restored.
OpenClaw’s documented migration can be scripted through its CLI and includes a plan preview, but those capabilities concern importing Claude state into OpenClaw. No reverse-migration command is established here. For repeatable runs, record the reviewed source items, approved destinations, and validation tasks.
Sanitize and resolve stale or conflicting content
Review the actual transfer material before adding it to the destination. Exclude secrets, credentials, private prompts, personal data, and proprietary payloads that are not appropriate for the new setup. Use a separate sanitized copy so that cleanup does not destroy the original backup.
OpenClaw’s migration provider is described as redacting secrets during imports from Claude. That is not evidence of automatic redaction for this reverse workflow. Review text directly, and review any adapted executable content separately.
Deduplicate retained facts and instructions. Date facts that may change, remove obsolete entries, and resolve contradictions with an identified owner. If a fact cannot be confirmed, omit it from active context and preserve the question in the migration record.
Validate behavior, conflicts, and safety
A successful file transfer is only the beginning of verification. Define expected outcomes before testing, then migrate a small, reviewed set of items and check them in the intended workflow.
| Check | What to observe | What a failure means |
|---|---|---|
| Context | The agent uses a retained, verified project fact correctly | Access or interpretation needs investigation |
| Rule behavior | The agent follows a retained instruction when its condition applies | The instruction or its placement needs revision |
| Scope | A project-specific instruction stays within its intended project | Scope needs correction before expanding the migration |
| Conflict | The agent follows the reviewed policy where old instructions disagreed | Conflicting content or unclear wording may remain |
| Automation | An adapted workflow performs the reviewed action with the intended permissions | The runtime adaptation is incomplete |
| Sensitive content | The transfer material and resulting context exclude the designated sensitive categories | Stop and revise the sanitized transfer |
These checks are recommended acceptance criteria, not vendor guarantees. Record the task, expected outcome, observed behavior, and corrective action. Retest an affected behavior after changing its instructions or configuration.
An import finishing without an error is not an acceptance result. Check whether the retained information actually affects the relevant task.
Keep rollback available
Retain the destination’s earlier state until the migrated setup passes its acceptance checks. Apply reviewed changes in small groups so a regression can be traced to a manageable set of edits.
If behavior becomes worse, restore the recorded prior state and investigate the failing group. Keep the source backup intact. Record which items were removed, which remain active, and what must change before retrying. Avoid restoring an unsanitized source copy into active destination context during rollback.
Maintain the setup after migration
Assign responsibility for reviewing the migrated instructions and knowledge. Revisit them when project facts, tooling, or workflows change, and remove rules that no longer have a purpose.
Keep the inventory aligned with the active setup. Recheck the affected behavior when changing a destination mechanism or rebuilding an automation. This makes future maintenance a review of known decisions rather than another attempt to reconstruct why the agent behaves as it does.
Migration checklist and decision tree
Use this checklist as a recommended acceptance record:
- [ ] Source material and the destination’s initial state are recoverable.
- [ ] Every candidate has a source, scope, sensitivity classification, and disposition.
- [ ] Retained facts are reviewed, deduplicated, and dated where needed.
- [ ] Instructions have clear conditions and expected behavior.
- [ ] Sensitive content is excluded from the sanitized transfer.
- [ ] Each retained category has a verified destination mechanism or an explicit unresolved status.
- [ ] Tool-dependent features are tested individually or documented as deferred.
- [ ] Behavior, scope, conflict, automation, and sensitive-content checks are recorded.
- [ ] Rollback remains available, and the setup has a maintenance owner.
For each candidate, follow this decision sequence:
- Is it appropriate to transfer? If it is sensitive, stale, irrelevant, or unverified, exclude it from active context and record the reason without copying sensitive contents.
- Is it knowledge or an instruction? Review the text, choose its scope, and verify the destination mechanism before adding it.
- Does it depend on runtime behavior? Rebuild only when a supported destination mechanism is established; otherwise defer it and document the missing behavior.
- Does it pass the relevant acceptance checks? Retain passing items. Revise or roll back failing items before expanding the migration.
Explore more AI Agents coverage.
