[Windows] Codex Desktop silently exits when the in-app browser reaches DOM-ready on an external site after update to 26.707.8479.0

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

• Codex Desktop (Microsoft Store/MSIX): 26.707.8479.0

What subscription do you have?

Pro

What platform is your computer?

• Microsoft Windows 10 Pro, version 10.0.19045, 64-bit - GPU: NVIDIA GeForce GTX 1080 Ti - NVIDIA driver: 32.0.15.8253 - Codex install type: Microsoft Store/MSIX

What issue are you seeing?

Codex Desktop silently exits when its in-app browser loads https://research.kmutnb.ac.th/ (which may redirect to https://www.research.kmutnb.ac.th/login/). No error dialog is displayed. The Codex desktop log reaches the in-app browser dom-ready event for the external page and then ends abruptly, without a normal shutdown sequence.

This started immediately after the Microsoft Store update to 26.707.8479.0 on July 13, 2026. The failure can occur before any username or password is entered, so it does not appear to be caused by invalid credentials or a site authorization response.

What steps can reproduce the bug?

1. Launch Codex Desktop on Windows.
2. Open the Codex in-app browser / Browser Use panel.
3. Navigate to https://research.kmutnb.ac.th/.
4. Wait for the page to load and, if applicable, redirect to /login/.
5. Observe that the entire Codex Desktop application exits without an error message.

What is the expected behavior?

The external page should load inside the in-app browser. If the page or renderer fails, Codex should isolate the failure to the browser guest, display a recoverable error, and keep the main Codex window and active task running.

Actual behavior

The entire Codex Desktop application terminates silently shortly after the in-app browser reports dom-ready. There is no crash dialog and no recoverable browser error.

Additional information

Reproduction and timeline

The behavior was observed twice. Times below are local time (Asia/Bangkok, UTC+07:00) on July 13, 2026.

1. Codex process started at approximately 20:07:46.

• https://www.research.kmutnb.ac.th/ reached dom-ready at 20:09:42.235.
• The desktop log ended abruptly immediately afterward.

1. Codex process started at approximately 20:10:44.

• The home page reached dom-ready at 20:12:44.538.
• https://www.research.kmutnb.ac.th/login/ reached dom-ready at 20:12:45.873.
• The desktop log ended abruptly at that point.

I did not continue reproducing the failure because each attempt terminates the active Codex session.

Regression information

• Windows Reliability Monitor records successful installation of the Codex Microsoft Store update at approximately 19:52:10 on July 13, 2026.
• The previous Codex log recorded build 26.707.3748.0 and an available update to manifest build 26.707.8479.0.
• The silent-exit behavior was first observed after that update.

Control tests

• The site home page and login page both return HTTP 200 OK outside Codex.
• Chromium/Chrome with a fresh temporary profile loads the public home page successfully.
• No window.close() or self.close() call was found in the returned page HTML.
• No matching Windows Application Error event or Windows Error Reporting crash dump was found for the two exits.
• Available system memory was sufficient at the time of diagnosis.

These tests suggest that the site may trigger the failure, but the silent termination is specific to the Codex Desktop in-app browser/WebView path rather than a general site availability or Chromium failure.

Possibly relevant log observations

• An in-app browser attachment warning appeared during browser guest setup:

``text
mcp_app_sandbox.attach_unmatched guestWebContentsId=4 url=undefined urlProtocol=invalid
``

• The bundled Browser plugin was reconciled/uninstalled and installed again during startup as part of bundled marketplace synchronization.
• There was no graceful desktop shutdown line after the affected external page reached dom-ready.

The warning and plugin reconciliation may be unrelated; they are included only as potentially useful triage context.

Workaround

Opening the site in regular Chrome works. I am currently avoiding this URL in the Codex in-app browser because it can terminate the complete Codex session.

Related issues

• #23814 — Codex Desktop Windows: repeated silent app/window closes and in-app browser lifecycle activity
• #24998 — Windows Codex app closes automatically without a crash dialog
• #21824 — In-app browser disappears mid-session

This report differs in that it has a repeatable external URL trigger and the desktop log consistently stops immediately after the page or login route reaches dom-ready on Codex Desktop 26.707.8479.0.