How to Move a Cowork Session Between Computers

Undocumented/unsupported

The following solution works by directly manipulating undocumented internal storage structures — there's no guarantee the format stays stable across future updates, and doing this on a live/active project (rather than one you're not currently working in) risks conflicting with the app's own state. Back up both machines' session folders before attempting anything here, and treat this as a last resort rather than a routine fix.

Use at your own risk.

The problem

I'd been running a Claude Cowork project for a few weeks, split across two machines — most of the actual work happened on Computer A, with lighter use on Computer B. Both were signed into the same Anthropic account.

Claude Desktop auto-updated on Computer A. When it relaunched, the Cowork project was gone — not in the project list, no pinned chat, nothing in Recents, no search hits. Computer B, still on an older build, could still see the project — but with no sync between machines, each one had gone on accumulating its own task output independently since the project was created. Same project, diverged content, not two separate projects.

Worth flagging up front: this isn't something Anthropic currently supports recovering. Their own documentation states Cowork projects are desktop-only and stored locally, with no cloud sync for project data. Everything below is unsupported, manual recovery — not an official process.

Current Limitations

Projects are only available in Cowork, not in Claude Code. Support for Claude Code is planned for a future update.

Projects are desktop-only and stored locally. There's no cloud sync for project data at this time.

For members of Team and Enterprise plans, Cowork projects do not support project sharing.

Source: https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork

The core anomaly, though, is upstream of any of that. According to that same documentation, a Cowork project shouldn't have been usable across two machines at all — it's meant to be fully siloed to whichever device created it. In practice, I moved between Computer A and Computer B and kept working on the same project on both, going back and forth, with no obvious sign anything was wrong. That continuity isn't something Anthropic documents as supported, but it happened, for weeks, until the update on Computer A broke it. Whatever let that work in the first place is undocumented behaviour, not a feature — worth keeping in mind if you're relying on the same pattern.

Observations

A few things became clear while digging through the local file structure:

• Storage location depends on install method, not on winget itself. Running winget install doesn't inherently mean MSIX or non-MSIX — it depends on which package manifest winget resolves to, or on install scope switches (e.g. --scope user vs --scope machine). A Store/MSIX-style install sandboxes app data: MSIX redirects writes aimed at AppData\Roaming to a per-package container under AppData\Local\Packages\<PackageFamilyName>\LocalCache\Roaming, by design, for isolation and clean uninstall. A standard (non-MSIX) installer writes directly to AppData\Roaming with no redirection. Two machines can end up on different storage models even if you ran the exact same winget install command on both — check Get-AppxPackage rather than assume from the install command alone.

• A Cowork project isn't stored in one place. It's spread across several structures under the same session tree:

• .project-cache\<uuid>\ — a snapshot, not a live sync, of any linked Chat-project folder. Files added to that source folder later don't appear here automatically.
• spaces\<uuid>\memory\ — the project's accumulated Claude-authored memory notes.
• spaces.json — a registry file. Its presence or absence appears to control whether the project shows up in the UI at all.

• Root-level local_<uuid>.json files, paired with local_<uuid>\ folders (containing .claude\projects\*.jsonl transcripts, outputs\, uploads\) — individual task/session records. These appear to drive what shows in Pinned and Recents.

  Note

  In my case, the linked Chat-project folder itself was on OneDrive and already synced across both computers independently of Claude. That content was never actually at risk — only the Cowork-specific layers above (memory, registry, session records) were local-only and needed manual recovery.

• The update triggered a storage migration that only partially completed. Computer A had been running an older, unvirtualised install writing to AppData\Roaming\Claude — the same model Computer B was still on, which is how the project worked there beforehand. The update moved Computer A onto the MSIX/sandboxed storage model, and the old location was deleted afterward (confirmed: nothing remained under the old path once checked). The new location did retain the .project-cache snapshot content, but not spaces.json or the spaces\<uuid> memory folder — without which the app had no way to list the project in the UI. So this wasn't "nothing was deleted": the old copy was genuinely removed, and the migration into the new location was incomplete.

• No cloud sync exists for any of this. Only ordinary chat message history syncs via the account; Cowork project files, memory, and session records are 100% local to whichever machine generated them.

The solution

1. Check install type on both machines, since the storage root may differ:

    $Candidates = @(
        "$env:APPDATA\Claude\local-agent-mode-sessions",
        "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions"
    )
   
    foreach ($path in $Candidates) 
    {
      if (Test-Path $path) 
      {
        $itemCount = (Get-ChildItem $path -Recurse -File -ErrorAction SilentlyContinue | Measure-Object).Count
        Write-Host "$path -> EXISTS, $itemCount files" -ForegroundColor Green
      } 
      else
      {
        Write-Host "$path -> does not exist" -ForegroundColor DarkGray
      }
    }
   

   Claude paths

   It appears that Anthropic have changed installation locations, probably across multiple updates and they haven't done a very good job of cleaning up. There are remnants of Claude installs all over the place on my computers.

   I have found two different paths across two computers even though the same installation tool was used (winget). Your's may be totally different or the same. Who knows... Feel free to add a comment with your path and I'll update the list.

   Computer	$ClaudeInstallLocation Path
   A	$env:APPDATA\Claude\local-agent-mode-sessions
   B	$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions

2. Locate the project's session tree. Under $ClaudeInstallLocation, there are two levels of UUID folders — an outer one (device/account level) and an inner one (workspace level). The inner one is what you need; get a full recursive listing to confirm structure:

   (Get-ChildItem -Path "$ClaudeInstallLocation\local-agent-mode-sessions" -Recurse).FullName |
       Out-File C:\Temp\inventory.txt
   

3. Diff the inventories between machines to see what's genuinely missing versus what already exists (don't assume — verify by filename comparison).

4. Pack a transfer zip on the source machine (the one with the working project):

   $SourceRoot = "$ClaudeInstallLocation\local-agent-mode-sessions\<outer-uuid>\<inner-uuid>"
   $Staging = "C:\Temp\cowork-transfer"
   
   Remove-Item $Staging -Recurse -Force -ErrorAction SilentlyContinue
   New-Item -ItemType Directory -Path "$Staging\docs" -Force | Out-Null
   
   # Registry file — this is what makes the project visible at all
   Copy-Item "$SourceRoot\spaces.json" "$Staging\spaces.json"
   
   # Project memory
   robocopy "$SourceRoot\spaces" "$Staging\spaces" /E /R:2 /W:2
   
   # Session pointer files + their folders (drives Pinned/Recents)
   $SessionIds = @("<uuid-1>", "<uuid-2>", "<uuid-3>")   # list the local_ session UUIDs you find
   foreach ($id in $SessionIds)
   {
     Copy-Item "$SourceRoot\local_$id.json" "$Staging\local_$id.json"
     robocopy "$SourceRoot\local_$id" "$Staging\local_$id" /E /R:2 /W:2
   }
   
   # Any generated output files worth keeping, copied flat into docs\
   # Copy-Item "$SourceRoot\local_<uuid>\outputs\<file>" "$Staging\docs"
   
   Compress-Archive -Path "$Staging\*" -DestinationPath "C:\Temp\cowork-transfer.zip" -Force
   

5. Transfer the zip to the target machine by whatever method's convenient (USB, network share, cloud storage).

6. Fully quit Claude Desktop from the system tray on the target machine first — don't just close the window. Copying files while the app still has them open risks them being locked or the app overwriting your changes on its next background write.

7. Extract on the target machine, then relaunch:

   $ZipPath = "C:\Temp\cowork-transfer.zip"
   $TargetRoot = "$ClaudeInstallLocation\local-agent-mode-sessions\<outer-uuid>\<inner-uuid>"
   $DocsTarget = "$TargetRoot\.project-cache\<project-cache-uuid>\docs"
   $ExtractTo = "C:\Temp\cowork-extracted"
   
   Expand-Archive -Path $ZipPath -DestinationPath $ExtractTo -Force
   
   Copy-Item "$ExtractTo\spaces.json" "$TargetRoot\spaces.json" -Force
   robocopy "$ExtractTo\spaces" "$TargetRoot\spaces" /E /R:2 /W:2
   
   Get-ChildItem "$ExtractTo\local_*.json" | ForEach-Object {
       Copy-Item $_.FullName "$TargetRoot\$($_.Name)" -Force
   }
   Get-ChildItem "$ExtractTo" -Directory -Filter "local_*" | ForEach-Object {
       robocopy $_.FullName "$TargetRoot\$($_.Name)" /E /R:2 /W:2
   }
   
   Copy-Item "$ExtractTo\docs\*" $DocsTarget -Force
   

8. Then relaunch Claude Desktop. Electron (1) apps like this often keep running in the background even after you think you've quit, which is why quitting from the tray first, before copying anything, is the safer order.

   1. An Electron app is desktop software built by taking a web app (HTML, CSS, JavaScript) and bundling it with a stripped-down copy of the Chromium browser engine plus Node.js, so it runs as a standalone .exe instead of needing an actual browser. Slack, Discord, VS Code, and Claude Desktop are all Electron apps — that's why they tend to feel and behave a bit like web pages, use a fair amount of RAM, and often have that same "Chrome-but-not-quite-Chrome" look and feel.

Once relaunched, the project, its memory, and its session history should reappear in the sidebar.

---

Comments