Switch Coding Agents Without Losing Context Setup

You want to switch coding agents without re-teaching the new tool your repo. Point it at the same project memory, import past CLI sessions, and verify recall before you assign work.

Why switching tools wipes history today

Every coding agent keeps its own history. Claude Code, Codex, and OpenCode each keep separate session stores, while Cursor and Windsurf keep prompts and inline edits inside the editor workspace. No tool reads another tool's store.

So project knowledge stays trapped where you started. Package manager choices, test commands, naming rules, rejected approaches, and staging quirks live in old prompts. A new agent sees files but not decisions: it asks which test filter to run, proposes a structure you already discarded, or repeats a migration ordering mistake you already fixed.

Re-teaching costs turns. You paste a summary from the old tool, the new agent misses the one-line reason behind a decision, and the first session goes to conventions. Teams that alternate tools pay this tax on every switch.

A shared memory layer stores distilled facts outside any single conversation. Audaxic Memory is one shared memory layer for all your coding agents, with one memory per project, so switching agents never resets context. The plugins save preferences, decisions, and constraints as you work and inject relevant memories when a session starts.

Before the switch: one project, one key

Keep one project per repo. That scoping keeps recall precise after you move: when the new agent opens the checkout service, it gets checkout facts, not rules from an unrelated side project. Projects are unlimited on every plan from Hobby through Enterprise, so one project per repo costs nothing extra.

Every agent on the repo must use the same project key. The data plane authenticates with an ak_... API key, and both the plugins and the remote MCP server use that key to read and write the same memory. Two agents with different project keys have two separate memories and no shared context, even when both integrations work.

Find your current key before installing anything new. Open the dashboard project you already use and confirm which ak_... key your current agent uses. If you created the project from the quickstart, the key is already in your environment or plugin configuration. Write it down for the next section. Do not create a second project for the same repo unless you want to start from empty.

Audit what the old tool stored. Call GET /list with a small limit and scan the first page, or run POST /search with the repo name and touched areas. The list endpoint is paginated with limit and offset. If old sessions never stated a fact in plain language, the plugin never extracted it — restate the missing convention to your current agent now, before you move.

Connect the new tool when you switch coding agents

When you switch coding agents, you point a new client at the existing project memory. Memory carries over; tool-specific configuration does not. No migration command moves keybindings, editor rules, or model settings between vendors.

Pick the connection type for the new tool. Claude Code, Codex, and OpenCode each have a plugin. Cursor, Windsurf, Claude Desktop, and any MCP-compatible client connect through the remote MCP server. Cursor connects via MCP only, because there is no Cursor plugin.

Install the matching plugin for the CLI tools:

npx @audaxic/memory-claude install
npx @audaxic/memory-codex install
npm install -g @audaxic/memory-opencode

During setup, provide the same ak_... project key you confirmed above. Each plugin saves facts as you work and injects relevant memories when a session starts. The Codex CLI memory guide covers the Codex-side setup; the pattern is the same when your pair of tools differs.

For MCP clients, add the remote server over Streamable HTTP with a Bearer header carrying the same project key:

# MCP endpoint used by Cursor, Windsurf, Claude Desktop, and any MCP-compatible client
# URL: https://memory-mcp.audaxic.com/mcp
# Header: Authorization: Bearer ak_...

You run no local server and no container for this path. If Cursor is the new tool, follow connecting Cursor via MCP for persistent memory for the exact client-side steps. The MCP setup guide shows where each client pastes the URL and header. Confirm the client lists memory tools after restart — an empty tools list means the URL or Bearer value is wrong, or the client needs a restart.

Keep one key per project as you add tools. Do not share one key across unrelated repos; that merges memories that should stay separate. Data is isolated per organization with namespace-scoped vector search. If two repos share a key today, split them before the switch.

Import past Claude Code, Codex, and OpenCode sessions

New connections recall what the plugins saved going forward. Past conversations need an explicit import. The importer reads prior sessions from the three supported CLIs and stores them as timestamped memories in the project you choose.

Install the importer and point it at the existing project:

npm install -g @audaxic/memory-import

The importer covers past Claude Code, Codex, and OpenCode conversations with correct timestamps — nothing else. History in Cursor, Windsurf, or a chat app does not go through this path; those sessions contribute new memories from the switch date onward once the MCP connection is live. The import past conversations guide explains what the importer reads and how to scope the run to one repo.

Run the import against the same project key you connected above. Imports are per project: a different key fills a different memory and leaves the new tool looking empty. The import documentation describes the expected inputs and how timestamps are preserved. After the run, check the project with GET /list and confirm entries from the old tool appear with their original dates.

Keep imports scoped to the repo the project represents. Importing a second repo or an unrelated machine into the same project mixes contexts and weakens recall. The old CLI history for that repo lands in that repo's project, and the new tool reads exactly that history.

Review what the import stored before you rely on it. Look for duplicates where two sessions stated the same rule in different words, and for contradictions where an early decision was later reversed. Correct drift with PUT /update and remove expired rules with DELETE /delete/{memory_id}. An add request is counted per memory extracted from a message batch, so tight atomic facts keep accounting and retrieval predictable. If two competing facts remain, every future search returns both and the new agent guesses.

Verify recall in the new tool

Never trust a switch without a recall check in the new tool. Verification takes under a minute and catches the two common failures: a mismatched key and facts that were never stored or imported.

Ask three questions only the old sessions could answer: the repo's package manager and test command, one design decision with its reason, and one gotcha from mid-task. A working connection answers all three without re-asking. If the new agent asks something the old tool already resolved, stop and diagnose — every further turn on a broken switch compounds the divergence.

If recall fails, check in order. First, confirm the project key matches in both configurations. A wrong-project key makes memory look empty while both tools work in isolation. Second, confirm the fact exists with POST /search on the task terms, or with GET /list and a small page scan. A fact you never stated and never imported was never saved — restate it to the old agent or add it through the documented POST /add shape, then ask the new tool again.

Test cross-tool write-back too. State one new fact in the new tool in plain language, then search for it from the old tool or through the API. Both directions see the same project memory, because REST and MCP read and write the same store. The data plane lives at https://api.memory.audaxic.com with the ak_... key and a pinned date-based X-Api-Version header, currently 2026-09-25.

For the first week after you switch coding agents, close each session by stating the one new thing the project should keep, and open the next session in either tool by asking what the project knows before assigning work. This recall-first loop surfaces missing facts while they are still easy to restate.

Honest limits: what carries over and what stays tool-specific

Only memory carries over. Editor settings, keybindings, model selection, ignore rules, and tool-specific instruction files stay with the old tool. No plugin or MCP step moves those. Reconfigure the new tool by hand and treat memory as continuity for project knowledge, not configuration sync.

Imports cover three CLIs: past Claude Code, Codex, and OpenCode conversations import with correct timestamps. Conversations from Cursor, Windsurf, Claude Desktop, or any other client do not go through the importer. Those tools join the same project memory from the switch date onward through MCP. Only the three supported CLI histories move — plan team communication around that.

Memory quality depends on what was stored. The layer does not index your repo or infer rules from diffs — it stores what you or the agent saved. Keep entries atomic with one fact each, attach the reason to every decision, and prune with update and delete as the code changes.

The API surface is mem0-like across six data-plane endpoints: POST /add, POST /search, GET /list, PUT /update, DELETE /delete/{memory_id}, and DELETE /delete. There are no webhooks, SSO, RBAC, audit logs, or usage dashboards to migrate, because those features do not exist. Servers are located in the US and EU, customer data is never used for training, and graph memory is included on all plans from Hobby through Enterprise. What moves is project memory — enough for the new agent to start informed.

FAQ

Written by Efe — Oct 11, 2026 · More articles · X @AudaxicTech