Windows desktop app crashes with "Another program is currently using this file" under high concurrent-session memory pressure

Summary

The Windows desktop app (MSIX install under C:\Program Files\WindowsApps\Claude_1.40609.0.0_...) intermittently crashes/hangs with a Windows error dialog:

Another program is currently using this file.

This has happened more than once on the same machine during a single long-running session, disrupting an active workflow.

Circumstances observed at time of crash

• Version: Claude_1.40609.0.0 (path visible in the crash dialog title bar)
• OS: Windows 11 Home 10.0.26200
• Concurrency: 13 separate claude processes running simultaneously at the time of the crash (multiple Claude Code windows/sessions open on the same machine)
• System memory pressure: only ~2 GB free out of 13.8 GB total physical RAM at the time (~85% utilized) - the 13 claude processes alone totaled ~2.7 GB combined working set, alongside other heavy applications (browser with 7+ processes, Discord, WSL vmmem) also consuming several hundred MB each
• This machine has a documented history of chronic RAM pressure from routinely running many concurrent Claude Code sessions (this is not a one-off environment quirk)

Hypothesis (not confirmed - no visibility into app internals)

Under this kind of severe, sustained memory pressure with many concurrent instances of the app running, some shared file the app touches (e.g. an update check, log file, or shared session/state file) appears to hit a file-lock conflict between instances, surfacing as this crash dialog rather than a graceful retry/backoff or a more specific error message.

Impact

Interrupts whatever session/window hit it - in this case, a long-running task had to be picked back up manually after the crash. Reported by the user as recurring ("crashed again"), not an isolated incident.

Ask

• Investigate whether concurrent instances on the same machine can contend for a lock on a shared file (update-related or otherwise) under memory pressure, and whether that can degrade gracefully (retry/backoff) instead of a hard crash.
• If there's a known safe limit on concurrent local instances/sessions per machine given typical memory footprint, documenting that would help users avoid this proactively.