How to Migrate From Perplexity Spaces to Claude Code Without Losing Your Research (2026)

A Space is four things, and they land very differently on the other side.

Threads transfer as documents, one at a time. Open a thread, use the share or more-options menu, and export to PDF, Markdown, or DOCX. Markdown is the one you want — the export carries your prompts, the answers, the formatting, and the citation blocks with the source list, which is the part that makes the research reusable later. There is no official way to export a whole Space in one action. Browser extensions exist that will batch-export Spaces and even push them into Notion, and they work; they also require authorizing access to your Perplexity account, which is a decision to make deliberately rather than casually.

Uploaded files don't transfer — you already have them. Whatever PDFs and documents you attached to the Space are still on your disk, or should be. Re-upload or copy them into the repo rather than trying to pull them back out of Perplexity.

Custom instructions transfer almost directly. A Space's instructions are already written as directives about tone, depth, and what to prioritize. Most of it maps onto CLAUDE.md with light editing; the parts about citation style and answer length usually don't survive the trip, because you're no longer asking for answers, you're asking for code.

The exploration doesn't transfer, and shouldn't. Thirty of your forty threads were you working out what the right question was. Their value was in producing the other ten. Exporting all forty gives Claude Code a pile of superseded reasoning, some of it contradicting your final conclusion, all of it competing for context. This is where migrations go wrong: not by losing information, but by carrying too much of it.

One asymmetry worth naming up front. Perplexity's memory is organized around threads — each conversation is its own container, which is why content inside a Space doesn't automatically inform your other threads. Claude Code's memory is organized around the filesystem — it reads what's in the project. You're not just moving text between tools; you're converting conversation-shaped knowledge into file-shaped knowledge. Everything below is that conversion.

Step 1: Export the threads that still matter

Go through the Space and triage before you export anything. For each thread, ask one question: does this contain a conclusion I'd defend, or a search I already finished? Export the first kind. Skip the second.

Concretely, keep threads that established a decision ("we're using this library because of the licensing"), threads that gathered comparative evidence you'll want to cite again, threads with domain facts that constrain the build (rate limits, formats, regulatory requirements), and threads where you got something wrong and figured out why. That last category is the most valuable and the most commonly discarded.

For each keeper: open the thread, use the share or more-options menu, choose Markdown. You'll get the prompts, the answers, the formatting, and the citations with their source list. Keep the citations — the whole reason to migrate research rather than re-do it is that the sourcing came with it.

If a Space has dozens of keepers, this is where the third-party bulk exporters earn their keep. Weigh it honestly: they need account access, and you're handing a browser extension the ability to read everything in your Perplexity account. For a personal research Space that may be fine. For anything under a client NDA, export the threads by hand and don't think about it again.

Do not skip the triage because bulk export exists. The point of triage isn't saving export clicks; it's that everything you carry over will compete for Claude Code's attention later.

Step 2: Turn the exports into files Claude Code will actually load

Raw thread exports are not useful project documents. A thread is a transcript: your half-formed question, a long answer, a follow-up correcting it, another answer. Claude Code will read all of it and weight the wrong parts.

So condense. For each cluster of related threads, write one Markdown file in the repo — docs/research/ is a reasonable home — with this shape:

• The conclusion first, in one or two sentences, stated as a fact about the project.
• What it rules out, if anything. "We evaluated X and rejected it because Y" prevents an agent from cheerfully re-proposing X in three weeks.
• The evidence, condensed, with the source links from the export's citation block.
• The date, and the tool it came from. Research goes stale; a dated file lets you tell.

Then make Claude Code aware of it. CLAUDE.md at the project root is the file it loads automatically — that's where the pointers go, not the content:

```markdown

Decisions and their evidence live in docs/research/. Read docs/research/auth-approach.md before touching anything under src/auth/. Do not re-open decisions recorded there without flagging it. ```

Two things make this work better than dumping the research inline. First, CLAUDE.md is loaded on every session, so keeping it to pointers and rules costs you almost nothing per task while a 4,000-word research dump costs you on every single request. Second, @path imports let you pull a specific file in when it's actually relevant rather than always.

Put personal preferences in ~/.claude/CLAUDE.md instead of the project file, and commit the project one so your team inherits the same context. If you'd rather have Claude Code draft the first version of the file, /init will scaffold it from the repo, and /memory opens the memory files for editing directly.

Then set expectations correctly: this makes the knowledge available, not remembered. Claude Code still starts each session fresh and still compacts context in long sessions, which is why it forgets project context between sessions even with good files in place. Files are the floor, not the ceiling.

Look at what Step 2 actually was: you hand-converted research from one tool's format into another tool's format, and stored the result in a place only the second tool can read.

Now consider the next six months. You'll research again — in Perplexity, or in whatever replaces it — and you'll build in Claude Code, or Codex, or something announced in October. Each pairing needs its own conversion. The knowledge is stable; the tools around it are not.

Keeping the knowledge in a layer both sides can reach removes the conversion step. MemoryLake is a memory layer that sits under your tools: research notes, decisions, and source documents go in once, and Claude Code reads them over MCP while anything else you use reads the same store through the API. Your research stops being a Perplexity artifact that needs migrating and becomes something your tools query.

Being fair about the trade-off: docs/ plus CLAUDE.md has genuine virtues. It's plain text, it's in version control, it gets reviewed in pull requests, and it works with zero setup. Keep it for anything that belongs to the codebase. The memory layer earns its place for the knowledge that isn't repo-shaped — cross-project research, client context, the decisions that span three repositories — and for making that knowledge readable from a tool you haven't chosen yet.

Step 1: Create an API key

Generate a key and make your first request in about 30 seconds. Store it in your environment or a secret manager, not inline in a config file that gets committed or synced.

Step 2: Upload your first memories

Drop in the documents, images, and files your research actually rests on — the exported threads, the PDFs you'd uploaded to the Space, the decisions doc. Upload the sources where you can, not only your summary of them. A summary is where the caveat that mattered tends to vanish.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other AI agents access to memory via MCP or the API. Claude Code supports MCP servers, so this is a configuration entry rather than a rewrite. For research tools without an MCP client — Perplexity among them — pull what you need through the API and inject it into the prompt or workflow, so the direction of travel works both ways.

The first change is that "what did we decide about auth?" gets an answer with sources attached, in the tool where you're writing the code. Not a link to a thread in another product you'd have to go read.

The second is that rejected options stay rejected. The single most common failure after a research-to-build handoff is an agent confidently proposing the library you spent a week ruling out, because the ruling-out lived in a Perplexity thread and the code lives here. Once the decision and its reasoning are in the store, that stops.

The third is the direction most people don't anticipate: it works backwards too. Once implementation decisions are in the same layer, your next research pass can start from what the codebase actually does rather than from what you remember it doing.

And practically, it survives the next switch. Whether you end up in Cursor or back in a chat product, the knowledge is in one place and the tool is a client.

Condense before you import, not after

The instinct is to move everything and let the agent sort it out. It won't — it will weight a superseded answer the same as your final one, because nothing in the export marks which is which. Ten well-written conclusion documents beat forty transcripts, and the writing is what forces you to notice which conclusions you can't actually defend.

Keep the citations

The reason migrating research beats re-doing it is that the sourcing came along. Strip the citation blocks out of your exports for tidiness and you've kept the claims while discarding the evidence — which means the first time someone challenges one, you're back at the search box. The Markdown export includes the source list. Leave it in.

Date everything, and say what's stale

Research about a fast-moving API is a snapshot. Put the date in the file and, when you learn something has changed, edit the file rather than adding a newer document beside it. Two undated documents that disagree are worse than one that's honestly marked as of a date.

Keep instructions and knowledge in different places

CLAUDE.md is for rules and pointers, loaded every session, and should stay short. Research is knowledge — long, occasionally relevant, expensive to load unconditionally. Mixing them gives you a bloated file you pay for on every request and still can't fit everything into.

Perplexity exports one thread at a time to PDF, Markdown, or DOCX, and there's no official bulk Space export; Claude Code has no importer. So the honest path is manual and short: triage the Space for conclusions rather than searches, export those as Markdown with their citations, condense each cluster into a dated document that leads with the decision, and point CLAUDE.md at the folder rather than pasting it inline.

The choice worth making deliberately is where the knowledge lives afterward. In the repo, it serves this project in this tool. In a memory layer both sides read, it serves the next project and the next tool too — which matters more than it sounds, because the research took you a week and the tool choice will change before the research does.