MemoraX Code: A Shared Memory Layer for Coding Agents
A memory plugin for AI coding that turns engineering experience, repository knowledge, and your way of working into memory that remains useful in future tasks.
At a glance
- What is it?
- MemoraX Code stores engineering context, repository knowledge and working preferences so that Codex, Claude Code and five other clients can reuse them in later sessions. The design is client-agnostic and account-backed, but its usefulness depends on hooks actually firing and on network access to the MemoraX service.
- Who is it for?
- Adopt MemoraX Code if you run two or more of the supported clients and want the same repository context to follow you between them, and if you are comfortable with memory living behind a remote service rather than on disk. Do not adopt it if your work happens on machines without outbound network access, or if you want the memory layer to be inspectable and editable as plain local files.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between one agent session and the next
The README states the problem plainly: a new session often starts without the architecture, failed attempts, repository rules, or working preferences established before it. Coding agents are described as good at the task in front of them and bad at carrying anything forward. MemoraX Code targets that gap by giving several clients a shared memory layer, so that knowledge from a finished task can be recalled in a later one.
The intended audience is developers who already use at least one of Codex, Claude Code, CodeBuddy CLI, WorkBuddy, DeepSeek Harness, OpenCode or Trae, and who work across more than one of them or across more than one machine. The README is explicit that the goal is not to remember everything, but to bring back the small amount of memory relevant to the current task. That scoping decision matters: a memory system that tries to retain everything becomes a retrieval problem, and the project defines its success as reaching useful investigation and validation sooner, not as accumulating the largest store.
How memory is captured: adapters, hooks and a managed backend
The mechanism visible in the material is a client adapter plus hooks. During setup, the tool detects supported coding agents and installs a managed plugin, hooks and, for some clients, a Skill. Each client then loads that integration in its own way. Codex requires the MemoraX Code Codex Adapter to be enabled from Plugins or `/plugins`. Claude Code needs a restart or refresh to load the managed plugin and hooks. CodeBuddy CLI needs a new session. WorkBuddy manages its plugin, hooks and Skill independently and needs a restart. DeepSeek Harness registers the plugin in existing Profiles. OpenCode discovers the managed plugin and Skill on restart. Trae is the odd one out: setup installs the hooks and Skill, but you must enable the registered Global Hooks once under Settings, Hooks, Global, Configured Hooks.
There is also a local Backend process, referenced by the status command and by the npm lifecycle scripts that stop and restore a running managed Backend during package replacement. The README notes that search and writeback require network access, so the local component is not the whole story. The exact split between what the local Backend does and what the remote service does is not spelled out in the supplied material. What can be said is that the memory is account-backed: credentials come from a MemoraX account or from guest mode, and the configuration file at `~/.memorax-code/config.toml` holds the username and API key on a configured device.
Getting it running: the commands that matter
Installation is a single global npm package: `npm install -g @memorax/memorax-code`. The README warns against `--ignore-scripts`, because the lifecycle scripts stop and restore an existing running managed Backend during replacement. Node.js 20 or newer is required, with Node.js 24 LTS recommended. DeepSeek Harness has a narrower window: `^22.19.0 || >=24.0.0`, and DSH must be installed and initialized with at least one Profile and `pnpm` on PATH before setup. MemoraX Code does not install or update DSH.
There are two connection paths. The recommended one is `memorax-code setup --existing-account`, run from a normal interactive terminal, which prompts for a MemoraX username and API key. The alternative is `memorax-code setup`, which creates or restores guest credentials and is described as a 90-day guest mode. Replacing a saved connection uses `memorax-code setup --reconfigure` for guest mode or `memorax-code setup --existing-account` for a registered account. If you start as a guest and want to keep that memory when you register, run `memorax-code account --show-mark-id` before registering and use the Mark ID to activate the guest account on the platform. The README states the platform does not currently support attaching a Mark ID to an account that has already been registered, so the order is not optional.
Verification uses three commands from the project directory: `memorax-code --version`, `memorax-code status` and `memorax-cli status`. On Windows PowerShell the last one is `memorax-cli.cmd status`. The README is careful about what these prove: `memorax-code status` checks the local Backend and client integrations, `memorax-cli status` checks the local memory configuration and workspace scope, and neither sends a test request to MemoraX. Only a real search or write verifies remote connectivity and credentials.
The hook-runtime state is the honest part of the design
A configured integration may still report `hook-runtime=unverified` until the client executes its hook. After a hook executes successfully, that client's hook runtime should change to `observed`. This two-state reporting is the most useful thing in the README, because it separates installation from operation. A plugin can be present on disk and still never fire, and the status output tells you which of those situations you are in.
The practical consequence is that a clean install proves very little. You need to open a project, start a new client session, send one prompt, and then check status again. Trae makes this more visible than the others, since its hooks require a manual switch that setup cannot flip. Anyone evaluating the tool on a single client should expect at least one round of restart, prompt and re-check before the memory layer is doing anything.
Where it breaks: credentials, network and environment boundaries
On Linux, setup-managed credentials require `/usr/bin/secret-tool` from libsecret and an available Secret Service in the current user session. That is a hard dependency, not a suggestion, and headless or minimally provisioned Linux environments frequently lack it. For Remote SSH, WSL or Dev Containers, the README instructs installing MemoraX Code in the same environment as the coding agent. Install it on the host while the agent runs in a container and the integration will not line up.
Network access is required for search and writeback. That rules the tool out for air-gapped work or for anyone who does not want repository context leaving the machine, and the README offers no local-only mode. Guest mode expires after 90 days, and the Mark ID activation path is one-way: register first and the guest memory cannot be attached afterwards. The configuration file contains an API key, and the README warns to keep it private and never paste it into chats or public issues.
The material also does not describe what gets sent to the service, how long it is retained, or how to delete it. For a tool whose whole purpose is retaining engineering context, that omission is the largest unanswered question, and it is something a prospective user should resolve before pointing it at a private repository.
What it is not: a replacement for repo-local instruction files
The obvious alternative is the mechanism each client already ships: repository-local instruction files and per-client memory. Codex and Claude Code both read project-level guidance committed alongside the code, and that approach has properties MemoraX Code does not claim. It is versioned with the repository, reviewable in a pull request, identical for every teammate, and works with no account, no daemon and no network. Its weakness is the mirror image: it is static, it does not learn from a failed attempt, and it does not follow you between clients or machines.
The difference in approach is capture versus declaration. A committed instruction file states rules up front and stays silent about what happened during a task. MemoraX Code is built to capture reusable lessons from completed work and carry procedures and preferences into future sessions, which is why it needs hooks, a backend and an account. If your need is a stable set of project conventions that every contributor sees identically, the committed file is the better tool and always will be. MemoraX Code only earns its complexity when the knowledge you want to reuse is the kind that accumulates from doing the work, and when you move between the supported clients often enough that retyping it is a real cost.
Maintenance cost, licensing and what to watch
The package is MIT-licensed, which permits commercial use and modification, and places the usual obligation to preserve the copyright and permission notice. That is a statement about the licence text, not legal advice; if you redistribute the package or a modified version, read the licence yourself.
Upgrade cost is low in command terms: a global npm install replaces the package, and the README states the lifecycle scripts safely stop and restore a running managed Backend during replacement. The real cost is re-verification. Every upgrade can change hook behaviour, and after each one you are back to checking that the client's hook runtime returns to `observed` with a real prompt. The release cadence visible in the repository is fast: v0.1.14, v0.1.15 and v0.1.16 landed on 7, 9 and 10 September 2026 respectively. Three patch releases in four days at the 0.1.x line is a signal about stability, and it argues for pinning a version you have verified rather than tracking the latest tag. There is no information in the supplied material about a changelog, a deprecation policy, or what a future major version would break.
Editorial conclusion
Adopt MemoraX Code if you run two or more of the supported clients and want the same repository context to follow you between them, and if you are comfortable with memory living behind a remote service rather than on disk. Do not adopt it if your work happens on machines without outbound network access, or if you want the memory layer to be inspectable and editable as plain local files. Before trusting it, run `memorax-code setup`, then confirm `memorax-code status` and `memorax-cli status` report what you expect, and check that the client's `hook-runtime` moves from `unverified` to `observed` after a real prompt. Until that transition happens, the memory layer is installed but not actually capturing anything.
Community notes