›_ Codex Issues
Codex Issues / #35637

[Windows][Codex App][In-App Browser] Reopening one thread restores a persisted GitLab webview and crashes Desktop across reinstalls

Resolved 💬 6 comments Opened Jul 27, 2026 by Canlendula Closed Aug 6, 2026
💡 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 (From “About Codex” dialog)?

26.721.41059

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex Desktop crashes consistently when I open one specific existing thread.

Immediately before the crash, the right-side environment/in-app-browser area restores a GitLab icon and a previously persisted GitLab webview. Codex Desktop then exits without displaying an application-level error.

After the crash, Windows reports that the Codex application package is damaged and needs to be repaired.

The failure follows this specific thread across multiple Codex Desktop reinstallations. New blank threads and other existing threads from the same repository remain stable.

The affected thread remains usable through Codex CLI.

Original browser history

During earlier troubleshooting of an unrelated GitLab MCP initialization problem, Codex attempted to inspect GitLab group settings using the Codex in-app Browser, which is the embedded Chromium/webview.

It did not use my normal Chrome profile.

The in-app Browser opened:

https://gitlab.com/dashboard/groups

The page was redirected to:

https://gitlab.com/users/sign_in

A Cloudflare / GitLab sign-in page was displayed. No credentials were entered, and no GitLab settings were modified through the browser.

The in-app-browser tab was not successfully closed or finalized afterward.

Control tests

I performed the following control tests:

  • Reinstalled Codex Desktop.
  • Opened a new blank thread: stable, with no browser/environment item.
  • Opened other existing threads from the same repository: stable.
  • Opened the affected thread: the GitLab icon reappeared, followed by a Desktop crash.
  • Completely removed the GitLab MCP registration before the latest reproduction.
  • Quarantined/reset the local Codex in-app-browser profile and its dedicated browser partition before reinstalling Codex Desktop.
  • The failure still followed the affected thread after the local browser profiles were reset.

This suggests that the crash may involve restoration or rehydration of thread-specific in-app-browser/sidebar state.

What steps can reproduce the bug?

The issue is currently deterministic for one affected thread. I have not yet reproduced the creation of the bad state from a newly created thread.

  1. Start with an existing Codex thread in which Codex previously opened a GitLab page using the Codex in-app Browser.
  2. Ensure that the GitLab MCP registration has been completely removed.
  3. Reset or quarantine the local Codex in-app-browser profile and its dedicated browser partition.
  4. Reinstall Codex Desktop.
  5. Launch Codex Desktop.
  6. Create and open a new blank thread.
  7. Observe that the blank thread remains stable.
  8. Open other existing threads from the same repository.
  9. Observe that those threads also remain stable.
  10. Open the affected thread.
  11. Observe that a GitLab icon reappears in the right-side environment/in-app-browser area.
  12. Codex Desktop exits shortly afterward.
  13. When I try to reopen Codex, Windows reports that the application package is broken.

No code snippet is involved. The crash happens while restoring the thread, before a new prompt is sent.

What is the expected behavior?

Codex Desktop should open an existing thread safely even if its persisted in-app-browser state cannot be restored.
And a browser, Chromium GPU process, or webview restoration failure should be isolated from the main application.

Additional information

Sanitized local log evidence

The same event sequence was observed across multiple crashes:

  1. Codex restores the affected thread.
  2. The in-app Browser creates and attaches a right-panel webview with: initialUrl=https://gitlab.com/users/sign_in
  3. The browser sidebar reports dom-ready.
  4. Several seconds later, the Chromium GPU child process crashes.
  5. The GPU child process fails to relaunch.
  6. The Codex Desktop/AppX container exits.

Representative sanitized events:

2026-07-27T14:19:54.398Z
IAB_LIFECYCLE renderer created browser sidebar webview
hostKind=right-panel
initialUrl=https://gitlab.com/users/sign_in

2026-07-27T14:19:54.535Z
IAB_LIFECYCLE did attach browser sidebar webview

2026-07-27T14:19:55.568Z
browser sidebar dom-ready
url=https://gitlab.com/users/sign_in

2026-07-27T14:20:00.650Z
Recoverable Chromium child process gone
exitCode=101457950
processType=GPU
reason=crashed
serviceName=GPU

2026-07-27T14:20:00.656Z
Recoverable Chromium child process gone
exitCode=18
processType=GPU
reason=launch-failed
serviceName=GPU

The same pattern was observed at least four times:

  • 13:57:05Z: GitLab webview created; 13:57:12Z: GPU process crashed.
  • 14:03:21Z: GitLab webview created; 14:03:29Z: GPU process crashed.
  • 14:19:54Z: GitLab webview created; 14:20:00Z: GPU process crashed.
  • 14:34:42Z: GitLab webview created; 14:34:48Z: GPU process crashed.

During the most recent attempt, the final relevant browser event was:

2026-07-27T14:50:08.028Z
IAB_LIFECYCLE rebound browser sidebar window

The Desktop log stopped abruptly immediately afterward.

Windows AppModel-Runtime records show that the Codex AppX container was destroyed at the same time as the Chromium GPU process crashes.

During startup, the logs also showed the bundled browser@openai-bundled plugin being temporarily removed and then reinstalled during plugin marketplace reconciliation.

However, a new blank thread remained stable during the same application startup. I am including this as a secondary observation and am not claiming that plugin reconciliation is the root cause.

Possibly related issues

Similar in-app Browser/webview crash behavior.

Similar Chromium-layer crash on Windows, although my system did not
produce a dump or confirm the same 0xC0000005 exception.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35603
  • #35635
  • #35625
  • #35566

Powered by Codex Action

Canlendula · 1 month ago

I reviewed the suggested issues. This issue is deterministic for one specific persisted thread: reopening that thread restores its GitLab in-app-browser/webview state, after which the Chromium GPU process crashes and fails to relaunch. New threads and other existing threads remain stable, and the behavior survives both Desktop reinstallation and a reset of the local in-app-browser profile.

Therefore, I think it is not a duplicate issue

wes-vkco · 1 month ago

Confirming the same deterministic failure with a persisted Cloudflare webview.

Environment:

  • Codex Desktop: 26.721.4979.0
  • Browser runtime: 26.721.41059
  • Windows 11 Home x64, build 26200
  • NVIDIA GeForce RTX 3080
  • Driver: 32.0.15.9186

In my case, one specific task previously opened https://dash.cloudflare.com/ through the Codex in-app browser. The active browser turn was interrupted.

Opening that task now restores a right-panel webview at https://dash.cloudflare.com/login. The webview reaches DOM-ready, then Codex exits approximately 5–8 seconds later.

Reproduced on three separate launches. Each crash ends with:

Recoverable Chromium child process gone
exitCode=101457950
processType=GPU
reason=crashed
serviceName=GPU

Recoverable Chromium child process gone
exitCode=18
processType=GPU
reason=launch-failed
serviceName=GPU

Other tasks remain stable. The affected task history can also be read successfully without opening its desktop window, suggesting the transcript itself is healthy and restoration of the persisted browser state is the trigger.

This appears to be the same issue as reported here, but with a direct Cloudflare dashboard/login webview and an NVIDIA RTX 3080.

DocBlack89 · 1 month ago

I reproduced what appears to be the same issue on:

  • Windows 11 Pro 64-bit, build 26200
  • Codex Desktop 26.721.4979.0
  • A local task using the in-app Browser with a Cloudflare dashboard

The affected task crashed the entire app every time it was opened, including after reinstalling the Microsoft Store package. Other tasks remained stable.

The task transcript was valid JSONL and remained readable through the thread inspection path. The relevant persisted state was located in:

%USERPROFILE%\.codex\.codex-global-state.json

under:

electron-persisted-atom-state
→ thread-browser-tabs-v1:<affected-thread-id>

The entry contained two orphaned browser-use:* tabs whose Browser storage/session identifiers no longer existed. One tab had a null restore URL.

Important persistence behavior: deleting this property while Codex Desktop was running did not work permanently. The application still held the stale state in memory and wrote it back during shutdown.

The successful recovery was:

  1. Wait for the main ChatGPT/Codex process to exit.
  2. Wait for Electron's final state write.
  3. Back up .codex-global-state.json.
  4. Remove only thread-browser-tabs-v1:<affected-thread-id>.
  5. Validate the resulting JSON.
  6. Restart Codex Desktop.

Two stale tab entries were removed. The affected task then opened successfully and its transcript remained intact.

This strongly suggests the crash is caused by task-specific in-app Browser tab restoration. Codex should discard invalid persisted tabs instead of crashing, and it would be useful to provide a supported per-task “Reset browser state” recovery action.

mkhatuntcov-korewireless · 1 month ago

Hello — I’m Codex, the assistant helping @mkhatuntcov-korewireless collect and sanitize this reproduction.

This appears to be the same bug, confirmed with another hardware configuration and three matching log sequences.

Environment

  • Codex Desktop: 26.721.4979.0
  • Bundled browser runtime/plugin: 26.721.41059
  • Windows 11 Enterprise 64-bit, build 26200
  • Intel UHD Graphics, driver 31.0.101.2137
  • NVIDIA Quadro T1000, driver 32.0.15.8195
  • Parsec Virtual Display Adapter, driver 0.45.0.0

Observed behavior

The user reports several full Codex Desktop crashes after attempting to authenticate to GitLab through the in-app Browser. Reinstalling Codex was used to recover after previous failures.

During this reproduction, the Browser navigated to a private GitLab page and was redirected to https://gitlab.com/users/sign_in, where GitLab displayed its Cloudflare security-verification page.

Sanitized Codex logs from July 28 show this sequence three times:

2026-07-28T22:00:40.593Z  GitLab sign-in DOM-ready
2026-07-28T22:00:45.586Z  GPU crashed, exitCode=101457950
2026-07-28T22:00:45.641Z  GPU relaunch failed, exitCode=18

2026-07-28T22:11:43.811Z  GitLab sign-in DOM-ready
2026-07-28T22:11:50.253Z  GPU crashed, exitCode=101457950
2026-07-28T22:11:50.265Z  GPU relaunch failed, exitCode=18

2026-07-28T22:41:56.623Z  GitLab sign-in DOM-ready
2026-07-28T22:42:01.642Z  GPU crashed, exitCode=101457950
2026-07-28T22:42:01.653Z  GPU relaunch failed, exitCode=18

In each case, the GPU process failed approximately 5–6 seconds after the GitLab/Cloudflare sign-in webview reached DOM-ready.

As a control, the same in-app Browser subsequently completed GitHub authentication and remained stable while reading and preparing this comment. This suggests the failure is not triggered by every Browser navigation and is specifically associated with the GitLab/Cloudflare sign-in webview or its persisted restoration state.

No credentials, Cloudflare challenge parameters, private GitLab project paths, browser-session identifiers, or thread identifiers are included here.

This closely matches the sequence already reported in this issue: restored or active login webview → DOM-ready → Chromium GPU crash → GPU relaunch failure → Codex Desktop failure. A supported per-task “Reset browser state” action, validation of persisted tabs before restoration, and isolation of GPU/webview failures from the main application would all help recovery.

Sanitized surrounding log lines can be provided if maintainers need them.

asully-oai · 22 days ago

this is very likely a dup of #35352