What version of the Codex App are you using (From “About Codex” dialog)?
26.623.3763.0
What subscription do you have?
API
What platform is your computer?
Microsoft Windows 11 Pro, version 10.0.26200, x64
What issue are you seeing?
Summary
Codex Desktop crashes or exits when the in-app Browser opens an arbitrary real web page. The issue still reproduces after updating Codex Desktop from 26.616.10790.0 to 26.623.3763.0.
The strongest captured evidence from the previous version shows a native access violation in the bundled Chromium/Electron chrome.dll during the in-app Browser webview attach/navigation flow. After the update, Codex logs still show the same in-app Browser lifecycle sequence immediately before the app exits.
What steps can reproduce the bug?
Steps to reproduce
- Launch Codex Desktop on Windows.
- Open the in-app Browser/right-panel browser.
- Navigate to any URL such as
https://github.com/.
- Observe the main Codex app process crash/exit and the app restart state afterward.
The same symptom has also been observed when opening arbitrary web pages and localhost pages, not only GitHub.
What is the expected behavior?
No response
Additional information
Current environment
- OS: Microsoft Windows 11 Pro, version
10.0.26200, x64
- GPU: NVIDIA GeForce RTX 4060
- GPU driver:
32.0.16.1062, driver date 2026-06-11
- Current Codex AppX package:
OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0
- Current Codex AppX version:
26.623.3763.0
- Current
Codex.exe file/product version: 149.0.7827.197
- Current bundled
chrome.dll file/product version: 149.0.7827.197
- Current bundled Browser plugin cache version observed locally:
26.623.31443
Current-version log evidence
After updating to Codex AppX version 26.623.3763.0, a new repro still follows the same in-app Browser lifecycle path.
Relevant log directory:
<UserProfile>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\26
Observed in:
codex-desktop-ae228db3-50a2-4419-b6c9-cd51b33a47a6-12880-t0-i1-033626-0.log
Key lifecycle events:
2026-06-26T03:37:08.718Z: renderer created browser sidebar webview with initialUrl=https://github.com/
2026-06-26T03:37:08.724Z: browser sidebar webview attach token created
2026-06-26T03:37:08.780Z: mcp_app_sandbox.attach_unmatched while URL is about:
2026-06-26T03:37:08.781Z: runtime attached browser sidebar webview
2026-06-26T03:37:08.982Z: browser sidebar dom-ready at about:blank#codex-browser-sidebar-attach-token=...
Observed again in:
codex-desktop-3c056cee-ef33-4175-9bf5-1d3e2c7a3390-13048-t0-i1-033718-0.log
Key lifecycle events:
2026-06-26T03:38:37.630Z: renderer created browser sidebar webview with initialUrl=https://github.com/
2026-06-26T03:38:37.633Z: browser sidebar webview attach token created
2026-06-26T03:38:37.661Z: mcp_app_sandbox.attach_unmatched while URL is about:
2026-06-26T03:38:37.662Z: runtime attached browser sidebar webview
2026-06-26T03:38:37.787Z: browser sidebar dom-ready at about:blank#codex-browser-sidebar-attach-token=...
2026-06-26T03:38:38.540Z: browser sidebar dom-ready at https://github.com/
This matches the earlier crash window: after the temporary attach-token page is ready, and before or very early in real URL navigation/rendering.
Native crash evidence from previous version
The earlier version OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0 produced a captured SilentProcessExit dump from the same in-app Browser repro path.
Captured process evidence:
- Exiting main process dump:
exiting-19916.dmp
- Initiating crashpad-handler dump:
initiating-5432.dmp
- Main process binary:
Codex.exe
- Faulting module: bundled
chrome.dll
- Faulting
chrome.dll file/product version: 149.0.7827.115
- Exit code:
3221225477 / 0xC0000005
CDB recovered exception:
ExceptionAddress: 00007fff59fae5b6 (chrome!GetHandleVerifier+0x1ef976)
ExceptionCode: c0000005 (Access violation)
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000558
Attempt to read from address 0000000000000558
Disassembly at the exception address:
00007fff`59fae5b6 488b8158050000 mov rax,qword ptr [rcx+558h]
Because the attempted read address was 0x558, this is consistent with a null object/base dereference inside native Chromium/Electron code.
Note: public symbol names around chrome.dll may be approximate without private symbols. The reliable facts are the module, exception code, attempted read address, faulting instruction, and surrounding in-app Browser lifecycle timing.
What appears less likely
- This does not look like an ordinary JavaScript exception.
- This does not look like a recoverable webview load error handled by Codex JS; the app exits before a useful handled error path is logged.
- A stale Browser plugin cache was a possible earlier concern, but after the update the observed Browser plugin cache is
26.623.31443, so an old 26.616.* plugin cache mismatch is no longer the primary explanation.
- The
mcp_app_sandbox.attach_unmatched message is probably not the direct cause by itself. It appears during the expected temporary about: attach-token phase in both old and new logs.
- No new Codex WER/CrashDumps entry was found in the checked default locations after the update. SilentProcessExit/IFEO monitoring had already been cleaned up, so no fresh full dump was expected for the updated repro.
What version of the Codex App are you using (From “About Codex” dialog)?
26.623.3763.0
What subscription do you have?
API
What platform is your computer?
Microsoft Windows 11 Pro, version
10.0.26200, x64What issue are you seeing?
Summary
Codex Desktop crashes or exits when the in-app Browser opens an arbitrary real web page. The issue still reproduces after updating Codex Desktop from
26.616.10790.0to26.623.3763.0.The strongest captured evidence from the previous version shows a native access violation in the bundled Chromium/Electron
chrome.dllduring the in-app Browser webview attach/navigation flow. After the update, Codex logs still show the same in-app Browser lifecycle sequence immediately before the app exits.What steps can reproduce the bug?
Steps to reproduce
https://github.com/.The same symptom has also been observed when opening arbitrary web pages and localhost pages, not only GitHub.
What is the expected behavior?
No response
Additional information
Current environment
10.0.26200, x6432.0.16.1062, driver date2026-06-11OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g026.623.3763.0Codex.exefile/product version:149.0.7827.197chrome.dllfile/product version:149.0.7827.19726.623.31443Current-version log evidence
After updating to Codex AppX version
26.623.3763.0, a new repro still follows the same in-app Browser lifecycle path.Relevant log directory:
Observed in:
Key lifecycle events:
2026-06-26T03:37:08.718Z: renderer created browser sidebar webview withinitialUrl=https://github.com/2026-06-26T03:37:08.724Z: browser sidebar webview attach token created2026-06-26T03:37:08.780Z:mcp_app_sandbox.attach_unmatchedwhile URL isabout:2026-06-26T03:37:08.781Z: runtime attached browser sidebar webview2026-06-26T03:37:08.982Z: browser sidebardom-readyatabout:blank#codex-browser-sidebar-attach-token=...Observed again in:
Key lifecycle events:
2026-06-26T03:38:37.630Z: renderer created browser sidebar webview withinitialUrl=https://github.com/2026-06-26T03:38:37.633Z: browser sidebar webview attach token created2026-06-26T03:38:37.661Z:mcp_app_sandbox.attach_unmatchedwhile URL isabout:2026-06-26T03:38:37.662Z: runtime attached browser sidebar webview2026-06-26T03:38:37.787Z: browser sidebardom-readyatabout:blank#codex-browser-sidebar-attach-token=...2026-06-26T03:38:38.540Z: browser sidebardom-readyathttps://github.com/This matches the earlier crash window: after the temporary attach-token page is ready, and before or very early in real URL navigation/rendering.
Native crash evidence from previous version
The earlier version
OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0produced a captured SilentProcessExit dump from the same in-app Browser repro path.Captured process evidence:
exiting-19916.dmpinitiating-5432.dmpCodex.exechrome.dllchrome.dllfile/product version:149.0.7827.1153221225477 / 0xC0000005CDB recovered exception:
Disassembly at the exception address:
Because the attempted read address was
0x558, this is consistent with a null object/base dereference inside native Chromium/Electron code.Note: public symbol names around
chrome.dllmay be approximate without private symbols. The reliable facts are the module, exception code, attempted read address, faulting instruction, and surrounding in-app Browser lifecycle timing.What appears less likely
26.623.31443, so an old26.616.*plugin cache mismatch is no longer the primary explanation.mcp_app_sandbox.attach_unmatchedmessage is probably not the direct cause by itself. It appears during the expected temporaryabout:attach-token phase in both old and new logs.