Session export/import preserves compartments well; consider tooling for project-scoped memories

[simuxipalacheshi]

Hi! First of all, thank you for Magic Context. I recently went through a real OpenCode session migration and wanted to report both what worked surprisingly well and where there may be room for a safer migration helper around project memories.

Scenario

I had a very large OpenCode session that was accidentally created in the wrong directory/project scope.

• Original session directory: /home/abc
• Target project directory: /path/to/target-project
• OpenCode version: 1.15.11
• Magic Context plugin: @cortexkit/opencode-magic-context@latest
• Migration method: official OpenCode opencode export <session> followed by opencode import <export.json> from the target project directory

The OpenCode import preserved the same session_id while rewriting the session's project/directory metadata to the target project.

What worked very well

Magic Context's compressed history survived the migration very cleanly.

After the OpenCode import, the migrated session still had its Magic Context session-scoped state:

• compartments continued to be associated with the same session_id
• prior compressed conversation history remained visible/usable
• session_meta still existed for the session
• the migrated session did not feel like it had lost its compressed long-running history

This was genuinely impressive. The session had accumulated a lot of history, and I expected the migration to be more fragile. In practice, the compressed history behaved almost exactly as I would hope.

What did not migrate automatically

The part that did not naturally follow was persistent ctx_memory / project memory.

From inspecting the local Magic Context database, this looks consistent with the current design:

• compartments are session-scoped (session_id, sequence, content, harness, etc.)
• session_meta is session-scoped
• memories are project-scoped via project_path
• after OpenCode import moved the session into the target project, the old memories still belonged to the previous project key
• the target project key had no memory rows yet

So the behavior seems internally consistent: compressed history follows the session because it is keyed by session_id; persistent memories stay with the old project because they are keyed by project.

Why this may matter

OpenCode now has more workflows where sessions may move between directories/projects, intentionally or as recovery from starting in the wrong directory.

In this situation, Magic Context already gives a great migration experience for compressed history, but memory behavior may surprise users:

• The migrated session still has its compressed history.
• The user may reasonably expect related long-term memories to be available too.
• But project-scoped memories intentionally do not follow.

I agree that blindly moving all project memories would be dangerous. A broad project memory store may contain unrelated OS, tooling, or other project facts. But the current situation leaves users with no obvious safe path other than manually inspecting and copying SQLite rows.

Manual recovery I performed

To recover the useful project memories, I manually did the following:

1. Backed up ~/.local/share/cortexkit/magic-context/context.db.
2. Identified the old memory project key and the target git project key.
3. Filtered active memories for project-specific terms such as Holochain, DHT, lair, Android app, Tryorama, CredentialEntry, PairedNote, source_code_dna, AgentPubKey, etc.
4. Copied only those selected active memories to the target project key.
5. Copied their memory_embeddings rows as well.
6. Verified the target project had the copied memories and FTS rows.

In my case this copied 160 relevant active memories into the target project scope. It worked, but it is not a workflow most users should be expected to perform safely by hand.

Possible improvements

I do not think Magic Context should automatically copy all project memories. Project-scoped memory is the right default.

But one of these might make the migration story much safer:

1. Documentation: explicitly document that OpenCode export/import preserves Magic Context session-scoped compression state, but not project-scoped memories.
2. Nudge/warning: detect when a known session appears under a different project key and warn that project memories remain in the old scope.
3. Migration helper: provide a command/tool to copy selected memories from one project key to another.
4. Conservative mode: copy only memories whose source_session_id matches the migrated session.
5. Interactive/filter mode: let users preview categories and candidate memories before copying.

The conservative source_session_id option seems especially safe because it avoids dragging an entire old project/global memory store into a new project.

Summary

The good news: Magic Context's compressed history migration behavior was excellent in a real large-session migration. The session-scoped design worked very well.

The follow-up opportunity: project-scoped ctx_memory probably needs either documentation or a safe migration helper for users who intentionally move sessions between OpenCode projects/directories.

Thanks again for the work on this plugin — this was one of the more successful long-session migration experiences I have had with an AI coding tool.