[BUG] Claude Desktop 1.3883.0 — repeated renderer crashes on Windows 11 x64 (BuddyBleTransport `No handler registered`)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported for Windows x64
• [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?

Claude Desktop renderer crashes repeatedly on Windows 11 x64 with version 1.3883.0. Five crashes observed over twelve hours of active use, three of them within one single hour. Every crash correlates 1:1 with the same BuddyBleTransport_$_reportState IPC error as the existing macOS-reported issue #48281.

Filing this as a separate Windows-specific report per Anthropic Support's recommendation — #48281 is currently labeled platform:macos only, which hides Windows reports from anyone searching.

What Should Happen?

Claude Desktop should launch without the renderer taking down the UI every ~1–3 hours of use.

Error Messages/Logs

Recurring error in %APPDATA%\Claude\logs\claude.ai-web.log:

[error] Uncaught (in promise) Error: Error invoking remote method
'$eipc_message$_<uuid>_$_claude.buddy_$_BuddyBleTransport_$_reportState':
Error: No handler registered for '...BuddyBleTransport_$_reportState'

Crash timestamps (local time), each followed by a cleanupVMBundleIfUnsupported sequence in cowork_vm_node.log:

2026-04-23 22:11:32
2026-04-24 00:43:56
2026-04-24 01:11:22
2026-04-24 09:23:09
2026-04-24 09:30:13

Steps to Reproduce

1. Install/upgrade Claude Desktop to 1.3883.0 on Windows 11 x64 (not ARM64).
2. Sign in to a Max plan account, open Cowork / Code.
3. Use actively (chat, file edits, MCP tools) for 30–90 minutes.
4. Renderer crashes — UI freezes / white-screens / reloads. claude.ai-web.log receives the BuddyBleTransport_$_reportState entry at the same moment.

Reproduces consistently under normal workload. No specific user action seems to trigger it — the IPC call happens from renderer-side initialization / polling.

Diagnostic findings (Windows-specific)

| Check | Result |
|---|---|
| Crashpad/reports/ | empty — Electron does not dump renderer crashes of this kind |
| Windows Application Event Log | no claude.exe Application Error / WER entries in 24h — not a hard OS-level crash |
| Hyper-V, HypervisorPlatform, VirtualMachinePlatform | all enabled — virtualization stack not the cause |
| yukonSilver not supported in cowork_vm_node.log | unrelated — feature intentionally disabled on this config |
| Wall-clock vs crash correlation | 1:1 with each BuddyBleTransport_$_reportState log entry |

Workaround (confirmed working)

Downgrading to 1.3561.0 eliminates the crashes completely. Squirrel preserves previous builds under %LOCALAPPDATA%\AnthropicClaude\app-*\:

Get-Process -Name "claude" -ErrorAction SilentlyContinue | Stop-Process -Force
& "$env:LOCALAPPDATA\AnthropicClaude\app-1.3561.0\claude.exe"

Squirrel will silently auto-upgrade back to 1.3883.0 eventually, so this workaround is not permanent.

Pattern (cross-reference)

This is the same class of bug as:

• #48281 — primary macOS report, OPEN. I posted a Windows confirmation there before filing this separate report: #48281 (comment).
• #48261 — same BuddyBleTransport_$_reportState error co-occurring with V8 OOM on macOS 1.2581.0. OPEN but labeled invalid.
• #37346 — identical "No handler registered" pattern on Windows 1.1.7714.0 with a different handler (ComputerUseTcc_$_getState), closed as stale without structural fix.

The common root cause in all four: the renderer bundle calls an IPC method that the main process never registers → unhandled promise rejection → renderer process dies.

Request

1. Acknowledge the Windows platform scope of the BuddyBleTransport_$_reportState bug (either in this issue or by expanding #48281's labels to include platform:windows).
2. Either register the missing IPC handler in main, or gate the renderer call-site behind a typeof handler === 'function' / feature-flag guard so a missing handler becomes a no-op instead of a crash.
3. Document how to pin Claude Desktop to an older working version (disable Squirrel auto-upgrade for a specific installation) as a temporary mitigation for affected Windows users.

Claude Model

Not applicable (Desktop binary crash, not a model issue)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.3561.0

Claude Code Version

Claude Desktop 1.3883.0 (Windows 11 x64 build, not ARM64)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

N/A (Desktop app, not CLI)

Additional Information

I can provide the full log bundle (claude.ai-web.log, main.log, cowork_vm_node.log — scrubbed of session-ID UUIDs) on request. Support ticket also filed via support@anthropic.com referencing this issue and #48281.