[Windows Desktop 26.721.4979.0] Session restore should quarantine failed in-app-browser state instead of terminating Codex

What version of the Codex App are you using?

Microsoft Store/MSIX 26.721.4979.0 (internal browser release in logs: 26.721.41059).

Platform

• Windows 11 Pro x64, build 26200
• Hardware acceleration enabled
• NVIDIA RTX 4090 (32.0.16.1074) and Intel Graphics (32.0.101.8801)

What issue are you seeing?

Rapidly switching among existing sessions can restore/rebind persisted in-app-browser WebViews. When one of those browser states hits the Chromium GPU failure path, Codex terminates as a whole and the next launch asks the user to restore the interrupted session.

The affected conversation state should remain recoverable even when its embedded browser state is not. Users should not have to edit .codex-global-state.json, remove thread-browser-tabs-v1:* properties, reset application data, or repair the Microsoft Store package to reopen a conversation.

This report is specifically about the state lifecycle and automatic recovery boundary. The related GPU/SwiftShader failures are already discussed in #35352 and #32094, but a failed browser child must not make the containing session or desktop application unrecoverable.

Steps to reproduce

1. Run the current Microsoft Store build with several existing conversations.
2. Have at least one conversation with persisted in-app-browser state.
3. Rapidly switch among those conversations.
4. Codex restores/rebinds the browser sidebar WebView while changing thread activity.
5. The GPU child crashes, its replacement fails to launch, and the desktop application exits.
6. Relaunch Codex; it offers to restore the interrupted session.

Redacted log sequence

thread_stream_view_activity_changed
maybe_resume_started
IAB_LIFECYCLE renderer created browser sidebar webview
IAB_LIFECYCLE runtime attached browser sidebar webview
error [electron-message-handler] Conversation state not found
...
warning Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed serviceName=GPU
warning Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed serviceName=GPU

At the same timestamp, Windows AppModel-Runtime logged 0x3CFC, refusing to create a process because the machine-level package state check failed. Event 217 then destroyed the Codex AppX container. The package subsequently entered Modified, NeedsRemediation and underwent Store/AppX remediation.

Crashpad also produced a 45 MB minidump:

• Exception: EXCEPTION_BREAKPOINT
• Exception address resolves inside the packaged chrome.dll
• No memory-exhaustion event
• No Windows display-driver TDR/reset

Expected behavior

• A conversation opens even if its persisted browser tab cannot be restored.
• After an abnormal browser/GPU termination, Codex automatically quarantines or skips the failed browser-tab state on the next launch.
• Conversation, authentication, project, and configuration state remain intact.
• The browser surface reports a recoverable error; the desktop application and AppX package remain usable.
• Recovery never requires users to manually edit internal JSON state or repair/reinstall the Store package.

Actual behavior

A browser/GPU failure crosses the browser boundary, terminates the entire desktop container, interrupts the active session, and can leave the Store package in remediation state. Persisted browser state can re-arm the same failure when the conversation is restored.

The raw minidump and full logs are not attached because they contain process memory, conversation identifiers, local paths, and project metadata. Sanitized excerpts can be provided if maintainers need them.