Codex App crashes when in-app browser opens a site with failed TLS / fake-ip routing

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

OpenAI.Codex_26.707.9981.0_x64

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

The Codex Windows desktop app crashes when I use the in-app browser to open:

https://jiaowu.hufe.edu.cn/sso.jsp

The website itself may be unreachable from my current network environment, but the Codex app should show a recoverable browser/network error instead of crashing the whole desktop app.

Observed evidence:

• Windows Event Viewer records a MoAppCrash for ChatGPT.exe / OpenAI.Codex.
• Exception code: 0xc06d007f.
• Faulting module: unknown.
• Codex logs include in-app browser / WebView lifecycle messages followed by “No target available”.
• Browser navigation returned ERR_CONNECTION_CLOSED.
• curl HTTPS testing failed during TLS handshake.
• Local DNS resolves jiaowu.hufe.edu.cn to 198.18.0.8, likely a mihomo fake-ip address.
• A DoH lookup showed the real IP as 59.71.96.15.

What steps can reproduce the bug?

1. Use Windows with mihomo / Meta Tunnel / TUN / fake-ip enabled.
2. Open the Codex Windows desktop app.
3. Use the Codex in-app browser / Browser Use.
4. Navigate to:

https://jiaowu.hufe.edu.cn/sso.jsp

1. Observe that the page does not load normally and the Codex desktop app may crash.

Notes:

• The website may require a specific campus network or VPN, so the network failure itself may be expected.
• The bug is that Codex crashes instead of showing a recoverable browser/network error.

What is the expected behavior?

Even if the website connection fails, the TLS handshake fails, or DNS/fake-ip routing is abnormal, Codex should only show a page loading failure or network error.

The in-app browser tab may fail or become stale, but the whole Codex desktop app should not crash.

Additional information

This appears to be a Codex in-app browser stability issue triggered by a specific network environment involving mihomo TUN/fake-ip routing and a failed HTTPS connection.

Suggested investigation areas:

• Whether the in-app browser WebView target disappears during navigation failure.
• Whether Browser Use / CDP / Playwright commands are being sent after the browser target is already unavailable.
• Whether ERR_CONNECTION_CLOSED, TLS handshake failure, or empty server replies can trigger an unhandled exception.
• Whether WebView or browser target failures are properly isolated from the main Codex desktop process.

I can provide attachments containing Windows Event Viewer excerpts, Codex log snippets, and network [diagnostics.

codex-browser-crash-report-v3-en.zip