Skip to content

Codex Desktop in-app Browser crashes the main app during webview navigation #30178

Description

@vir-tu

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

  1. Launch Codex Desktop on Windows.
  2. Open the in-app Browser/right-panel browser.
  3. Navigate to any URL such as https://github.com/.
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions