claude code and codex shared memory

[github-actions[bot]]

Originally posted as issue #3132 by @aethyron
#3132

Before submitting

• I searched existing issues and confirmed this is not a duplicate, i think

---

Is your feature request related to a problem? Please describe.
If you use both Claude Code and Codex, they share the same memory, and over time it confuses them and makes them use more tokens

The memory should be separated and more effective; maybe it's placebo, but I don't feel a real token save when I use Claude Mem. Also, if I clear the conversation and give a new task, the usage skyrockets

[loulanyue]

I checked the current source before suggesting a direction. The project identity and the client identity are already separate concepts:

• getProjectName() derives a stable project key from the Git repository root.
• normalizePlatformSource() already normalizes sources such as claude, codex, and cursor.

So the data needed for isolation largely exists; the missing product decision appears to be whether retrieval/injection should be scoped by project only or by project plus platform.

A backward-compatible design could be:

memoryScope = shared | platform
shared:   project = repo-name
platform: project = repo-name AND source = claude|codex|cursor

The scope needs to be applied consistently to startup injection, search, summaries, and context previews, not only writes. Existing rows with no source would need an explicit fallback rule. The UI could still offer an “all platforms” view, while agent injection remains isolated.

This would also make a useful regression test: write two observations for the same repo and session-shaped input, one from Claude and one from Codex; platform scope must retrieve only its own observation, while shared scope returns both.

The token spike after clearing a conversation may be related but is not necessarily the same bug: a new session can trigger startup context injection again. Platform filtering reduces irrelevant context, but a per-platform startup budget or observation limit may still be needed.

I would be interested in contributing the filtering/tests once maintainers confirm two points: should platform become the default for new installs, and how should legacy rows without a source be treated?