Problem
opencode-mem identifies projects by hashing the working directory path. When a user moves a repository to a different location (e.g., from /mnt/c/Users/alice/projects/infra to /home/alice/git/infra), the hash changes. The plugin creates a new empty shard for the new path. The old shard with all existing memories remains on disk under ~/.opencode-mem/data/projects/ but is no longer associated with any project.
There is no command to reassociate the old shard with the new directory.
Example
# Original location, 15 memories stored over 3 months
/home/user/git/ansible-workspace/
-> shard: project_fa645294d88bbae2_shard_0.db
# User moves the repo (different mount point, new machine, reorganized dirs)
/home/user/repos/ansible-workspace/
-> shard: project_c3a8bf0112e74d01_shard_0.db (new, empty)
# Old shard still exists but is orphaned
~/.opencode-mem/data/projects/project_fa645294d88bbae2_shard_0.db
The user has no way to connect the old shard to the new path without manually renaming the libSQL database file, which requires knowing the internal hash for the new directory.
Current workaround
- Open OpenCode in the new directory.
- Run
memory add "test" to trigger shard creation.
- Note the new shard filename.
- Stop OpenCode.
- Replace the new shard file with the old one.
- Restart and delete the test memory.
This works but is error-prone and undocumented.
Proposed solution
One or more of:
memory migrate --from <old-path> -- rehashes the current directory, renames the old shard file to match the new hash.
memory export --output memories.json / memory import --input memories.json -- dumps all memories (content, tags, metadata, timestamps) to a portable JSON file and re-imports them with new embeddings. This also covers backup/restore and cross-machine transfer.
memory list-shards -- shows all shard files with their associated directory paths (or "orphaned" if the path no longer exists). Helps users identify which shard belongs to which project.
Context
Shard files are libSQL (Turso) databases. The directory-to-hash mapping is internal to the plugin and not exposed to users. Without a migration path, any directory change (OS migration, path reorganization, switching from a Windows mount to a native Linux path) orphans the memory database.
Problem
opencode-mem identifies projects by hashing the working directory path. When a user moves a repository to a different location (e.g., from
/mnt/c/Users/alice/projects/infrato/home/alice/git/infra), the hash changes. The plugin creates a new empty shard for the new path. The old shard with all existing memories remains on disk under~/.opencode-mem/data/projects/but is no longer associated with any project.There is no command to reassociate the old shard with the new directory.
Example
The user has no way to connect the old shard to the new path without manually renaming the libSQL database file, which requires knowing the internal hash for the new directory.
Current workaround
memory add "test"to trigger shard creation.This works but is error-prone and undocumented.
Proposed solution
One or more of:
memory migrate --from <old-path>-- rehashes the current directory, renames the old shard file to match the new hash.memory export --output memories.json/memory import --input memories.json-- dumps all memories (content, tags, metadata, timestamps) to a portable JSON file and re-imports them with new embeddings. This also covers backup/restore and cross-machine transfer.memory list-shards-- shows all shard files with their associated directory paths (or "orphaned" if the path no longer exists). Helps users identify which shard belongs to which project.Context
Shard files are libSQL (Turso) databases. The directory-to-hash mapping is internal to the plugin and not exposed to users. Without a migration path, any directory change (OS migration, path reorganization, switching from a Windows mount to a native Linux path) orphans the memory database.