Does a decision recorded in Claude Code reach Codex on your machine?

[michielinksee]

I wrote linksee-memory, a local MCP memory server. The part I trust least is the
handoff between Claude Code and Codex: a decision recorded in one should be there
when the other starts work on the same repo. It works on my Windows machine and on
one Mac. That is all the evidence I have.

If you use both tools on one repo (0.17.1, published today):

1. Back up ~/.claude/settings.json, then run npx -y linksee-memory setup
   (it edits that file, and keeps a settings.json.bak-<timestamp> next to it).
2. Add it to Codex: codex mcp add linksee -- npx -y linksee-memory
3. In Claude Code, record a real decision, e.g. "pnpm, not npm, because the
   workspace scripts assume it".
4. Open Codex on the same repo and ask for something that touches it.

Then write here what happened. "Nothing happened" is the reply I need most.

What it does not do yet: the warning before an edit only fires in Claude Code,
because it runs on Claude Code hooks. Codex can read the decision, but nothing
stops it. Until 0.17.1 the hook also took several seconds to start through npx;
setup now writes a direct node call instead, but I have only measured that on my
own machine.

I'll answer in this thread within a day and post whatever I change.

---

Update, 2026-11-05 (0.17.2): if your install is from April or May, the database is an old
schema and 0.17.x refuses to open it. npx -y linksee-memory@0.17.2 migrate copies it aside,
migrates the copy, and only then swaps it in; the original stays as a backup. Close every
client before running it. The hook also now calls node directly instead of npx, so it
starts in well under a second here.

[SebastiaanBoon]

I have not run your setup, so this is not a test report. But I have hit the same handoff problem from the other side, so here are the cases I would try first, because they are where a decision memory usually breaks in practice:

1. A decision that gets reversed. Record "pnpm, not npm", then later record "we moved back to npm". Does Codex see only the newer one, or both? An append-only log with a date and a "supersedes" link per decision is easier to trust than editing entries in place.
2. A decision that belongs to one repo. Record it in repo A, then open Codex in repo B. It should not show up there. The same goes for a decision that is meant to hold for every repo, which needs its own scope.
3. Who said it. If the entry says whether you decided it or the assistant suggested it, the next tool can treat a suggestion as softer than a rule.
4. Two tools writing at once, for example Claude Code and Codex both recording something in the same minute.

One limit of the local approach, in case it matters to you: a stdio server on one machine cannot be reached from a second machine or from a chat app, so the handoff stops at the edge of the laptop. I took the other route with Cloud Alter Ego, which I built. It keeps rules, a profile and per project notes as plain files in your own cloud and serves them through a remote MCP connector, so any assistant that supports MCP reads the same files. Docs: https://cloudalterego.cafeboon.com/docs.html and the open source template: https://github.com/SebastiaanBoon/cloud-alter-ego. It is a different trade-off (a hosted connector instead of a local process), not a replacement for what you are building.

[michielinksee]

Your first case, the reversed decision, is how 0.18.0 handles it now: remember({ supersedes: <id> }) links the new decision to the old one, and recall leaves the old one out unless you ask for it with include_superseded: true. That came from your list (PR #21: #21, changelog:

linksee-memory/CHANGELOG.md

Lines 136 to 137 in f7886f2

	- **`remember({ content, supersedes: <id> | [<id>, …] })`** — the new memory replaces older ones.
	Writes a `supersedes` edge (new → old) and sets the old memory's `state` to `superseded` with

).

The weekly report in this thread has an "Added by others" section, and I'd like to list you there for that case, with a link to your comment above. If you'd rather not, a "no" is fine, and if I don't hear back I'll leave your name out.

Separately, if you don't mind saying (skipping it is fine), where did you first come across Linksee?

I read the Cloud Alter Ego README afterwards: hooks journal each turn into a private Git repo that every device pulls on start, which is a direct answer to the laptop edge you pointed out.

[SebastiaanBoon]

Thanks for building the supersedes link so quickly. Yes, you can list me in the "Added by others" section for that case, linking to my comment is fine. I'll skip the second question, I can't point to a single source for it.

[michielinksee]

Thanks, this is more useful than a test report would have been, because three of your four cases are exactly where I already know it is weak:

1. Reversal: the store has a supersedes edge in the schema, but as of 0.17.2 nothing writes it. A newer remember sits next to the older one and recall ranks by recency and score, so Codex would most likely see both. Append-only with an explicit supersedes link is the right shape; it is on the list for 0.18.
2. Repo scope: this one works. Memories are keyed to a project (the workspace root), and a decision can be marked as holding everywhere. I will put a two-repo step into the test above so people actually try it.
3. Who said it: not recorded today. There is a source column, and nothing fills it from the MCP side. Treating a suggestion as softer than a rule needs that first.
4. Two writers in the same minute: SQLite in WAL mode with a 5 s busy timeout. I have not reproduced a real collision, so I will not claim it is fine.

On the laptop edge: agreed, that is the trade-off I chose. Thanks for the pointer to Cloud Alter Ego; a shared plain-file store behind a remote connector is a reasonable other side of it.

[michielinksee]

Correction to my point 2 above: repo scope does not work the way I said. I tested it properly while building 0.18: a decision recorded in repo A does come back from recall in repo B, labelled with its project (entity: repo-a), and it is only narrowed if the agent passes entity_name, which is a substring match on the project name (so repo-a also matches repo-a-backup). I had answered from memory instead of from the code, which is exactly the mistake this tool is meant to prevent. The README test now says what actually happens.

What 0.18.0 (PR open, not yet published) does change:

• Reversal: remember({ supersedes: <id> }) writes the supersedes link and marks the old memory superseded in one transaction; recall hides it by default and include_superseded: true brings it back. A missing id, another project's memory, or the memory itself is refused with nothing written.
• Who said it: new rows record the MCP client name and version from initialize (or claude-code / stop-hook for the hook), and recall shows by: <client>. It is self-reported, and older rows stay blank rather than guessed.
• Concurrent writes are unchanged: WAL with a 5 s wait; a save that times out writes nothing.

[michielinksee]

0.18.0 is on npm. Two of the four cases above are now in the product: remember({ supersedes: <id> }) writes the supersedes link and marks the old memory superseded in one transaction (a missing id, another project's memory, the memory itself, or a half-structured JSON payload is refused with nothing written), and recall hides superseded memories by default (include_superseded: true brings them back). New memories also record which MCP client wrote them, shown as by: <client>; it is self-reported, and older rows stay blank.

Still as stated in the correction: memories come back across repos on one machine, entity_name narrows by substring, and concurrent writes are unchanged (WAL, 5 s wait, a timed-out save writes nothing).

npx -y linksee-memory@0.18.0 setup upgrades an existing install; a database from before May still needs npx -y linksee-memory@0.18.0 migrate first, with every client closed.

[michielinksee]

Linksee Lint Weekly #1 (2026-11-05)

Weekly check of one real linksee-memory database (package v0.18.0). Section 1 comes from a read-only query of memory.db; sections 2-4 are written by hand. You can run the same check on your own DB: recall({ dream: true }) shows your rewrite queue, and the SQL for every row is at the bottom.

1. Warnings this week

Check	Last week	This week	Change
Memories (total)	—	3499	—
New in the last 7 days	—	443	—
Rewrite pending (needs_distill=1, not superseded)	—	9	—
Rewrite queue as recall({dream:true}) sees it	—	9	—
Superseded (state=superseded)	—	110	—
No title (valid JSON, title missing)	—	1057	—
Broken JSON (json_valid=0)	—	136	—
Missing axis (altitude/type/state)	—	200	—

By layer (this week):

Layer	Memories	New	No title	Broken JSON	Missing axis	Rewrite pending	Superseded
caveat	710	4	222	42	18	0	14
context	131	46	1	9	1	0	0
emotion	1	0	0	1	0	0	0
goal	692	103	142	36	140	0	5
implementation	805	247	27	23	4	0	0
learning	1160	43	665	25	37	9	91

First report: there is no "last week" column yet. From #2 on, "Change" is this week minus last week; a negative number on a warning row is good.

2. Fixed this week

Three things happened to this DB this week. None of them needed a schema change; everything went through the public tools (recall, remember) so you can repeat it on your own DB.

Item	Before	After	How	PR / Issue
Rewrite queue drained	237	8	recall({ dream: true }) -> remember({ memory_id, content }), 30 headless agent runs of 8 items each. 201 rewritten, 28 dismissed as noise/stale, 8 left. (9 at report time: new raw rows arrive every session.)	no PR, DB maintenance only
Rewrites spot-checked	-	20 sampled	Random 20 of the 201: 18 good, 2 thin, 0 wrong. Axis (altitude/type/state) unchanged 20/20, no invented facts 0/20. Found: title dropped in 18/20, affects / evidence_refs / session_id dropped 20/20.	no PR
Dropped keys restored	201 rows missing keys	199 restored, 2 skipped, 0 failed	Merged the original keys back over the rewritten what/why with remember({ memory_id, content }). Verified read-only afterwards: 199/199 byte-exact, title and evidence_refs present 199/199, axis unchanged 199/199. The 2 skipped rows were created after the backup and have no original to restore from.	no PR
supersedes + hidden superseded rows	-	shipped in v0.18.0	remember({ ..., supersedes: id }) writes the edge and the state in one transaction; recall now hides superseded rows by default and reports superseded_hidden: n.	PR #21

The drain exposed four product gaps. They are 0.18.x candidates; issue numbers will be added here once filed.

1. The dream queue does not return altitude / type / state / title, so the rewriter has to guess them.
2. remember({ memory_id }) replaces content wholesale; any key you leave out disappears (this is why the restore above was needed).
3. Maintenance sessions are themselves captured by the Stop hook: the 30 runs added 98 raw rows. A way to mark a session as "do not capture" is needed.
4. A truncated remember payload leaves broken JSON in the DB. remember should validate JSON and reject.

If you want to check the same things on your DB: recall({ dream: true }) returns your distill_queue; the SQL below gives the rest.

3. Added by others

This section is empty. If you add a lint rule or a test case, your name goes here.

4. Next week

• Rewrite pending: should stay under 20. It only grows by what new sessions capture; if it climbs past that, the triage rules (not the drain) are the thing to fix.
• No title (1,057) and Missing axis (200): most are rows written before title and the three axes existed (665 of the no-title rows are old learning rows; 140 of the missing-axis rows are old goal rows). Decide next week whether to backfill or leave them and only lint new rows.
• Broken JSON (136): 1 new this week; the other 135 predate this week (mostly plain-text rows from before the JSON contract). Gap 4 above would stop new ones.
• Superseded (110): first week with v0.18.0 in use. Watch whether this row moves and whether superseded_hidden shows up in recall output.
• Which of the four gaps goes first. If you have an opinion, reply here.

How each row is counted (SQLite, read-only)

altitude, mem_type and mem_state are generated columns in memory.db (json_extract of $.altitude, $.type, $.state). "New" = created in the last 7 days.

-- Memories (total)
SELECT count(*) FROM memories;

-- New in the last 7 days
SELECT count(*) FROM memories WHERE created_at >= unixepoch() - 604800;

-- Rewrite pending (needs_distill=1, not superseded)
SELECT count(*) FROM memories WHERE CASE WHEN json_valid(content) THEN json_extract(content, '$.needs_distill') = 1 AND coalesce(mem_state, '') <> 'superseded' ELSE 0 END;

-- Rewrite queue as recall({dream:true}) sees it
SELECT count(*) FROM memories WHERE layer IN ('learning', 'caveat') AND created_at < unixepoch() - 1800 AND CASE WHEN json_valid(content) THEN json_extract(content, '$.distill_verdict') IS NULL AND (json_extract(content, '$.needs_distill') = 1 OR json_extract(content, '$.why') = 'Decision detected by pattern match — may need agent enrichment' OR json_extract(content, '$.why') = 'User-stated warning/prohibition — auto-extracted by caveat pattern match') ELSE 0 END;

-- Superseded (state=superseded)
SELECT count(*) FROM memories WHERE mem_state = 'superseded';

-- No title (valid JSON, title missing)
SELECT count(*) FROM memories WHERE CASE WHEN json_valid(content) THEN json_extract(content, '$.title') IS NULL ELSE 0 END;

-- Broken JSON (json_valid=0)
SELECT count(*) FROM memories WHERE NOT json_valid(content);

-- Missing axis (altitude/type/state)
SELECT count(*) FROM memories WHERE json_valid(content) AND (altitude IS NULL OR mem_type IS NULL OR mem_state IS NULL);

_{Generated by lint-weekly.mjs on 2026-11-05T09:15:33.258Z. Counts only; no memory content is included.}