v6.0.4

A launcher for the in-app Browser crash.

The problem

Current Claude builds have a fatal GPU-process crash: #80444,
exit code 101457950 (0x060C201E). Open a page in the in-app Browser preview, the
page runs a WebGL capability probe, the GPU process dies, and Claude goes with
it. No warning, no recovery.

From a user's logs, to the second:

10:02:22  [Preview] Created browser preview
10:02:27  WebGL: INVALID_ENUM: getInternalformatParameter    (x57)
10:02:28  WebGL: CONTEXT_LOST_WEBGL: loseContext
10:02:28  GPU process gone: exitCode 101457950

Running with --disable-gpu avoids it. The awkward part is that an MSIX app
launched normally never receives a command line, so the flag has nowhere to go.
That is where most people give up.

What this adds

Prevent-ClaudeIssues now writes Launch-Claude-NoGPU.cmd into your Claude
folder, plus a "Claude (no GPU)" desktop shortcut.

It uses Invoke-CommandInDesktopPackage, which starts the executable inside the
package identity. The flag arrives, and the install is not damaged the way
launching the .exe directly from WindowsApps would damage it. On a
traditional install the flag just goes on the command line.

The launcher closes any running instance first. Claude is single-instance, so
launching a second copy over a running one only focuses the existing window and
the flag is silently ignored. That is the step most hand-written versions of
this miss, and it is why they appear to do nothing.

Everything identifying your install comes from runtime discovery, so it works on
any machine rather than only the one it was written on.

Using it

Run Prevent-ClaudeIssues.bat once, then launch from the "Claude (no GPU)"
shortcut when you need the Browser pane. Your normal shortcut is untouched and
still uses the GPU, so this costs you nothing when you are not using that
feature. -Undo removes the launcher and the shortcut.

Expect the UI to feel slightly slower without hardware acceleration. That is the
trade.

Honest caveat

--disable-gpu is the prevention listed in #80444 and it is not confirmed to
hold over long sessions, since Chromium may still spawn a GPU process for
software compositing. If it does not hold for you, the only certain answer today
is to avoid the in-app Browser pane on this build and use a real browser window
for testing.

Also

• A CI gate that builds the generated launcher for both install shapes and
  parses it. Script-writing-script code never runs at build time, so a dropped
  escape would have shipped and only surfaced when someone double-clicked it.
• The admin shortcut's icon lookup now reads runtime discovery instead of
  re-running Get-AppxPackage and walking three hardcoded install paths.

Full detail in CHANGELOG.md.