[BUG] [Windows] Local agent / claude code session hangs on endless loading spinner — spawn EBUSY on bundled claude.exe, triggering an infinite re-download loop

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?

Regular chat works perfectly. Only local agent mode (Code / Cowork) is broken. Starting a new local session shows an endless loading spinner and never connects.

The underlying cause is that the app fails to launch its own bundled claude.exe binary with Error: spawn EBUSY. Because the spawn fails, the binary's .verified marker is never written, so on the next session the app assumes the binary is bad and re-downloads and re-installs the entire ~243 MB binary which then fails to spawn again. This is a self-perpetuating loop; the session never gets a first response (hadFirstResponse=false).

Critically, the binary itself is not corrupt: running it manually from a terminal works fine (see below). The failure only happens when the app spawns it.

Environment

OS: Windows 11 Pro (x64)
Claude Desktop app version: 1.12603.1
Bundled Claude Code version: 2.1.170
Node (bundled): 24.16.0
Antivirus: Windows Defender only (no third-party AV installed)
Account type: Organization / Team account
Working directory for the session: a normal local folder on a local drive (not a network/synced/OneDrive path)

What Should Happen?

The local session should launch the bundled claude.exe, connect, and be ready to read/write files in the working directory without an endless spinner, and without re-downloading the binary on every attempt.

Actual behavior

The session spinner hangs forever. The log shows spawn EBUSY on the bundled binary, followed by a full re-download/re-install of the binary, repeating on every session attempt.

Error Messages/Logs

Spawn failure (repeats every session attempt):
[warn] [CCD] Binary preflight: .verified marker missing but binary exists at
  <home>\AppData\Roaming\Claude\claude-code\2.1.170\claude.exe. Proceeding with spawn.
[error] Failed to get commands from temporary query {
  error: Error: spawn EBUSY
      at ChildProcess.spawn (node:internal/child_process:441:11)
      at Object.spawn (node:child_process:810:9)
    code: 'EBUSY',
    syscall: 'spawn'
}
[error] Failed to get agents from temporary query {  error: Error: spawn EBUSY ... }

Session shell starts but the agent never responds:

[info] LocalSessions.startShellPty: sessionId=<blob>, cols=80, rows=24
[info] [CCD CycleHealth] healthy cycle for <blob> (1s, hadFirstResponse=false)

Immediately after each failed spawn, the full binary is re-downloaded and re-installed (the loop):

[info] [CCD] Downloaded file size: 242929824 bytes, transferred bytes: 54661611 bytes (expected: 54661611)
[info] [CCD] Verifying checksum
[info] [CCD] Installed at <home>\AppData\Roaming\Claude\claude-code\2.1.170\claude.exe

Secondary errors observed in the same sessions — Claude's own child processes being terminated externally:

[error] Network Service process gone (reason=killed, exitCode=1) outside app quit —
  main-process networking is broken until relaunch
[error] Sentry caught: { type: 'Unknown', value: "'Utility' process exited with 'killed'" }

Proof the binary itself is healthy

Running the exact same binary manually from a terminal succeeds and prints a version:

> & "$env:APPDATA\Claude\claude-code\2.1.170\claude.exe" --version
2.1.170 (Claude Code)

Steps to Reproduce

Open the Claude Desktop app on Windows (chat works normally).
Start a new local agent / Code / Cowork session pointed at a local folder.
The session shows a loading spinner indefinitely and never produces a first response

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.177

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Troubleshooting already attempted (none resolved it)

Fully quit the app and ended all claude.exe / Claude.exe processes in Task Manager; relaunched.
Deleted the entire %APPDATA%\Claude\claude-code\ folder it re-downloads, then fails identically.
Added Windows Defender exclusions for all of: the file ...\claude-code\2.1.170\claude.exe, the folder %APPDATA%\Claude, the folder %LOCALAPPDATA%\AnthropicClaude, and the process claude.exe. EBUSY still occurs, which suggests the standard Defender scanner is not the locker.
Confirmed no third-party antivirus is installed (Windows Defender only).
Confirmed the working folder is on a local drive (not network/OneDrive/Dropbox).
Verified the binary runs fine when launched manually (see above).

Workarounds that DO work

Cloud sessions connect normally (they don't spawn the local binary) but cannot read/write local files, so this isn't viable for local file work.
Installing Claude Code as a standalone CLI (native installer / npm) runs locally and writes to the project folder, bypassing the desktop app's bundled binary entirely.

Suspected root cause / notes for maintainers

The combination of (a) spawn EBUSY immediately after the app's own install step, (b) the binary running fine when launched manually, and (c) the .verified marker never being written, which forces a full re-download every session strongly suggests an app-side race condition: the binary is spawned before the install/write handle is released (or before a scan window clears), the verification consequently fails, and the app falls into an infinite reinstall loop instead of retrying the spawn or trusting the already-installed, checksum-verified binary.

Suggested fixes to consider:

After install, retry the spawn with a short backoff on EBUSY instead of failing outright.
Write the .verified marker based on the successful checksum verification (which already passes) rather than on a successful spawn, so a transient EBUSY doesn't trigger an endless re-download loop.
Add a process guard so repeated failed attempts don't accumulate/kill helper processes.

Happy to provide the full main.log on request.