Guide · 7 min

Why switching AI coding tools loses your context, and how to keep it

Codex ships a feature you want, so you try it, and a week of project history stays behind in Claude Code. The tools change every month; the cost of re-explaining your project shouldn't. Here's why the context gets trapped, and how to set things up so it doesn't.

The trap

Your context lives inside the tool, so it can't leave.

Claude Code, Codex and Cursor each keep the two things that actually matter, your project history and your secrets, in their own silo. The decisions you reached, the approaches you ruled out, the conventions you settled on: all of it accumulates inside whichever assistant you were using. Switch assistant and none of it comes along. You start the new tool cold and re-explain the project, which is exactly the moment most people give up and stay put.

That's lock-in, and it's not on purpose so much as a side effect of where the state is stored. The assistant is treated as the home for your context. In a field where the best tool changes every few weeks, that's a bad place to keep anything you don't want to lose.

What transfers, what doesn't

Rules copy. History and keys don't.

Conventions (partly portable)

A CLAUDE.md can be recreated as an AGENTS.md for Codex. Tedious but doable, and it only carries the static "how we work", not what you decided.

Conversation history (stuck)

The reasoning and decisions from your sessions stay in the old tool's private store. There's no export that the next tool can meaningfully load. This is the part you actually miss.

Secrets (re-wired each time)

Keys pasted into one tool's config or a .env it reads have to be set up again in the new one, multiplying the places your secrets are exposed.

For the mechanical side of a Claude Code to Codex move, the step-by-step is in our Claude Code to Codex migration guide. This post is about the deeper fix, so the next migration costs nothing.

The fix

Keep memory and secrets outside the assistant.

The durable answer is to stop storing your context in the assistant at all. Put the two things worth keeping in tool-agnostic stores that any assistant can read, and switching tools becomes a non-event.

Memory lives in a store exposed over the Model Context Protocol, so Claude Code, Codex and Cursor read and write the same project decisions. Secrets live in a vault, referenced from .env, so no single tool holds the raw value. This is what Tramya is, a local-first app that keeps both on your machine:

# same memory, whichever tool you open next
get_project_context(project, "current state")

# same secret, referenced not pasted
OPENAI_API_KEY=tramya://local/OpenAI/api-key

Now the assistant is just an interface over your context, not the vault holding it. Try Codex on Monday and go back to Claude Code on Friday; the project's memory and keys were never inside either. Keeping context across sessions of one tool works the same way, more on that in keeping context across AI coding sessions.

Honest limits

Portable, not automatic.

Tool-agnostic storage removes the lock-in, it doesn't remove the work of writing good memory in the first place, and it doesn't magically merge two tools' past histories you never captured. What it does is make the next switch free: from the moment your memory and secrets live outside the assistant, changing assistant stops costing you your project's brain. You also still keep a rules file per tool (CLAUDE.md / AGENTS.md) for conventions; that's cheap and complementary. The point isn't zero setup, it's that you never pay the re-explanation tax again.