In-app browser Cloudflare Turnstile GPU crash leaves Windows Codex app unlaunchable

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

• #27308
• #27236

Powered by Codex Action

Additional Windows repro/evidence from another machine on Stable Codex Desktop 26.609.3341.0.

Environment:

• Codex package: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
• OS: Windows 11 Home, 10.0.22631, x64
• GPU adapters: AMD Radeon(TM) Graphics driver 30.0.13044.0; GameViewer Virtual Display Adapter driver 15.6.5.199

Observed behavior:

• The app updated from 26.608.1337.0 to 26.609.3341.0 on 2026-06-12 at about 08:14 local time.
• After the update, Codex crashed twice while using/starting the in-app Browser/webview path.
• The app could be relaunched afterward, so this did not leave the app permanently unlaunchable on this machine.

Crash evidence:

• Crashpad produced two dumps at the exact exit times: 2026-06-12 19:58:51 and 2026-06-12 23:46:30 local time.
• Both dumps have the same exception:
• exception code: 0x80000003 (EXCEPTION_BREAKPOINT)
• module: chrome.dll
• module offset: 0x142a419
• dump sizes: about 40 MB each
• Windows Application Error / WER did not record a standard APPCRASH entry for these exits.

App log evidence immediately before both crashes points to in-app browser lifecycle/webview attachment:

[browser-use-iab-api] IAB_LIFECYCLE iab backend request received ... request=executeUnhandledCommand:browser_viewport_set
[browser-session-registry] IAB_LIFECYCLE created browser use host ...
[browser-use-iab-api] IAB_LIFECYCLE iab backend request received ... request=createTab
[browser-sidebar-manager] IAB_LIFECYCLE waiting for browser sidebar webview attachment ...
[electron-message-handler] IAB_LIFECYCLE renderer created browser sidebar webview ... hostKind=hidden-browser-use initialUrl=about:blank
[browser-sidebar-manager] IAB_LIFECYCLE did attach browser sidebar webview ... guestWebContentsId=5

This looks related to the same in-app browser / Chromium crash surface, though in this case there was no confirmed Cloudflare Turnstile trigger. I am not attaching dumps publicly because they may contain local/session data, but the two dump signatures are consistent and available for private follow-up if useful.

Same behavior when codex tried to pull up the cloudflare login page with the in-app browser.

I am experiencing what appears to be the same issue on Windows.

When the Codex in-app browser navigates to a website protected by Cloudflare and the Cloudflare verification/Turnstile page appears, the entire Codex app crashes.

After the crash, Codex cannot be launched again normally. Windows shows an error directing me to the Microsoft Store, and I have to use Repair/Restore or reinstall the Codex app before it starts working again.

This has happened more than once and appears to be specifically triggered when the in-app browser encounters a Cloudflare verification page.

I can provide my Codex version, Windows version, GPU information, and relevant logs if that would help with debugging.

Additional evidence on the current Store build, with a to-the-second correlation between the Code Integrity block and the GPU crash — plus the detail that explains why the app becomes unlaunchable rather than just crashing once.

Environment

• Codex desktop package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• codex-cli 0.146.0-alpha.3.1
• Windows 11 Pro 25H2, build 26200.8875, x64
• NVIDIA GeForce RTX 5070 Ti Laptop GPU, driver 32.0.16.1074 (2026-07-02)
• AMD Radeon(TM) Graphics, driver 32.0.21043.19003 (2026-06-19)
• Parsec Virtual Display Adapter, driver 0.45.0.0
• app\vk_swiftshader.dll version 5.0.0, 5,424,640 bytes, Authenticode status NotSigned

Worth noting: this reproduces on a current discrete GPU with a three-week-old driver, so it is not limited to blocklisted or older GPUs as suggested in #35132.

Trigger

Any page embedding a Cloudflare Turnstile widget — not only the Cloudflare dashboard or login page. I reproduced it repeatedly on an ordinary site whose contact form embeds cf-turnstile (loaded from challenges.cloudflare.com). Other pages on the same origin, without the widget, load fine in the same session.

Timeline — two consecutive reproductions

20:20:54.378  browser sidebar dom-ready url=https://<site>/en/contact
20:20:56      CodeIntegrity Event 3033: ChatGPT.exe attempted to load
              app\vk_swiftshader.dll — did not meet the Microsoft signing level requirements
20:20:57.252  Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed
20:20:57.260  Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed

20:25:24.605  browser sidebar dom-ready url=https://<site>/en/contact
20:25:26      CodeIntegrity Event 3033: vk_swiftshader.dll blocked
20:25:27.170  Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed
20:25:27.178  Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed

A consistent 2.5–3 seconds elapses between DOM ready and the crash — the interval in which the Turnstile widget mounts and begins its canvas/WebGL work. The Code Integrity block lands about one second before the GPU process dies, in both runs.

Same signature as the original report. An earlier Crashpad dump on this machine matched @zzryu01-source's: exception 0x80000003 (EXCEPTION_BREAKPOINT) in chrome.dll.

Why the app becomes unlaunchable (I believe this is the missing piece)

The GPU crash on its own is a one-off. What turns it into a boot loop is browser tab persistence.

~/.codex/.codex-global-state.json holds, under electron-persisted-atom-state, keys shaped like:

"thread-browser-tabs-v1:<threadId>": {
  "tabs": [ { "restoreUrl": "https://<site>/en/contact", "...": "..." } ]
}

On launch, the app restores those tabs automatically, before any tool call or origin permission check. If a persisted URL is a Turnstile-protected page, the GPU process is killed within seconds of every startup. That is what produces the roughly 60-second death and the Microsoft Store "repair" prompt others in this thread describe — and it is why reinstalling doesn't help: this state lives outside the MSIX package, so a Store repair restores the binaries but leaves the crashing URL in place.

Workaround (no reinstall needed)

1. Fully exit Codex and confirm no ChatGPT.exe processes remain.
2. Back up ~/.codex/.codex-global-state.json.
3. Remove the thread-browser-tabs-v1:* entries whose tabs contain a Turnstile-protected restoreUrl.
4. Relaunch.

After this the app ran normally for over 20 minutes with zero GPU crashes and zero 0x3CFC activation failures, having previously died about 76 seconds into every launch. It only crashed again when the in-app browser was deliberately pointed back at the Turnstile page — and that immediately re-armed the loop, because the crashing URL was written back into thread-browser-tabs-v1 under the new thread ID.

Suggested fixes

• Do not restore persisted browser tabs before the window is interactive, or restore them suspended, so that a crash during restore cannot loop.
• Ship a vk_swiftshader.dll signed to the level the app's own Code Integrity Guard (MicrosoftSignedOnly) mitigation demands, or exempt the GPU process from that mitigation, so the software-rendering fallback can actually load.
• Treat a GPU crash in the embedded browser as a browser-tool error rather than terminating the whole app, as requested in #35352.

Additional reproduction on the current Windows Store build, with a timestamp-correlated Browser PiP / Cloudflare / Code Integrity sequence from an AMD-only system.

Environment

• Codex Desktop: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Codex app-server/runtime reported in logs: 0.146.0-alpha.3.1
• Windows 11: 10.0.26200, x64
• GPU: AMD Radeon(TM) 860M Graphics
• AMD driver: 32.0.22024.3004 (2025-10-30)

Correlated timeline

Local time is UTC+8.

20:59:31  Repeated IAB getInfo failures:
          "No ChatGPT browser route is available for browser session ..."

21:00:09  browser sidebar dom-ready
          url=https://dash.cloudflare.com/

21:00:13  Browser Use PiP metadata received, tabID=1
21:00:13  Failed to upsert Browser Use PiP content
21:00:18  Browser Use PiP metadata received, tabID=undefined

21:00:20  Code Integrity Event 3033:
          ChatGPT.exe attempted to load app\vk_swiftshader.dll,
          which did not meet Microsoft signing level requirements

21:00:20  Recoverable Chromium child process gone
          exitCode=101457950 processType=GPU reason=crashed
21:00:20  Recoverable Chromium child process gone
          exitCode=18 processType=GPU reason=launch-failed

The Codex instance log ends immediately after the two GPU-process messages. The desktop window disappeared and was later relaunched.

Additional checks

• No standard Codex/ChatGPT Application Error, Application Hang, or WER crash was recorded for this occurrence.
• No Display/AMD driver-reset or WHEA event was recorded around the failure, so this did not look like a machine-wide GPU TDR.
• The AMD adapter reported Status=OK afterward.
• Microsoft Store/AppX repair activity began only after the GPU failure. AppX subsequently repaired ACLs and re-registered the same package version.
• The active workspace and completed Git commit remained intact.

This matches the original report's Cloudflare/Turnstile trigger, Code Integrity rejection, and exact GPU exit-code pair. The preceding Browser PiP route/upsert failures may provide an additional lifecycle signal immediately before the known SwiftShader failure.

Full local logs are not attached because they contain paths, conversation IDs, and account-related state. Sanitized excerpts can be supplied if maintainers need more fields.

Additional reproduction: reopening one affected thread repeatedly restores an interrupted Browser Use state and crashes the GPU process

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Browser Use runtime observed in logs: 26.721.41059
• Codex app-server/runtime: 0.146.0-alpha.3.1
• Windows 11 Pro x64: 10.0.22631
• GPU: NVIDIA GeForce RTX 4060
• NVIDIA driver: 32.0.15.9186
• A virtual display adapter is also installed
• Affected thread ID: redacted, available privately if requested

Trigger and reproduction

1. During a research task, Browser Use opened the public SSRN page for abstract 5358509.
2. The page displayed a Cloudflare security-verification challenge.
3. The last in-flight Browser Use operation waited for the page and requested another DOM snapshot.
4. Codex then crashed.
5. Repairing or reinstalling the Microsoft Store package allowed Codex to launch again on a safe task.
6. Opening the same affected thread reproduced the Browser/GPU failure three consecutive times.
7. A new clean task remains usable when Browser Use is avoided.
8. Archiving the affected thread prevents accidental restoration of the failing state.

Relevant desktop log sequence

Received Browser Use PiP metadata ... backend=iab tabID=1 threadID=<redacted>
Failed to upsert Browser Use PiP content backend=iab tabID=1

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

When the affected thread is reopened, the logs show the thread becoming active and the IAB/WebView route being restored shortly before the same GPU-process failure.

Local state checks

• The affected rollout JSONL parses successfully.
• Rollout/state-database parity is valid.
• The Browser Use screenshot stored in the rollout is a valid 1920x1080 JPEG.
• The thread contains an unfinished Browser Use call, but there is no evidence that the whole conversation file or database is corrupt.
• codex doctor reports the Codex installation and local state databases as consistent.

This suggests that opening the thread restores or reattaches incomplete persisted IAB/Browser Use state, after which the Chromium GPU child crashes and cannot be relaunched.

I am not claiming that the PiP upsert warning is the proven root cause. It is a repeatable precursor in the captured logs.

Expected behavior

A failed or interrupted Browser Use state should be quarantined or skipped when reopening a thread.

Codex should:

• open the conversation without restoring the failing WebView;
• convert the browser failure into a recoverable tool error;
• preserve the conversation and project state;
• avoid repeatedly crashing when the same thread is opened;
• not require Microsoft Store repair or reinstall.

Sanitized desktop logs, exact timestamps, the affected thread ID, and Windows event details are available privately if maintainers provide a safe upload route. I am not attaching raw rollout files, full logs, or dumps publicly because they may contain conversation content, local paths, and session metadata.

This is reproducible by simply navigating to https://dash.cloudflare.com within a Codex thread using the internal browser.
Immediately after the login screen loads codex crashes and must be repaired.

I can reproduce the same failure signature on the same Store build and OS family. My case initially looked task-specific, but the evidence shows that the affected task is simply the one that resumes the built-in Browser path.

Environment:

• Windows 11 Pro 25H2 x64, build 26200.8875
• Microsoft Store package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• NVIDIA RTX 3070 driver 32.0.16.1047
• Intel UHD 770 driver 32.0.101.6129
• Affected task ID: 019fa851-2db4-73e2-a713-cb385b917228

The task used Browser/node_repl to open Cloudflare’s domain-registration page. Six retries produced six Code Integrity Event 3033 records for:

ChatGPT.exe -> vk_swiftshader.dll
RequestedPolicy=8
ValidatedPolicy=1
Status=0xC0000428

At each timestamp, AppModel Runtime immediately emitted Event ID 6:

0x3CFC: Cannot create the process ... while checking the machine-level
package status ... Try reinstalling the application.

Failure-window totals:

• 6 Code Integrity 3033 events
• 30 AppModel 0x3CFC errors
• 9 AppX forced repair registrations
• 1 Store remove/reinstall
• no conventional Application Error event or crash dump

Two especially tight correlations:

06:46:15.788  Browser call opens Cloudflare registration page
06:46:20.017  Browser call records completion
06:46:20.142  Code Integrity 3033

06:53:25.534  Browser call starts
06:53:28.693  Code Integrity 3033
                (the call never records completion)

The package payload is intact. I validated ChatGPT.exe and vk_swiftshader.dll block-by-block against the signed AppxBlockMap.xml:

ChatGPT.exe:       64 blocks, 0 mismatches
vk_swiftshader.dll: 83 blocks, 0 mismatches

vk_swiftshader.dll version is 5.0.0, SHA-256:

2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

Smart App Control is off and user-mode WDAC enforcement is off. All GPUs report healthy.

The task itself remains readable: after reinstall, three backend thread/read calls completed in 11 ms, 3 ms, and 10 ms with no error. This rules out a malformed/oversized transcript. Continuing the task is what re-enters the Browser/GPU path.

After enough retries, Windows shows “This app can't open — Check the Store for more info about ChatGPT,” and the Store reinstall is required.

I have a sanitized event timeline and screenshot available. I did not attach the raw task JSONL because its Browser DOM snapshots may contain signed-in account data.