Can You Continue a Shared Claude Chat? What Transfers

A shared Claude link is a copy of a transcript, not a seat in the conversation. That single distinction answers most of what people arrive looking for, and it is worth stating first because the interface does not make it obvious: the page you open from a share link looks exactly like a chat, which is a reasonable reason to expect you can type in it and carry on.

What follows is what actually transfers when a conversation is shared, why resuming a snapshot is a different thing from resuming a session, and the procedure that gets you the outcome you wanted anyway. It is short work once the mechanism is clear.

Two Different Questions Wearing the Same Words

The phrase covers two situations that need different answers.

Someone sent you a link. You want to pick up where their conversation left off — ask the next question, push the work forward, have the assistant continue as though you had been there. You are not the author, you may not even have an account on the same plan, and what you have is a URL.

You shared your own conversation and now want to carry on in it. Perhaps you shared it from a device you no longer have, or you are hoping the share page is a second door into the same thread.

Neither of these resumes the original. The reasons differ slightly and the practical fix is the same, so the distinction matters mostly for understanding why.

Why a Snapshot Cannot Be Resumed

A conversation, while it is live, is state belonging to one account in one session. Every time you send a message, the exchange so far is assembled and supplied to the model, and the reply is appended to a thread that sits in your history. Continuity comes from that assembly happening again on every turn.

A share link is an export of what that thread looked like at the moment it was shared. It is text, rendered to a page. There is no session behind it, no thread in anyone's history being appended to, and nothing assembling context for a next turn — because there is no next turn to assemble for. Even where the interface offers the recipient a way to start their own chat from the page, what that does is open a new conversation seeded with the transcript, which is a copy, not a continuation.

Two consequences follow, and both surprise people.

The first is that the snapshot is frozen. Messages added to the original after the share was created are generally not in it, because the link captured a moment rather than subscribing to a feed. If the author kept working for another hour, you are reading the state of play before that hour.

The second is that nothing attached to the original conversation travels with the transcript. Files that were uploaded into it, a project or workspace it belonged to, instructions configured on the author's account, anything the author's own memory settings were quietly contributing — none of that is part of a shared page. The recipient gets the words, which means an assistant continuing from them has a strictly thinner view of the problem than the author's assistant had. This is the same scoping that makes it awkward to get one conversation to see another, covered in Does Claude Remember Chats in the Same Project?.

Share behaviour and link settings are the kind of thing that changes between product releases and differs by plan, so treat the specifics on your own screen as the authority rather than any article, including this one. The underlying shape — snapshot, not session — is the part that does not move.

What Does Transfer, and Why It Is Usually Enough

The text transfers. That sounds like a consolation prize and it is actually the substance, because text is what an assistant works from in the first place.

A conversation's value to a fresh session is almost never the full transcript. It is the handful of things the transcript happens to contain: what was decided, what was ruled out and why, which constraints are in force, exact names and values that would be annoying to reconstruct, and where the work stopped. All of that is in the shared page, in prose, available to be copied.

So the question is not whether you can continue from a shared chat. You can. The question is what you paste into the new one, and pasting the whole thing is the common mistake.

The Procedure

Four steps, and the third is the one that does the work.

1. Read the shared page and copy the transcript, or the stretch of it that matters. If the conversation is long, the last third is usually where the conclusions live and the first third is where the constraints were set; the middle is often skippable.
2. Open a new conversation in whichever assistant you are using. It does not have to be the same one the original was in — the text is portable even when the memory features are not.
3. Write a handoff rather than pasting a transcript. Either condense it yourself into decisions, rejected options, constraints, open questions and current state; or paste the transcript into the new chat with an explicit instruction to extract exactly those categories first, confirm them with you, and only then continue. The second is faster and needs checking, because the extraction will quietly drop a constraint that was stated once.
4. State what you want next in the same message. A new session handed a transcript and no instruction tends to summarise it back to you, which wastes a turn and some of the room you just spent.

The reason step three matters so much is that a pasted transcript is expensive in a way that is easy to miss. It consumes a large part of the new conversation's working room before you have asked anything, and it dilutes the parts that mattered among a great deal of conversational filler — greetings, clarifications, the model's own restatements, abandoned branches. A three-hundred-word handoff routinely outperforms a six-thousand-word transcript in the session that follows, which is counter-intuitive until you have watched it happen once. The general mechanics of why a conversation has a ceiling at all are in Context Window vs Memory.

If You Are the Author

Your own conversation is still in your history, which means your situation is better than the recipient's and the fix is different: continue in the original thread rather than trying to re-enter through the share page.

If the original has become too long to work in, that is a separate problem with its own answer, and sharing it does not solve it. The manoeuvre there is to condense the thread into a handoff and start a fresh conversation with it, described for Claude specifically in Continuing a Long Claude Chat in a New Conversation.

If you shared it because you wanted the conversation available on another device or to a colleague as working context rather than as reading material, a share link is the wrong instrument. What they need is the handoff block, not the transcript, and you are the person best placed to write it since you know which of those six thousand words were load-bearing.

The Neighbouring Question: Can Claude See Your Other Chats?

This comes up in the same breath as the shared-link question, because both are really about the same wish: that context would move between conversations without being carried.

The mechanism to hold onto is that conversations are scoped. Each one is assembled from what is in it plus whatever the product deliberately supplies from outside — instructions you configured, documents attached to a workspace, whatever memory features your account has and has switched on. A conversation does not browse your history looking for relevant threads unless the product has specifically built that and you have specifically enabled it, and what any given account does today is a question for that account's own settings screen rather than for an article. The longer treatment is in Does Claude Remember Previous Conversations?.

What is stable across all of it is the asymmetry: whatever a product gives you in this department works inside that product only. A shared link crosses the boundary between accounts precisely because it is plain text and nothing else, and the same property is why plain text is the only thing that reliably moves between assistants at all.

The Failure Mode Worth Naming

The most common way this goes wrong is not failing to continue the chat. It is continuing it badly, and not noticing for twenty minutes.

You paste a long transcript into a new session, the assistant responds fluently, and everything appears to have carried over. What has actually happened is that the new session has read the transcript the way it reads any long input — unevenly, with the middle getting the least attention. It will often reproduce the tone and the general direction of the original conversation convincingly while having missed a specific constraint stated once in message eleven.

The symptom arrives later, as a suggestion that contradicts something settled, or a re-proposal of an option that was explicitly rejected. By then you have built on it.

The defence is cheap: after pasting, before asking for anything new, ask the session to list the constraints and rejected options it has taken from what you gave it. Read the list. It takes fifteen seconds and it surfaces the omission while it is still free. The broader habit of checking rather than assuming is laid out in How to Test What Your AI Assistant Actually Remembers.

Build the Handoff Before You Need It

Everything above is recovery, and recovery is more work than the alternative.

The alternative is writing the handoff while the conversation is alive, when you still remember which parts mattered and the model still has all of it in view. At the end of any session worth keeping, ask for the five categories, correct what it got wrong, and keep the result. It takes two minutes and it is useful in every direction at once: it is what you would paste into a new chat, what you would send a colleague instead of a share link, and what you would read yourself in three weeks when you have forgotten the whole thing.

A conversation you did not save is gone with the session, and no feature recovers it. A handoff you wrote is a file.

Copy It Before It Changes

A share link is not a durable archive, and this is the part that bites later rather than now.

The page exists because the author's account continues to host it. Links can be revoked, and in most products the author can unshare a conversation at any time, after which the URL simply stops resolving for everyone who had it. Shared pages can also stop matching the original when the author keeps working, since the snapshot was taken once. None of that is announced to the people holding the link.

So if a shared conversation contains anything you expect to need again — a specification, a set of constraints, a worked solution — copy the text out the first time you open it rather than bookmarking the URL and assuming it will be there. A bookmark is a dependency on someone else's settings; a few hundred words in a file of your own is not.

This is the same reasoning that applies to your own conversations, and it generalises badly in one specific way: people treat the chat history in their account as an archive, and it is only an archive for as long as the account, the product and the retention policy all continue to behave as they do today. Anything you would be annoyed to lose belongs somewhere you control.

Where MindLock Sits

MindLock is the maintained version of that habit, for people who find that keeping the file by hand works for a fortnight and then quietly stops.

Saving is manual, because there is no way around it: no third-party software can read your conversations in the background, and none can type into one on your behalf. You press Ctrl or Cmd plus S on a conversation in Claude, ChatGPT, Gemini or Perplexity to save the page and upload it, or you use the one-click Save to Memory button from the Chrome extension, which is loaded unpacked in developer mode rather than installed from a store. The procedure is in Importing Conversations.

What is automated is the middle. Saved conversations are distilled into memory documents — a profile memory plus topic memories — by a model running locally in your browser on a WebGPU-capable GPU, with Llama 3.2 3B as the default, or in the cloud on the paid tier where the hardware cannot run it. On the free tier the store lives in your browser and works offline. Those documents are plain text you can read, correct and delete, which matters because the alternative is a store you cannot audit. Semantic search finds the right material later and a context block is generated for pasting into whichever assistant you are using next — Claude today, something else next year, since the output is text and crosses every boundary a share link does. The documents themselves are described in Memory Documents, and what the free tier includes is on the pricing page.