[Windows] Clicking a local HTML file link opens an IAB file:// webview and silently restarts the entire Codex Desktop app

Codex app version

OpenAI.Codex 26.707.8479.0 x64, installed from the Microsoft Store.

The same general silent-close behavior was also observed immediately before the update on package 26.707.6957.0, but the clean valid-file reproduction below is from 26.707.8479.0.

Operating system

Microsoft Windows 11 x64, build 10.0.26200.

The app is running natively on Windows:

runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

Summary

Clicking a local .html file link inside a Codex conversation opens the file in the right-panel IAB/browser sidebar. The file reaches dom-ready, then the entire Codex Desktop AppX container is silently destroyed and the app automatically relaunches several seconds later.

This is not limited to WSL paths or missing files. I reproduced it with an existing 30 KB HTML file on C:. A second, unrelated local HTML file produced the same behavior earlier.

There is no crash dialog, fresh Crashpad .dmp, Windows Application Error, or WER APPCRASH event for the reproduction. The desktop log simply stops, AppModel-Runtime records the container being destroyed, and a new Codex process is launched.

Steps to reproduce

1. Run Codex Desktop natively on Windows.
2. In a conversation, have Codex produce or reference an existing local HTML report on C:.
3. Click the local HTML link rendered in the conversation.
4. Codex creates a right-panel browser/sidebar webview with a URL similar to:

``text
file:///C:/Users/<user>/.../report.html
``

1. The document becomes visible or the sidebar begins rendering.
2. Within a few seconds, the entire Codex Desktop window freezes/closes.
3. Codex automatically relaunches in a new AppX container.

I reproduced this multiple times. A restored invalid sidebar URL can also cause repeated close/relaunch cycles.

Expected behavior

Codex should do one of the following:

• open the local HTML file in the system default browser;
• safely render it in an isolated local-file preview; or
• show a recoverable unsupported-link error.

A webview or local-file failure must not terminate the entire Desktop app or interrupt unrelated tasks.

Actual behavior

• The local file is normalized to file:///C:/... and reaches dom-ready.
• The desktop log ends abruptly shortly afterward.
• Windows destroys the complete Codex Desktop AppX container.
• Codex relaunches automatically several seconds later.
• No actionable error is shown to the user.

Reproduction timeline

Local time, UTC-03:00:

| Time | Evidence |
|---|---|
| 07:52:27 | [link-opening] Invalid link URL, initiated by mcp_app_resource |
| 07:52:31.511 | IAB renderer creates a right-panel webview with the correct file:///C:/.../report.html URL |
| 07:52:31.997 | browser sidebar dom-ready for the valid local file |
| 07:52:32.983 | Last desktop log entry; no normal shutdown sequence |
| 07:52:34 | AppModel-Runtime Event ID 217: Desktop AppX container destroyed |
| 07:52:42 | New AppX container and Codex main process created |

Sanitized log excerpt

warning [link-opening] Invalid link URL
initiator=mcp_app_resource
url="C:/Users/<user>/.../report.html"

info [electron-message-handler] IAB_LIFECYCLE renderer created browser sidebar webview
hostKind=right-panel
initialUrl=file:///C:/Users/<user>/.../report.html

warning [mcp-app-sandbox] mcp_app_sandbox.attach_unmatched
guestWebContentsId=<redacted> url=undefined urlProtocol=invalid

info [browser-sidebar-manager] browser sidebar dom-ready
interactionMode=browse
url=file:///C:/Users/<user>/.../report.html

error [electron-message-handler] Received item/started for unknown conversation
error [electron-message-handler] Conversation state not found

Windows then records:

Microsoft-Windows-AppModel-Runtime/Admin
Event ID 217
Desktop AppX container destroyed for package
OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0

Additional diagnostics

• The reproduced HTML file existed and was 30,628 bytes.
• The webview used the correct, percent-encoded Windows file:///C:/... URL.
• No new file appeared under Crashpad/reports.
• No matching Application Error, Application Hang, or Windows Error Reporting APPCRASH event was recorded.
• Crashpad/settings.dat was updated during the relaunch, but there was no crash report.
• The app had previously generated a Windows RADAR_PRE_LEAK_64 report, and some long-running desktop logs contain many unknown conversation / Conversation state not found messages. These may be aggravating factors, but they are not presented as the confirmed root cause.

Suspected component boundary

The strongest evidence points to the lifecycle boundary between:

• mcp_app_resource local-link handling;
• IAB/browser-sidebar file:// webview attachment;
• renderer conversation-state handling; and
• the AppX container/watchdog relaunch path.

The unknown conversation messages occur immediately after dom-ready, but the available evidence does not establish whether they cause the process exit or are only concurrent state corruption.

Workaround

Avoid clicking local HTML links inside Codex Desktop. Open them directly in the default external browser, for example:

Start-Process "C:\path\to\report.html"

Related issues

• #14079 — Windows local file paths are rendered/handled incorrectly
• #24847 — Browser Use blocks file:// previews before navigation
• #29230 — malformed URL closes the in-app browser sidebar
• #32040 — Browser Use/PiP can hang or close Codex after localhost navigation
• #23814 — repeated silent Windows app/window closes with browser/sidebar and conversation-state churn
• #24998 — Windows Desktop closes automatically without an actionable crash message

This reproduction is distinct because a human click on a valid local HTML link reaches dom-ready, then the complete AppX container is destroyed and automatically relaunched without a Crashpad or WER crash record.

I can provide additional targeted, sanitized log excerpts privately if needed. Full logs contain local paths and conversation metadata, so they are intentionally not attached publicly.