Memmy Agent Gives Six AI Tools One Memory. That Is Also One Blast Radius.

MemTensor's cross-agent memory hub imports your Claude Code, Codex, and Cursor history into a single local layer. How to try it in an afternoon, and the trust boundary it moves without saying so.

Read the CLI reference for Memmy Agent and one line does something the rest of the README does not prepare you for. memmy-memory init writes a memory config and, in the project's own words, installs "Skills for each Agent as needed."

Not skills for Memmy. Skills for your other agents. Claude Code, Codex, Cursor, OpenCode, OpenClaw, and Nous Research's Hermes Agent each get taught how to read and write a memory store that all six of them share.

That is a genuinely good idea and a security decision, in that order, and the README only frames it as the first one.

Why a shared memory layer is the right call

Agent memory has been a per-tool feature since the category existed. Claude Code has its files. Cursor has its rules. Hermes writes its own notes and caps them. Every one of those stores is a walled garden, so switching tools means reintroducing yourself, and running two in parallel means maintaining two versions of the same context that drift apart within a week.

MemTensor's argument is that memory is infrastructure and belongs underneath the tools rather than inside one of them. Their README puts it plainly: Memmy "remembers you first, then builds a general-purpose Agent on top of that."

That framing is correct and I think the whole space ends up there. A memory only one harness can read is a memory you will abandon the next time you switch harnesses, and this year people are switching harnesses constantly. So the interesting question is not whether shared memory wins. It is what changes when it does.

The mechanism

Memmy is an npm workspaces monorepo under MIT, requiring Node 22 or later, and it ships three entry points onto one runtime.

The Memory Service listens on http://127.0.0.1:18960 by default and exposes session, turn, search, write, panel, and analytics APIs, backed by SQLite at ~/.memmy/memory-service/memory.sqlite. The Agent Runtime handles model calls, the message loop, tool registration, MCP, sessions, skill loading, auto-compaction, and memory hooks. memmy serve puts an OpenAI-compatible API on port 18990. Config lives in ~/.memmy/config.yaml. The retrieval engine is MemOS, MemTensor's separate and considerably larger memory framework.

Then there is the piece that makes the whole thing work: Agent Source. The README describes it as "an adapter that collects historical context from external Agents; each source has history-reading logic and an optional Skill install target." Read that twice. Each adapter has a reader and a writer. The reader ingests months of your past sessions into long-term memory and generates what the project calls a "First Meeting Report." The writer plants a skill inside that agent's own configuration so it can query the shared store going forward.

One design choice here deserves credit, with a caveat. The README states that when the memory service is unavailable, Memmy reports the error explicitly rather than returning "fake memories." That sounds obvious until you have watched a retrieval layer silently degrade to plausible fiction on a connection timeout.

The caveat is that this guarantee applies where you would want it least tested. The documentation describes the client refusing to start unless it reaches a real memory layer or finds a local SQLite source, while recall and capture at runtime are fail-open: errors get logged and the agent carries on with its task rather than stopping. Fail-loud at startup, fail-open mid-session. Both are defensible choices and they are not the same promise, so do not read the README line as meaning your agent will tell you when a memory lookup silently returned nothing.

The part the README does not frame as a risk

Six agents reading one memory store is the feature. Six agents writing to one memory store is the same sentence with the arrow reversed, and it changes the threat model.

Consider the ordinary case. You point Cursor at a repository. Somewhere in it is a comment, a README line, or a dependency changelog carrying an instruction aimed at a model rather than a human. Cursor reads it. Nothing dramatic happens. But that session is now history, and history is what Memmy distills into long-term memory.

Tomorrow you open Claude Code on an unrelated project. It queries the shared store, and the instruction comes back as your remembered preference, carrying the authority of "this is what the user has always wanted," stripped of the context that would have let you recognize it as foreign.

Prompt injection has mostly been a session-scoped problem. Shared memory makes it a persistence problem, and cross-agent shared memory makes it a lateral movement problem. The injection lands in the tool with the weakest input hygiene and reaches the tool with the most privilege.

To their credit, MemTensor has thought about this and the documentation says so. Retrieved memory gets wrapped in a <memmy_memory_context> tag while the live request sits in <current_user_request>, explicitly so the model is less likely to treat an old memory as a new instruction. Imports are deduplicated and passed through a sensitive-data filter before anything becomes a memory.

That is more than most projects in this category ship, and it is still framing rather than validation. Tags tell the model how to weigh a piece of text. They do not decide whether the text should have been stored. An instruction that reads as a legitimate user preference will survive both the dedup pass and the context wrapper, because it looks exactly like the thing the system is designed to preserve.

Compare it to how Nous Research handled the same surface in Hermes Agent: self-written memory capped at 2,200 characters, writes scanned for injection, forced consolidation. Different bet, aimed at the write path rather than the read path.

I want to be fair about severity. This is not a vulnerability and I am not claiming anyone has exploited it. It is a structural property of shared memory that every project in this category will have to answer, and Memmy is early enough that the answer is still being written.

Local-first, and where the default actually points

The README's local-first section is strong: memory, configuration, and app state stored on your machine, no upload required.

Then the build instructions say cp .env.example .env and note that the cloud address comes pre-filled so it works out of the box. Open that file and it is twelve lines. MEMMY_APP_EDITION=intl, MEMMY_CLOUD_SERVICE=https://memmy-api.memtensor.cn, and a GA4 measurement ID field. So the international edition's default endpoint is a .cn domain, and the documented happy path connects you to MemTensor's hosted service. Account mode grants 30,000,000 trial tokens with automatic model routing, which is a real convenience and also means your prompts cross their infrastructure until you switch to BYOK.

None of this is hidden. It is in the README, stated directly, and BYOK works. But "local-first" describes where your memory is stored, not where your model traffic goes by default, and those are two different promises the phrase blurs together. Decide about it on purpose rather than by copying a file.

Put this into practice

The lowest-friction useful thing here is the history audit, and you can get value from it without adopting anything.

1. Back up your agent configs first. Copy your .claude/, .cursor/, and Codex config directories somewhere safe. memmy-memory init writes into them. Five minutes, and it makes step two reversible.

2. Read .env.example before you copy it. If you build from source, change MEMMY_CLOUD_SERVICE or go straight to API Key mode. The default is their cloud.

3. Run the history scan and read the report. Install, open the Memory panel, and scan your agent history sources. Even if you uninstall the same day, seeing what months of Cursor and Claude Code sessions actually contain is worth the hour. Most people have never looked.

4. Check what is listening, and set the token. Memmy's documented default ports run 18960 for memory HTTP, 18970 for gateway health, 18980 for the web UI and admin HTTP, and 18990 for the OpenAI-compatible API. Confirm every one of them is bound to loopback rather than 0.0.0.0, and pay particular attention to 18980, since that is the admin surface. Endpoints can be protected with a bearer token via MEMMY_MEMORY_TOKEN, so set it rather than assuming loopback is enough. A memory API reachable from café wifi is a bad afternoon, and this class of local agent service has a track record of getting that wrong.

5. Connect one agent, not six. Start with your least privileged tool. The value of shared memory scales with how many agents share it, and so does everything else. Add the second one after a week of watching what got written.

6. Query the store yourself. sqlite3 ~/.memmy/memory-service/memory.sqlite and look at what it decided to remember about you. A memory layer you cannot read is a memory layer you cannot audit, and this one hands you the file. Use that.

Steps one, two, and four take about fifteen minutes together. Step six is the one that will actually change your opinion of the tool, in either direction.

Honest limitations

The repository is early and the served numbers disagree with themselves. GitHub returned 70 stars, 22 forks, and 0 watchers on the repository page during this write-up, then 666 stars and 74 forks on a file page in the same session. A third-party index scanning in late July also reported 666 and 74, which suggests the higher pair is closer to real and the 70 was a stale or partial render. Commit history showed 39 commits on the first load. Treat any single star figure as a snapshot, including these. What is stable is the shape: a small, fast-moving project, not a proven one.

The comparison table is the maintainers' own positioning. The README scores Memmy against Hermes and OpenClaw across nine capabilities and says so directly, noting it reflects public positioning rather than item-by-item testing and inviting corrections. Read it as a product argument, which is what it is.

Much of the memory quality claim belongs to MemOS. The README credits distillation and hybrid retrieval to that engine, which is a separate and larger project with its own release history. Judging Memmy on retrieval quality means judging MemOS.

The roadmap widens the surface. Planned sources include browser activity and local documents, and planned team features include agent-to-agent sharing between colleagues under stated privacy protection. Each is a reasonable direction and each enlarges the same store six agents already write to. If the content question is unanswered at one user and six agents, it does not get easier at ten users.

The release cadence is fast enough to be its own risk. The project changelog lists six versions between July 17 and August 12, roughly one a week: v1.0.1 through v1.0.6. Versions to pin exist, which is good. A memory layer that reaches into six other agents' configuration directories and revs weekly is also a thing you should pin deliberately rather than tracking main.

The open question

I keep coming back to a distinction this category has not made yet: the difference between memory an agent stores and memory a user endorses.

Right now Memmy imports everything, distills it, and serves it to whoever asks. That is what makes the onboarding feel like magic, and it is also why the store inherits every bad instruction any of your agents ever read. A review step would kill the magic. No review step means the magic is load-bearing on trust you never explicitly extended.

Nobody has solved this. Hermes went with hard caps and injection scanning on the write path. Rowboat went with a plain-text vault you can open and delete from. Memmy went with importing your whole history and tagging it on the way back out so the model knows it is old. Three different answers, all reasonable, none of them a standard.

Run the history scan this week. Then look at what it remembered about you and ask whether you would have approved each line if it had asked. That answer is the actual review, and right now you are the only one performing it.

Sources: MemTensor/memmy-agent on GitHub (README and .env.example, MIT, retrieved August 15, 2026); MemTensor/MemOS; Memmy documentation, including the ports reference, memory sources, security notes, and changelog.