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

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.8479.0

Bundled Codex CLI/app-server: 0.144.2

What subscription do you have?

Not relevant to this local Desktop process failure.

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 (Windows 10 Pro 22H2)

What issue are you seeing?

Summary

Codex Desktop silently terminated and relaunched its full AppX container three times during one session. The strongest reproduction occurred while six concurrent subagents from two independent parent tasks were streaming progress.

The Desktop did not register those child conversation IDs in its normal thread store, but it broadcast every child event to both renderers:

• rendererWindowAppearance=primary
• rendererWindowAppearance=avatarOverlay

Both renderers then emitted an error for nearly every child item transition:

Received item/started for unknown conversation conversationId=<redacted-subagent-id>
Received item/completed for unknown conversation conversationId=<redacted-subagent-id>
Conversation state not found conversationId=<redacted-subagent-id>

In the third process lifetime, the main Desktop log contained:

• 2,467 total lines in about 7 minutes
• 1,460 error lines
• 1,454 unknown-conversation/state-not-found errors across eight child IDs
• at least six IDs confirmed as live subagent rollouts
• two separate parent thread IDs
• six distinct depth-1 subagent paths
• the same child events duplicated to the primary renderer and avatarOverlay

The six child rollout JSONL files were present, readable, and identified themselves as source.subagent.thread_spawn with valid parent thread IDs. None of the six child IDs existed as rows in the Desktop threads table. This is consistent with a routing/hydration boundary bug: child streams are globally broadcast before the Desktop renderer has registered child conversation state.

After the error storm, Windows AppModel-Runtime recorded event ID 217 destroying the complete OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0 Desktop AppX container. The UI disappeared and a new main process/container was created.

This is not adequately mitigated by disabling multi_agent; concurrent subagents are an intended stable feature and should not destabilize the Desktop host.

What steps can reproduce the bug?

Observed reproduction:

1. Use Codex Desktop 26.707.8479.0 with multi_agent enabled.
2. Run two independent local parent tasks.
3. Spawn three active depth-1 subagents from each parent task.
4. Keep the main Desktop window and Pet/avatarOverlay renderer active.
5. Let the child turns stream reasoning/item start/item completion events concurrently.
6. Inspect the Desktop main-process log.
7. Observe that each child event is rejected as an unknown conversation by both renderers.
8. The error volume grows rapidly; in this reproduction it reached 1,454 state errors.
9. The full AppX container is destroyed without a normal quit marker, WER event, or Crashpad dump, and Desktop later relaunches.

The three local container exits were:

| Local time | Final Desktop log evidence | AppModel result |
|---|---|---|
| 20:31:40 | log ended at 20:31:34 after unknown-conversation errors plus thread/browser route activity; no shutdown marker | event 217 destroyed container |
| 20:35:08 | log ended at 20:35:03 after repeated unknown conversation and Conversation state not found; no shutdown marker | event 217 destroyed container |
| 20:44:49 | preceding process produced the 1,454-error subagent storm; no normal quit marker | event 217 destroyed container and a new main process was created two seconds later |

The failure is not fully deterministic yet, but the third occurrence provides a high-volume, multi-parent subagent reproduction and the same machine experienced three full-container exits in roughly 13 minutes.

What is the expected behavior?

• Subagent conversations should be registered/hydrated before their events reach renderer conversation-state handlers, or subagent-only events should be intentionally filtered from handlers that require a normal Desktop thread entry.
• The same child stream should not generate duplicate state errors in both the main renderer and avatarOverlay.
• Missing child UI state must be isolated from the parent task and must never terminate the Desktop host.
• Concurrent subagents from unrelated parent tasks must remain isolated.
• If Desktop must restart, it should persist a concrete restart reason and collect a usable diagnostic artifact.

Additional information

Package and system checks:

• Microsoft Store package status: Ok
• Package signature kind: Store
• app.asar size matched AppxBlockMap.xml
• all 3,043 SHA-256 BlockMap chunks for app.asar verified successfully
• no matching Windows Application Error event
• no matching Windows Error Reporting crash event
• no Codex/ChatGPT dump in %LOCALAPPDATA%\CrashDumps
• no Crashpad report for the incidents
• no Windows resource-exhaustion event
• no display-driver reset event
• no GPU reason=crashed marker in these three process logs
• no Codex app-server is not available marker in these three process logs
• no stop_process, normal shutdown, or package-update transition explaining these three exits

The raw logs and conversation IDs are intentionally not attached because they contain private task data. Sanitized excerpts and aggregate counts above are reproducible from the local artifacts.

Related reports:

• #32738 confirms that this exact build sends subagent events to the primary renderer and avatarOverlay as unknown conversations, but that report did not observe a crash.
• #31583 tracks silent Windows AppX container destruction/relaunch without WER or Crashpad evidence.
• #32722 documents unbounded full conversation snapshot fan-out in this exact Windows package.

This report adds a concrete bridge between those symptoms: concurrent child streams from two parent tasks produced a duplicated renderer error storm immediately within a session that ended in another silent full-container teardown.