Skip to content

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

Open

Description

@rafox2005

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:

    file:///C:/Users/<user>/.../report.html
    
  5. The document becomes visible or the sidebar begins rendering.

  6. Within a few seconds, the entire Codex Desktop window freezes/closes.

  7. 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

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.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Jul 13, 2026
  2. github-actions commented on Jul 13, 2026

    @github-actions
    Contributor
  3. briedle commented on Jul 13, 2026

    @briedle

    Independent reproduction on the same current Windows package, with a different local HTML workload.

    Environment

    • Microsoft Store package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
    • Native Windows / PowerShell runtime
    • Codex CLI: 0.144.1
    • Bundled Chromium manifest: 150.0.7871.115
    • in_app_browser and browser_use were enabled

    Different reproducer

    The clicked file was an existing local screenshot-gallery page rather than a report:

    file:///C:/Users/<redacted>/.../gallery/index.html
    

    Ordinary code and Markdown links continue to use their normal file-preview path. The restart happened specifically when this .html link was routed into the right-panel IAB webview.

    Sanitized timeline

    UTC:

    21:06:00.204  IAB renderer created browser sidebar webview
                    hostKind=right-panel
                    initialUrl=file:///C:/Users/<redacted>/.../gallery/index.html
    
    21:06:00.800  mcp_app_sandbox.attach_unmatched
                    guestWebContentsId=7 url=undefined urlProtocol=invalid
    
    21:06:01.253  browser sidebar dom-ready
                    interactionMode=browse
                    url=file:///C:/Users/<redacted>/.../gallery/index.html
    
    21:06:02.729  final desktop-log entry; no normal shutdown sequence
    
    21:06:14      AppModel-Runtime created the replacement Codex AppX processes
    21:06:15.223  first new desktop-session log created
    

    Immediately after webview creation, the main renderer logged:

    [desktop-notifications][global-error]
    ResizeObserver loop completed with undelivered notifications.
    
    Received item/started for unknown conversation
    Received item/completed for unknown conversation
    

    The unknown-conversation events were broadcast across the primary renderer and hidden auxiliary renderers. I am not claiming that either the ResizeObserver warning or the conversation-state errors caused the termination; they are simply the last unusual application-level events before the log stopped.

    The old session's main log ended at 21:06:02.729Z. A new desktop session began about 12.5 seconds later. Several unrelated long-running tasks were interrupted by the full-app restart.

    Crash evidence checked

    For this reproduction I found:

    • no fresh Crashpad .dmp;
    • no matching Windows Application Error, Application Hang, or WER APPCRASH event;
    • no graceful desktop shutdown sequence.

    AppModel-Runtime did record creation of the replacement AppX processes. Unlike the original report's reproduction, I did not find an Event ID 217 in the narrow checked interval, so the evidence here establishes abrupt termination plus relaunch but not the exact Windows container-destruction event.

    Possible relationship to #32683

    This installed package uses Chromium 150.0.7871.115, the same Chromium build reported in #32683, where six independent IAB reproductions produced the identical native CrBrowserMain access violation at chrome.dll+0x2e08f46.

    Because this reproduction emitted no dump, I cannot establish that exact native signature here. However, the same Chromium build, same mcp_app_sandbox.attach_unmatched / IAB attach path, DOM-ready timing, and silent full-app exit make #32683 a strong candidate for the underlying crash family.

    This also confirms the problem is not specific to the original HTML file: an independently generated local screenshot gallery triggers the same behavior on 26.707.8479.0.

  4. cis-aconiticacid commented on Aug 24, 2026

    @cis-aconiticacid

    This needs to be fixed

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