Anyone else using both Codex and Claude Code and tired of keeping project context in two places?

[Patdolitse]

I bounce between Codex and Claude Code depending on the task, and the thing that quietly wears on me is that each one has its own notion of project memory. The conventions I taught one don't exist in the other, so I end up maintaining two versions of basically the same context and they drift apart over time.

I get why it's like this, the tools are separate products. But from where I sit as a user, the project is the same project and the decisions are the same decisions no matter which assistant I happen to open.

Wondering if others run a multi-tool setup like this, and how you cope. Do you keep a single source-of-truth file you paste into both, symlink something, or just accept the duplication? Is a shared, tool-neutral project memory something people would actually want, or am I the only one bothered by this?

[zhaoyeyu]

This is close to the problem that led me to build TaskState Vault.

The approach is to keep project state outside either assistant: account/domain/project/task/run layers, stable project intent, task state and next actions, evidence/artifacts/errors, and SQLite/JSONL indexes. Relevant long-lived information can be copied into the current task scope with a pointer back to its source, so the active tool does not need the entire history.

I am already using it with Codex and it has solved part of the duplication problem for me. It includes a Codex usage guide and an MCP-ready adapter, but Claude Code integration is not packaged yet, so I would not claim it is a complete cross-tool solution today.

I would genuinely value your take on whether this data model matches what you mean by a shared, tool-neutral project memory, especially which information should remain global and which should be copied into each task.

[Patdolitse]

Thanks for sharing this — and yeah, same itch exactly. The account/domain/project/task/run layering is close to how I ended up thinking about it.

Funny timing: I went far enough down this hole that I built my own take on it (piia-engram, a local-first MCP memory layer), so I'm answering as someone who made specific choices here, not a neutral observer. Disclosure: I maintain it, so I'm biased.

On your real question — what stays global vs. copied per task — the split that's held up for me is by origin, not by content:

• Identity/global tier: things true about me regardless of repo (how I work, review style, language). These follow me into every task and never get copied down — the moment you copy them you get drift between the copies.
• Project tier: decisions and conventions that belong to this repo. Stable, lives at the root, referenced by pointer rather than copied.
• Task/run tier: the volatile stuff — current state, next actions, the error you're mid-fixing. This is the only layer I actually copy into the active scope, and I treat it as disposable.

Rule of thumb I landed on: copy the volatile, point at the durable. Most of the drift you're trying to kill comes from copying something durable into a task and then editing the copy.

The one thing I'd push on in your model: when you copy long-lived info into a task "with a pointer back to its source" — what happens when the source changes after the copy? That staleness was the exact failure that pushed me to point-only for the durable tiers. Curious how TaskState Vault keeps the copy from going stale.

[zhaoyeyu]

That is a valid push, and the honest answer is that TaskState Vault does not automatically prevent that stale-copy failure yet.

Today an imported task copy retains its source pointer and import reason, which makes provenance inspectable, but source changes do not automatically invalidate or refresh the task copy. Re-import and conflict review are still explicit/manual operations. That means the current model can detect where a copied claim came from, but it cannot guarantee that the copy is fresh.

Your rule, "copy the volatile, point at the durable," is a useful refinement. I think the next version should make the policy explicit:

• stable account/project facts remain pointer-first and are resolved when needed;
• volatile task/run state can be materialized locally;
• any materialized durable item carries source version/hash, imported-at time, and freshness status;
• source changes mark dependent copies stale rather than silently refreshing them;
• promotion and conflict resolution remain explicit and auditable.

That would preserve task-local reproducibility without pretending copied durable state stays current. Thanks for identifying the exact weak point; I am recording it as a product gap rather than defending the current behavior.

[Patdolitse]

Yeah respect for just saying it straight. Keeps a source pointer but doesn't stop the stale copy yet is the honest answer and honestly that's kind of the whole thing right there.

The bit I keep tripping over is a back pointer tells you where a fact came from not whether it's still true. Feels like the same thing until it isn't. The copy just sits in your task scope looking confident while the source quietly moved on like three sessions ago.

Couple things that helped me on top of the pointer. One is some sense of freshness. Basically has the source changed since the copy was made and when did I last actually check it. So recall can go eh this might be stale and quietly demote it instead of handing it back like gospel. The other is whether I actually confirmed the fact or the assistant just inferred it and nobody checked. A copied guess turning up in a new tool like it's settled fact is where the whole thing goes sideways for me.

That's roughly what I leaned on with piia-engram. Provenance plus a fresh aging stale decay plus a don't trust it till it's promoted gate. Not treating a copy as solid just because it has a link home. Usual disclaimer I build the thing so take it with salt.

Genuinely curious where you'd land though. Should the vault notice a copy went stale or is that the tool's job at read time. That split feels like the real fork in the road.