My agents forget everything between sessions — decisions, bug root causes, "why we didn't use MongoDB". All gone when the context
window resets.
So I tried Memexa, a persistent memory layer for coding agents exposed as an MCP server.
## Setup: one command
\bash
cd my-project
npx -y memexa-mcp init
\\
Wizard detects your agents (Claude Code, Cursor, Devin, Codex, Gemini…), asks for an API key once, stores it privately. Config
s contain zero secrets — committable to git, teammates get the same setup by cloning.
It also writes usage rules into AGENTS.md/CLAUDE.md so agents call get_context, add_decision, log_bug without being as
ked.
## It broke on me (instructively)
First update_context → 500, retried 4×. Logs showed invalid input value for enum snapshottype: "SESSION" — a Postgres enum c
reated by an old migration never got the new label because a later migration skipped when the column already existed.
ALTER TYPE … ADD VALUE ×4 → fixed in ~30 min. First snapshot written right after.
## What's actually good
-
add_decisionstores the why + rejected alternatives — the stuff diffs don't capture -
log_bugwith root cause → same bug never diagnosed twice - pgvector
search_memoryfinds entries even with different wording - One key → configs for every agent you use
## Honest limits
- Prompt-driven: agents can ignore it. Works with Claude Code/Cursor/Devin; tiny local models won't bother
- Free tier = 2 projects
- Rough edges expected — it's new (I found one in the first hour)
## Verdict
Context now survives sessions. get_context at startup gives agents real project awareness instead of a blank slate.
\bash
npx -y memexa-mcp # key at app.memexa.tech, free tier
\\
Hands-on tryout, not a paid review.
Top comments (4)
The
snapshottype: SESSIONmigration failure is a useful reminder that memory reliability starts below the model. I like storing rejected alternatives alongside decisions. How do you tell an agent that a decision has been superseded after the codebase changes? A commit or version reference on each memory entry could keepget_contextfrom presenting stale rationale as current.Already halfway there: decisions can point to the ones they replace (
supersedes_id), with contradiction detection and versioning.What's missing is exactly your point: no link to the code state.
Shipped it: entries now store the Git SHA they were written at (
source_commit, viagit rev-parse HEADin the MCP client). A decision 40 commits behind HEAD can now be flagged as potentially stale instead of being presented as current. It's not perfect — a SHA doesn't prove the rationale is wrong, but it gives us an objective signal.Have you tried the Memexa tool?
Prompt-driven memory rules have an asymmetric compliance cost across a session. Reading context at startup is easy for the agent to justify because it needs file and architecture state before editing, whereas logging rejected alternatives or bug root causes happens after the fix already works. Without a post-session hook or commit check enforcing the write, the agent tends to skip the recap to finish sooner.
The four retries on that Postgres enum 500 show a similar cost in MCP setups. Retrying a deterministic schema error burns tokens and wall time without changing the database state, so failing fast on a 500 with the raw SQL message cuts debugging time down immediately.
Both points land.
On asymmetric compliance: you're right —
get_contextat startup has aforcing function (the agent needs project state anyway), while
log_bug/add_decisionhappen after the fix works, when the agent's incentive is towrap up. We're testing enforcement via agent hooks: a SessionEnd hook that
nudges
update_contextonce, rather than relying on mid-task discipline.Pre-commit is trickier — too early, the session isn't done.
On fail-fast: agreed, and it's partly on us — the API returned a generic
INTERNAL_SERVER_ERRORwith emptydetails, which is why the enum labelonly surfaced in backend logs. Better error propagation (sanitized DBAPI
messages on 5xx) would have cut that debugging loop significantly. Adding
it to the list.