mex

Shared project memory for engineers and their coding agents.

npx mex-agent@0.8.3 setup

Setup includes the official Inbox and Relay skills for your selected Claude Code or Codex integration. Standalone skill installation is an alternative for existing MEX projects.

MEX keeps your team's architecture, decisions, requirements, and handoffs alongside the code. Engineers and their agents can build on shared context, review proposed changes, and carry work between sessions and teammates—with Git as the sharing layer.

English | 简体中文 | Español | Português (Brasil)

Team memory · A teammate-handoff example · Project Hub · Quick start · How it works · Command map

---

One engineer knows why a constraint exists. Another has the debugging history. A coding agent found an important edge case in a session nobody else will read. The next teammate has to piece it together again.

What one engineer and their agent learn should become context the next teammate can use. MEX gives that knowledge a durable home in the repository: readable Markdown, code-linked explanations, reviewed knowledge contributions, and structured handoffs. People explore and review it in a local Hub; agents retrieve and help maintain it through project instructions and the CLI.

[!IMPORTANT] MEX 0.8.3 makes graph refresh incremental and grounding more reliable, adds FastAPI, Flask, and NestJS routes, and brings scaffold export and Markdown timelines. Existing projects should follow the graph upgrade steps to preserve TypeScript grounding links.

💬 Join the MEX community on Discord — discuss ideas, get help, share feedback, and show what you're building.

Join the Discord →

What your team remembers

What the team needs to retain	Where it lives in MEX
How the system works, and why	Wiki architecture, decisions, conventions, and patterns, with Code Graph grounding
A decision or explanation worth sharing	An Inbox proposal that adds to or corrects existing Wiki knowledge
Product requirements already captured	Existing Specs, requirements, constraints, and acceptance criteria remain supported
Where another engineer should continue	Relays with progress, decisions, blockers, evidence, and next actions
Earlier workflow context	Existing Workstream records remain readable
Who is involved, and what MEX recorded	Members and Activity history

Canonical memory travels with ordinary Git commit, push, and pull. Each teammate keeps their own local indexes, drafts, identity selection, and Hub. No hosted MEX service, Docker, proxy, MEX account, or MEX-owned model key is required.

Working solo? The next person using that memory can be you in a new session.

From one engineer to the next

An example: Alex changes webhook retry handling, and Sam will continue the work. Both are active MEX Members in a repository their team has already set up.

1. Start with the team's context. Alex asks Codex to inspect the existing architecture, relevant decisions, and code evidence before making the change and running tests.
2. Keep the useful discoveries. With Alex's direction, Codex updates the relevant Wiki explanation and code references. For a conclusion the team should review, it prepares an Inbox knowledge proposal for explicit approval.
3. Prepare and publish the handoff. Alex asks $mex-relay to draft a Relay for Sam: what changed, which tests ran, what remains, and where to look next. She reviews the draft and publication preview in Hub, explicitly publishes it, then reviews, commits, and pushes the code and canonical MEX files through Git.
4. Continue from shared context. Sam pulls the relevant branch, updates his local indexes as needed, and opens Hub. He reviews and takes the Relay, then asks his coding agent to read its context and continue. His acknowledgement is another canonical change to commit and push.

The Relay carries the explanation and observed repository state—not the uncommitted code. Publishing writes files to Alex's checkout; it does not notify Sam or deliver anything until they share through Git. See Relay boundaries for lifecycle and concurrency details.

Project Hub

The Hub is where people explore and review their team's memory. Open it to explore connected project knowledge and code, review a proposed knowledge change, find an eligible handoff, or see recorded team history.

• Understand the project: Home, Search, Context, and Code bring explanations and implementation evidence together. The Context graph shows knowledge entities and relationships; selecting one reveals its direct code groundings and details.
• Review and carry work forward: Inbox proposes additions and corrections to project knowledge; Relays preserve what the next person needs. Existing Spec proposals and Workstream records remain readable.
• See who and what: Team/Members supports attribution and local identity selection. Activity shows accepted MEX workflow events and recorded project notes—not every code edit or Git action.
• Keep context usable: Health and Jobs expose index status and explicit maintenance.

After setup, run mex hub. Each engineer's Hub reads their own checkout and listens on 127.0.0.1; it is not a shared hosted dashboard. Git brings the team's canonical records into that checkout. Hub protects mutations with a server-side session and CSRF token. Playbook and Catch Up product workflows remain future work.

Quick start

MEX requires Node.js 22.5 or newer, SQLite FTS5 support in that Node build, and a Git repository. See runtime compatibility.