[BUG] Claude Desktop (Windows MSIX): severe flickering on NVIDIA RTX 50-series, fixed by --disable-direct-composition, but MSIX packaging blocks applying the workaround

A few more details if it helps to resolve, upon repeated attempts no method was found via Nvidia control panel specific application adjustments (Fixed Refresh, Disable GSync, Vsync Variations etc.).

Mini/Max Window would generate a brief pause in the flickering, then various sections of the screen would be populated with black squares, full window flashing, blurred text, and so forth.

Hopefully this facilitates a future fix.

Confirming this on RTX 40-series as well — not limited to 50-series hardware. Might be worth broadening the title.

Environment

• Claude Desktop 1.40609.0.0 (MSIX, Claude_pzs8sxrjxfjjc) — latest as of 2026-08-30, "No Update Available"
• Windows 11 Pro, build 26200
• NVIDIA GeForce RTX 4080 SUPER, single display (LG DualUp 2560×2880 portrait), HDR off
• Reproduced identically on driver 596.49 and, after updating, 616.56 — so this is driver-independent

Symptoms: severe strobing composed of bounded rectangular regions flashing at different rates, plus stale regions that stop updating — typed characters don't appear in real time, and scrolling leaves artifacts — mostly unreadable. Notably, dragging or even just click-holding the title bar temporarily reduces it (consistent with DWM forcing full-surface recomposition during a window move, and with OP's observation that minimize/maximize briefly pauses it before black squares repopulate). Present in both dark and light themes (subjectively worse in light). I'm not seizure-prone, but this is genuinely a photosensitivity hazard.

Diagnostic data point: while the window was strobing, the app's renderer and GPU child processes were nearly idle (~5–9% of one core). So this isn't an app-level repaint storm — consistent with OP's conclusion that it's a DirectComposition presentation conflict.

Confirmed fix: --disable-direct-composition via direct launch of the packaged exe fully eliminates it (verified the flag was on the running process command line; reproducible on/off).

Improvement for workaround pitfall 1 (stale version-pinned path): you don't need a pinned shortcut. Standard users can't wildcard-enumerate WindowsApps, but Get-AppxPackage returns the current install path, so this launcher survives app updates:

@echo off
set "EXE="
for /f "delims=" %%D in ('powershell -NoProfile -Command "(Get-AppxPackage -Name Claude).InstallLocation"') do set "EXE=%%D\app\Claude.exe"
start "" "%EXE%" --disable-direct-composition

Can also confirm pitfall 3: if a flagless instance is running (or auto-restarts after an update), launching with the flag silently no-ops into the existing window — you must fully quit first.

+1 to the ask: a hardware-acceleration / DirectComposition toggle in app settings, or honoring ELECTRON_EXTRA_LAUNCH_ARGS in the MSIX package.

Claude Fable 5 via Claude Code, running locally on my machine while diagnosing this, suggested a more specific lead: the per-region strobe rates and stale rectangles point at partial-present/dirty-rect handling rather than full-frame presentation. (I'm not a graphics-layer expert — offered as a triage lead, not a claim.)

Isolated to Windows/NVIDIA Multi-Plane Overlay (MPO) — system-level fix below.

Disabling MPO eliminates it completely, with no per-app flags:

HKLM\SOFTWARE\Microsoft\Windows\Dwm → OverlayTestMode (DWORD) = 5

Reboot, then launch Claude normally — no --disable-direct-composition, no launcher script. Flicker gone. Same for Docker Desktop, which flickered identically on this machine.

To be precise about what this is: MPO is the mechanism, not the culprit. The underlying defect is somewhere in the interaction between NVIDIA's overlay implementation, Windows DWM, and how certain Chromium builds present — I haven't isolated which, and can't from here. This is a working mitigation, not a diagnosis.

What localized it — 2 of 5 Chromium/Electron apps affected on this machine:

Affected: Claude Desktop, Docker Desktop
Clean: VS Code, LM Studio, GitHub Desktop

The open question that would actually locate the bug: what do the affected apps do differently in their present path from the clean ones? Same GPU, same display, same session, same driver. If Claude and Docker share an Electron version or swap-chain/present-mode configuration that VS Code, LM Studio and GitHub Desktop don't, that's where the answer is — and that part is checkable on the Claude side.

Also: immune to a driver update (596.49 → 616.56), and --disable-direct-composition works precisely because it bypasses the path MPO breaks.

Environment: RTX 4080 SUPER, LG DualUp 2560×2880 @ 59.98 Hz, 150% scaling. (I did not test whether refresh rate or scaling matter — MPO was the first thing I tried and it resolved it, so those remain unexamined variables.)

Not a Claude-specific defect, but the 2-of-5 split suggests the present-path config may be partly actionable here rather than purely environmental. The standing ask helps either way: an in-app hardware-acceleration / DirectComposition toggle, or honoring ELECTRON_EXTRA_LAUNCH_ARGS in the MSIX build.