Migrate Memory
Carry an agent group's memory across a provider switch, in either direction, by distilling the source store into the target store.
What it does
- Carries agent memory across a provider switch in either direction
- Translates between store shapes: flat CLAUDE.local.md and the memory/ scaffold tree
- Copy, never move — the source store stays intact as your rollback
- Idempotent — re-running never duplicates imported memory
- Distills durable facts and drops conversational residue
- Restarts the group and verifies a migrated fact survived
What you'll need
- NanoClaw installed and running
- A group whose provider was switched with `ncl groups config update --provider`
- The target provider installed and its auth configured
Install
/migrate-memory How it works
NanoClaw does not migrate memory at runtime. Each provider keeps its own store, and switching a group’s provider leaves both stores untouched — the new provider simply starts with its own. Carrying memory across is a separate, explicit step, and /migrate-memory is that whole mechanism: your coding agent reads the source store, distills what’s durable, writes it into the target store, and restarts the group.
The skill translates between two store shapes, not provider names:
- Flat file —
CLAUDE.local.mdat the group workspace root (the Claude provider). - Scaffold tree — a
memory/directory used by any provider with a memory scaffold, such as Codex.memory/index.mdis the index, and durable notes live undermemory/memories/.
A switch only needs migration when it crosses shapes. Two providers that both use the scaffold share the same memory/ tree, so switching between them carries nothing. The real work is always one of two directions: flat to scaffold, or scaffold to flat.
Three principles govern the migration. Copy, never move — the source store stays intact, because it is the rollback. Idempotent — re-running must never duplicate what a previous run imported. Distill, don’t dump — the agent is the inference step, keeping identity and seed instructions, user preferences, and durable facts while dropping conversational residue.
Setup
Switching the provider is an operator action, run from the host before the skill:
ncl groups config update --id <group-id> --provider <name>
ncl groups restart --id <group-id>
Then run /migrate-memory. It works in four steps:
- Identify the group and direction. The skill uses
ncl groups listandncl groups config get --id <group-id>to read the current (target) provider, maps each side to its store shape, and inspects the group folder. If both sides use the same shape — or the source is empty — there’s nothing to migrate, and it says so and stops. - Flat to scaffold. It reads
CLAUDE.local.mdand any files it references, then distills the content intomemory/memories/imported-agent-memory.md, leading with anything that defines who the agent is. It adds a line tomemory/index.mdpointing at the imported file. - Scaffold to flat. It reads
memory/index.mdand the notes it points to, then integrates the durable facts intoCLAUDE.local.mdunder a clearly marked, dated section, deduplicating against what’s already there. - Restart and verify. It runs
ncl groups restart --id <group-id>and asks you to send the group a test message that depends on a migrated fact.
Tips
- If
memory/memories/imported-agent-memory.mdalready exists from a previous run, the skill shows you what’s there and asks before touching it, integrating only what’s new. - Because the source store is never modified, rollback is lossless — switch the provider back and the old store is waiting exactly as it was.
- If the test agent doesn’t know a migrated fact, re-check that the target file landed in the right group folder.
- For a full picture of what a provider switch carries over automatically, see the provider-migration docs.