[Windows Desktop 26.707.8479.0] Concurrent subagent streams flood both renderers, then silently terminate the AppX container

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32737
• #32738
• #32502

Powered by Codex Action

Thanks. I reviewed all three suggested duplicates in detail.

• #32737 is the closest mechanism-level match: subagent threads are not registered in renderer state, so their events are dropped as unknown conversations. It is a macOS report whose visible result is stuck/missing subagent UI, not a full host-process exit.
• #32738 reproduces the same unknown-subagent behavior on the exact Windows Desktop build, but it explicitly reports that no application crash was recorded; its other primary symptom is the Pet's fixed 180-second running-notification expiry.
• #32502 concerns the VS Code extension rather than the Microsoft Store Desktop AppX host.

This issue adds a separate reliability escalation: the same subagent registration/routing defect was observed at high volume immediately within a process lifetime that ended in another silent full-AppX teardown, and the machine had three such container exits in about 13 minutes. I therefore do not believe #32789 is an exact duplicate of any one suggested issue.

Local investigation conclusion

The strongest evidence points to a Desktop event-routing/hydration boundary failure, not failed subagent execution:

1. Six live depth-1 subagent rollout files from two independent parent tasks were present, readable, and continued to receive events. Each identified itself as a subagent and carried a valid parent thread ID.
2. None of those six child IDs existed as a normal row in the Desktop threads store.
3. Despite that missing renderer-visible state, every child turn/item event was broadcast to both:

• rendererWindowAppearance=primary
• rendererWindowAppearance=avatarOverlay

1. Both renderers then rejected the same child event as unknown conversation or Conversation state not found.
2. During the third process lifetime, the Desktop main-process log accumulated:

• 2,467 total lines in about seven minutes
• 1,460 error lines
• 1,454 unknown-conversation/state-not-found errors
• eight affected child IDs, at least six directly confirmed as active subagents

1. Windows AppModel-Runtime subsequently recorded event ID 217 destroying the complete Codex Desktop AppX container. A new main process/container was created two seconds later.

The same machine recorded three unexpected event-217 container destructions at 20:31:40, 20:35:08, and 20:44:49 local time. None was accompanied by a normal Desktop shutdown marker or a package-update transition.

Checks that did not support alternative explanations

For these three process lifetimes, current checks found:

• no matching Windows Application Error or WER crash event;
• no current Codex/ChatGPT dump in %LOCALAPPDATA%\CrashDumps;
• no Crashpad report;
• no Windows resource-exhaustion event;
• no display-driver reset event;
• no GPU reason=crashed marker in the Desktop logs;
• no Codex app-server is not available marker;
• no stop_process or normal quit marker;
• Store package status Ok and signature kind Store;
• the installed app.asar matched its declared size, and all 3,043 SHA-256 chunks matched AppxBlockMap.xml.

This rules against package corruption, a recorded GPU/app-server failure, an OS-level OOM/driver reset, or a normal update/restart as the explanation for these three exits.

Confidence boundary

The evidence directly demonstrates the following chain:

active subagents -> child IDs absent from Desktop thread state -> global event broadcast to two renderers -> duplicated unknown-conversation/state errors -> high-volume error storm within a process lifetime that silently loses its AppX container

Because the product did not preserve a WER/Crashpad dump or final shutdown reason, I am not claiming that the exact final app.quit/termination instruction has been identified. The missing diagnostic artifact is itself part of the defect. However, the event-routing failure and its high-volume correlation with the full-container exit are concrete and reproducible from the preserved local artifacts.

I suggest keeping #32789 open as the Windows Desktop crash/reliability escalation, while linking its registration/routing mechanism to #32737 and #32738 and its silent-container-loss behavior to #31583. If maintainers prefer consolidation, the crash-specific evidence should be carried into the selected canonical issue rather than treating this as only a Pet or VS Code visibility problem.

Update: another full AppX teardown on 26.707.9981.0 (2026-07-15)

The same machine had another unexpected Desktop exit at approximately 18:26 Europe/Lisbon. This occurrence is useful because, unlike the earlier exits reported above, Windows preserved WER events and a local dump.

Confirmed timeline

• 18:24:33.640: the Desktop issued a burst of 40 thread/backgroundTerminals/clean requests; 39 failed with thread not found.
• 18:24:34: Windows recorded Application Error plus MoAppCrash for ChatGPT.exe (PID 25620), exception 0xc06d007f.
• 18:26:10.167: the final Desktop lines report IAB_LIFECYCLE route window is not live.
• 18:26:10.205: the app-server transport begins stopping.
• 18:26:10.513: AppModel-Runtime event 217 destroys the full Desktop AppX container.
• 18:26:36: Windows creates a replacement AppX container and process.

The native exception preceded the container teardown by about 96 seconds.

State and workload evidence

Across the terminated process lifetime, the main Desktop log contains:

• 8,995 unknown conversation / Conversation state not found errors;
• 224 in-app Browser lifecycle entries;
• conversation-state errors continuing until roughly three seconds before teardown.

The Git telemetry stream also recorded 5,394 review_model Git command completions, including 2,699 diff commands. Those diff records report about 555 MB of aggregate stdout, with many aborted or waitFailed completions.

This is strong evidence of abnormal state/workload pressure in the same process lifetime, but it does not by itself prove the final termination instruction.

Native exception boundary

A local minidump stream parse found delay-load metadata with Win32 error 127 (ERROR_PROC_NOT_FOUND). The metadata maps to the bundled @serialport/bindings-cpp native addon under @worklouder/device-kit-oai; the exact missing exported procedure was not recoverable. WER itself reports the faulting module as unknown, so this should be treated as a diagnostic lead rather than a proven root cause.

The same 0xc06d007f exception has since been recorded 12 times in the replacement process while that process remained alive. Therefore this native fault is real, but it is not sufficient on its own to explain the full application exit.

Checks

• No Windows Defender detection, block, ASR action, Code Integrity, or AppLocker event matched the crash window.
• No Windows resource-exhaustion event matched the crash.
• The raw dump is intentionally not attached because it may contain private session data.

There is also an independent silent-exit reproduction on the exact same Store package version in #23814, triggered there by in-app Browser navigation. The final IAB lines in this occurrence may be part of shutdown rather than the initial trigger, so I am not claiming that Browser activity alone caused this exit.

I have the same issues, can attach logs if needed!

Additional reproduction on Windows Desktop 26.715.2305.0 (2026-07-18)

I hit the same failure pattern on a newer Windows Desktop build. The app became severely laggy during a long, tool-heavy task with concurrent subagents in a large local codebase, then the Desktop app disappeared. After relaunch, I had to delete the affected task to continue working.

I have experienced the slowdown/failure mode at both normal and Ultra reasoning settings. The preserved post-relaunch diagnostics below were collected while using gpt-5.6-sol with xhigh reasoning and the priority service tier.

Environment

• Codex Desktop at the time of the incident: 26.715.2305.0
• Reported app-server: 0.145.0-alpha.18
• ChatGPT plan: Pro
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Hardware: Intel Core i7-13700H (14 cores / 20 threads), 32 GB RAM, NVMe SSD, Intel UHD Graphics

The app has since updated to 26.715.4045.0. I have not yet reproduced the crash on that build, so I am not claiming the update fixes it.

Renderer/event evidence

Within the preserved 26.715.2305.0 log after relaunch:

• 1,873 log entries were tagged to a renderer: 761 for primary and 1,112 for the hidden avatarOverlay.
• The busiest second contained 138 renderer events; the next second contained 122.
• 362 unique Reasoning summary item completed item IDs were delivered to primary; the exact same 362 item IDs were also delivered to avatarOverlay.
• avatarOverlay then logged:
• 217 Received item/started for unknown conversation errors
• 217 Received item/completed for unknown conversation errors
• 83 Conversation state not found errors
• Those unknown-state errors covered five distinct conversation IDs. Six distinct thread IDs were present in the reasoning-summary stream.

Sanitized representative lines:

... Reasoning summary item completed ... rendererWindowAppearance=primary ...
... Reasoning summary item completed ... rendererWindowAppearance=avatarOverlay ...
... Received item/started for unknown conversation conversationId=<redacted> rendererWindowAppearance=avatarOverlay ...
... Received item/completed for unknown conversation conversationId=<redacted> rendererWindowAppearance=avatarOverlay ...
... Conversation state not found conversationId=<redacted> rendererWindowAppearance=avatarOverlay ...

The app-server was also slow during the same period even though the machine had resource headroom:

• thread/search: 6,065 ms
• thread/start: 6,700 ms
• thread/resume: 2,897 ms
• mcpServerStatus/list: 8,177 ms

Local-state pressure and mitigation result

Before cleanup, the active Codex session history contained 193 rollout files totaling about 805 MB. The three largest individual rollouts were about 154 MB, 122 MB, and 103 MB. In the local thread database, 201 of 262 rows were subagent sessions.

I archived inactive rollout history without deleting it, leaving 3 active files totaling about 29 MB, then restarted the app. The task list subsequently responded in 49 ms and the UI was materially lighter. This is an A/B mitigation result, not proof of the root cause.

Clearing Electron caches does not appear to explain the improvement: only 18.33 MB was moved, and the app immediately recreated about 13.8 MB after restart. During the earlier resource sample, Codex used about 1.37 GB private memory across 10 processes while Windows still had about 12.8 GB available. The disk was healthy and not saturated. No matching WER, local crash dump, or Crashpad report was preserved for the exit.

Why this appears related

This reproduction has the same core boundary failure described in this issue: concurrent subagent events are delivered to both the primary renderer and the avatar overlay, while the overlay lacks state for the child conversations and emits a high-volume unknown-conversation error storm. Large accumulated rollout/thread state appears to amplify startup, task-list, and resume latency.

Potential hardening points suggested by the evidence:

1. Do not subscribe the hidden avatar overlay to the full thread/subagent event stream unless it needs those events.
2. Register child conversation state before routing child events, and deduplicate or quietly discard stale events instead of producing an error per event.
3. Paginate or lazily hydrate large local session histories rather than scanning/replaying hundreds of rollouts into both renderers.
4. Preserve a final shutdown reason or crash/hang artifact for silent Desktop exits.

I can provide a more complete sanitized log excerpt if maintainers specify the preferred diagnostic bundle and upload channel.

I reproduced an app-server notification-ordering bug that appears to explain the unknown-conversation flood described here. On macOS, the same ordering failure has a lower-severity manifestation: completed subagent cards can remain active for days, then reconcile to completed immediately when opened.

Root cause

For an AgentControl-spawned child, try_attach_thread_listener currently calls thread_watch_manager.upsert_thread(). That can emit thread/status/changed for the child before the client has received thread/started. Attaching the listener can then replay buffered child turn/* and item/* notifications before the child thread is known to the client.

Clients that reject notifications for unknown thread IDs can therefore discard the child's lifecycle events, including turn/completed. This matches both the unknown-conversation logs here and the stale-completion behavior in #23930 and #25179.

Reproduction and proposed fix

I added an app-server integration test through the public JSON-RPC surface. It spawns a MultiAgentV2 child, observes raw notifications through child turn/completed, and fails if any child status, turn, or item notification arrives before thread/started.

On current main, the test fails with:

spawned subagent status arrived before thread/started

The proposed fix:

• seeds the child watch entry without emitting status;
• constructs Thread from the loaded snapshot and resolves its current status;
• emits thread/started before attaching listeners that may replay buffered notifications;
• documents this ordering guarantee.

After the change, the new regression test and two adjacent app-server tests pass. just fix -p codex-app-server, just fmt, and git diff --check also pass.

Public branch and commit:

• https://github.com/LKRCharon/codex/tree/agent/announce-spawned-subagent-threads
• https://github.com/LKRCharon/codex/commit/0e73da21225afa5f286b80674e8908b4e5ffab92

This proves and fixes the notification-ordering violation. I have not reproduced the Windows AppX container termination itself, so I am not claiming that this patch alone resolves the process crash.

If this approach matches the intended app-server contract, would a maintainer be willing to invite a PR?

Follow-up: I found earlier independent prior art from @brainstencil in #24475 and commit https://github.com/brainstencil/codex/commit/edbde7f4803235090c94d349658e383378dd33e2. That patch identified the same listener-attachment gap and correctly scoped the child thread/started notification to the captured connections. Credit to @brainstencil for getting there first.

I have now tightened my branch accordingly:

• thread/started is sent only to the initialized connections that are about to receive the child listener stream;
• an empty connection set is explicitly skipped, because the outgoing helper treats an empty target list as broadcast;
• the silent watch upsert remains, so thread/status/changed cannot beat registration;
• the notification carries the resolved current child status;
• the public JSON-RPC integration test still verifies the full order through child turn/completed, rejecting child status, turn, or item events before thread/started.

Updated branch tip: https://github.com/LKRCharon/codex/commit/33b7086958

The targeted regression test passes, as do just fix -p codex-app-server, Rust formatting, and git diff --check. The only unrelated repository-wide formatting blocker in this checkout is a missing local dotslash executable for the Bazel formatter.

I also traced the separate historical-state path in the currently installed Desktop 26.803 bundle. That client now contains a descendant reconciliation flow that discovers subagent threads with reconciliation enabled and derives done from each child conversation latest-turn/runtime state. This supports treating historical self-healing as a Desktop state-reconciliation concern, separate from the app-server live notification-ordering violation fixed by this branch. I have not claimed that closed-client path as part of this source patch.

The maintainer-invite request for an upstream PR still stands.

I have an opt-in app-server patch ready for clients that intentionally do not render child threads. With CODEX_APP_SERVER_SUPPRESS_SUBAGENT_NOTIFICATIONS enabled, child-thread notifications are filtered at the shared outgoing boundary while JSON-RPC requests, responses, errors, and request-resolution messages continue normally. The default behavior is unchanged, and subagents still execute normally.

The patch includes coverage for configuration parsing, child-only filtering, preserved request resolution, and lifecycle cleanup. The daemon suite passes all 35 tests; the app-server suite passes 1,314 tests, with 23 unrelated integration failures caused by unavailable companion binaries or host subprocess features.

Patch: https://github.com/luca-ctx/codex/commit/71e1195de1eb73a1fbc24e612e6a20dec226ed32

The repository's invite-only contribution policy prevents opening the PR directly. If this mitigation fits the intended client model, could a maintainer invite or approve the contribution?