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.

v6.0.3

The user who reported the 6.0.2 problem sent their logs. The logs show 6.0.2
fixed the wrong thing.

6.0.2 stopped the script repeating an unfixable message every five seconds. It
never asked whether the message was true. It was not.

What was actually happening

Restart-CoworkService ran a prerequisite check first, and on a failure it
returned without ever calling Start-Service. Every "Service failed to start"
and every "Service died, restarting" in that transcript was printed for a start
that was never attempted.

Their own cowork-service.log settles it. Between 11:12:16, when the script
stopped the service, and 11:29:18, when Claude Desktop started it again, the
file contains nothing at all. Not one failed start, because there was no start.

And when something finally did ask, it worked. The 11:29 start took 293
milliseconds: vmcompute.dll and computecore.dll loaded, HCN enumerated two
networks, the named pipe came up. A Cowork VM had been running on that machine
at 10:02 the same morning, and had reported "Startup complete" the day before.

Nothing was broken. The script broke it, for seventeen minutes, and told them
their machine was misconfigured.

The Virtual Machine Platform check was wrong

Not just badly worded, which is what 6.0.1 and 6.0.2 treated it as. Wrong.

What Cowork needs is a working Host Compute Service stack. Virtual Machine
Platform is one way to get one. Full Hyper-V is another. On a machine with
Hyper-V fully enabled, VirtualMachinePlatform can read Disabled while HCS
works perfectly, which is exactly what their machine looks like.

So the reporter's original screenshot, showing every Hyper-V feature enabled,
was more relevant than it appeared. The feature is only named as a cause now
when vmcompute and hns are genuinely missing.

The rule this changes

Prerequisites are advisory. The service is always asked to start, and the
findings are only read out if it refuses.

A check that can be wrong must never prevent the attempt that would prove it
wrong. Trying to start a service that truly cannot start costs a few seconds and
an error message. Refusing to try on a machine that can costs someone their
working install.

There is a CI gate for it now. It stubs the check to report a blocker and
asserts a start happens anyway, across three cases: check wrong and service
fine, check clean, and service genuinely dead. It was verified by putting the
old behaviour back and watching five assertions fail.

Support bundles

The bundle now reads the log folder rather than copying a list of filenames.
That list was written from one machine, and the first real export it was
compared against had coworkd-user.log and vm-info.json, neither of which was
on it. vm-info.json was the most useful file in the whole export: it carries
the VM bundle size, whether the download completed, and whether the guest is
connected.

Files are ranked rather than treated equally, because reading the folder turned
up 40 files and 32 were per-server MCP logs. Cowork and VM logs take four fifths
of the space, everything else shares the rest.

Upgrading

If you are on 6.0.1 or 6.0.2, take this one. On a machine where the
prerequisite check is wrong, both of those will refuse to do anything useful.

Full detail in CHANGELOG.md.

v6.0.2

From a user report. The script found the real problem straight away and then
spent the rest of the run behaving as though it had not.

What went wrong

On that machine, Virtual Machine Platform was disabled. The script detected it,
said so, and correctly declined to purge the cache over something a cache purge
cannot fix. Then it launched Claude anyway, entered the workspace wait, found
the service dead, restarted it, hit the same wall, and printed the same
four-line remediation every five seconds until the user pressed Ctrl+C.

The wait loop was throwing away the one signal that mattered. Restarting the
service returns false when a human has to change something first, and that
result was being piped to nothing. It now skips the wait entirely once the
blocker is known, and stops after three restarts when it is not, because a
service that has died four times is not going to survive a fifth attempt.

Why the message made it worse

The old text read "Cowork runs in a Hyper-V VM and cannot start without it". So
the reporter searched their Windows features for *Hyper-V*, saw all seven
Hyper-V features enabled, and reasonably concluded the script was wrong.

It was not. That search cannot match VirtualMachinePlatform, because the name
has no "Hyper-V" in it. They are separate Windows features, and turning on
Hyper-V does not turn on Virtual Machine Platform. A machine can have every
Hyper-V feature enabled and still be missing the one Cowork needs.

The message now says that outright, and gives the command that actually answers
the question:

Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

If it does not say Enabled:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All

Then restart. Use Restart, not shut down and power on. With Fast Startup on, a
shutdown cycle can leave the virtualization services uninitialized.

Support bundles

Diagnostic mode now gathers what a bug report needs into one zip: the Claude log
folder, the Service Control Manager entries for the services that have to be
alive, and the Windows feature states listed by exact name.

The event log is the part people miss. When a service refuses to start there is
almost nothing in Claude's own logs, because nothing ran to write them. Windows
is the only thing that recorded what happened.

The bundle is built to a 4 MB budget shared across the files, then zipped, so it
fits an attachment limit. On the machine this was tested on that came to 318 KB.
Missing files are reported rather than quietly skipped, because no VM log at all
is itself the answer: it means the VM has never started there.

Run it with:

.\Fix-ClaudeDesktop.ps1 -Mode Diagnostic

It changes nothing, and prints the path to the zip at the end.

Also

Step 5 reported "No orphan compute systems via hcsdiag" on a run whose step 0
had already reported hcsdiag unavailable. Both cases returned zero and the
caller could not tell them apart.

Full detail in CHANGELOG.md.

v6.0.1

A follow-up to 6.0.0. Four defects, three of them in code 6.0.0 itself changed,
plus the launchers, which no release had ever looked at.

The one worth reading

Prevent-ClaudeIssues.ps1 -WhatIf applied every change for real.

The script relaunches itself elevated, and that relaunch forwarded -Undo but
not -WhatIf. So the unelevated process understood you wanted a dry run, then
started a fresh elevated process that knew nothing about it. Everything you
asked it to preview, it did. If you ran a preview on this script, treat it as a
real run and use -Undo if you want the changes back.

The same relaunch also returned the instant UAC was accepted rather than
waiting for the elevated process, so a failed run reported as a clean one.

The launchers

All four .bat files treated any non-zero exit code as a launcher failure and
told you to screenshot an error. 6.0.0 made the repair script exit 1
deliberately when it runs out of retries, which turned an ordinary outcome the
script had already explained on screen into a second, more alarming prompt
about an error that was not there.

They now distinguish "the script ran and had something to say" from "PowerShell
could not start the script at all", and only stop for the second.

The third copy

The HCS cleanup step in Prevent-ClaudeIssues.ps1 still called
hcsdiag close. There is no close verb, so the call did nothing and then
logged success. It also ran while Claude was open, which meant "stale compute
system" could mean the VM you were working in. It now uses kill, and leaves
everything alone while Claude is running.

6.0.0 fixed exactly this in the repair script and the health monitor, and
missed this copy. There were four copies of that parse across three scripts,
each with its own variation on the same two mistakes. There is one now, in the
shared discovery region, with tests.

Also

Prevent-ClaudeIssues.ps1 now uses discovered values throughout rather than
only in its constants block. The service name, the service executable and the
Claude data folder are read from discovery at every site, including the boot
task it writes, where the value is baked in at install time because that task
runs on its own with no discovery available.

The health monitor reports guest-connect as dormant rather than active when
cowork-service.log is stale or missing. On builds that do not write that log
the check cannot fire, and the banner used to claim it was armed.

Two new CI gates. One runs each launcher with a stubbed exit code and checks
what you would actually see. The other reads the source and requires that any
script which elevates itself forwards -WhatIf, waits for the child, and
propagates its exit code. Both were verified by putting the bug back and
confirming they fail.

Upgrading

Download the three .ps1 files and four .bat files, put them in the same
folder, and run Prevent-ClaudeIssues.bat once if you want the scheduled tasks
refreshed. Nothing else is needed.

Full detail in CHANGELOG.md.

ClaudeFix v6.0.0: the repairs actually run now

If you have been running this toolkit and wondering why it never seemed to help,
this release is probably why.

What was not working

Every HCS cleanup did nothing. All ten call sites asked hcsdiag to "close" a
compute system. hcsdiag has no close verb. The call returned without error and
the toolkit logged success. The GUID parser feeding those calls expected hcsdiag
to print a GUID on a line of its own, which it never does, so it always came
back empty. Both bugs existed in two separate copies, in two different scripts.

The health monitor could not repair anything, ever. It preferred a log file
that stopped being written in March, so its session check reported an active
session forever and every repair attempt took the "blocked" branch.

The VHDX backup checked for 720 MB of free space before copying a file that
is over 3 GB. The check passed, the copy ran out of room part way, the catch
deleted the partial, and the purge then destroyed the original anyway.

The restore ran after the service restart, by which point the service had
already recreated the directory tree, so the restore declined to overwrite it. A
3 GB backup was abandoned on every deep run, silently.

What was actively harmful

-SkipLaunch could purge 13 GB of cache and then fail, because the escalation it
fell into read variables that only exist in the branch it had skipped.

One of the three purge blocks had no -WhatIf gate at all, so a dry run deleted
the cache.

The user-activity guard failed open. Any unexpected error meant "nobody is using
this", and the repair proceeded while someone was working.

Session transcripts older than 7 days were deleted on every run, in every mode,
while the help text stated that conversations were never touched. That deletion
is now -PurgeSessions, off by default.

What changed

The toolkit discovers where Claude is installed rather than assuming: package,
executable, service binary, log directory, VM cache and VHDX inventory. The dead
%ProgramData%\Claude paths and both hardcoded C: drive letters are gone.

VM log staleness is now a warning rather than a repair trigger. Fixing the log
selection made a previously dead check live, and testing showed it firing on a
healthy idle machine. An idle VM and a hung VM look identical from the host, so
it no longer authorises a repair on its own.

One version across all three scripts, and CI runs on every push: syntax,
ASCII-only, undefined variables, version agreement, shared-region drift, backup
purge logic, parser logic, and PSScriptAnalyzer.

Upgrading

Download the files into the same folder you had before, then run
Prevent-ClaudeIssues.bat once to refresh the scheduled tasks. Your power
settings, exclusions and existing configuration are not touched.

Old UpdateN and HotfixN tags stay where they are. Tags are semver from here.

Full detail in CHANGELOG.md.

ClaudeFix v5.4.0: missing AppData folder fix + service prerequisite diagnostics

Two fixes reported from the field.

Prevent-ClaudeIssues.ps1 (2.0.1)

The script wrote its power plan backup into %APPDATA%\Claude\ without creating that folder first. On a machine where Claude Desktop has not been installed or launched under the running account, the folder does not exist, so step 1 of 26 died with:

Could not find a part of the path 'C:\Users\<name>\AppData\Roaming\Claude\power-plan-backup.txt'.
Line: 393

Step 1 also had no error handling of its own, and the whole script body sits inside one outer try/catch. That single failure ended the run before the other 25 steps got a chance.

• The folder is created at startup, and every state file write goes through a helper that creates it and falls back to a warning if the path is unwritable.
• Steps 1, 2, 3, 5, 18, 21, 22, 23 and 24 have their own error handling now, so no single step can end the run.
• The error box says the run stopped early instead of leaving you to work that out.

Fix-ClaudeDesktop.ps1 (5.4.0)

sc start CoworkVMService answers a blocked service with FAILED 87 or FAILED 1058 and says nothing about why. The script only read the service Status, never its StartType or the platform underneath it, so it retried, escalated to a cache purge, and reported failure against a service that was never going to start.

A prerequisite check now runs before the start attempt and names the actual cause:

• Virtual Machine Platform feature disabled
• Host Compute Service stack missing (vmcompute, hns)
• hypervisorlaunchtype not set to auto, which is common when VMware or VirtualBox is installed
• CoworkVMService not registered, which happens when the MSIX was installed per-user instead of provisioned machine-wide
• CoworkVMService start type set to Disabled, re-enabled automatically when running elevated
• Duplicate Claude package registrations, the documented cause of error 87

Each result prints the command that fixes it. Smart mode no longer escalates to the cache purge when the check says the service cannot start, because purging cannot help.

The checks follow the remediation steps in Anthropic's deployment article: https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows

ClaudeFix Hotfix

Changelog

v5.3.1 -- Close Mode Fix (2026-03-23)

• Close mode rewrite (Fix) -- stop-then-restart pattern. Stops CoworkVMService (triggers graceful VM shutdown ~31s), cleans HCS orphans, kills Claude UI, restarts service so it is ready for the next launch. Fixes the Windows behaviour where manually-stopped services ignore ETW named pipe triggers
• Stop-ClaudeDesktop.bat -- new launcher for clean shutdown via Close mode. Double-click to stop Claude without running a repair
• Test-RecentHcsErrors Admin log fix (Fix) -- Admin log code path now skips 0xC037010D events with continue instead of returning shutdown_stale, which was bypassing the >15 threshold on any single event
• Version bump -- Fix updated to v5.3.1

v5.0.0 -- HCS Safety & Close Mode (2026-03-23)

• Invoke-HcsDiag helper (Fix + Watch) -- all hcsdiag calls wrapped with Start-Job + 15s timeout to prevent indefinite hangs when HCS is corrupted. 14 call sites in Fix, 3 in Watch
• ServiceTimeout raised (Fix) -- service stop timeout increased from 8s to 30s. Prevents premature force-kills that cause HCS state corruption
• Graceful service polling (Fix) -- WaitForStatus replaced with polling loop, preventing PowerShell timeout exceptions during slow VM shutdowns
• VHDX handle verification (Fix) -- 3 sites now verify VHDX files are not locked before backup/restore operations
• 0xC037010D threshold raised (Fix) -- from 8 to 15 in Test-RecentHcsErrors. This event occurs on every normal VM shutdown (property query bug) and is not a blocker
• vmcompute restart guards (Watch) -- active session detection + Fix mutex check before vmcompute restart. Threshold raised from >5 to >15. Prevents disrupting running Cowork sessions
• Log paths updated (Fix + Watch) -- primary log path changed to C:\ProgramData\Claude\Logs\coworkd.log with fallback to %APPDATA%\Claude\logs\cowork_vm_node.log
• BootPrep delay increased (Prevent) -- boot-fix task delay raised from 30s to 45s with smart pre-check: skips if CoworkVMService or Claude is already running
• Version bump -- Fix 5.0.0, Watch 5.0.0, Prevent 2.0.0

v4.9.0 -- Guest Connection Timeout Detection (2026-03-22)

• New detection source (Fix) -- reads C:\ProgramData\Claude\Logs\cowork-service.log for isGuestConnected RPC state via new Test-CoworkServiceLog helper
• Guest timeout in HCS detection (Fix) -- Test-RecentHcsErrors now returns "guest_connect_failure" when repeated isGuestConnected polls get no guest response
• Targeted Step 9 recovery (Fix) -- when guest-timeout is detected after 90s, performs HCS cleanup + service restart instead of waiting for the full 240s timeout
• Guest connection health monitor (Watch) -- new Check 10 monitors cowork-service.log for sustained isGuestConnected polling with zero guest responses (3 consecutive checks required before trigger)
• Error patterns expanded (Watch) -- added isGuestConnected timeout patterns to log-scan error list
• README updated with isGuestConnected error documentation, new tracked issues (#31848, #31314), troubleshooting entry, and updated step descriptions
• Version bump -- Fix and Watch updated to v4.9.0

v4.8.6 — Audit cleanup, dead code removal, version sync

Remove legacy $SkipLaunch vmcompute restart path from Fix Step 3 (dead since v4.8.4 BootPrep).
Fix stale .NOTES version headers in Watch (was 4.8.3) and Prevent (was 4.8.3).
Update README: add Step 0 to Fix table, update #26554 closure status, add #32172.
Delete 24 obsolete diagnostic scripts and CodePrompt files from Claude\ subfolder.
Rebuild distribution zip.

ClaudeFix v4.8.4 — Non-Destructive Boot Prep + README Overhaul

• New BootPrep mode: lightweight, non-destructive vmcompute restart at logon (30s delay, replaces 180s full fix) to prevent 0x800707DE construct failures without killing Claude or stopping services
• Boot-fix scheduled task updated from -SkipLaunch -Quiet (180s) to -BootPrep -Quiet (30s)
• Active workspace detection: BootPrep safely exits if Claude is already running with an active Cowork VM
• Stale VM cleanup at boot before vmcompute restart
• README: Added v4.8.4 changelog, BootPrep documentation, Known Limitations section (multi-window startup race condition), expanded SEO error keywords (0x800707DE, "Failed to start Claude's workspace", "VM service not running"), new tracked issues (#29045, #27801), added @Onimir89/Restart_claude to credits
• All scripts bumped to v4.8.4

Full Changelog: Update7...Update8

ClaudeFix v4.8.0: HCS hardening, robustness fixes, README update

Adds CoworkVMService auto-recovery and pre-emptive HCS state cleanup to Prevent (new steps 13-14). Introduces Close-StaleHcsVms unified helper in Fix for consistent GUID parsing across all code paths. Adds heartbeat detection to Test-HyperVReady, VHDX backup/restore to Smart escalation, and FileStream try/finally leak protection. Watch gains HCS state health monitor (Check 8) with stale VM cleanup and 0xC037010D spike detection, deduplicates event log reads, and passes explicit -Mode Smart -Quiet to auto-fix. Fixes Prevent step count off-by-one, Watch Check 8 race condition that could close the active VM, and uninitialized $vhdxBackedUp variable. Updates README with new step numbering (26 steps), nine monitor sources, v4.8.0 changelog, and corrected prose references. Rebuilds ClaudeFix.zip with all updated files.