Where Does Claude Desktop Store Its Config on Windows? And a PowerShell Module to Fix the Frustration

You’ve just reinstalled Windows. You install Claude Desktop, launch it, and realize your MCP servers are gone. You know the fix — restore claude_desktop_config.json from backup. Simple enough. Except… where is it?

If you installed Claude Desktop via the Microsoft Store, WinGet, or the MSIX enterprise installer, good luck finding it without PowerShell. It’s buried here:

C:\Users\YourName\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\

Note the pzs8sxrjxfjjc — a package identity hash that means nothing to a human, changes nothing useful, and exists purely because of how the Windows App packaging model works. Even seasoned IT pros do a double-take at this path.

If you installed via the direct .exe installer, it lands somewhere more sensible:

C:\Users\YourName\AppData\Roaming\Claude\

Two install methods. Two completely different paths. No documentation telling you which one you used or where to look.

Why This Happens

This isn’t entirely Anthropic’s fault. Microsoft’s modern app packaging model — MSIX and the Windows App Store — sandboxes applications into per-package container paths under %LOCALAPPDATA%\Packages\. The intent is security and clean uninstallation. The reality for developers and power users is a fragmented, non-deterministic file system where app data can live in completely different locations depending on distribution channel.

App install paths should always be deterministic. A developer, IT pro, or power user should be able to predict exactly where an app stores its configuration without running a search. The deeply-nested Packages folder structure — with its GUIDs and LocalCache subdirectories — fails this basic test. It’s not intuitive to anyone, including people who’ve spent careers in the Windows ecosystem.

We hope Microsoft revisits this, and that Anthropic considers the direct .exe installer as the recommended path for developers — it produces a predictable, standard location that anyone familiar with %APPDATA% can find immediately.

A Step Backward from Traditional Windows App Behavior

There’s a reason Windows developers and IT pros remember the old installer model fondly. Traditional Windows installers — whether MSI, InstallShield, NSIS, or Inno Setup — did something elegant in its simplicity: they showed you exactly where the application was going to be installed, and they let you change it.

That dialog box – Destination Folder: C:\Program Files\ApplicationName\ [Browse…] was more than a UX nicety. It was a contract between the software and the person installing it. You knew where the binaries lived. You knew where the config files were. You could back them up, script against them, include them in Group Policy, reference them in documentation. The path was yours to control.

Application data followed a similarly predictable convention. User-specific config went in %APPDATA%\CompanyName\AppName\. Machine-wide config went in %ProgramData%. Logs went somewhere sensible under one of those. Any experienced Windows administrator could navigate a new application’s file footprint in minutes.

The MSIX packaging model discards all of this. There is no “choose install location” dialog. There is no predictable convention for where config lives. Instead, you get a virtualized, sandboxed container path buried five levels deep in your user profile, with a package identity hash that is meaningless to humans and different enough between install methods that even knowing the app name doesn’t help you find its files.

The security rationale is real — sandboxed apps can’t easily corrupt each other or the system, and uninstallation is cleaner. But the cost is significant: determinism, transparency, and administrative control are all casualties. For consumer apps on a locked-down kiosk, that trade-off makes sense. For developer tools used by people who need to script, back up, and manage their environment — it’s a regression.

ClaudeTools exists precisely because that regression has a real cost. A developer shouldn’t need a PowerShell module to find a JSON file.

The Solution: ClaudeTools

Rather than memorize two paths or run a file search every time, I built ClaudeTools — a PowerShell module that handles Claude Desktop config management regardless of how it was installed.

It started as a single function to locate the config file. Then came edit, backup, and restore. Then during a Windows reinstall where several MCP servers stopped working, it grew into a log viewer too — with live tail support for debugging MCP/Connector server issues in real time.

Installation

# Create the module folder
New-Item -ItemType Directory -Path "$env:USERPROFILE\Documents\WindowsPowerShell\Modules\ClaudeTools" -Force

# Copy module files from the repo
Copy-Item "ClaudeTools.psm1" "$env:USERPROFILE\Documents\WindowsPowerShell\Modules\ClaudeTools\"
Copy-Item "ClaudeTools.psd1" "$env:USERPROFILE\Documents\WindowsPowerShell\Modules\ClaudeTools\"

# Allow unsigned local scripts if needed
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Unblock-File "$env:USERPROFILE\Documents\WindowsPowerShell\Modules\ClaudeTools\ClaudeTools.psm1"

# Import
Import-Module ClaudeTools

Add Import-Module ClaudeTools to your $PROFILE to load it automatically in every PowerShell session.

Finding the Config File

Get-ClaudeConfig
# Claude config found at:
# C:\Users\YourName\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

Works regardless of install method. No searching, no guessing.

Editing the Config

Edit-ClaudeConfig

Opens claude_desktop_config.json directly in Notepad. Restart Claude Desktop after saving for changes to take effect.

Backup and Restore

The most common use case — preserving your MCP server configuration across a Windows reinstall:

# Before reinstalling Windows
Backup-ClaudeConfig -Destination "D:\backup\Claude"

# After reinstalling — launch Claude Desktop once first, then:
Restore-ClaudeConfig -Source "D:\backup\Claude"
# Restart Claude Desktop

If no destination is specified, Backup-ClaudeConfig defaults to Documents\ClaudeBackup. If the folder doesn’t exist you’ll be prompted to create it. If the drive isn’t available you get a clean error — no silent failures.

The Logs Feature

Claude Desktop creates separate log files per MCP/Connector server:

When an MCP server stops working, Get-ClaudeLogs makes diagnosis a one-liner:

# See all MCP server errors at once
# Use "[error]" with brackets to match the severity tag only,
# not the word "error" anywhere in the log content
Get-ClaudeLogs -MCP -Filter "[error]"

# Specific server log
Get-ClaudeLogs -Server MyMcpServer

# Watch a server live while restarting Claude Desktop
Get-ClaudeLogs -Server MyMcpServer -Follow

# Watch all MCP servers simultaneously — interleaved with [server-name] prefixes
Get-ClaudeLogs -MCP -Follow

# Search all logs for a string
Get-ClaudeLogs -All -Filter "disconnected"

The -Follow flag implements a clean tail mode. Multiple log files are interleaved with [server-name] prefixes so you can tell which server each line came from. Ctrl+C exits cleanly.

A Note on the Future

Claude Desktop is evolving quickly. MCP servers are now being rebranded as Connectors, with a built-in connector marketplace replacing the need for some local Python and Node.js based servers entirely. The config file isn’t going away — MCP/Connector definitions still live there — but the ecosystem around it is maturing fast.

ClaudeTools is designed to grow with it. Claude Code support is a natural next addition — config management, session tooling, log access. If you have ideas or want to contribute, the repo is open.

GitHub: github.com/bharatsuneja/ClaudeTools