Estimated reading time: 4 minutes
I’ve been running a fairly hefty WooCommerce rebuild for a client over the past few weeks — the kind of project that started as a quick fix and turned into a multi-block overhaul touching subscriptions, product structure, reviews, redirects, and a fair bit of live-site surgery still to come. All of it lived in one long-running Claude chat.
Great while it lasted. But a chat isn’t really built for a project this size. So this week I asked Claude whether I should have set this up in Cowork from the start instead.
The “Import” button looks simple. It isn’t quite.
My first assumption was that there’d be a one-click way to just move the whole conversation over. There sort of is — Cowork has an “Import a project” option that pulls in an existing Claude project’s files and instructions. But that’s not the same as pulling across the actual working context: the decisions made, the dead ends ruled out, the reasons behind choices that aren’t obvious just from looking at a finished file.
I found a blog post by Sean Davis describing exactly this snag. He’d tried the straightforward import on his own project and found the new Cowork project came over with none of the working context from the original chat — the files transferred, but the “why” behind them didn’t. His fix was simple and, in hindsight, obvious: before closing out the old chat, ask the assistant to write up everything that actually matters, then hand that document to the new session to read first.
Genuinely useful to find that before I ran into the same wall myself.
What I actually did
Rather than dump the whole conversation across, I asked Claude to write a proper handoff summary — not a transcript, but a “what we decided and why” document. Sean makes a good point in his post: you can hand over too much context. A blow-by-blow of every debugging detour isn’t useful to a fresh session; the decisions and the reasoning behind them are.
The handoff doc covered:
Who’s involved and what the project actually is
The core problem being solved, and why
Every significant structural decision — and the reasoning, not just the outcome
What’s been tested and confirmed working so far
Anything discovered along the way that changed the plan
A clear “here’s what’s still outstanding” list
Then I organised everything — the handoff doc, reference documents, working scripts, raw data exports, screenshots — into a proper folder structure, with the handoff doc numbered first so it’s obviously the starting point for anyone (human or Claude) picking this up fresh:
Project-Name/
├── 00-Handoff/
│ └── Project_Handoff.md
├── 01-Plans-and-References/
├── 02-Client-Facing/
├── 03-Scripts/
├── 04-Raw-Data/
└── 05-Screenshots/
That folder became the “Use an existing folder” option when setting up the new Cowork project — no import button needed at all.
Setting it up, step by step
For anyone wanting to do the same:
Update Claude Desktop to the latest version (Cowork needs it)
Get your folder structured and sitting somewhere sensible on your machine
Open Cowork → Projects → the + button
Choose “Use an existing folder” rather than “Import a project”
Point it at your folder, give the project a name
Optionally add a standing instruction like “always read the handoff doc first if you haven’t this session”
First task: ask Claude to read the handoff doc and summarise what it understands — a quick sense-check before you dive into real work
Why bother with any of this
Memory in regular chat doesn’t carry into Cowork sessions automatically. Cowork Projects have their own persistent memory, but it starts empty. Without a proper handoff, you’re back to re-explaining weeks of context from scratch — which rather defeats the point of moving to a persistent workspace in the first place.
Took maybe twenty minutes to set up properly. Worth every one of them.
Credit where it’s due — the handoff-doc approach came from Sean Davis’s post on this exact problem. If you’re moving a meaty project of your own, worth reading his account too.