[BUG] Windows x64: "Restart to update" cannot restart — Notification Area instance holds the single-instance lock (ref #42776)

Summary

On Windows x64, Claude Desktop's "Restart to update" cannot complete, because Claude runs in the Notification Area and that background instance is still holding the single-instance lock when the updater relaunches. The relaunch loses the race and shows "Another copy of Claude is already running."

This is a catch-22: the only control that triggers the update lives inside the app that has to fully exit for the update to land. The user cannot quit first (the button disappears with the app), and clicking the button does not quit the background instance.

Same underlying orphaned-process behaviour as #42776 (open), and related to #61635 (ARM64, closed as invalid). Filing against x64 with the app's own strings as evidence.

Environment

• Claude Desktop 1.34493.1.0, x64, MSIX package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
• Windows 11 Pro 26200
• Notification Area mode enabled (the default state on this install)

Steps to reproduce

1. Have Claude Desktop running with "Claude runs in the Notification Area" enabled.
2. Wait for an update to be staged (it downloads automatically).
3. Click "Restart to update to \<version\>".
4. The window closes; the app attempts to relaunch.

Expected: the app fully exits, the staged package activates, the app reopens on the new version.

Actual: relaunch fails with "Another copy of Claude is already running" / "Please quit the other copy of Claude and try again." The app is unreachable until the user right-clicks the tray icon and chooses Quit, or reboots.

Evidence

The app's own string table (app\resources\en-US.json in the installed package) documents both halves of the conflict:

"xJs1jZ8PoA": "Claude runs in the background even when you close the window.
               Click the Claude icon in the tray to reopen the app, or right-click to quit."
"W1pELwt/+a": "Claude runs in the Notification Area"
"hzKMHWvM80": "Restart to update to {updateVersion}"
"/eO5H6Jz2q": "Another copy of Claude is already running"
"SEE6jniXQK": "Please quit the other copy of Claude and try again."
"RIl6xxcojL": "Claude was restarting"

The presence of "Claude was restarting" suggests this relaunch path is already known to be able to fail.

What is NOT the cause

Worth stating explicitly, because it consumed a lot of diagnostic time and #61635 raises it:

CoworkVMService and the MSIX package lock are not the blocker on x64. Windows terminates packaged services for updates on its own. From Microsoft-Windows-AppXDeploymentServer/Operational during a successful update on this machine:

9648  0x0: TerminateSingleService for update successful for service ... in package CoworkVMService, terminateService: true
9650  0x0: Succesfully terminated service ... in package CoworkVMService
400   Deployment Register operation on Package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc from: (AppxManifest.xml) finished successfully

The package update itself succeeds. The failure is purely the app-level single-instance check afterwards.

Also note that sc.exe config CoworkVMService start= demand is impossible as a user workaround — the packaged service's DACL grants Authenticated Users start/stop only, has no Administrators ACE, and grants DC (change config) solely to the service's own SID:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...)

It returns OpenService FAILED 5: Access is denied even from an elevated prompt.

Workarounds

• Recovery after the error: right-click the Notification Area icon → Quit, then launch Claude. The staged update applies. A reboot is not required.
• Avoid entirely: don't click "Restart to update." Since updates download and install automatically, simply quitting via the tray and relaunching picks up the new version.
• Prevention: disable "Claude runs in the Notification Area", so closing the window actually exits the process.

Note that force-killing claude.exe after clicking "Restart to update" does not help — the app is in a pending-restart state and relaunches itself, which reads to users as the process "coming back on its own" and drives them to reboot.

Suggested fix

Have "Restart to update" perform a genuine full application quit — including the Notification Area instance — and wait for the single-instance lock to be released before relaunching, rather than closing the window and immediately racing the still-resident process.

Related

• #42776 — same orphaned-process-holds-lock behaviour on relaunch (open)
• #61635 — ARM64 variant with a deeper AppContainer/AppInfo root cause (closed as invalid)
• #51847 — "Another program is currently using this file" after update