[BUG] Windows Desktop update blocks relaunch with 0x80070020 while background project processes retain the old AppX container

## Summary

After Claude Desktop updated to `Claude_1.49585.0.0_x64__pzs8sxrjxfjjc`, the new version would not launch. The dialog said only:

```text
Another program is currently using this file.
```

Windows logged the actual failure in `Microsoft-Windows-AppModel-Runtime/Admin` at 16:29:36 CDT on 2026-09-09:

```text
Event 215: 0x80070020: Cannot create the Desktop AppX container for package
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Event 208: 0x80070020: Cannot create the process for package
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
```

The main `Claude.exe` was **not** running. An elevated, read-only query of the **previous** package's user container job (`\Container_Claude_1.34493.1.0_x64__pzs8sxrjxfjjc-`) showed it was still alive with **18 member processes** — all background helpers from long-running project work started between Aug 27 and Sep 2: an `ssh` file-existence check, five `tail` log readers with their `grep` filters, a `nohup → pythonw → pythonw` status-monitor chain, three orphaned Python `multiprocessing` workers (parent PID gone), and a `conhost`.

Stopping the abandoned members and relaunching the one functioning monitor **outside** the old container let Windows destroy that container (**Event 217**, 16:39:38), after which the new version launched normally (**Event 201**, 16:40:08) — **no reboot**. All 25 unrelated Python processes recorded before cleanup were still present afterwards.

This is the same signature as #73107 and #91763. The blocking set here was ordinary project daemons rather than elevated descendants (#73107) or the git fsmonitor daemon (#91763) — ten detached `git fsmonitor--daemon` processes were also present on this machine and **none** of them was in the old container.

## Why this matters

> "that is literally all i use claude desktop for. long running projects"

The affected user's primary workflow is long-running project work driven from Claude Desktop. Every update has required a full Windows reboot to recover. A fix that indiscriminately kills all descendants would destroy legitimate running work; a workaround of "reboot after each update" interrupts everything else on the machine. The recovery below is a one-incident repair, not a fix.

## Environment

| Item | Observed |
|---|---|
| OS | Windows 11 Pro 25H2, build 10.0.26200.9168 |
| Last Windows boot | 2026-08-23 22:29:58 CDT |
| Installed package at failure/recovery | `Claude_1.49585.0.0_x64__pzs8sxrjxfjjc` (status `Ok`) |
| Older package whose user container survived | `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc` |
| Package family / AppId | `Claude_pzs8sxrjxfjjc` / `Claude_pzs8sxrjxfjjc!Claude` |
| Packaged service | `CoworkVMService` (`cowork-svc.exe`), in its own `-PackagedService` container |
| Install location | `C:\Program Files\WindowsApps` (packaged install; store vs direct channel not established) |

The two versions above are the installed version and the observed retained version; a single direct update between exactly those two was not established.

## Evidence: members of the retained old container

Opening the job from an ordinary user context returned `0xC0000022` (access denied); an elevated `JOB_OBJECT_QUERY` succeeded. `Assigned=18`.

| Process | Count | Role |
|---|---:|---|
| `ssh.exe` | 1 | remote file-existence check, started Aug 27 |
| `tail.exe` | 5 | log readers, started Aug 28 – Sep 2 |
| `grep.exe` | 5 | filters attached to those readers |
| `nohup.exe` | 1 | wrapper for a project status monitor |
| `pythonw.exe` | 2 | venv launcher → actual monitor (functioning) |
| `python.exe` | 3 | `multiprocessing` spawn workers; parent PID 87464 no longer existed; 0 CPU/IO delta over 2 s; 110 threads all waiting |
| `conhost.exe` | 1 | console host whose parent PID 34660 no longer existed |

Neither a running `Claude.exe` nor a `GetPackageFullName` scan identified these — package identity on the process was not the tell; **membership in the old container's job object** was.

## Recovery performed (this incident only)

1. Recorded name / PID / creation time for each target; re-verified identity before each stop (PID-reuse guard).
2. Stopped the old `ssh` check and `tail` readers (their `grep` filters exited on EOF).
3. Stopped the three orphaned `multiprocessing` workers (the old `conhost` exited with them).
4. Stopped the monitor chain, then relaunched the same monitor script, same venv, same working directory, hidden, **outside** the old container.
5. Retried activation.

| Time (CDT, 2026-09-09) | Event |
|---|---|
| 16:29:36 | Events 215 / 208 — new version fails, `0x80070020` |
| ~16:35:11 | elevated job query: 18 members in the old user container |
| ~16:39:02–16:39:16 | targeted cleanup; monitor relaunched detached |
| 16:39:35.798 | an early relaunch retry **still failed** — teardown not yet complete |
| **16:39:38.672** | **Event 217: old user container destroyed** |
| **16:40:08.853** | **Event 201: new-version process created** (`Created process 110620 for application Claude_pzs8sxrjxfjjc!Claude`) |
| later | window `Claude`, `Responding=True`; all 25 unrelated Python processes still present; monitor still producing output ~90 min later |

Not done: terminating the whole job, killing all Python, reinstalling, resetting app data, or rebooting.

Note the retry that failed **three seconds before** Event 217 — recovery/retry logic should confirm old-container teardown rather than concluding cleanup failed.

## What is established, and what is not

**Established for this incident:** background project processes kept the obsolete user container alive after the app closed and a newer package was installed; new-version activation failed at container/job setup; removing the abandoned members and relocating the live one allowed teardown and a clean launch without reboot. The membership query → Event 217 → Event 201 chain is much stronger evidence than the generic file-in-use dialog.

**Not established:** the updater code path / launch flags that leave descendants in the old container; when each descendant became orphaned; a historical failure rate (only this incident was instrumented); that any single member was individually sufficient; that `CoworkVMService` played a role; that future updates are safe.

## Requested investigation

1. **Background-process lifetime across updates** — why do project descendants stay attached to an obsolete, version-specific container, and why does that block new-version activation?
2. **Update scheduling that respects running work** — a supported way to defer applying an update when it would strand the app or interrupt project processes. UI idleness is not proof that project work has ended.
3. **Preservation of legitimate jobs** — a supported launcher/worker model where intended long-running work survives an update and stays manageable.
4. **Targeted recovery** — detect a retained old container, enumerate its actual members, distinguish abandoned helpers from live tasks; do not silently terminate all descendants.
5. **Actionable diagnostics** — tell the user a previous Claude environment is still held by background processes, name them where possible, and offer a safe recovery or deferral. The current dialog points at a vague file lock.
6. **Completion-aware retry** — confirm teardown before retrying activation.

## Suggested regression scenarios

- Update while a genuine long-running process is active
- Update after the main UI exits but an intended monitoring daemon remains
- Orphaned `tail` / `grep` log followers
- Python `multiprocessing` children whose parent has exited
- venv launchers, `pythonw`, `nohup`, `conhost` descendants
- Detached `git fsmonitor--daemon` (as in #91763)
- Elevated and non-elevated descendants
- Multiple package versions accumulated without a reboot
- Delayed container teardown after the last member exits
- A packaged-service container coexisting with an old user container

## Questions

- Is this failure mode tracked internally, and can this evidence be attached to it (and correlated with #73107 / #91763)?
- What is the supported recovery that preserves legitimate active jobs?
- Is there a supported update-deferral / maintenance-window option for an individual Desktop user?
- What bounded diagnostics would help on the next occurrence?
- Can a fixed build be tested against the scenarios above?

## Diagnostic method (read-only)

Enumerate the NT object-manager root with `NtOpenDirectoryObject` / `NtQueryDirectoryObject`; find names beginning `Container_Claude_`; open the exact job with `NtOpenJobObject` requesting only `JOB_OBJECT_QUERY (0x0004)` (needs elevation here); `QueryInformationJobObject(JobObjectBasicProcessIdList)`; resolve PIDs to names / creation times / parents; close handles promptly. This avoids inferring membership from process names or `GetPackageFullName`, both of which missed the blockers here. The incident-specific cleanup script is deliberately not included as a reusable kill command.

Account SID, home paths, remote-host identity, and project contents are omitted. Package IDs, PIDs, event record numbers, and timestamps are retained for correlation.

Full forensic report (verbatim, prepared 2026-09-09)

# Claude Desktop Windows update failure: old app container retained by background project processes

**Report date:** September 9, 2026
**Status:** Current incident recovered without a PC restart; recurring updater defect remains unresolved.
**Suggested issue title:** Windows Desktop update blocks relaunch with 0x80070020 while background project processes retain the old AppX container
**Evidence source:** Live inspection and recovery on the affected computer by Codex, plus the user's description of recurrence.
**Submission status:** This document has been prepared for the user. No feedback or support case was submitted during its preparation.

## Request to Claude

Please help me get this report to the appropriate Anthropic Desktop engineering or Product Support team.

My primary use of Claude Desktop is long-running projects. A recommendation to avoid long-running projects, or a fix that indiscriminately kills their processes, does not meet my needs. I need the updater to handle this workflow reliably and preserve legitimate running work.

Please:

1. Read the confirmed local evidence below and distinguish it from the proposed explanation and external reports.
2. Identify whether this session has an actual supported feedback or support-submission capability. If so, explain what it sends and help prepare the submission. If I need to operate a menu or command, give me the exact next step.
3. Prefer the appropriate Desktop support channel. Request engineering review of background-process lifetime across MSIX updates.
4. Ask for a case/reference number, a supported interim workaround, and clarification of whether a fix is being investigated.
5. State clearly whether the report was merely prepared, saved locally, or actually submitted. Do not say that Anthropic received it without a successful submission result or support confirmation.

The process IDs and actions in this document are historical evidence from a completed recovery. They are not instructions to terminate those IDs again. Any future process cleanup must use fresh evidence and preserve active project work.

## 1. Summary and user impact

The user reports that Claude Desktop repeatedly stops working after updates and has required a full Windows restart before it will launch again.

The supplied screenshot displayed:

```text
Another program is currently using this file.
```

Its title bar referenced the newly installed Claude package under `C:\Program Files\WindowsApps`.

During the September 9 incident, Windows logs showed that Claude failed while creating its Desktop AppX container, with error `0x80070020` and an error encountered "converting the job." The main Claude application was already closed.

An administrator-level, read-only query of the old Claude container's job object identified **18 surviving processes**. These included old log readers, an SSH file-existence check, three idle Python multiprocessing workers whose parent was gone, and a functioning research status monitor. They were attached to an older Claude package even though a newer package was installed.

After the abandoned processes were stopped and the functioning monitor was restarted separately, Windows logged destruction of the old container. The new Claude application then launched successfully without rebooting. All **25 unrelated Python processes** recorded before cleanup were still present immediately afterward.

The user specifically clarified:

> "that is literally all i use claude desktop for. long running projects"

This is therefore a reliability problem affecting the user's central workflow. Requiring a reboot interrupts unrelated work, and automatically killing all project processes would risk losing legitimate progress. The recovery described here addresses one incident; it is not a permanent updater fix.

## 2. Environment

| Item | Observed value |
| --- | --- |
| Operating system | Microsoft Windows 11 Pro, version 25H2 |
| Windows build | 10.0.26200.9168 |
| Last Windows boot | August 23, 2026, 22:29:58 CDT |
| Installed Claude package during failure and recovery | `Claude_1.49585.0.0_x64__pzs8sxrjxfjjc` |
| Installed package version | `1.49585.0.0` |
| Package status | `Ok` |
| Older package with surviving user container | `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc` |
| Package family | `Claude_pzs8sxrjxfjjc` |
| Application ID | `Claude_pzs8sxrjxfjjc!Claude` |
| Application executable in package | `app\Claude.exe` |
| Packaged background service | `CoworkVMService`, running from the installed package |
| Incident date | September 9, 2026 |
| Timezone for all incident timestamps below | America/Chicago, CDT, UTC-05:00 |

The WindowsApps location confirms a packaged installation. The original download/install channel was not established; this report does not assume the user installed it through Microsoft Store.

The two package versions above are the installed version and the observed older retained version. The investigation did not establish that this was a single direct update between those versions.

## 3. Confirmed local evidence

### 3.1 The failure occurred during app-container creation

Log: `Microsoft-Windows-AppModel-Runtime/Admin`

At **16:29:36.072239**, Event **215**, Record **814194**:

```text
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc because an error was
encountered converting the job.
```

At **16:29:36.072325**, Event **208**, Record **814195**:

```text
0x80070020: Cannot create the process for package
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc because an error
was encountered while configuring runtime. [LaunchProcess]
```

These events locate the failure more precisely than the screenshot's generic file-in-use message. This investigation did not directly identify a conventional file handle on `Claude.exe`; it identified a surviving old container and its process membership.

### 3.2 Looking for Claude.exe did not identify the blockers

No main `Claude.exe` process was running during the initial inspection. A scan using `GetPackageFullName` also did not identify the relevant descendants as readable processes carrying Claude package identity.

That negative result did not mean that no process belonged to the old Claude container. Querying the actual container job revealed the members listed below. The important distinction is between a process's visible name/package identity and its membership in the old app's job object.

### 3.3 The old container was still present

The Windows NT object namespace contained this named job:

```text
\Container_Claude_1.34493.1.0_x64__pzs8sxrjxfjjc-
```

The account-specific SID has been redacted. The current package also had a separate service container:

```text
\Container_Claude_1.49585.0.0_x64__pzs8sxrjxfjjc-PackagedService
```

Opening either job for a membership query from the ordinary user context returned access denied (`0xC0000022`). An elevated, read-only probe succeeded.

The old user container's query returned:

```text
Assigned=18
PIDs=1288,27712,56924,69660,77872,35292,18408,44604,53432,
84272,67256,13916,43808,36344,78852,39544,22216,46636
```

The current packaged-service container separately contained PID **43596**, `cowork-svc.exe`, at the initial elevated check. Later automatic package activation/repair restarted that service as PID **121576**.

### 3.4 Exact surviving members of the old container

| Process type | Count | Historical PIDs | Observed role |
| --- | ---: | --- | --- |
| `ssh.exe` | 1 | 1288 | Old remote file-existence check, started August 27; its command tested for a result file rather than starting a remote training job |
| `tail.exe` | 5 | 27712, 69660, 35292, 36344, 39544 | Old log readers, started August 28 through September 2 |
| `grep.exe` | 5 | 56924, 77872, 18408, 78852, 22216 | Associated log-filter processes |
| `nohup.exe` | 1 | 44604 | Wrapper for the project status monitor |
| `pythonw.exe` | 2 | 53432, 46636 | Virtual-environment launcher and actual status-monitor process |
| `python.exe` | 3 | 67256, 13916, 43808 | Multiprocessing children whose parent PID 87464 was no longer present |
| `conhost.exe` | 1 | 84272 | Console host whose original parent PID 34660 was no longer present |
| **Total** | **18** | | |

The status-monitor chain was:

```text
nohup.exe (44604)
-> pythonw.exe virtual-environment launcher (53432)
-> pythonw.exe actual monitor (46636)
```

The monitor ran a project-local Python script that periodically checked campaign/GPU state and atomically refreshed a local status file. It was functioning, so the recovery preserved its purpose by restarting it outside the old Claude container.

The three Python workers had command lines of this form:

```text
python.exe -c "from multiprocessing.spawn import spawn_main;
spawn_main(parent_pid=87464, pipe_handle=)" --multiprocessing-fork
```

Before cleanup, each worker had:

- No living parent at PID 87464.
- No appearance in the GPU process query.
- Zero CPU-time, read-byte, and write-byte change during a two-second sample.
- 110 threads, all reported as waiting.

Some TCP entries still existed for these workers, so this report does not claim that all their handles or connections were absent. These observations, their age, and the missing parent supported the classification of these specific workers as abandoned. They do not establish a general rule that any idle Python process is safe to kill.

### 3.5 A plausible initial suspect was ruled out

Ten detached Git filesystem-monitor daemons were also found on the computer. Similar public reports implicated such daemons, but **none of these ten was in the old Claude container's 18-member list**. They were not terminated by this recovery.

The resolution depended on querying actual container membership rather than broadly killing Git, Python, or other processes by name.

## 4. Recovery performed and observed result

The recovery was limited to the identified old-container members:

1. Recorded each target's process name, PID, and creation time.
2. Rechecked process identity before stopping each target, to guard against PID reuse.
3. Stopped the old SSH check and log readers. Several corresponding filter processes exited automatically when their input ended.
4. Stopped the three identified abandoned Python workers. The old console host also exited.
5. Stopped the old status-monitor process and its remaining wrappers.
6. Restarted the same monitor script using the same virtual-environment interpreter and project working directory, hidden, from outside Claude's old container.
7. Retried Claude's registered application activation.

The recovery did not terminate the entire job object, kill all Python processes, reinstall Claude, reset its application data, or reboot Windows. There was no direct manual stop of `CoworkVMService` as part of the cleanup; the package activation path restarted it during failed launch attempts.

### Recovery timeline

| Local time, September 9 | Evidence |
| --- | --- |
| 16:29:36 | New Claude version failed with Events 215 and 208, `0x80070020` |
| Approximately 16:35:11 | Elevated job query recorded 18 members in the old user container |
| Approximately 16:39:02-16:39:16 | Targeted cleanup ran; the status monitor was restarted separately |
| 16:39:17.223 | The restarted monitor refreshed its status file |
| 16:39:35.798 | An initial relaunch still failed while old-container teardown had not completed |
| **16:39:38.672** | **Event 217 recorded destruction of the old user container** |
| Approximately 16:39:54 | A new elevated query showed only the current Claude service container; the old user container was absent |
| **16:40:08.853** | **Event 201 recorded successful creation of the updated Claude application process** |
| Subsequent verification | Claude had a window titled `Claude` and reported `Responding=True`; all 25 previously recorded unrelated Python processes were still present |
| 18:10:29.912 status-file timestamp | A later check while preparing this report confirmed continued status-monitor output well after recovery; Claude's main window was still present and responding |

At **16:39:38.672086**, Event **217**, Record **814223**:

```text
Destroyed Desktop AppX container
{221FDD54-9F6B-11F1-8AD3-F057A6D2BA3F} for package
Claude_1.34493.1.0_x64__pzs8sxrjxfjjc.
```

At **16:40:08.853193**, Event **201**, Record **814227**:

```text
Created process 110620 for application Claude_pzs8sxrjxfjjc!Claude
in package Claude_1.49585.0.0_x64__pzs8sxrjxfjjc. [LaunchProcess]
```

The replacement status monitor had launcher PID **118576** and child PID **47608**. Its output was verified after launch and again later. The old container's subsequent absence established that the replacement was not retaining that old container.

The first retry occurred shortly before Windows finally destroyed the old container. This delay matters: recovery logic should verify teardown or wait for the relevant state change before concluding that cleanup failed.

## 5. Diagnosis and confidence limits

### Strongly supported conclusion for this incident

Surviving background project processes retained an older Claude Desktop user container after the application had closed and a newer package was installed. New-version startup failed during app-container/job setup. Removing the abandoned members and relocating the functioning monitor allowed the old container to be destroyed and the updated application to launch without rebooting.

The direct membership query, destruction event, and successful launch form a much stronger explanation than the generic file-in-use message alone.

### What has not been established

- The exact updater code path, internal race, or launch flags that caused each descendant to remain in the old container were not traced.
- The exact moment at which every descendant became orphaned was not established.
- The user reports recurrence after every update, but only this incident was instrumented and recovered in this investigation. No precise historical failure rate is claimed.
- No new update was deliberately triggered to reproduce the problem after recovery.
- The recovery addressed the members as a group; it did not isolate a single uniquely responsible process by restoring each process and reproducing the failure.
- The service's separate presence is not evidence that CoworkVMService was the culprit here.
- Process survival of the 25 unrelated Python processes was checked. This is not a complete validation of every research job's output or scientific correctness.
- The initial fixed condition is not proof that future updates are safe. No permanent updater change was made.

## 6. Related public reports

These are firsthand reports in Anthropic's GitHub repository, not independent confirmation that Anthropic has accepted a root-cause analysis or shipped a fix.

- [Issue #73107](https://github.com/anthropics/claude-code/issues/73107): Reports the same dialog and Events 215/208 after a package upgrade. The reporter queried the old named container job, found surviving elevated descendants, and restored startup by removing those specific processes. This guided the useful diagnostic approach in the present case; our process membership was independently measured locally.
- [Issue #91763](https://github.com/anthropics/claude-code/issues/91763): Reports the same type of old-container retention involving a detached, non-elevated Git filesystem-monitor daemon. That process type was not the blocker in the present incident, which instead involved the 18 members documented above.

Both reports were open when inspected on September 9, 2026 and carried Desktop/Windows bug and reproduction labels. This report should be correlated with those cases while preserving the distinct evidence and long-running-work requirements here.

## 7. Requested product behavior and engineering follow-up

### User requirement

Claude Desktop must support long-running projects as a normal workflow. An application update should not force the user to choose between an unusable application and ending unrelated or legitimate project work.

### Requested investigation

1. **Background-process lifetime across updates.** Determine why project descendants remain attached to an obsolete, version-specific Desktop AppX container and how that condition blocks new-version activation.
2. **Update scheduling that accounts for running work.** Evaluate a supported way to defer applying an update when doing so would strand the app or interrupt project processes. Apparent UI idleness should not be treated as proof that project work has ended.
3. **Preservation of legitimate jobs.** Evaluate a supported worker/launcher architecture that allows intended long-running work to survive a Desktop update and remain manageable afterward. The required behavior matters more than any particular implementation suggested by this report.
4. **Targeted recovery.** Detect an old retained container and identify its actual members. Distinguish abandoned helpers from active tasks. Do not silently terminate all descendants as a universal repair.
5. **Actionable diagnostics.** Explain that a previous Claude environment is still held by background processes, name the relevant tasks/processes where possible, and offer a safe recovery or deferral path. The current generic message directs the user toward a vague file-lock problem.
6. **Completion-aware retry.** Confirm old-container teardown before retrying activation. In this incident, a retry failed seconds before Event 217 finally recorded teardown.

### Suggested regression scenarios

- An update while a genuine long-running research process is active.
- An update after the main Claude UI exits but an intended monitoring daemon remains.
- Orphaned log readers and filters such as `tail` and `grep`.
- Python multiprocessing children whose parent has exited.
- Virtual-environment launchers, `pythonw`, `nohup`, and console-host descendants.
- Detached Git monitoring daemons, as described in the related report.
- Elevated and non-elevated descendants.
- Multiple package versions accumulated without a Windows reboot.
- Delayed container teardown after the final member exits.
- A current packaged-service container existing separately from an old user container.

### Questions for Product Support / engineering

- Is this failure mode currently tracked, and can this evidence be attached to the appropriate internal issue?
- What is the supported recovery that preserves legitimate active jobs?
- Is there a supported update-deferral or maintenance-window option for an individual Desktop user? Please specify account/platform limitations rather than assuming an enterprise policy applies.
- What additional bounded diagnostics would be useful on the next occurrence?
- Can a fixed build be tested against these background-process scenarios?

## 8. Official reporting route and what Claude can actually do

For Desktop-specific problems, Anthropic's [Desktop troubleshooting documentation](https://code.claude.com/docs/en/desktop#still-stuck) points to **Help > Get Support** or the Claude support center. It requests the app version, OS, exact error, and relevant logs. It directs users toward GitHub for problems that also reproduce in the standalone Claude Code CLI; this investigation did not establish such CLI reproduction.

The [Claude Help Center support instructions](https://support.claude.com/en/articles/9015913-how-to-get-support) describe the account menu route **Get help > Send us a message**. The support assistant can pass inquiries requiring investigation to Product Support.

Claude Code also documents a [`/feedback` command](https://code.claude.com/docs/en/errors#report-an-error). Availability of that command does not establish that an ordinary Claude chat has an autonomous internal bug-submission capability. The receiving session should identify what is actually available.

According to Anthropic's [feedback data-use documentation](https://code.claude.com/docs/en/data-usage), feedback can include conversation history and code; the user can select the history scope. Some provider/credential configurations save a local archive instead of transmitting it. Review what would be included and distinguish a local archive from a successful submission. Attaching this report through Desktop Product Support is the primary route recommended here.

## 9. Diagnostic method for engineering reference

The decisive probe was read-only:

1. Enumerate the Windows NT object-manager root (`\`) with `NtOpenDirectoryObject` and `NtQueryDirectoryObject`.
2. Identify the actual names beginning with `Container_Claude_`.
3. Open the exact absolute NT job name using `NtOpenJobObject`, requesting only `JOB_OBJECT_QUERY` (`0x0004`). This required elevation on the affected computer.
4. Query `QueryInformationJobObject` with `JobObjectBasicProcessIdList` (information class `3`) to obtain actual members.
5. Resolve those PIDs to process names, creation times, parent IDs, and roles.
6. Close the diagnostic job handles promptly so the probe itself does not retain an otherwise unreferenced object.

Relevant primary API references: [Microsoft NtQueryDirectoryObject](https://learn.microsoft.com/en-us/windows/win32/devnotes/ntquerydirectoryobject), [QueryInformationJobObject](https://learn.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-queryinformationjobobject), and [Microsoft hcsshim native job declarations](https://github.com/microsoft/hcsshim/blob/main/internal/winapi/jobobject.go).

The native method above avoids inferring job membership from process names or from `GetPackageFullName`. The recovery script was deliberately incident-specific and is not included as a reusable kill command.

## 10. Scope of information shared in this document

This report reproduces selected local observations needed to explain and investigate the failure. Account SID, personal home-directory paths, remote-host identity, private project paths, and project output contents have been omitted or generalized. Historical package IDs, process IDs, event record numbers, and timestamps are retained for technical correlation.

Local diagnostic captures and the original screenshot existed during investigation. This Markdown is self-contained; it does not require access to private project files or the Codex conversation. Any request for additional raw logs or transcripts should identify exactly what is needed for this Desktop updater issue.

No repository files or tests are identified. Start by reviewing the read-only container diagnostic method and compare the failure signature with #73107 and #91763; done requires engineering to identify the updater/container lifetime defect and define a supported recovery or deferral path that preserves legitimate background work.

Escrito por el modelo de indexación a partir del texto del issue.