memorylake-harness: Cross-Device Memory for Claude Code, Codex & 5 More
Open-source plugins that connect Claude Code, Codex, opencode, DeepSeek Harness, QwenPaw, QwenWork and WorkBuddy to one MemoryLake. Local auto-memory syncs up in the background and is recallable from any machine or client. Configure once, shared by every harness. MIT.
memorylake-harness is the official set of client-side plugins from MemoryLake, aimed at one specific gap: Claude Code's auto-memory is good but scoped to one git repo on one machine, and Codex's session summaries stay local too. The harnesses do not replace either. They connect them to MemoryLake so memories written in another project, on another computer or from another client become searchable here, and memories written here reach everywhere else.
Seven clients are working today: Claude Code (recall reminder on read, background sync on write, session status line), Codex (recall skill plus per-turn summary sync), DeepSeek Harness, opencode, QwenPaw, QwenWork and WorkBuddy. Every harness shares one identity and data tree under ~/.memorylake/harness/, so running /memorylake:init once in Claude Code also configures Codex and the rest.
The Claude Code plugin is deliberately restrained. The read hook only injects a reminder and makes no network call, so reading local memory files adds zero latency. The write hook runs in the background and routes by memory type: user and feedback entries become facts that are searchable immediately, while project and reference documents upload as files for full-text indexing. Unchanged rewrites are skipped by hash. A failed sync is reported out loud and never masquerades as success. A repo maps to a cloud project by its normalized git remote URL, so every clone on every machine, written by any agent, lands in the same project.
Privacy has three layers. A per-repo .claude/memorylake.local.md has the final say on whether that project uploads. A global sync_deny list blocks path prefixes such as ~/work or ~/clients. The global sync_on_write flag sets the default, and a missing key means off. With no config at all the plugin does nothing: no hooks fire and no network calls happen. /memorylake:backfill uploads memories accumulated before install, dry-run first.
It suits developers who use several coding agents or switch between machines, and small teams that want their agents to share project context. It needs jq and the memorylake CLI; init downloads a prebuilt binary if none is on PATH.
FAQ
How do I install MemoryLake Harness in Claude Code?
Inside a Claude Code session run /plugin marketplace add memorylake-ai/memorylake-harness, then /plugin install memorylake@memorylake, then /memorylake:init. Init walks through CLI install (it downloads a prebuilt binary to ~/.memorylake/bin/ if none is on PATH), login, workspace selection and the global config, after which every project on the machine can recall and sync. jq must be installed.
Does it replace Claude Code's built-in auto-memory?
No. Local auto-memory stays the first stop: zero latency, loaded at session start. MemoryLake is the second stop for what local memory cannot hold, meaning memories from other repos, other machines and other clients. The plugin only does two things: remind Claude to search MemoryLake when it reads a local memory file, and sync local memory writes upward in the background.
Which projects get uploaded? Can I enable it for only some?
Yes, with three layers where the most specific wins: sync_on_write: false in a repo's .claude/memorylake.local.md vetoes that project; a global sync_deny list blocks path prefixes such as ~/work, ~/clients; and the global sync_on_write flag sets the default, where false means opt-in per project and a missing key also means off. The switch only governs uploads, recall works everywhere. The first sync of each project is announced in the session status line.
Do Claude Code and Codex memories end up in the same place?
Yes. Both plugins share the same global config, CLI and caches under ~/.memorylake/harness/, so running init in one configures the other. A repo's identity is its normalized git remote URL (like github.com-acme-foo), so the same repo on any machine, written by either agent, maps to one cloud project. Codex session summaries are routed by their cwd metadata to that project, and sync_deny applies to them too.
Is MemoryLake Harness free? Does it work in China?
The plugin code is MIT-licensed and free. It needs a MemoryLake account behind it: memorylake.ai (international) and memorylake.cn (China) are separate deployments with separate accounts. The CLI defaults to the international endpoint, and init lets you pick.