Switching to a new computer? Here’s how to transfer Claude Desktop to the new PC

Disclaimer: This post is written by Claude. I’m putting this here not for the SEO but because surprisingly, I couldn’t find any proper tutorial on this specific topic so I had to figure it out myself in Claude Chat. The good news, I finally got it done, so I hope this experience benefits someone else too. This article was written for technical people and LLMs – if you’re not sure what to do, just point Claude to this URL and let it tell you what to do, step by step.

Copying your .claude folder to a new PC isn’t enough. Claude Desktop stores history in three separate places, and the Code tab needs two of them to be correct before your sessions show up in the sidebar.

This guide covers the full migration on Windows: what to copy, what to leave behind, and the errors you’ll likely hit.

What lives where

The Code tab is the tricky one. The .jsonl files in .claude\projects\ are the conversation content. The local_*.json files in claude-code-sessions\ are the index that populates the sidebar. Copy only the transcripts and the sidebar stays empty.

Step 0: Find your real app data path

Claude Desktop ships two ways on Windows, with different data locations.

Direct .exe installer:

C:\Users\<username>\AppData\Roaming\Claude\

Microsoft Store (MSIX) package:

C:\Users\<username>\AppData\Local\Packages\Claude_<packageid>\LocalCache\Roaming\Claude\

Packaged apps get a private storage sandbox, so writes aimed at AppData\Roaming\Claude get redirected into that container. That’s why searching for the documented path returns nothing on a Store install.

Find the real path on each machine:

Get-ChildItem -Path $env:APPDATA, $env:LOCALAPPDATA -Recurse -Filter "*claude*" -ErrorAction SilentlyContinue |
    Where-Object { $_.PSIsContainer } |
    Select-Object FullName

Whichever folder contains claude-code-sessions or local-agent-mode-sessions is your data root. Check both machines separately, because if one is a Store build and one is .exe, you’ll be copying into a folder the app never reads.

Step 1: Match your drive letters

If your working directories sit on a different drive letter on the new machine, deal with this before you copy anything.

Claude Code keys everything to absolute paths, and the drive letter is part of that path. A project at H:\clients\acme is stored as H--clients-acme. On a machine where the same folder is G:\clients\acme, nothing matches. Worse, absolute paths also get baked into config files, MCP server definitions, worktree records and your own scripts, so renaming transcript folders fixes discovery but leaves everything else pointing at a drive that no longer exists.

The clean fix is to reassign the drive letter on the new machine to match the old one.

Local disks and partitions: open Disk Management (diskmgmt.msc), right-click the volume, Change Drive Letter and Paths. Or in PowerShell as admin:

Set-Partition -DriveLetter G -NewDriveLetter H

If the letter you want is already taken, move the current occupant to a spare letter first, then reassign.

Google Drive for Desktop: Preferences, gear icon, then set the drive letter under the streaming options.

Network shares:

net use H: \\server\share /persistent:yes

Do this before launching Claude Code on the new machine so it never records the wrong paths to begin with.

If you can’t match the letters, you’ll need a find-and-replace across the migrated data. On top of the folder renames in Step 4, check these for hardcoded paths:

• %USERPROFILE%\.claude.json (per-project config and MCP server definitions)
• %USERPROFILE%\.claude\settings.json
• claude_desktop_config.json
• git-worktrees.json
• project-level .mcp.json and CLAUDE.md files
• your own scripts or hooks that reference absolute paths

Step 2: Close everything, then back up

Quit Claude Desktop on both machines and confirm no Claude processes remain in Task Manager. The app flushes session state to disk on exit, so copying while it runs gives you a partial snapshot.

Zip the .claude folder and the app data Claude folder from the old machine before you change anything.

Step 3: Copy the transcripts

C:\Users\<username>\.claude\

This holds transcripts, settings, custom agents and commands, and per-project memory. Also copy %USERPROFILE%\.claude.json if it exists, which sits alongside the folder and holds per-project config and MCP server definitions keyed by absolute path. If you use a custom CLAUDE_CONFIG_DIR, adjust accordingly. Claude Code inside WSL keeps a separate .claude in the Linux filesystem, migrate that on its own.

Step 4: Fix the project folder names

Claude Code organises transcripts by project path. Each working directory gets a folder under .claude\projects\, named after the absolute path with separators replaced by dashes:

C:\Users\alice\Projects\my-site
→  .claude\projects\C--Users-alice-Projects-my-site\

The path is the identifier, drive letter included. If your Windows username changed, or your projects sit on a different drive letter, the copied folder names no longer match your working directories and the sessions stay invisible. Matching the drive letters (Step 1) avoids this half of the problem entirely.

If you haven’t started any sessions on the new machine, rename in bulk. Check nothing exists under the new name first:

Get-ChildItem "C:\Users\<newname>\.claude\projects\" -Directory |
    Where-Object { $_.Name -like "*newname*" }

If that’s empty:

Get-ChildItem "C:\Users\<newname>\.claude\projects\" -Directory |
    Where-Object { $_.Name -like "*oldname*" } |
    ForEach-Object {
        Rename-Item $_.FullName ($_.Name -replace "oldname", "newname")
    }

If you have already used Claude Code on the new machine, don’t rename over an existing folder. Copy the .jsonl files in instead, filenames are UUIDs so there’s no collision risk:

Copy-Item "C:\Users\<newname>\.claude\projects\C--Users-oldname-Projects-my-site\*.jsonl" `
          -Destination "C:\Users\<newname>\.claude\projects\C--Users-newname-Projects-my-site\"

Also make sure the actual project folders exist at matching paths on the new machine.

If history.jsonl exists at the root of .claude\, it’s a session index containing absolute paths. Find-and-replace works, but back it up first, and check your matches if your old username is something generic like admin:

(Get-Content "C:\Users\<newname>\.claude\history.jsonl") -replace 'oldname', 'newname' |
    Set-Content "C:\Users\<newname>\.claude\history.jsonl"

No history.jsonl is normal if you’ve worked through the desktop app rather than the CLI.

Step 5: Copy the session index folders

This is the step most people miss. From the app data root, copy both:

claude-code-sessions\
local-agent-mode-sessions\

claude-code-sessions is the current index the Code sidebar reads. local-agent-mode-sessions is the legacy location for the same data, and also where Cowork sessions, spaces and auto-memory live. Older installs may only have the legacy one.

The structure inside is <accountId>\<orgId>\ holding local_*.json files. Those IDs are account-scoped, not machine-scoped, so with the same login on both machines they already match. No renaming needed.

If sessions exist only in the legacy folder: the storage directory changed at some point with no automatic migration. Move them yourself:

$root = "<your app data root>"
$old  = "$root\local-agent-mode-sessions\<accountId>\<orgId>"
$new  = "$root\claude-code-sessions\<accountId>\<orgId>"

New-Item -ItemType Directory -Force -Path $new
Get-ChildItem "$old\local_*.json" | ForEach-Object {
    if (-not (Test-Path "$new\$($_.Name)")) { Copy-Item $_.FullName "$new\" }
}

If the new machine already has an <accountId>\<orgId> pair, use that as the destination since it matches your current login.

Step 6: Copy your config

No conversation history here, but it saves rebuilding your setup by hand.

If you run MCP servers, claude_desktop_config.json is the highest-value file in that list.

Optional and mostly cosmetic: IndexedDB\, Local Storage\, WebStorage\, Preferences. One exception for IndexedDB in troubleshooting below.

What not to copy

Caches and runtime data. These regenerate on their own and are tied to the specific build and machine. Copying them across versions can cause launch crashes or inconsistent behaviour:

Cache, Code Cache, GPUCache, DawnGraphiteCache, DawnWebGPUCache, blob_storage, Network, Partitions, Session Storage, Shared Dictionary, shared_proto_db, VideoDecodeStats, ChromeNativeHost, Crashpad, sentry, logs, vm_bundles, claude-code-vm, fcache, Conversions, DIPS, SharedStorage, window-state.json, extensions-blocklist.json, bridge-state.json

Device identity and auth files, which deserve a specific warning:

• ant-did, ant-device-registry.json: device identity records. Copying them makes the new machine present as the old one, which can confuse device management and session attribution.
• buddy-tokens.json, Local State: auth tokens and Chromium’s encryption key. Local State is bound to the machine via Windows DPAPI, so a copied one is unreadable and can break credential decryption. Just sign in normally.

The history and config classifications above are verifiable by opening the files. The cache list follows standard Electron and Chromium conventions rather than Anthropic documentation, so treat that tier as informed judgment. Corrections welcome.

Troubleshooting

“The file name would be too long for the destination folder”

The MSIX path eats most of Windows’ 260-character MAX_PATH budget before your filenames start. Use robocopy, which handles long paths natively:

robocopy "<source>" "<destination>" /E /R:1 /W:1

Still failing? Enable long path support (admin, then reboot):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

No admin access? Shorten the path with a temporary drive mapping:

subst Z: "<long destination path>"
robocopy "<source>" "Z:\" /E /R:1 /W:1
subst Z: /d

robocopy: “ERROR 53 The network path was not found”

If this appears on a local path like C:\Temp, robocopy has misread the \\?\ extended-length prefix as a UNC network path. Drop the prefix and run as a plain path. With LongPathsEnabled set, robocopy doesn’t need it.

Cloud-sync virtual drives (Google Drive, OneDrive, Dropbox) can also produce misleading errors, since they run their own filesystem layer that may ignore long path settings. Stage files to a local folder first.

Access denied on the MSIX folder

Packaged apps wrap LocalCache in package-specific permissions. If robocopy reports access errors rather than path errors:

icacls "C:\Users\<username>\AppData\Local\Packages\Claude_<packageid>" /grant "${env:USERNAME}:(OI)(CI)F" /T

The direct .exe installer avoids the sandbox entirely and uses a plain %APPDATA%\Claude\ path, worth considering if you change machines often.

Sessions appear but show no messages

There’s a reported bug where message content sat in the app’s IndexedDB cache and was never flushed to the session .jsonl files. Copying IndexedDB\ from the old machine can recover those. Good reason to verify before wiping the old install.

Sidebar still empty with everything in place

Several reported issues describe the sidebar failing to render sessions despite correct data on disk, including after migrations where all paths match. Your data is still fine, and the CLI reads transcripts directly:

cd <your project folder>
claude --resume

Each .jsonl filename in .claude\projects\<project>\ is the session ID, so you can also resume a specific one with claude --resume <session-id>. Worth testing during migration regardless of what the sidebar does.

Verify before wiping the old machine

• Code sidebar lists your old sessions, grouped by project
• Two or three older sessions render their messages, not an empty conversation
• Cowork sessions and auto-memory are present
• MCP servers appear and connect
• claude --resume works from a project directory

One thing to do afterwards

Claude Code prunes transcripts older than 30 days by default, and migrated sessions keep their original timestamps, so some may age out shortly after you’ve moved them. Zip .claude\projects\ and keep a copy outside the folder, or raise the retention window in your Claude Code settings.

Checklist

[ ] Identify install type and app data path on BOTH machines
[ ] Match drive letters on the new machine, or plan a find-and-replace
[ ] Close Claude fully, verify in Task Manager
[ ] Back up .claude\ and the app data Claude\ folder
[ ] Copy %USERPROFILE%\.claude\ and .claude.json
[ ] Recreate project folders at matching paths
[ ] Rename .claude\projects\ folders to match new paths
[ ] Find-and-replace paths in history.jsonl if present
[ ] Copy claude-code-sessions\ and local-agent-mode-sessions\
[ ] Migrate legacy sessions into claude-code-sessions\ if needed
[ ] Copy config files (MCP, extensions, settings)
[ ] Skip caches, device identity files, auth tokens
[ ] Verify sessions open WITH content
[ ] Test claude --resume
[ ] Back up .claude\projects\
[ ] Decommission the old machine

Paths and known issues reflect Claude Desktop on Windows as of mid-2026. Storage locations have changed between versions before, so trust what’s on your disk over this article.