[BUG] Windows desktop (MSIX): Claude Code sessions' writes to HKCU\Software are silently virtualized despite `desktop6:RegistryWriteVirtualization=disabled`, so the agent confirms changes that never reach the real registry

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment: Claude Desktop (MSIX) 2.19675.0.0, Code tab. Windows 11 Home 25H2, build 26200.9550, x64.

Registry writes under HKCU\Software made by the tools Claude Code runs (PowerShell, reg.exe…) end up in the package's private hive (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat). Reads from inside the session return that virtualized value, so the agent's read-back "verification" succeeds while the real registry stays unchanged. There's no error and no warning.

This is the registry side of #93152 and #94254, which cover the filesystem. #93152 notes that HKCU\Environment isn't virtualized. That's correct, but HKCU\Software is, and that's where most user settings live.

Real-world impact. I used the Code tab to tune my PC. Over several weeks:

• About 20 privacy and content-delivery values (ContentDeliveryManager\*, Search\BingSearchEnabled, Explorer\Advanced\Start_IrisRecommendations, Privacy\TailoredExperiencesWithDiagnosticDataEnabled, Policies\Microsoft\Windows\Explorer\DisableSearchBoxSuggestions) were reported as applied and verified. None of them reached the real registry.
• A DirectX per-app setting (HKCU\Software\Microsoft\DirectX\UserGpuPreferences) was reported as applied, but it never existed outside the package. Weeks later this caused a misdiagnosis of an FPS drop: the agent "saw" a setting that Windows didn't have.
• Files deleted under %APPDATA% came back after a reboot. That's the filesystem side, already covered by #93152.

The worst part isn't the redirection itself. It's that the agent verifies by reading the same virtualized view, so it confidently confirms changes that never happened.

What Should Happen?

Writes to HKCU\Software from Code tab sessions should land in the real user registry, the same way HKLM writes from an elevated session already do. The manifest even declares <desktop6:RegistryWriteVirtualization>disabled</desktop6:RegistryWriteVirtualization>.

Possible fixes:

1. Actually disable registry write virtualization for Code tab sessions: drop the flexible virtualization:RegistryWriteVirtualization block, or exclude HKEY_CURRENT_USER\SOFTWARE as a whole. Do the same for the filesystem (see #93152).
2. Or launch session shells outside the package context.
3. At the very least, tell the model in its environment context that writes to HKCU\Software and %APPDATA% are virtualized, and warn the user.

Error Messages/Logs

None. That's the problem: every write succeeds silently, and reading it back from inside the session returns the written value.

Steps to Reproduce

1. In a Claude Desktop (MSIX) Code tab session on Windows, have Claude run:

New-Item 'HKCU:\Software\ClaudeVirtTest' -Force | Out-Null
New-ItemProperty 'HKCU:\Software\ClaudeVirtTest' -Name Marker -Value 42 -PropertyType DWord -Force | Out-Null
(Get-ItemProperty 'HKCU:\Software\ClaudeVirtTest').Marker   # -> 42

1. Check the real registry, either from a normal PowerShell outside the app or from inside the session via WMI (the WMI provider runs outside the package):

$sid = [Security.Principal.WindowsIdentity]::GetCurrent().User.Value
Invoke-CimMethod -Namespace root\default -ClassName StdRegProv -MethodName GetDWORDValue -Arguments @{ hDefKey = [uint32]2147483651; sSubKeyName = "$sid\Software\ClaudeVirtTest"; sValueName = 'Marker' }
# -> ReturnValue 2 (not found)

1. Expected: the value exists in the real HKCU. Actual: it exists only in the package hive.

HKLM writes from an elevated session are real (checked the same way).

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 2.19675.0 (Code tab; CLAUDE_AGENT_SDK_VERSION=0.3.286)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Likely cause (from the installed AppxManifest.xml). The manifest declares both of these, plus the unvirtualizedResources capability:

<desktop6:RegistryWriteVirtualization>disabled</desktop6:RegistryWriteVirtualization>
...
<virtualization:RegistryWriteVirtualization>
  <virtualization:ExcludedKeys>
    <!-- 12 keys: browser NativeMessagingHosts, Chrome extensions, Office WEF -->
  </virtualization:ExcludedKeys>
</virtualization:RegistryWriteVirtualization>

What I observe fits the flexible-virtualization element winning on this build: everything under HKCU\Software is virtualized except the 12 listed keys, so the disabled flag has no effect. That's my reading of the manifest. I haven't confirmed the precedence rule in Microsoft's documentation.

Related: #93152, #94254 (filesystem write virtualization, same root cause family).