[Windows Desktop] Tool-managed pytest subprocess can terminate the whole Codex app; same workload exits 0 in independent PowerShell

Summary

Codex Desktop on Windows can silently terminate its entire observed process set while a local pytest workload is running through the Codex tool/terminal execution path.

I reproduced this multiple times during normal local development. I then built an offline, passive, out-of-process flight recorder (1-second sampling) and captured one failure precisely. The recorder shows:

• the pytest subprocess was alive immediately before failure;
• both observed Codex Desktop processes were alive immediately before failure;
• all observed Codex PIDs disappeared within one 1-second sample window;
• the pytest/Python process disappeared in that same sample window;
• system RAM, commit, and pagefile were healthy;
• there was no matching Windows Application Error, Application Hang, WER, or Resource Exhaustion event.

A control experiment used the same Python interpreter, same repository HEAD, and same pytest selection, but launched it through an independent PowerShell process created by Win32_Process.Create / WMI. That PowerShell's parent was WmiPrvSE.exe, it was verified not to be in any Job Object, Python exited 0, and Codex Desktop remained alive.

This strongly localizes the failure boundary to the Codex Desktop tool/subprocess execution lifecycle path, not to system resource exhaustion or a pytest workload that inherently crashes Windows/Python.

Environment

• Platform: Windows 10 x64 (19045 family)
• Codex Desktop: Microsoft Store / packaged Windows app
• Exact About/version string: not captured during the incident; can provide on request
• Python: 3.11 (python.exe from a normal local Python installation)
• Workload: local private repository, 12-file pytest selection, expected 182-case related matrix
• No Agent or Reviewer was required for the captured crash

Private repository name, Windows username, full local paths, prompts, conversation contents, and raw logs are intentionally omitted from this public report.

Captured failure timeline

Local timezone: UTC+8.

Flight-recorder activity/system evidence:

PYTEST_BEGIN (durable PRE marker)
2026-08-28T03:55:35.7528337+08:00

First pytest process observed
2026-08-28T03:55:49.6728573+08:00

Last sample with Codex alive and pytest alive
2026-08-28T03:55:51.6758542+08:00

First sample with all observed Codex PIDs gone
2026-08-28T03:55:52.6657298+08:00

First sample with pytest gone
2026-08-28T03:55:52.6687300+08:00

Observed exit ordering therefore cannot be resolved below the 1-second sampling interval:

PROCESS_EXIT_ORDER=SAME_SAMPLE_WINDOW
PYTEST_WAS_RUNNING_AT_CODEX_FAILURE=YES

Immediately before failure:

Codex process count:          2
Codex PIDs:                   9064, 10996
Codex working set total:      289 MB
Codex private bytes total:    213 MB
Python process count:         1
Python working set total:     87 MB
pytest process count:         1
System available RAM:         8919 MB
Commit used / limit:          9202 / 30669 MB
Pagefile current / peak:      56 / 59 MB

Five-second deltas before failure:

Codex working set delta:      -2 MB
Available RAM delta:          -145 MB
Commit-used delta:            +151 MB

There was no evidence of system resource pressure.

Process disappearance pattern:

ALL_OBSERVED_CODEX_PIDS_DISAPPEARED_IN_SINGLE_SAMPLE_WINDOW
NO_PRIOR_PARTIAL_DROP

Windows evidence around the recorder-derived failure timestamp:

Application Error:            NOT_FOUND
Application Hang:             NOT_FOUND
Windows Error Reporting:      NOT_FOUND
Resource Exhaustion event:    NOT_FOUND
Faulting application/module:  NOT_FOUND
Exception code:               NOT_FOUND

The local recorder logs were hashed immediately after capture:

system.jsonl SHA-256:
72014c0da539eee7d91cbbe678c3569e38e5fbe7d5f77a0a28c079b38dd06858

activity.jsonl SHA-256:
4ab5340337aadcfd920c56c28e7c0f5555a54481dd8a0339541774e6dc6387c0

The raw logs are not attached publicly because they contain local process/path metadata. I can provide sanitized excerpts or additional counters through a maintainer-approved private channel.

Reproduction pattern

The captured crash did not require multi-agent or reviewer workflows.

1. Open Codex Desktop on Windows.
2. Work in a clean local repository/worktree.
3. Through the Codex terminal/tool execution path, run one moderately sized local pytest command selecting 12 test files (-q; approximately 182 expected cases in this project).
4. During the captured reproduction, pytest appeared as a Python child process.
5. Within seconds, the complete observed Codex process set exited silently and pytest disappeared in the same 1-second recorder window.
6. Reopen Codex Desktop; no corresponding WER/Application Error was found.

The exact private test filenames are omitted publicly. The exact command string has SHA-256:

823ad2ddab627740c4ef3ba13b73fe67ce560928ee0a0c0a172b9345690566b6

I can provide the sanitized/full command privately if maintainers need it.

A/B control: same workload outside Codex process management

To distinguish a pytest/test defect from a Codex process-lifecycle defect, I ran the same workload through an independently created PowerShell process.

The control process was created through WMI / Win32_Process.Create, not as a normal Codex child:

External PowerShell parent:   WmiPrvSE.exe
Parent is Codex:              NO
Job Object membership:        VERIFIED NOT IN ANY JOB
Same Python interpreter:      YES
Same repository HEAD:         YES
Same pytest selection:        YES

Control result:

External pytest started:      YES
External pytest completed:    YES
Python/pytest exit code:       0
Duration:                      2.872053 s
stderr bytes:                 0
result JSON valid:            YES
Codex Desktop crashed:        NO
Codex Desktop froze:          NO
Codex disappeared:            NO
System resource pressure:     NO

The captured quiet-mode stdout contained 24 dots but no final textual summary line, so I am not claiming the exact 182 passed count from this control capture. The defensible result is that the same selected workload exited Python with code 0 while Codex remained alive.

Expected behavior

A local command/test subprocess should not be able to terminate the Codex Desktop host/control plane.

If a child process exits, hangs, closes a pipe, receives a console event, or otherwise fails, Codex should isolate that failure to the tool invocation and return a bounded tool error while keeping the Desktop app and other tasks alive.

Actual behavior

When the workload is run through the Codex tool/terminal execution path, the entire observed Codex Desktop process set can silently disappear while the pytest process is active.

When the same workload is moved outside the Codex-owned process lifecycle into an independent WMI-created PowerShell, Python exits 0 and Codex remains alive.

Current workaround

For large/long-running local test workloads on this Windows machine:

• start a passive offline recorder;
• create an external PowerShell through WMI / Win32_Process.Create;
• verify its parent is not Codex and it is not in a Codex Job Object;
• redirect stdout/stderr to local files;
• write a durable result JSON;
• let Codex only initiate/observe/read the result instead of owning/capturing the pytest subprocess directly.

This workaround has prevented the observed Desktop exit in the control run.

Why I think this is Codex-side

Evidence currently supports the following boundary, without claiming a source-level root cause:

Agent required:                     NO
Reviewer required:                  NO
System OOM/resource exhaustion:     NO EVIDENCE
Windows WER/Application Error:      NONE FOUND
Codex-owned/tool subprocess path:   WHOLE-PROCESS EXIT REPRODUCED
Independent Windows process path:   PYTHON EXIT 0, CODEX STAYED ALIVE

The exact internal defect is still unknown. Candidate areas for maintainers to inspect include Windows console/process-tree isolation, Job Object ownership/cleanup, terminal/PTY lifecycle, app-server/tool subprocess IPC, and error handling when a managed child exits or its pipe/session changes state.

Possibly related issues

• #32653 — entire Desktop crash around a failed local pytest exec tool call / missing tool result
• #35782 — full Windows Desktop termination during app-server disconnect/recovery under task load
• #38444 — tool subprocess console-control behavior can terminate the Codex control plane
• #38360 — unhandled pipe EOF/EPIPE in Windows Desktop main-process IPC lifecycle

This report differs by providing a passive 1-second process/resource timeline and a same-workload independent-process A/B control.

Additional evidence available

If useful, I can provide sanitized versions of:

• the system.jsonl timeline around the failure;
• the activity.jsonl PRE marker timeline;
• external-runner result JSON;
• process-parent / Job Object verification;
• exact private pytest command and selected test filenames;
• additional repetitions using the same offline recorder.

I would prefer a private maintainer-approved channel for any artifact containing full local paths or repository metadata.