›_ Codex Issues
Codex Issues / #23814

Codex Desktop Windows: repeated silent app/window closes and sidechat becomes non-interactive after running

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

What version of the Codex App are you using?

Codex Desktop on Windows, installed package observed locally:

  • OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0
  • Desktop log release annotation: 26.519.21041
  • Electron annotation in crashpad process: 42.1.0

Previous package immediately before update/hang:

  • OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0

What operating system are you using?

Windows 11, Windows build observed in WER report:

  • 10.0.26100.8457.amd64fre.ge_release.240331-1435

What happened?

I am seeing two likely related Codex Desktop issues on Windows after the 26.519 update:

  1. Codex Desktop repeatedly closes or drops the active window/session without an obvious Windows crash report. This happened around four times within roughly an hour.
  2. A sidechat can run for a while and then becomes non-interactive: I cannot type into it and it does not respond, as if the UI/session state is stuck.

The first close today appears to have happened during a Windows app update, but later closes/restarts do not appear to be normal update behavior.

Timeline / evidence

All times below are local machine time, Europe/Copenhagen, 2026-05-21.

Update-time hang

Windows Event Viewer recorded:

  • 00:41:59 Windows started installing update 9PLM9XGG6VKS-OpenAI.Codex
  • 00:42:34 Application Hang: Codex.exe version 2886.0.0.0 stopped interacting with Windows and was closed
  • 00:42:35 Windows successfully installed 9PLM9XGG6VKS-OpenAI.Codex

WER report details:

  • EventType: MoAppHang
  • Target app: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0!App
  • FriendlyEventName: Stopped responding and was closed
  • AppPath: ...\OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0\app\Codex.exe
Repeated later restarts / false closes

After the update, the desktop log sessions show multiple fresh Codex main-process sessions:

  • session ending/last write around 05:17:07
  • new session created around 05:17:13
  • session ending/last write around 05:25:02
  • new session created around 05:25:10
  • session ending/last write around 05:28:56
  • new session created around 05:29:12

For these later closes, I did not find corresponding Windows Application Error, Application Hang, or Crashpad dumps. The Codex desktop logs simply stop and a new main process/session starts.

Relevant desktop log patterns

Immediately before or around these restarts, the desktop logs are dominated by in-app browser / sidebar lifecycle and conversation-state errors. Examples:

IAB_LIFECYCLE rebound browser sidebar window ownerWebContentsId=1 previousOwnerWebContentsId=1 windowId=1
IAB_LIFECYCLE resolved browser use route conversationId=... ownerWebContentsId=1 turnId=... windowId=1
IAB_LIFECYCLE browser sidebar guest torn down conversationId=... guestWebContentsId=... windowId=1

Repeated state errors also appear:

error [electron-message-handler] Item not found in turn state itemId=call_...
error [electron-message-handler] Received turn/started for unknown conversation conversationId=...
error [electron-message-handler] Received turn/completed for unknown conversation conversationId=...

On restart/resume, the logs show interrupted turns marked as streaming:

maybe_resume_success conversationId=... latestTurnStatus=interrupted markedStreaming=true turnCount=...

For the sidechat freeze / non-interactive issue, this looks suspicious because the UI may be resuming an interrupted/stale turn as markedStreaming=true, while conversation state has already lost or mismatched the turn/tool items. After that, the sidechat can appear stuck: input unavailable and no response.

There are also repeated startup feature-protocol mismatch errors after restart:

Request failed conversationId=none error={"code":-32600,"message":"unsupported feature enablement `auth_elicitation`: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation"} method=experimentalFeature/enablement/set

Expected behavior

  • Codex Desktop should not silently close/restart the active app window/session after the update.
  • If the app/server/session is restarted, sidechat state should recover cleanly.
  • A sidechat should not become permanently non-interactive after a long-running or interrupted turn.
  • If a turn is interrupted or the conversation is unknown/stale, the UI should clear the busy/streaming state and re-enable input or show a recoverable error.

Actual behavior

  • The app/window appears to close or restart repeatedly without Windows recording a crash for the later events.
  • Sidechat can become stuck after running for a while: user cannot write into it and it does not respond.
  • Logs show unknown conversation events, missing turn-state items, interrupted turns being resumed as streaming, and heavy in-app browser/sidebar lifecycle churn.

Notes

I am intentionally not attaching full local logs because they contain local paths and potentially sensitive user/session metadata. I can provide targeted sanitized excerpts if helpful.

The repeated later false closes look distinct from the initial update-time hang. The initial hang correlates with Windows replacing the app, but the later restarts do not show as Windows app crashes and appear more related to Codex Desktop UI/session/browser-sidebar state.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22655
  • #23725
  • #23644
  • #23035

Powered by Codex Action

dagagemaster · 1 month ago

I can now reproduce a closely matching silent exit deterministically on Windows, and the trigger appears narrower than general browser/sidebar activity.

Environment:

  • Codex Desktop (Microsoft Store): 26.707.8479.0
  • No Application Error/Hang event and no Crashpad minidump were produced for these exits.

Reproduction matrix:

  1. Open the account usage-details link in the right in-app browser and leave the panel open -> the app exits.
  2. Open the right browser manually, navigate to the same OpenAI help URL, and leave it open -> the app exits.
  3. Open it manually, navigate to https://www.google.com/, and leave it open -> the app exits.
  4. Open the right browser and leave the tab blank -> stable; no exit.

The panel does not need to be closed, and the behavior is not specific to one website. Browser Use automation is also not required; manual navigation reproduces it.

Desktop log sequence from three page-load reproductions:

  • renderer created browser sidebar webview
  • guest webContents attaches
  • browser sidebar dom-ready
  • the Desktop log stops almost immediately
  • AppModel Runtime records the Desktop AppX container being destroyed 43, 71, and 48 seconds after dom-ready

The strongest control case was Google:

  • the blank browser tab remained stable for approximately 8 minutes 52 seconds
  • after navigating to Google, the guest webview/renderer was created
  • dom-ready occurred at 09:12:16
  • the Desktop log stopped on that line
  • the AppX container was destroyed approximately 48 seconds later

This suggests that the trigger is real-page navigation/guest webview renderer creation, or its post-navigation IAB lifecycle/watchdog, rather than browser-tab initialization, closing the panel, or a particular website.

Recurring WindowsApps/EFS copy failures (errno=-4094, EXDEV) are also present on this machine, but they occur during stable blank-tab sessions as well, so they do not appear sufficient to cause the exit by themselves.

Expected: Codex Desktop remains running while an in-app browser page is displayed.

Actual: The complete app exits silently 43-71 seconds after dom-ready.

I have retained targeted timestamps and sanitized log excerpts if maintainers need additional details.

joseroldanortiz · 1 month ago

Additional reproduction on 26.707.9981.0 + stale Browser plugin cache finding

I can reproduce the silent exit on another Windows installation, and found an additional startup/plugin-cache failure that may explain repeated closes after the initial Browser-triggered exit.

Environment

  • Windows 10 22H2, build 19045, x64
  • Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
  • Desktop/browser release annotation: 26.707.72221
  • Chromium/Electron runtime annotation: 150.0.7871.115

Reproduction

  1. Ask Codex to use the bundled in-app Browser.
  2. Navigate a new in-app tab to https://example.com/.
  3. Browser automation successfully returns the title, URL, and DOM snapshot.
  4. The Codex Desktop window exits silently during that run.

This reproduced twice. Windows Event Viewer and Reliability Monitor recorded no Application Error/Hang, and no Crashpad report was created.

Additional startup evidence

After reopening Codex, the desktop telemetry contained:

[AppServerConnection] plugin_uninstall_failed
failed to uninstall plugin: failed to remove existing plugin cache entry:
Access is denied. (os error 5)
pluginId=browser@openai-bundled

[bundled-plugins] bundled_plugins_reconcile_failed
hasExternalPluginStateSync=true reason=startup

The affected cache was under:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.707.72221

Its ACL contained explicit deny entries for sandbox-style SIDs that did not match the machine's current CodexSandboxOffline / CodexSandboxOnline account SIDs. I cannot prove those stale ACL entries caused the silent exit, but they correlate directly with the app's Access is denied cleanup failure.

Workaround used

codex plugin remove browser@openai-bundled --json

The command succeeded, the stale Browser cache directory was removed, and codex plugin list no longer showed Browser as installed. The Chrome, Computer Use, and Visualize plugins remained enabled. The current Codex process remained stable after removal.

This is a mitigation, not a functional Browser fix: it disables the bundled in-app Browser. A possible follow-up area is whether an IAB-triggered exit leaves Browser plugin state/cache in a form that makes the next bundled-plugin reconciliation fail and contributes to subsequent silent closes even when Browser is not invoked again.

sheljong · 1 month ago

I can corroborate this on a much newer Windows Store build, with a long tool-heavy turn producing closely matching UI/session-state symptoms.

Environment

  • Microsoft Store package: OpenAI.Codex 26.721.4979.0
  • Version shown in About: 26.721.41059
  • Windows x64, OS build 26200
  • Multi-monitor environment (two 3840x2160 display records)
  • Local Git repository: approximately 1.428 GiB / 17,461 files

Most recent occurrence

  • Date/time: July 25, 2026, approximately 9:27 PM PDT
  • Task ID: 019f9c08-d73d-7951-a7e3-0fa5521b799f
  • Interrupted turn ID: 019f9ca4-8efa-7f82-b844-615468f3e84b
  • The app exited during a long implementation/validation turn while a clean managed build was starting. After restart, the active turn was recorded as interrupted. Source edits remained on disk, but the build was terminated.

Log observations

The captured desktop session showed:

  • Duplicate reasoning-summary events delivered to both the primary renderer and an avatarOverlay renderer/WebContents.
  • Repeated ResizeObserver loop completed with undelivered notifications global errors.
  • Repeated Item not found in turn state errors, including tool-call item IDs that had already produced file-change events.
  • In the filtered diagnostic excerpt: 685 ResizeObserver errors, 64 missing-item errors, 969 avatarOverlay references, and 553 references to the affected task ID.

There was no matching Windows Application Error or Windows Error Reporting event between 9:20 PM and 9:35 PM PDT. A local monitor did capture a 49,172,256-byte Crashpad dump at 9:27:31 PM.

Scope isolation

This originally appeared correlated with a repository containing a large amount of tracked generated evidence. I removed approximately 163 MB / 1,945 generated evidence files, permanently ignored the raw generated paths, verified zero tracked raw-evidence files, and recovered into blank tasks. The later crash still occurred with those safeguards intact, so tracked generated evidence may amplify turn size but is not sufficient to explain the failure.

The strongest common signal with this issue is renderer/turn-state divergence during a long active turn followed by a silent app exit without a WER/Application Error event.

I submitted the detailed diagnostic PDFs through OpenAI Support and also used the in-app Bug feedback form with current session/browser logs enabled. The raw dump and full logs were kept out of this public issue because they may contain sensitive process/session data.