Windows "Claude" service (cowork-svc.exe) installs/disables itself 7x in 67 minutes during MSIX auto-update, ends in "file in use" error on relaunch

Status Open
Reported on v2.1.241
Maintainer reply None cached
Activity 1 comment · opened Aug 26, 2026

Environment

  • OS: Windows 11 Pro
  • Install method: MSIX package (Claude_pzs8sxrjxfjjc)
  • Version before incident: 1.37937.0.0
  • Version after incident: 1.37937.1.0
  • Bundled claude-code binary observed being rewritten during the same

window: claude-code\2.1.241\claude.exe (322 MB), written at 09:40:56 local

Summary

During what appears to be a routine background auto-update
(1.37937.0.01.37937.1.0), the Windows Service named "Claude"
(service binary app\resources\cowork-svc.exe, inside the MSIX package
path) was installed and then had its start type set to "disabled"
seven times in 67 minutes, with one of those cycles following a
confirmed unexpected service termination. Shortly after, relaunching the
app failed with:

"Há um outro programa usando este arquivo no momento" ("Another program is currently using this file"), pointing at C:\Program Files\WindowsApps\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\...

Evidence (Windows Event Log, System log, Service Control Manager provider)

All timestamps local, captured via Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'}:

| Time | Event ID | Detail |
|---|---|---|
| 09:36:41 | 7045 / 7040 | Service "Claude" installed (package ...1.37937.0.0...), then disabled |
| 09:36:50 | 7045 / 7040 | Same cycle repeats 9s later |
| 10:15:58 | 7045 / 7040 | Service reinstalled — package path now shows 1.37937.1.0 (version already swapped) |
| 10:19:25 | 7045 / 7040 | Cycle repeats |
| 10:19:42 | 7034 | "The Claude service terminated unexpectedly. This has happened 1 time(s)." |
| 10:19:47 | 7045 / 7040 | Cycle repeats |
| 10:25:51 | 7045 / 7040 | Cycle repeats |
| 10:28:34 | 7045 / 7040 | Cycle repeats |
| 10:43:40 | 7045 / 7040 | Cycle repeats |

Total: 7 install-then-disable cycles for the "Claude" service between
09:36 and 10:43, one confirmed crash (event 7034) in the middle of that
window.

Additional correlated evidence from the same machine, same window:

  • %LOCALAPPDATA%\CrashDumps\ActivationNotifier.exe.11492.dmp (27.6 MB)

generated at 09:44:55 — a Windows AppX-activation-related component
crashing minutes after the service cycling started.

  • %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json

rewritten at 09:40:34, and
...\claude-code\2.1.241\claude.exe (322 MB) written at 09:40:56 —
consistent with the update writing a large binary payload right before
the service cycling began.

  • No Application Error (Event ID 1000) or Windows Error Reporting

(Event ID 1001) entries mention claude anywhere in the 25-26 Aug
window, despite 689 unrelated 1000/1001 events existing in the same
window — so this is not a hard-fault/unhandled-exception crash of the
main Electron process itself.

  • Crashpad\reports\ (the app's own native crash-dump folder) is empty

for the period, and the local Sentry error queue
(sentry\queue\queue-v2.json) is empty too.

  • The app's own log files (logs\main.log, claude.ai-web.log,

ssh.log, unknown-window.log, cowork_vm_node.log) all stopped
being written on 21 Aug, five days before this incident, so they
do not cover the window and could not be used to see what the process
was doing internally.

Impact

The app became unrelaunchable for a period after the update, blocked by
a file-in-use error against its own package directory. Whatever holds
the file handle during this service-cycling window (the updater, the
service manager, or a stale cowork-svc.exe instance) appears to
prevent a clean relaunch until it releases on its own.

What I could not determine

  • Which process specifically held the file handle at the moment of the

"file in use" error — would need a live capture (e.g. Sysinternals
handle.exe) taken during the incident, which I did not have
running at the time.

  • Whether the service-cycling pattern itself is the intended update

mechanism working as designed (just unusually chatty) or a bug in how
the Cowork feature (cowork-svc.exe) re-registers itself during an
update.

Ask

Could someone from the team confirm whether 7 install/disable cycles of
the "Claude" service in ~67 minutes during a single auto-update is
expected, and whether the "file in use" relaunch failure is a known
side effect? Happy to provide the raw Get-WinEvent export if useful.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗