[BUG] Claude Desktop (Windows MSIX): Help > Troubleshooting > "Disable Hardware Acceleration" silently fails to persist (isHardwareAccelerationDisabled never written to config.json)

The in-app toggle intended to disable hardware acceleration never writes its setting. This matters because it is the mitigation most commonly suggested for the GPU-process crash in #81341 — users are told to flip a switch that silently does nothing.

Filing separately from #81341 since this is a settings-persistence defect rather than the crash itself.

Environment

• Claude Desktop 1.40609.0.0 (Windows MSIX, x64, Claude_pzs8sxrjxfjjc)
• Windows 11 Home 10.0.26200 (25H2)

Steps to reproduce

1. Help → Troubleshooting → Disable Hardware Acceleration (checkbox)
2. Accept the "Restart Required" dialog, then restart the app
3. Inspect the config:

Get-Content "$env:APPDATA\Claude\config.json" | Select-String isHardwareAcceleration

Expected: "isHardwareAccelerationDisabled": true

Actual: the key is absent. Hardware acceleration remains on — the GPU process still launches with hardware D3D11 and WebGL reports the hardware adapter.

Attempted twice, with a full quit and relaunch each time. config.json was rewritten on both restarts (size unchanged at 7554 bytes) and the key never appeared.

Not a file-permission or MSIX-virtualization problem

The app writes this same file successfully throughout the session. config.json also holds the OAuth token cache ([oauth] token cache location: ...\config.json), and main.log records Config file written during the same restarts in which the toggle failed to persist.

Both config paths are a single file behind MSIX redirection:

• %APPDATA%\Claude\config.json
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\config.json

Writing the key to one makes it appear in the other.

The setting works when it is actually present

Inserting the key externally, with the app fully closed, is honored at launch:

"isHardwareAccelerationDisabled":true

After relaunch the GPU process starts with --use-gl=angle --use-angle=d3d11-warp-webgl, and WebGL reports ANGLE (Microsoft, Microsoft Basic Render Driver ... D3D11). So the read path and the effect are fine; only the write path from the menu is broken.

Caveat worth recording

Once applied, this setting does not mitigate the #81341 crash. navigator.gpu remains exposed, requestAdapter() still reaches the blocked SwiftShader path, and the app still terminates. Verified on 1.40609.0.0.

So the toggle is both broken and, when repaired externally, ineffective for the purpose it is most often recommended for. Reporting it because it is presented to users as the remedy, and its silent failure means nobody can even determine that the remedy doesn't work.