01 · Review today (T2)
Read facts, observed work and open threads from a day card without turning them into durable traits.
Call get_daily_review and show T2, both T3 lanes, and pending candidates separately.Your AI should remember you — and remember that you changed.
Give AI a memory
that knows you changed.
MindBridge gives Codex and other AI tools a traceable long-term memory: operational T3 remembers how to work with you, while reflective T3 stores only patterns and identity hypotheses you confirmed. Every recall carries its source and date. The Memory Core runs locally by default.
See the product before the architecture
One card captures today. One timeline explains change.
MindBridge turns scattered conversations into memory you can revisit, recall, and audit — without stuffing the full chat history back into every prompt.
2026-08-04 · Tueauto-generated
Today's memory card
- Three graph problems in Codex; stuck on topological sort.
- Stood up /retrieve in FastAPI, cleared three 500s.
- Still editing architecture at 1:12am — two hours later than yesterday.
New preferences
uv for PythonNo weekend meetingsAnswer directly
You wrote none of this yourself.
from 38 projects · 243 transcripts
Written for you, once a night.
Memory timeline
Prefer uv for Python projects
created_at 2026-08-04 · just writtenNo meetings on weekends
created_at 2026-07-28 · valid_at openGym on Saturday mornings
created_at 2026-07-19Open to weekend work
superseded by the 2026-07-28 recordMemory you stop mentioning fades on its own.
VERIFIED IN A REAL CLIENT
Not just a web mockup. MindBridge now runs inside Codex and Claude Code.
Codex and Claude Code call the same MemoryService over local STDIO MCP; their local JSONL logs also increment into one T1/T2 store. Reads can run directly, while durable writes require user confirmation.
Local verification on Aug 20, 2026: a fresh Claude Code session called get_daily_review and received all four sections; three local log sources entered one Postgres store with zero duplicate source keys.Open the full install and usage guide Codex + Claude Code × MindBridgeLOCALLY VERIFIED
01Paste the install instruction below into Codex or Claude Code
02After setup, open a fresh session in that client
03Review T2 and T3 separately, then confirm durable writes only when needed
Read https://mindbridge.liangyue.site/install.md to install MindBridge locally, connect Codex and Claude Code, and ingest both local transcript sources.Call get_daily_card for the latest T2 card, then review_long_term_memory for the newest three T3 records. Answer in separate sections, cite every id, and do not write.Verified locally, not a public hosted memory service; the local data layer must be running. The public Companion Loop uses synthetic data.SIX STEPS IN CODEX / CLAUDE CODE
Review today, then separate work preferences from hypotheses about yourself.
Daily Review separates T2, operational T3, reflective T3, and pending Pattern Candidates. An inference stays outside memory until the user confirms its wording.
02 · Audit memory (T3)
List current and superseded long-term records instead of seeing only semantic search hits.
Call review_long_term_memory twice, once per namespace, and cite every id.03 · Work with context
Recall only the T3 records relevant to the current task, with provenance attached.
Use temporal_query for my writing preferences, cite the memory ids, then edit this essay.04 · Propose a Pattern Candidate
Require three observations across two dates and show counter-evidence. A candidate is not a trait.
Use propose_pattern for a hypothesis about how I respond to unclear scope, but do not write T3.05 · Confirm before Reflective T3
Confirm, edit, or reject with a receipt; only confirm/edit creates durable memory.
Show me the candidate first. Call resolve_pattern only after my explicit decision.06 · Memory Garden repair path
Read one memory by id, then edit or archive it so your history stays transparent.
Call get_memory_record(42) first; then call edit_memory(42, ...) or archive_memory(42).What each of the 11 tools does
Read tools run directly; every write asks you first. Grouped by what you get out of them.
READ · REVIEW
get_daily_card- Read one day's T2 card to see what actually happened.
get_daily_review- One day across T2, both T3 lanes, and pending pattern candidates.
review_long_term_memory- List long-term memory by namespace, unranked, for a full audit.
temporal_query- Recall preferences relevant to a question, newest weighted heavier.
WRITE · ASKS YOU FIRST
upsert_preference- Store a durable fact, deduplicated against what is already known.
PATTERNS · CANDIDATE FIRST
propose_pattern- Raise a hypothesis about you outside T3, as a candidate.
review_pattern_candidates- Read candidates and their evidence without touching T3.
resolve_pattern- Apply your confirm / edit / reject; only the first two reach T3.
MAINTAIN · MEMORY GARDEN
get_memory_record- Read one T3 row by id, for citing and checking.
edit_memory- Replace a memory with your confirmed wording; history stays.
archive_memory- Close a memory without deleting history.
What makes this memory trustworthy
Every recall answers three questions.
Where did it come from?
Memory ids and source records lead you back to the evidence.
When was it true?
created_at records the write; valid_at tells you whether it still applies.
What changed later?
A new preference supersedes conflicts. History stays visible without defining the present.
Two capture paths
One needs nothing from you. One lets the model do it. Both write to the same store.
Passive log parsingPath Aworking today
Nothing for you to do. An incremental pass reads the structured logs already on disk and computes what happened, masking suspected secrets before storing.
~/.claude/projects/**/*.jsonl~/.codex/sessions/** + archived_sessions/Active MCP read/writePath Bworking today
Mounted as a standard MCP server, so the model decides mid-conversation when to write, recall, and keep memory edits auditable.
get_daily_cardget_daily_reviewreview_long_term_memorytemporal_queryupsert_preferencepropose_patternreview_pattern_candidatesresolve_patternget_memory_recordarchive_memoryedit_memoryCodex · Claude Desktop · Claude Code · Cursor · VS CodeMindBridge memory layerT1Session buffer — today's raw turnsT2Rolling summary — one card per dayT3operational preferences + user-confirmed reflective patterns
Daily memory card
Written for you, and readable a month later.Cross-client recall
A habit mentioned in Claude applies in Cursor.Parsing and storage are local: it reads transcripts on your machine and writes to a local Postgres.
Stated plainly: Path A only works for tools that already write structured local logs (Claude Code, Codex CLI). Path B works with any MCP client. ChatGPT and web Claude expose no history API — those need a manual export and are out of scope for the automatic path.
Architecture
Each stage says where it runs and what produced it. Rule-computed and model-written are labelled separately, because they do not carry the same confidence.
One transcript, from disk to recallable memory
- 01Sourceslocal
local disk
- ~/.claude/projects/**/*.jsonl
- ~/.codex/archived_sessions/
- 02Path A · incremental parselocal
local · plain Python, no model
- byte cursors resume mid-file
- merges records sharing message.id (fixes a 2.5x token overcount)
- secrets masked before anything is stored
- 03T1 session bufferlocal
Postgres
- raw turns + project / git branch / tool names
- 04T2 day cardlocal
local · rule-computed
- rebuilt from T1 over the whole day, never from a delta
- counts, spans, tool tallies — reproducible
- 05M2 extractionleaves machine
generative model (optional)
- prose narrative + structured preference JSON
- Pydantic validation, repaired with the errors named
- the only step that sends anything off the machine
- 06T3 long-term memorylocal
pgvector · local embeddings
- cosine dedup before write (threshold 0.80)
- operational / reflective lanes
- recall scored cosine × e^(-λΔt)
MCP clientsClaude Code / Cursor / VS Code read and write the same memory
Diary UI/demo reads the same API; falls back to sample data and says so
Pattern loopcandidate → you confirm → only then a reflective write
Trust boundaries
Local-first should be specific, not vague.
Default behaviour, optional external processing, and unsupported scope are stated together.
Local by default
Transcript parsing, Postgres / pgvector, Redis, and retrieval run on your device.
Hosted extraction is explicit
A hosted model is optional for training-data generation; no excerpt leaves without --send-to-provider.
The public demo is synthetic
Companion Loop contains no personal corpus. Local verification and the public demo are kept distinct.
Codex native Memories are not merged yet
Today, Codex connects over MCP. A single source of truth requires an audited migration, not direct edits to ~/.codex/memories/.
Reproducible evidence
Only results we can rerun and explain.
Every number comes from eval scripts and results.json in the repository. Small samples stay labelled as pilots; a feature without a safe threshold stays off.
Connect your workflow
Next time Codex or Claude Code opens, let it ask: is this still true about you?
Start the local Memory Core, connect it over MCP, then run one query with memory ids to inspect what it remembers.