[BUG] Claude Desktop (Windows 11, MSIX 1.37937.3.0): clicking a link inside the app kills it instantly - reproducible 0x80000003 assert at Claude.exe+0x6E89D89, zero third-party DLLs in the process

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?

This report is about the Claude Desktop app for Windows (MSIX 1.37937.3.0), not the Claude Code CLI. Filing here because #87659 and #81398 are desktop-app reports in this tracker and I could not find another public one.

Clicking any link inside the Claude desktop app closes the entire app immediately. No error dialog, no warning. It has happened four times over two days.

All four crash dumps are the same fault at the same address, so this is a deterministic assert in the app, not an environmental flake:

EXCEPTION CODE : 0x80000003  STATUS_BREAKPOINT
FAULT ADDRESS  : 0x00007FF7EDD59D89
FAULTING MODULE: Claude.exe  v1.37937.3.0  (+0x6E89D89)
PARAMETERS     : 0x0

Anthropic's own Crashpad catches the crash; Windows Error Reporting never sees it. That is why nothing appears in the Windows Application log and why days of normal troubleshooting found nothing.

The important negative result - I enumerated the full module list from the dump:

TOTAL MODULES: 134
   132  Windows system (C:\Windows\...)
     2  Claude package
     0  anything else

No Bitdefender, no CyberGhost VPN, no injected hook of any kind. Anti-virus / VPN interference is ruled out for this crash.

Anthropic's own native module sits right at the fault on the scanned stack:

app\resources\app.asar.unpacked\node_modules\@ant\claude-native\claude-native-binding.node  +0x279680
app\resources\app.asar.unpacked\node_modules\@ant\claude-native\claude-native-binding.node  +0x211B40
app\resources\app.asar.unpacked\node_modules\@ant\claude-native\claude-native-binding.node  +0x1372D5
Claude.exe +0x39B7C30 / +0x39B8040 / +0xAFA78C5 / +0x2835328
KERNELBASE.dll +0x58A4C, +0x1E1CD, +0x1A488
ntdll.dll +0xA1B05, +0x178894, +0x127BB3

(Scanned stack - stack addresses that fall inside a loaded module - so frame order is approximate.)

Offset +0x6E89D89 in the shipped 1.37937.3.0 binary should map to one specific CHECK/assert in your symbols. Since it fires identically every time on the link-open path, that single symbol is very likely the whole answer.

Happy to supply the full 35 MB dump privately.

What Should Happen?

The link should open in the default browser (Firefox is correctly registered here for both http and https), and the Claude desktop app should stay running.

Error Messages/Logs

Crash dump parsed from %APPDATA%\Claude\Crashpad\reports\ (36,169,632 bytes, 2026-08-28 07:40:41):

EXCEPTION CODE : 0x80000003  STATUS_BREAKPOINT
CRASHING THREAD: 10828
FAULT ADDRESS  : 0x00007FF7EDD59D89
FAULTING MODULE: Claude.exe  v1.37937.3.0  (+0x6E89D89)
PARAMETERS     : 0x0

Module count from the same dump:
TOTAL MODULES: 134
   132  Windows system
     2  Claude package
     0  third-party

--- SECOND, SEPARATE DEFECT FOUND ALONGSIDE IT ---
Package Remove operations fail repeatedly. Get-AppxLog for the failing activity:

Started deployment Remove operation on package Claude_1.37937.3.0_x64__pzs8sxrjxfjjc, Options RemoveForAllUsers
0x0: TerminateSingleService for uninstall successful for service ... in package CoworkVMService
0x0: AllowUninstall successful
error 0x8007007E: Failed to load the extension DLL due to the following error: The specified module could not be found.
Error 0x80073CF6: Failure in the MachineRegisterAdd state handler

80 of these between 2026-08-25 14:59 and 2026-08-28 00:03:
  Claude 35 | OpenAI.Codex 2 | MicrosoftCorporationII.WinAppRuntime.Main.1.8 1 | package not named 42

Windows never names the missing module. Because it also hits non-Anthropic packages it may be Windows-side, but the CoworkVMService extension is in the failing path every time.

Residue this leaves behind - HKCU\Software\RegisteredApplications currently holds SIX AppX<hash> values for Claude, FIVE pointing at package versions that no longer exist:
  1.1.5749.0, 1.1.6041.0, 1.9255.2.0, 1.10628.0.0, 1.15962.2.0
Failed removals are leaving registrations behind.

Steps to Reproduce

1. Install Claude Desktop for Windows, MSIX build 1.37937.3.0 (Claude_1.37937.3.0_x64__pzs8sxrjxfjjc).
2. Open the app and open any conversation that contains a hyperlink.
3. Click the link.
4. The whole app closes instantly. No dialog, no error, nothing in the Windows Application log.
5. A minidump appears in %APPDATA%\Claude\Crashpad\reports\.

Happens every time here - 4 for 4 over two days, same fault address in every dump.

How to read the dump without a debugger (WinDbg on this machine is the GUI-only MSIX build). This parses the exception record and module list straight out of the minidump with the Python standard library:

import io, struct
buf = io.open(r"<path-to>.dmp", "rb").read()
sig, ver, n, dr = struct.unpack_from("<4sIII", buf, 0)
streams = {}
for i in range(n):
    t, s, r = struct.unpack_from("<III", buf, dr + i*12); streams[t] = (s, r)

# modules (stream 4)
_, rva = streams[4]
(nmod,) = struct.unpack_from("<I", buf, rva)
mods = []
for i in range(nmod):
    off = rva + 4 + i*108
    base, size = struct.unpack_from("<QI", buf, off)
    nr = struct.unpack_from("<I", buf, off+20)[0]
    ln = struct.unpack_from("<I", buf, nr)[0]
    mods.append((base, size, buf[nr+4:nr+4+ln].decode("utf-16-le")))

# exception (stream 6)
_, rva = streams[6]
code, flags, rec, addr = struct.unpack_from("<IIQQ", buf, rva+8)
print("code 0x%08X  addr 0x%016X" % (code, addr))
for base, size, name in mods:
    if base <= addr < base + size:
        print("module %s +0x%X" % (name, addr - base))

Output here, identical every time:

code 0x80000003  addr 0x00007FF7EDD59D89
module C:\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc\app\Claude.exe +0x6E89D89

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not established. 1.37937.3.0 is affected; crashes began 2026-08-27. Testing a rollback to 1.28929.0.0.

Claude Code Version

2.1.224 (Claude Code) - but note this report is about Claude DESKTOP 1.37937.3.0, not the CLI

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Note on the "latest version of Claude Code" checkbox

Being upfront: I ticked it because the subject of this report - Claude Desktop 1.37937.3.0 - is the latest desktop build (a clean download from the official installer on 2026-08-28 delivered that exact version). My Claude Code CLI is 2.1.224 while 2.1.250 is published. The CLI is not involved in this crash and updating it would not change anything here, but I would rather state that plainly than have the checkbox imply something untrue.

Environment

| | |
|---|---|
| App | Claude Desktop 1.37937.3.0 (MSIX, Claude_1.37937.3.0_x64__pzs8sxrjxfjjc) |
| Install | Direct MSIX from claude.ai/api/desktop/win32/x64/setup/latest/redirect |
| OS | Windows 11 Home 10.0.26200 |
| GPU | NVIDIA GeForce RTX 4080 Laptop (32.0.16.1088) + Intel UHD Graphics (32.0.101.7088) |
| Default browser | Firefox - http/https UserChoice = FirefoxURL-308046B0AF4A39CB |
| Security software | Bitdefender GravityZone; CyberGhost VPN |

Things I ruled out (all checked live, not assumed)

• Windows link handling is healthy. Start-Process 'https://example.com' from outside the app opens Firefox cleanly - no picker, no crash. A default browser is correctly registered for both http and https.
• Not the app-picker path. PickerHost.exe does crash on this machine (5 times, exception 0xc0000409 inside Intel's igd10um64xe.DLL v32.0.101.7088), but that is a separate Intel-driver defect and the picker never appears for a link click here.
• Not a stale or corrupt install. A clean reinstall from the official installer on 2026-08-28 at 00:03 delivered the same 1.37937.3.0 and the crash returned within ten minutes.
• Not fixed by re-registering. Add-AppxPackage -Register with ForceTargetApplicationShutdownOption completed successfully at 00:19:54 and the crash persisted.
• Not third-party interference. 134 modules in the crashed process: 132 Windows, 2 Claude, 0 anything else.

Note on the duplicate suggestions

GitHub flagged #60480, #88719 and #88971. All three are Claude Desktop on Windows/MSIX, and #88719 in particular matches the "Crashpad writes minidumps but nothing reaches the Windows log" behaviour exactly. None of them contains a parsed dump, an exception code, or a faulting offset - that is what this report adds. If you would rather fold this into one of those, please say which and I will move the analysis there.

Both #88719 and #60480 were closed as invalid / not-related-to-Claude-Code. If desktop-app bugs belong somewhere other than this tracker, please point me at it - I could not find another public channel.