Solving Cross-Project Conversation Handoff in Claude Desktop with MCP

TL;DR

• Created an MCP for conversation handoff to solve my own problems
• Memory-based, so no unnecessary files are created and no management is required
• Handoff between desktop apps and CLI is possible via a shared server

---

Introduction

Are you using the Claude Desktop project feature?
It's a convenient feature that allows you to separate memory and custom instructions for each project, but I was concerned about one problem.

You cannot refer to past conversations across projects.

I often find myself in conversation developments that span across projects, like "Wait, doesn't this connect to that thing from that other conversation project? Which means..."

For example, I might be talking about money in a "Home" project, then the discussion expands into design consultation like "Wouldn't it be better if we made this into an app?", and after talking for a while, I want to hand it off to a "Development" project.

I could scroll back to the relevant part and copy-paste, but going back through a long history or dealing with noisy, scattered topics is a hassle...
Or I could have it summarized, output to Markdown, and then load it into the other project...

To be honest, I thought it was a pain.
When you're organizing your thoughts, you want as few interruptions as possible, right?

So, this is a story about how I used a self-made MCP for conversation handoff.
While handoff MCPs already existed, mine has some specific preferences and differences, so please take a look.

Verification: Can you really not refer to conversations between projects?

First, I tried various ways to see if I could hand them off using standard features.

Claude has several means to access conversation history:

• conversation_search — Search past conversations by keyword
• recent_chats — Retrieve recent conversations
• Memory feature — Information learned from conversations

I verified whether these could span across different conversation projects.

Experiment: Trying to retrieve a conversation from another project

Let's start a conversation in the "Capybara" project.

We're talking about Marmots now!
I want to continue this conversation in the "Marmot" project.

Ah, as expected, the conversation from the other project can't be found.
Is copy-pasting the only way...?

Result: Can only be referenced within the same conversation project.

Feature	Cross-Project
conversation_search	❌ Within project only
recent_chats	❌ Within project only
Memory	❌ Within project only

Solution: MCPs Can Cross Projects

MCP servers run "outside" of the Claude Desktop project structure.
In other words, by saving the conversation context to an MCP, you can access it from any project.

I created "conversation-handoff-mcp" based on this idea.

https://github.com/trust-delta/conversation-handoff-mcp

Design Decisions: Why Memory-Based?

I found existing MCPs that can perform file-based conversation handoffs, but they were slightly different from what I was looking for.

Reasons for going memory-based:

1. I just want to hand it off — No need for persistence
2. Fast — No disk I/O
3. No clutter — No need for automatic cleanup or organization
4. No dependencies — No hassle of configuring file paths

For task handoffs, file-based systems have advantages because it's helpful if data isn't lost or if it can be edited. However, for conversations, you can always see them again by opening the history.
Therefore, I decided that if I need the handoff data again, I can just hand it off each time.

Usage

Installation

npm install -g conversation-handoff-mcp

MCP Configuration

Claude Desktop / Claude Code:

{
  "mcpServers": {
    "conversation-handoff": {
      "command": "npx",
      "args": ["-y", "conversation-handoff-mcp"]
    }
  }
}

Codex CLI (~/.codex/config.toml):

[mcp_servers.conversation-handoff]
command = "npx"
args = ["-y", "conversation-handoff-mcp"]

These are the only required settings.
There are a few minimum options, so please refer to the README if you are interested.

Basics: Cross-Project Handoff (Claude Desktop Only)

Save the conversation you want to hand off. (Either the whole thing or just a part is fine.)

Next, move to another project and have it load the handoff.

Success!
It's helpful to have an assistant that understands what's going on.

1. In conversation project A, say "Save this conversation for handoff."
2. Move to conversation project B.
3. Say "Handoff the saved conversation."

If you're between different projects in Claude Desktop, this is all it takes to hand off.
If multiple conversations are saved, you can select which one to hand off.

Now you can rest easy even if the conversation goes off on tangents!

Advanced: Cross-Client Handoff (All MCP-Compatible Clients)

If you want to hand off between different clients, such as Claude Desktop ↔ Claude Code ↔ Codex CLI, start a shared server.

In the terminal:

npx conversation-handoff-mcp --serve

That's it. The MCP configuration remains the same.

┌─────────────────────────────────────────────────┐
│  Shared Server                                   │
│  npx conversation-handoff-mcp --serve            │
│                                                  │
│  Memory: { "key1": {...}, "key2": {...} }       │
└─────────────────────────────────────────────────┘
        ↑           ↑           ↑
        │           │           │
   Claude      Claude        Codex
   Desktop      Code          CLI

The connection to the shared server is automatically determined for each request:

• If the server is running → Operates in shared mode
• If the server is not running → Operates with local memory (warning displayed)
• OK to start the server later — Automatically switches from the next request
• Even if the server goes down midway — Automatically falls back to local memory

You can use it without worrying about "I have to start the server first" or "Oh, I forgot."

Experiment: Successful Cross-Client Handoff Loop!

Demonstration experiment during development to see if it works properly.
I tried a one-round relay through the following loop path: Claude Desktop (Windows) → Claude Code (WSL) → Codex CLI (WSL) → Claude Desktop (Windows).

First, let's pass the story about the Marmot from Claude Desktop (Windows) to Claude Code (WSL) and continue the conversation.

Successfully handed off!
While talking, we veered off into talking about AI agents.
Let's pass just that part to Codex CLI (WSL).

This was also successful; I no longer feel like it will fail.
I gained the useful information that it's recommended to use them differently for Marmot research (lol).

Finally, ending this associative message-passing journey, let's return to Claude Desktop (Windows).

Good work!
We successfully handed off the conversation across Anthropic and OpenAI, Windows and WSL.

Client	Vendor	Environment	Result
Claude Desktop	Anthropic	Windows	✅
Claude Code	Anthropic	WSL	✅
Codex CLI	OpenAI	WSL	✅

As expected of the USB for AI.
It's truly wonderful to be able to interact regardless of the client.

Technical Supplement

Why a shared server is necessary

Each MCP client launches its own MCP server process.

Claude Desktop  → MCP Server (Process A) → Memory A
Claude Code     → MCP Server (Process B) → Memory B

Since memory is isolated, cross-client handoff is not possible as-is.
By setting up a shared server, all clients can access the same memory space.

Shared server matches the use case

Closing the server wipes all handoff data.
For better or worse, for me, this offered nothing but the benefit of not having to manage anything.

Operation	Result
Shared server running	Accessible from all clients
Shared server stopped	Memory wiped, clean

Dynamic Fallback

The connection check to the shared server is performed for each request.

Situation	Behavior
Server running	Process in shared mode
No server	Warning + Process in local memory
Server started midway	Switch to shared mode from the next request
Server stopped midway	Fallback to local memory from the next request

As a result, you don't need to worry about the order in which you start the servers.
This is a feature I added after actually using it and realizing it would be better to have.

Communication between Windows ↔ WSL

Thanks to the power of WSL, Claude Desktop on Windows and Claude Code/Codex CLI on WSL can share data without going through files.

┌─────────────────────────────────────────────────────┐
│  Windows                                            │
│  └── Claude Desktop ──┐                             │
│                       │ HTTP (localhost:1099)       │
├───────────────────────┼─────────────────────────────┤
│  WSL                  ↓                             │
│  ├── Shared Server ←──┘                              │
│  ├── Claude Code ────→ Shared Server                  │
│  └── Codex CLI ──────→ Shared Server                  │
└─────────────────────────────────────────────────────┘

Since WSL's localhost is also accessible from Windows, the HTTP-based shared server transparently connects different environments. You don't have to worry about differences in file paths.

Note that the shared server can be started in a Windows terminal without issue.

Summary

This time, I consulted Claude itself about the inconveniences I felt when using Claude Desktop, explored workarounds, and reached a solution.

It was suggested that I could build an MCP because there is a TypeScript SDK. Trying it out, being able to develop in a language familiar to frontend engineers made reviewing easy and was reassuring.

Memory-based with no files required. Clean once the server is closed.
This was the story of releasing "conversation-handoff," an MCP for cross-client conversation handoff.

• npm: https://www.npmjs.com/package/conversation-handoff-mcp
• GitHub: https://github.com/trust-delta/conversation-handoff-mcp

I thought it would be fine if I was the only one using it, but I'm trembling to see that it has been downloaded more than 600 times.

Since it was my first npm publication, there were some minor stumbling blocks like the shebang and the files field.
I also remember being troubled by the npx cache during testing on actual devices.

I might write about those details in another article if there's demand.