PAXM: A Provider-Neutral Memory Layer for Coding Agents

The repeated-context problem PAXM targets

Every new agent session starts blank. Architecture decisions, deployment rules, and naming conventions live in the previous session's transcript or in a human's head, and the README frames the product around exactly that gap: "Stop re-explaining your project to every new coding-agent session." The audience is developers who already run more than one coding agent, or who run one agent across several machines and want the same working context in each. A single-agent user with a stable setup gets less from this, because the agent's own project files already carry much of that context. The value appears when the same decision has to survive a switch from Codex to Claude Code, or from a laptop session to a later one. PAXM also targets teams that want a shared durable write profile, which the README describes as profiles such as team-pax-core created from optional team IDs.

How memory moves between agents: profiles, hooks, and MCP

PAXM is a Go binary with a CLI, and the memory itself is addressed through profiles. The README uses two: ltm for long-term memory and stm for short-term. Writes go through paxm remember with a --profile flag and a --text payload; reads go through paxm recall with a --query string. That CLI is the floor. Above it sit two integration styles. Active memory is skill-based and user-installed, which the README states plainly: active recall skills remain user-installed. Passive memory is hook-based. The Claude Code plugin registers five lifecycle hooks (SessionStart, UserPromptSubmit, PostToolUse, PostToolUseFailure, and Stop), and with passive integration enabled paxm recalls relevant context before the agent responds and captures completed turns afterward. Codex, Claude Code, and Pi use their session-start events; OpenCode runs the same bootstrap before the first message. The README also describes a refresh rule: if a later user input arrives more than 12 hours after the preceding turn activity, paxm refreshes local-time context before the agent handles that input. The MCP server bundled with the Claude plugin is the third path, and it is what non-listed MCP clients would use. Storage sits behind all of this: SQLite locally, or Zep, Mem0, MemOS, or OpenViking, or a private provider reached over JSON-RPC.

Getting to a first successful recall

The Codex path is four commands. Add the marketplace, add the plugin, run the install script, then run setup:

codex plugin marketplace add pax-beehive/paxm --ref paxm-memory-v0.1.4 codex plugin add paxm-memory@pax-agent-nexus curl -fsSL https://github.com/pax-beehive/paxm/releases/latest/download/install.sh | bash paxm setup --integration codex-plugin

The README notes that the plugin never installs a binary, writes credentials, or bypasses hook trust on its own, so the install script and the manual hook trust step in /hooks are both required. Claude Code substitutes claude plugin marketplace add and claude plugin install paxm-claude@pax-memory, followed by paxm setup --integration claude-plugin. For everything else, paxm setup alone runs an interactive flow that asks two questions: which providers to enable and which agents get passive memory. Agents found on the machine are pre-selected and marked (detected), and cloud API keys are masked as typed. Non-interactive runs accept repeatable flags, for example paxm setup --provider sqlite --agent codex --agent claude, and identity flags such as --user-id todd --team-id pax-core. The README gives this verification sequence, and it is the part worth running before you trust the passive path:

paxm config doctor paxm remember --profile stm --text "PAXM_FIRST_RECALL_OK" paxm recall --query "PAXM_FIRST_RECALL_OK" paxm history --days 1

For reproducible installs or rollback, set PAXM_VERSION before installation. Fine-tuning of paths, profiles, routing policy, and per-hook behavior is not in the setup wizard; it lives in the config file described in docs/config.md.

The SQLite sandbox failure mode

The default provider is SQLite with no account, API key, or embedding model, which is the main reason to start here rather than with a hosted memory service. It also produces the sharpest documented failure. SQLite health checks must be allowed to create WAL and SHM files beside the configured database, and a sandbox that can read the database but cannot write its parent directory may report SQLite error 14. The README's guidance is to use an isolated writable SQLite path for sandboxed evaluations, because the same configuration may be healthy in the real agent process. This is a real constraint rather than a footnote: containerized CI, read-only mounts, and locked-down agent sandboxes will hit it, and the error surfaces as a database problem when the actual cause is a directory permission. There is a second, softer failure mode in the hook layer. Passive memory depends on hook trust, and the README instructs users to let the bundled Codex plugin own Codex's hooks so paxm does not register a duplicate global hook. Running the plugin and a separately registered global hook is the configuration to avoid.

Where PAXM is the wrong tool

If your work stays inside one agent and that agent already persists project instructions in a file you commit, PAXM adds a second store to keep coherent. If you want memory that a vendor operates and guarantees, this is the opposite design: the README puts credentials, routing, data location, disable, uninstall, and rollback under user control, which means the operational work is yours. If your environment forbids writing beside the database, the default provider is not usable without changing the path. And if you need retrieval quality that depends on embeddings, the local default does not use them by the README's own description; you would move to a remote provider and take on its connection details during setup.

The alternative: agent-native memory files

The closest alternative is not another memory server but the file-based approach each agent already ships, where conventions live in a checked-in instructions file that the agent reads at session start. The difference is in the data path. A committed file is read by one agent in one repository, versioned with the code, and reviewed like code. PAXM writes to a database outside the repository and serves any configured agent, which is why a decision captured in Codex can be recalled from Claude Code, OpenCode, Pi, or an MCP client. That cross-agent reach is the whole argument, and it comes with a cost the file approach does not have: memory is no longer visible in a diff. If your team reviews conventions in pull requests, a database-backed store moves that review out of the normal path. PAXM's paxm history command is the substitute for reading a diff, and it is a weaker one for audit purposes.

Maintenance, licence, and what to check next

PAXM is Apache-2.0, a permissive licence that allows commercial use and modification; the repository ships a LICENSE file, and anything beyond that is a question for your own counsel. The project is active, with v0.2.6 released on 2026-07-26 and the last push to main on 2026-08-28. The versioning is worth reading carefully before you pin anything. The plugin marketplace command in the README pins --ref paxm-memory-v0.1.4 while the binary releases are at v0.2.6, so the plugin ref and the CLI version move on separate tracks. Set PAXM_VERSION before installation if you want the binary and the plugin to be reproducible together. Upgrade cost is mostly in the config file rather than the binary: docs/config.md covers paths, profiles, routing policy, and per-hook behavior, and those are the settings most likely to need attention when a provider or an agent integration changes. The first thing to verify on any new machine is that paxm config doctor passes in the same process that will run the agent, not just in your shell.

Editorial conclusion

Adopt PAXM if you switch between Codex, Claude Code, OpenCode, or Pi on the same repository and want one recall path without sending memory to a hosted service. Skip it if you work in a read-only sandbox or want a single-vendor memory feature that ships inside the agent. Before trusting passive memory, run paxm config doctor, then paxm remember --profile stm --text "PAXM_FIRST_RECALL_OK" followed by paxm recall --query "PAXM_FIRST_RECALL_OK" and paxm history --days 1, and confirm the SQLite directory accepts WAL and SHM files.

Official sources

1. Issues
2. License: Apache-2.0
3. pax-beehive/paxm on GitHub
4. README
5. Releases