Desktop app auto-update silently terminates long-running child processes started from a session

Summary

On Windows, the Claude desktop app updates itself in place (MSIX) with no consent prompt and
no warning, and the deployment's TerminateApplications step force-closes every process in
the app's process tree — including long-running jobs that a Code session started on the
user's behalf. The session is torn down at the same moment, so nothing reports the loss:
neither the app, nor the session transcript, nor any Windows log that is enabled by default.

In my case this silently aborted an overnight compute batch. It took several hours of event-log
forensics to establish that the app update was the cause, because the observable symptom
(a process disappearing) happened two hours after the actual kill.

Environment

• Windows 11 Pro 26200, desktop (always on AC; sleep/hibernate disabled)
• Claude desktop app, Code tab; Claude_1.40609.1.0_x64__pzs8sxrjxfjjc → 1.44121.2.0 → 1.44121.4.0
• claude-code 2.1.258

What happened

A long-running batch (powershell.exe -NoProfile -File run_batch.ps1, driving a compute job in a
loop) was launched from the session with:

Start-Process -FilePath 'powershell.exe' -ArgumentList '-NoProfile','-File','<script>' -WindowStyle Minimized

Timeline, all from Windows logs:

| local time | evidence | event |
|---|---|---|
| 00:17:28 | batch log; WER AppSessionGuid | batch PowerShell starts, PID 3192 |
| 02:34:01 | Application 7040/7045 | Claude service start type → disabled, new service installed |
| 02:34:01 | WER AppHang_powershell.exe, EventType=AppHangB1, ConsentKey=AppHangXProcB1, "stopped responding and was closed" | the batch PowerShell is force-closed |
| 02:34:02 | C:\Windows\appcompat\pca\PcaAppLaunchDic.txt | Claude_1.44121.2.0\app\claude.exe launched |
| 04:41:35 | Microsoft-Windows-AppModel-Runtime/Admin 217 | the orphaned child process finishes its work and exits |
| 11:22:12 | PCA launch log | app updates again → 1.44121.4.0 |

The WER report's AppSessionGuid (00000c78-…) decodes to PID 3192 with start time
00:17:28.018, which matches the batch's own first log line exactly — so the process the
update killed is unambiguously the job the session had started.

Start-Process is not a detach on Windows: the new console is still a descendant of the
tool shell, so it is inside the package's process tree and gets terminated with it.
ConsentKey=AppHangXProcB1 confirms the close was requested by another process (the
deployment), not a self-inflicted hang.

Impact

• ~5 hours of compute lost, and the failure is silent: the driver script died mid-loop with no

error line, no exit code, no entry in the session transcript.

• Two app updates in twelve hours, so this is not a rare event for anyone who runs overnight work.
• The child process happened to survive (it runs in its own Desktop AppX container), so it kept

running orphaned for two more hours and then exited normally. That later, innocent timestamp is
what a user sees as "the process vanished", pointing the investigation two hours away from the
real cause.

• Windows keeps very little by default here: Microsoft-Windows-TaskScheduler/Operational is

disabled and process-creation auditing is off, so without the WER AppSessionGuid and the
AppX container create/destroy events there would have been nothing to go on at all.

What I would expect

Any of these would have prevented the loss, roughly in order of preference:

1. Do not auto-update while a session has running background work. Defer until the app is idle,

or until the user accepts.

1. Ask for consent (or at least allow "update on next restart" / "remind me later"). Right now

the update just happens; there is no setting I could find to defer or disable it.

1. Do not terminate descendant processes on update — let jobs the user started outlive the

app restart.

1. Report it. If processes are terminated, say so: a notice in the session ("your background

job was terminated by an app update") turns a multi-hour mystery into a one-line message.

Even (4) alone would be a large improvement — the core problem is not that a process died, it is
that nothing anywhere said so.

Note

There is a workaround (launch such jobs from a Windows Scheduled Task so the Task Scheduler
service is the parent, outside the app tree), but it is not discoverable, and users will
reasonably assume that a job started with Start-Process from a session is independent of the
app that started it.