Memmy Agent: a local memory hub that keeps Claude Code, Codex and OpenClaw on the same page

The problem Memmy Agent solves: five agents, five separate memories

If you use Claude Code for one repository, Codex for another, and a Cursor session in between, each tool keeps its own picture of what you are doing. Project background, preferences and unfinished work do not travel. The README frames the product around three verbs shown in its card images: Remember, Relay and Act. Remember turns local collaboration history into structured memory. Relay carries project background, preferences and progress from one tool to the next. Act describes Memmy as an agent itself, able to organize information and continue unfinished tasks.

The intended user is someone who already runs more than one agent and treats them as interchangeable workers rather than as separate products. The README lists DeepSeek Harness, OpenClaw, Hermes, Claude Code, Codex, Cursor, WorkBuddy, OpenCode and Pi as connectable. That list is the whole pitch: the memory layer is the constant, the agent is the variable. A single-agent user gets little from this, because there is nothing to relay.

How Memmy is built: a memory service, a gateway and a desktop shell

The repository is an npm workspace monorepo. The workspaces listed in package.json are Migrations, AgentSourceCore, Memory, App/backend/local-api-contracts, App/backend, App/frontend/*, App/shell/desktop/interface and App/shell/*. The package description calls it a "Local-first agent memory substrate with desktop and CLI surfaces", which matches the split: Memory holds the store, AgentSourceCore holds agent logic, App holds the backend and the desktop and terminal shells.

Two local HTTP services do the work. The memory service listens on 127.0.0.1:18960 and is what the `memmy-memory` CLI talks to. The gateway listens on port 18990 and exposes an OpenAI-compatible API via `memmy serve`. On Linux both run as `systemd --user` units named `memmy-memory.service` and `memmy-gateway.service`, bound to localhost. The README states they persist after the TUI or terminal exits and start again on later logins, but that the installer does not enable linger. That last detail matters: without linger, the services stop when your last session ends, so a background agent cannot rely on them being up.

The separation is deliberate and worth noting. The memory service is initialized without touching any agent. Installing the Memory Skill and the supported Hook or plugin for Codex, Claude Code or Cursor is a separate, explicit step through `memmy-memory init`. That means you can run the store and inspect it before you let any agent write to it.

Installing Memmy and running a first memory query

There are three documented entry points. The desktop app is recommended: download it from memmy.bot or from GitHub Releases. Registration grants trial tokens for agent tasks, and the README says that when those run out you switch to BYOK mode with your own model API. The CLI path is for Linux x64 or arm64 with Node.js 22 or newer and an available systemd user session:

curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash
memmy

The installer enables the memory service immediately. The first bare `memmy` invocation opens the model setup wizard if needed, then enables `memmy-gateway.service`, waits for readiness, and enters the TUI. You can confirm both units afterwards:

systemctl --user status memmy-memory.service
systemctl --user status memmy-gateway.service

The minimal BYOK configuration lives at `~/.memmy/config.yaml` and needs a provider block with an API key reference:

agents:
  defaults:
    model: openai/gpt-4.1
    provider: openai
    timezone: "+08:00"
providers:
  openai:
    apiKey: ${OPENAI_API_KEY}

With the memory service running, the `memmy-memory` CLI is the fastest way to see whether the store works before wiring an agent into it. It defaults to `http://127.0.0.1:18960` and accepts `--url`, `--token`, `--config`, `--source` and `--user-id` for service and namespace selection:

memmy-memory health
memmy-memory add "a piece of knowledge worth saving"
memmy-memory search "memory policies in this project"

A healthy response confirms the service is reachable. The `add` call should return an identifier you can feed back into `memmy-memory get <id>`. Only after that works should you run `memmy-memory init` for a specific agent, because that is the step that writes a Skill and Hook into the agent's own configuration. Building from source is also documented: clone the repository, copy `.env.example` to `.env`, run `npm install`, `npm run build`, then `bash scripts/dev-start.sh`.

Where Memmy Agent gets in the way

The Linux CLI path assumes systemd. The README is explicit that the installer launcher is what activates this service management, and that source-built Linux CLIs keep their existing behavior. So the convenient install and the from-source install do not behave the same way, and the difference is not a flag you can flip. Anyone on macOS, Windows or a container without a user systemd session should treat the desktop app as the real path.

Credential handling is the second sharp edge. Before starting or reconnecting to the Gateway, `memmy` refreshes `~/.memmy/systemd/gateway.env` at mode 0600 with configuration-referenced environment variables, common provider credentials and the terminal `PATH`. If any of those values change, the next bare `memmy` invocation restarts the user service with the new environment. That is convenient, and it also means your provider keys are copied into a file on disk and into the environment of a long-running service. The README documents the file mode but not a rotation procedure.

The README does not document rollback. There is no described way to undo `memmy-memory init` for an agent, no uninstall section, and no statement about what happens to the memory store if you remove the services. The Migrations workspace implies schema changes over time, but the README does not describe a migration or downgrade path. If you cannot tolerate an agent configuration you cannot cleanly revert, this is the wrong tool today.

Memmy against a single-vendor memory feature

The obvious alternative is not another open source project but the built-in memory of whichever agent you use most. A vendor memory feature is maintained by the same team as the agent, needs no local service, and cannot break when the agent's plugin interface changes. Its limit is scope: it remembers you inside that product and nowhere else.

Memmy's difference in approach is architectural. It puts the store behind an HTTP service on 127.0.0.1:18960 with a CLI in front, and it exposes an OpenAI-compatible API on 18990, so the memory outlives any single agent's session. The cost of that design is exactly what a vendor feature avoids: you now operate two services, a config file, a credential file and per-agent Skill and Hook installations. Memmy is the better choice only when cross-agent continuity is worth that operational surface. If you only ever use one agent, the vendor feature wins on every axis the README does not address.

Licence, maintenance and what an upgrade costs

The project is MIT licensed, which permits commercial and private use with the usual requirement to keep the copyright and permission notice. Nothing in the README adds a separate terms file for the agent runtime, but the desktop app points at cloud service and legal URLs in `.env.example` (`MEMMY_CLOUD_SERVICE`, `MEMMY_LEGAL_CN_BASE_URL`, `MEMMY_LEGAL_INTL_BASE_URL`), so the hosted portions may carry terms that the MIT licence does not cover. Check those pages before shipping anything that depends on the cloud service. This is a description of what the repository states, not legal advice.

The repository is not archived. The last push was on 2026-09-09, and releases v1.1.2, v1.1.3 and v1.1.4 landed on 2026-09-04, 2026-09-08 and 2026-09-09, so the release cadence in that window was days, not months. The package version in package.json is 1.1.4, and the build pipeline runs `scripts/sync-project-version.mjs` before build, typecheck and test, so workspace versions are kept aligned automatically.

The upgrade cost is not the version bump, it is the surface around it. An upgrade can rewrite the systemd unit environment, restart the gateway, and re-run agent initialization if the Skill or Hook format changed. The test suite has dedicated guards for this: `tests/package-version-guard.test.mjs`, `tests/packaged-runtime-config.test.mjs`, `tests/prune-packaged-runtime.test.mjs` and `tests/linux-cli-packaging.test.mjs`. Those tests tell you the maintainers think about packaging drift. They do not tell you the migration story for an existing memory store, because the README does not describe one.

Editorial conclusion

Adopt Memmy if you already switch between two or more coding agents and want their context to live in one local store you control, and if you are comfortable running systemd user services on Linux or installing a desktop build on other platforms. Do not adopt it if you need a documented rollback or a stable storage format today, or if your agents are already happy inside a single vendor's memory feature. Verify three things before committing: that `memmy-memory init` supports each agent you use, that the `~/.memmy/config.yaml` provider block matches your model endpoint, and that the Gateway port 18990 does not collide with anything already running.

Frequently asked questions

Official sources

1. License: MIT
2. MemTensor/memmy-agent on GitHub
3. Project website
4. README
5. Releases