[Windows Desktop regression][26.715.10079.0] Authenticated startup crashes in bundled chrome.dll at two stable offsets

What version of the Codex App are you using?

• Microsoft Store package: OpenAI.Codex 26.715.10079.0 (x64)
• Internal desktop client version reported by logs: 26.715.72359
• Desktop host / bundled Chromium file version: 150.0.7871.124
• Electron metadata in the signed package: 42.3.0

What subscription do you have?

Not included. The failure is a local native crash in the signed Windows client.

What platform is your computer?

• Windows 11 Pro 25H2, build 26200.8875
• x64
• Microsoft Store/MSIX installation

What issue are you seeing?

After normal activation from the taskbar, Start menu, or the registered AppUserModelId, the window appears briefly and the whole app exits. AppX activation succeeds; this is a post-activation native crash in the desktop host, not an activation or package-registration failure.

Crashpad dumps consistently report:

Faulting application: ChatGPT.exe 150.0.7871.124
Faulting module: chrome.dll 150.0.7871.124
Exception code: 0xC0000005
Observed native offsets:
  chrome.dll+0x6182AB0
  chrome.dll+0x3ABDC00
Process exit code: 3221225477 (0xC0000005)

The smaller +0x6182AB0 dump recurs during quick exits. The larger +0x3ABDC00 dump recurs in runs that survive longer before exiting.

In one normal launch, desktop logs completed runtime-configuration selection, mounted the main routes, changed the browser pane from unavailable to available, and began in-app-browser/sidebar route registration. The process crashed approximately 0.3 seconds later at chrome.dll+0x6182AB0.

In another launch with hardware acceleration disabled through Chromium's documented Local State preference, the app completed route mounting and the in-app-browser backend reported ready. It crashed approximately 0.5 seconds later at chrome.dll+0x3ABDC00.

The timing strongly narrows the trigger to the authenticated post-login renderer path around runtime-feature and in-app-browser/sidebar initialization. It does not prove that one specific feature flag is the faulty source line.

What steps can reproduce the bug?

1. Install Microsoft Store package OpenAI.Codex 26.715.10079.0 on Windows x64.
2. Sign in to Codex Desktop.
3. Activate the app normally from the taskbar, Start menu, or OpenAI.Codex_2p2nqsd0c76g0!App.
4. The window appears and the application exits after several seconds.
5. A new Crashpad dump is generated with one of the two chrome.dll offsets above.

The taskbar pin resolves to the correct AppUserModelId. The same failure occurs with direct normal AppX activation, so the pin is not the cause.

Isolation results

• AppX activation and package registration succeed.
• A clean application-data test still crashes at chrome.dll+0x6182AB0.
• Same-version Store reinstall/restaging succeeds but does not change the crash.
• A completely isolated Codex home remains open for more than two minutes while signed out.
• The same isolated home crashes after sign-in state is restored, reaching chrome.dll+0x3ABDC00 after about 26 seconds. This makes the authenticated post-login path a critical trigger and rules out the original conversation history/configuration as a necessary cause.
• Setting browser_use=false and in_app_browser=false changes the UI state to browser-pane-disabled, but IAB sidebar routes are still registered and the native crash remains.
• Disabling Chromium hardware acceleration through hardware_acceleration_mode.enabled=false does not prevent the crash.
• A controlled A/B test with observed third-party overlay/injection processes held off does not prevent the crash. They are not a necessary condition for this build's failure.
• No matching Defender, Code Integrity, or application-control block was found.
• WebView2 is not the faulting runtime; the crashing module is the app-bundled chrome.dll.
• Microsoft Store currently offers no build newer than 26.715.10079.0 on the affected system.

Expected behavior

The signed Windows client should remain open after authentication. Runtime feature selection and in-app-browser/sidebar initialization should not cause a native Chromium access violation. If an optional browser component fails, the client should disable that component and surface an actionable error instead of terminating the entire desktop host.

Probable product-level cause

The evidence supports a regression in package 26.715.10079.0 / internal client 26.715.72359, triggered in the authenticated post-login renderer path while runtime features and IAB/sidebar state initialize. The two stable chrome.dll offsets indicate a native Chromium/Electron failure. Without OpenAI's matching symbols and source revision, the exact invalid object, callback, or source line cannot be identified from the public client alone.

This appears distinct from:

• #34907, which reports CPU saturation and KERNELBASE.dll failures on the same Store package.
• #34107, where third-party DLL injection was a necessary cause on an earlier build. In this case, a controlled no-respawn isolation still reproduced the crash.

Privacy and diagnostics

No raw dumps, application logs, session files, prompts, account identifiers, usernames, SIDs, machine names, local paths, or authentication material are attached. Crash dumps are retained locally because they may contain private process memory. A narrowly scoped dump or symbolicated excerpt can be provided through a private maintainer-approved channel if requested.