[BUG] Auto-update force-quits the working desktop app again: session child processes killed (exit 127), Remote Control dropped, app unlaunchable until reboot - why is there still no user-chosen update timing?
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?
The desktop app was force-quit by its own auto-update while I was actively working. This is not a one-off: the same class of failure has been reported repeatedly (see Related issues), and the request to let users choose update timing (#61582) was auto-closed as stale by a bot, not answered.
What it cost me today: the session I had been running continuously since 2026-09-02 disappeared from my phone (Remote Control), the local dev server that Claude Code itself had started died silently four times, and after the forced update the app would not launch at all, so I had to reboot the machine.
Timeline (2026-09-23, all verified in Windows Event Log)
| Time | What happened |
| --- | --- |
| 04:20 | Update 2.2553.13 staged. AppXDeploymentServer: "the package was not updated because the affected app is still running" -> registration deferred |
| 11:40 | Update 2.7032.0 staged. Deferred again for the same reason |
| 14:57 / 15:08 / 15:15 / 15:33 | The dev server (a child process started by the session) died four times with exit code 127. No error, no message |
| 15:43:42 | Register with ForceApplicationShutdownOption - the running app and its services (CoworkVMService) were force-terminated and 2.7032.0 was applied |
| 16:45:45 | Register with ForceTargetApplicationShutdownOption + RepairAppRegistrationOption (consistent with the app failing to start) |
| 16:46 | I rebooted the PC myself. The app would not come back any other way |
| 16:48 | App finally started on 2.7032.0 |
Why this is worse here than in other software
Claude Code is not a chat window. A session runs for hours or weeks, and it owns child processes: dev servers, test runners, builds. When the app is killed, all of that dies with it, and there is no record of why - the child just exits with code 127.
I run heavy desktop tools (for example Fusion 360). They have crashed on me for hardware reasons, but never because of an update. They show a notice and let me install when I am ready. This app is the only one that closes itself while I work.
Yes, this is an MSIX/Store package and Windows drives the forced shutdown once deferral runs out. That is an explanation, not a defence: Anthropic chose that packaging, and Anthropic is responsible for not losing user work on top of it.
Related issues (this overlaps them on purpose - the pattern is the point)
- #61582 - "Relaunch to update" applies immediately, no changelog, no confirmation, no defer. Closed as not planned by a stale bot.
- #69270 - update notification should not interrupt active sessions.
- #91786 - auto-update silently terminates long-running child processes started from a session.
- #95491 - Remote Control is not restored for sessions killed by a stealth update.
- #89680 / #92167 / #89599 - after a stealth update the app is unlaunchable until reboot.
What Should Happen?
- Ask before updating. Show that a new version is ready and let me choose when to restart. Never force-quit a running app, not even as a last resort after N deferrals.
- Defer while work is in flight. If a session is running, or child processes (dev server, tests, build) are alive, or Remote Control is serving a session, do not apply the update. The app already knows all three - it logs "Skipping pause for session ... - remote control is active".
- Recover if it does happen. After an update the app must relaunch on its own, restore sessions, and re-attach Remote Control. A user should never have to reboot the machine to get the app back.
- Leave a trace. If a child process was killed by the update, say so. Today the only evidence was exit code 127 and I had to read Windows event logs to find the cause.
Error Messages/Logs
Windows Event Log - Microsoft-Windows-AppXDeploymentServer/Operational
04:20:20 638 the package was not updated because the affected app is still running. Running app: {Claude_pzs8sxrjxfjjc!Claude}
11:41:00 638 (same deferral, for 2.7032.0)
11:41:00 658 {Claude_2.2553.1.0_x64__pzs8sxrjxfjjc} is still running, so package {Claude_2.7032.0.0_x64__pzs8sxrjxfjjc} registration was deferred
15:43:42 603 Deployment RegisterByPackageFamilyName with ForceApplicationShutdownOption
15:43:43 9650 Terminated service Claude_2.2553.1.0_x64__pzs8sxrjxfjjc in package CoworkVMService
16:45:45 603 Deployment Register with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption
16:45:46 649 Trying to repair ACLs for C:\Program Files\WindowsApps\Claude_2.7032.0.0_x64__pzs8sxrjxfjjc
System log: no sleep or resume events at all (Kernel-Power 42/107 absent). The machine ran continuously until my own reboot at 16:46, so this was not a sleep/hibernate artifact.
Claude Code background task output for the dev server the session had started - identical four times (14:57, 15:08, 15:15, 15:33):
> story-maker@0.1.0 start
> node scripts/withFonts.js server.js
no pending migrations
story-maker server listening on port 3100
[exited with code 127]
No other error was recorded anywhere. Exit code 127 was the only trace.Steps to Reproduce
- On Windows 11 with the Store (MSIX) build of the Claude desktop app, open a Code session and start a long-running child process from it, e.g. a dev server ("npm start", port 3100).
- Turn Remote Control on for that session and confirm it is visible from the phone.
- Leave the app running while a new version is published. Windows stages it and defers registration because the app is running ("the affected app is still running").
- Wait until the deferral limit is reached. The update is applied with ForceApplicationShutdownOption.
- Observe: the app is force-quit; the child process dies with exit code 127 and no explanation; the session disappears from the phone; the app does not come back; a reboot is required.
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.258 (Claude Code)
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment: Windows 11 Pro 10.0.26200 (build 26200), Claude desktop 2.2553.1 -> 2.7032.0 (MSIX / Microsoft Store), Claude Code 2.1.258, session running since 2026-09-02, Remote Control on.
From the user who hit this (quoted as said):
"업데이트 하면 강제로 닫게 하는 건 잘못된 거 아니야. 사용자들에게 물어보고 업데이트할지, 타이밍과 소통을 도입해서 업데이트를 진행해야 할 거 아니야." ("Force-closing the app to update is simply wrong. Ask users first, and introduce timing and communication, so people can update when it suits them.")
"너희처럼 데스크탑 앱이 자주 강제 종료되는 소프트웨어는 처음이다. 3D 툴도 업데이트로 다운되는 경우는 한번도 없었고, 필요한 업데이트는 항상 공지 줄을 띄워 사용자가 직접 하도록 안내한다." ("I have never used software whose desktop app force-quits this often. Even heavy 3D tools never went down because of an update - they show a notice and let the user do it.")
"MS 핑계 댈 문제가 아니다." ("Do not blame Microsoft for this.")