Windows Codex Desktop silently exits after in-app Browser WebView navigation; disabled Browser plugin is re-enabled on restart

Open 💬 2 comments Opened Jul 17, 2026 by SavesafetyMACD0801
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop for Windows repeatedly exits abruptly while Browser Use / the in-app browser is active. When the desktop process exits, its bundled codex app-server child process also exits, terminating all running local Codex tasks.

A related configuration issue makes the workaround ineffective: disabling browser@openai-bundled is persisted as enabled = false, but the next Codex Desktop startup reconciles/reinstalls bundled plugins and rewrites the setting to enabled = true. Browser Use then starts again.

Environment

  • OS: Windows 11 x64
  • Codex Desktop package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
  • Codex App version: 26.707.12708.0
  • Chromium: 150.0.7871.115
  • Browser plugin runtime observed in logs: 26.707.91948
  • Installation: Microsoft Store / MSIX

Observed behavior

Latest silent exit

On 2026-07-17 at 12:04:56 JST, the main desktop log ended abruptly immediately after the in-app WebView navigated to Facebook Business / Ads Manager.

The final sequence was:

  1. Repeated IAB backend getInfo calls, including:
  • No ChatGPT browser route is available for browser session ...
  1. Browser sidebar thread registration
  2. Browser Use tab and WebView creation
  3. mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid
  4. IAB WebView attachment and debugger listener setup
  5. DOM-ready navigation to a Facebook Business / Ads Manager login URL
  6. Log ends with no shutdown sequence

There was no corresponding Windows Error Reporting event, crash dump, normal shutdown entry, or Codex CLI process exited entry.

Earlier silent exits showed the same pattern immediately after the in-app browser loaded Cloudflare pages.

A separate earlier failure on 2026-07-16 at 23:26 JST was recorded as an Application Hang. Just before that hang, the log contained repeated:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications

followed by:

Recoverable Chromium child process gone exitCode=1 processType=GPU reason=killed
Codex CLI process exited ... code=1
fatal_error_broadcasted

Browser disable setting is reverted on startup

At 11:55 JST, disabling Browser in Settings successfully produced:

[plugins."browser@openai-bundled"]
enabled = false

and config/batchWrite completed successfully.

After Codex Desktop was relaunched at 14:17 JST, startup logs showed:

bundled_plugin_uninstall_requested pluginId=browser@openai-bundled reason=not_in_bundled_marketplace_plugin_names
plugin_uninstall_succeeded
bundled_plugin_install_requested ... pluginName=browser reason=missing
plugin_install_succeeded
bundled_plugins_reconcile_completed hasExternalPluginStateSync=true reason=startup

At approximately the reconciliation completion time, config.toml was atomically recreated and now contained:

[plugins."browser@openai-bundled"]
enabled = true

The same new session then logged multiple:

browser_use_iab_backend_startup_started
browser_use_iab_backend_startup_ready
IAB_LIFECYCLE created browser use host

So the disabled state did not survive the startup reconciliation.

Steps to reproduce

The crash itself is intermittent, but this is the repeatedly observed pattern:

  1. Start Codex Desktop on Windows.
  2. Run one or more local Codex tasks.
  3. Use Browser Use / the in-app browser to navigate through a complex login or challenge page (observed with Cloudflare and Facebook Business / Ads Manager).
  4. Codex Desktop silently disappears or hangs.
  5. Running local tasks terminate with the desktop-owned app-server process.

The configuration reset is consistently observable:

  1. Disable the bundled Browser plugin in Codex Settings.
  2. Verify config.toml contains enabled = false.
  3. Fully quit and restart Codex Desktop.
  4. During startup, bundled-plugin reconciliation uninstalls/reinstalls the Browser plugin.
  5. Verify config.toml now contains enabled = true.
  6. Browser Use/IAB starts again.

Expected behavior

  • Browser/WebView child process failures should not terminate or hang the Codex Desktop main process.
  • A desktop UI crash should not terminate running local tasks if task isolation/recovery is possible.
  • Explicitly disabling the bundled Browser plugin should persist across restarts.
  • Bundled-plugin reconciliation should not override the user's disabled state.
  • If Browser Use cannot establish a valid route, it should fail cleanly without creating inconsistent WebView/session state.

Additional diagnostics

  • Available physical memory and commit capacity were healthy at the time of investigation.
  • SQLite quick checks for state_5.sqlite and logs_2.sqlite returned ok.
  • No Windows System GPU reset/TDR event was recorded at the confirmed hang time.
  • The desktop process owns a bundled codex.exe ... app-server child, explaining why all app-hosted local tasks stop when the parent exits.
  • Sanitized log excerpts or additional targeted diagnostics can be provided on request.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32798
  • #33332
  • #33514
  • #32683

Powered by Codex Action

glzjin · 1 month ago

Regression confirmation on 26.721.3996.0 (Windows 11)

I observed the same class of silent Codex Desktop disappearance on 2026-07-24 around 15:38 UTC+8.

Environment

  • Windows 11 x64
  • Codex Desktop / MSIX version: 26.721.3996.0

Sanitized timeline

  • 15:38:05 — Browser Use created and attached a sidebar WebView.
  • 15:38:36–15:38:38 — the primary renderer emitted six consecutive errors:

``text
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications
``
The log still reported the primary window as focused and visible.

  • The visible Codex window disappeared around this point.
  • Background/main-process logging continued briefly with normal-looking activity.
  • 15:39:06 — the Browser Use route was torn down:

``text
IAB_LIFECYCLE unregistered debugger listener reason=manual webContentsDestroyed=false
IAB_LIFECYCLE browser sidebar guest torn down
IAB_LIFECYCLE closed browser sidebar page
``

  • The desktop log then ended without a graceful shutdown or fatal marker.
  • 15:39:12 — Explorer launched the registered MSIX Codex application again.

Crash checks

No matching evidence was found in:

  • Windows Application Error / Application Hang events
  • Windows Error Reporting
  • Crash dumps
  • GPU reset/TDR events

The Sentry session was recorded as status=ok, errors=0.

For transparency: at the incident time I was running a local diagnostic copy of the same 26.721.3996.0 build with only the Windows WMI telemetry/process sampler disabled while investigating severe WmiPrvSE.exe CPU usage. No Browser Use, WebView, renderer, or window-lifecycle code was changed. The registered, unmodified MSIX build was launched afterward.

This occurrence looks closer to a silent Browser Use/window lifecycle failure than the native chrome.dll crash signature in #32683.