[BUG] Windows: Claude Desktop leaves a stale %APPDATA%\\Claude\\claude-code\\... runtime that makes Claude Code appear to have multiple installed versions

Resolved 💬 1 comment Opened May 27, 2026 by ElliotDrel Closed Jun 30, 2026

### Preflight Checklist

  • [x] I have searched existing issues and found related Desktop/CLI split reports, but not this exact Windows version-mismatch presentation
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, it is possible to end up with:

  1. the current native Claude Code CLI installed at:

C:\Users\<user>\.local\bin\claude.exe

  1. a stale Claude Desktop-managed Claude Code runtime left behind at:

%APPDATA%\Claude\claude-code\<old-version>\claude.exe

Both binaries are valid Anthropic-signed claude.exe files, but they can be on different versions.

This creates the impression that Claude Code is installed twice, and makes it hard to tell which install is authoritative. In my case, the native CLI was current, but Claude Desktop had left behind an older runtime under %APPDATA%\Claude\claude-code\2.1.142\claude.exe.

What Should Happen?

Windows users should not be left with a misleading stale Desktop-managed Claude Code runtime after upgrading or uninstalling Claude Desktop.

At minimum:

  • Claude Desktop should clean up old %APPDATA%\Claude\claude-code\<version> runtimes when they are no longer in use
  • documentation and/or claude doctor should make it clear that %APPDATA%\Claude\claude-code\... is a Desktop-managed runtime distinct from the native CLI
  • there should be a clearer diagnostic path for "why do I appear to have multiple Claude versions installed?"

Error Messages/Logs

There was no direct CLI error. The problem presented as an apparent install/version mismatch.

Steps to Reproduce

  1. Install Claude Code natively on Windows
  2. Install and use Claude Desktop with Code/local-agent features
  3. Let the native CLI update independently
  4. Observe that %APPDATA%\Claude\claude-code\<old-version>\claude.exe can remain on disk even when the current terminal CLI is newer
  5. Compare versions/paths and conclude there appear to be multiple Claude Code installs

Diagnostic Evidence

On my machine, the active/native CLI was:

PS> claude --version
2.1.152 (Claude Code)

PS> where.exe claude
C:\Users\<user>\.local\bin\claude.exe

PS> Get-Command claude -All | Format-List Source,CommandType,Version
Source      : C:\Users\<user>\.local\bin\claude.exe
CommandType : Application
Version     : 2.1.152.0

The stale Desktop-managed runtime on disk was:

C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.142\claude.exe

Its version was:

2.1.142 (Claude Code)

Both executables were valid Anthropic-signed binaries.

Important Clarification

In my case, VS Code itself was not the cause.

After verification, both the VS Code integrated terminal and Windows Terminal resolved the same correct native CLI path:

C:\Users\<user>\.local\bin\claude.exe

The confusion came entirely from the stale Claude Desktop-managed runtime still existing on disk.

Resolution / Workaround

What fixed the confusion on my machine:

  1. verify the active terminal CLI with:

claude --version
where.exe claude
Get-Command claude -All

  1. confirm the native CLI is current
  2. remove the stale %APPDATA%\Claude\claude-code\<old-version> runtime (in my case this was safe because Claude Desktop had already been removed)

After cleanup, both terminals consistently reported:

2.1.152 (Claude Code)
C:\Users\<user>\.local\bin\claude.exe

Claude Code Version

Native CLI: 2.1.152

Stale Desktop-managed runtime found on disk: 2.1.142

Platform

Anthropic API

Operating System

Windows 11

Terminal/Shell

PowerShell

Additional Information

This seems related to the broader class of issues where Claude Desktop and the standalone Claude Code CLI maintain separate runtimes/config surfaces on Windows. The problem here is not that the native CLI resolved incorrectly; it is that the stale Desktop runtime remained on disk in a way that strongly suggested a second live install.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗