C:/Program Files/Git/desktop always reports "not installed" on Windows even when Claude Desktop is installed (reg.exe arg escaping bug)

Bug description

On Windows, the /desktop command always reports the desktop app as "not installed" / prompts to download it, even when Claude Desktop is genuinely installed and running, and even when the OS-level claude:// URI handler is correctly registered and functional.

Environment

• Claude Code version: 2.1.245 (Windows build)
• OS: Windows 11 Home 10.0.26200
• Claude Desktop: installed and running (confirmed two valid installs present — a Squirrel-installed copy under %LOCALAPPDATA%\AnthropicClaude and a Microsoft Store/MSIX package Claude_1.34493.1.0_x64)

Root cause (found via reverse-inspection of the shipped binary)

The Windows install-check in /desktop shells out to:

reg query "HKEY_CLASSES_ROOT\claude" /ve

Manually running this exact command succeeds (exit code 0) every time, using several different spawn methods (PowerShell, cmd /c, Python subprocess.run with an argv list, with a normal environment, and with a stripped-down environment).

However, I was able to reproduce the exact failure mode (ERROR: Invalid key name., exit code 1) by passing the registry path with a doubled backslash instead of a single one:

reg query "HKEY_CLASSES_ROOT\claude" /ve   # fails: Invalid key name
reg query "HKEY_CLASSES_ROOT\claude" /ve    # succeeds

This strongly suggests that whatever spawns reg.exe internally (this build appears to be a Bun-compiled binary) is double-escaping the backslash in the quoted registry path argument on Windows, causing the install check to always fail and report "not installed," regardless of actual installation state.

Steps to reproduce

1. On Windows, install Claude Desktop.
2. In Claude Code, run /desktop.
3. Observe: it reports the app is not installed / offers to download it, even though it is installed and running.

Expected behavior

/desktop should correctly detect an installed Claude Desktop app on Windows and hand off the session, instead of always falling through to the "not installed" / download-prompt path.

Suggested fix

Verify how the internal process-spawn helper constructs the Windows command line for arguments containing backslashes inside quotes (likely a Bun spawn/spawnSync argv-escaping issue specific to Windows), and/or avoid backslash-in-quotes registry paths by using reg.exe's alternate forms, or a native Windows registry API instead of shelling out to reg.exe.