›_ Codex Issues
Codex Issues / #35311

[Windows][26.721.4979.0] In-app Browser incident during Microsoft Store update-log lookup: startup crash loop, package remediation, and persistent deep-control timeouts

Resolved 💬 10 comments Opened Jul 25, 2026 by lby0707 Closed Aug 7, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows Codex Desktop 26.721.4979.0, a routine request to check the ChatGPT/Codex update notes in Microsoft Store developed into a two-stage in-app Browser incident:

  1. Codex crashed, became unlaunchable, and entered a repeated startup-crash loop while restoring the previous task/window/browser state.
  2. Windows Repair and isolation of the restored fault state recovered normal application startup, but Browser Use itself remained broken. Even after a later clean uninstall, deletion of the local .codex directory, official reinstall, and Windows reboot, deeper DOM, Playwright, CDP, and screenshot operations still timed out and reset node_repl.

The application currently launches normally and the project data was not lost, but Browser Use remains unusable for actual page inspection.

This report separates:

  • the earlier app/package/startup incident,
  • the recovery process,
  • and the current persistent Browser Use control failure.

I am not claiming that all three have one confirmed root cause.

---

Environment

  • Product: Codex Desktop for Windows
  • Distribution: Microsoft Store / MSIX
  • App version: 26.721.4979.0
  • Platform: Windows x64
  • Authentication: ChatGPT account
  • Browser paths tested:
  • Codex in-app Browser (iab)
  • bundled Chrome extension route

Browser Use had previously worked normally on this same computer for inspecting local frontend projects.

---

Original user request

The incident began with a normal, low-risk task.

I asked the Codex agent to:

Check the ChatGPT/Codex update notes in Microsoft Store.

I did not ask it to modify Windows, install or remove software, change the registry, debug the GPU, or perform any destructive system action.

---

Incident timeline

1. Browser Use was initialized to inspect Microsoft Store information

The agent initialized the Browser Use runtime and opened a browser result related to Microsoft Store / apps.microsoft.com, through a Bing search page.

The browser tab could be created and the page appeared to load.

The agent then attempted a deeper page operation, including waiting for page readiness and reading page/DOM state.

The Browser Use operation did not return and ended with:

js execution timed out; kernel reset, rerun your request

The JavaScript / Node REPL environment was reset.

2. Codex later crashed and became unlaunchable

During the same overall incident, Codex began closing or crashing and could no longer be opened normally.

Windows displayed an application activation dialog equivalent to:

Unable to open this app. Check Microsoft Store for more information or assistance.

Package diagnostics during the incident showed an abnormal package state:

Modified, NeedsRemediation

Windows Code Integrity logs also recorded Event ID 3033 involving:

ChatGPT.exe
vk_swiftshader.dll

The event indicated that the packaged DLL did not meet the Microsoft signing-level requirement applied to the process.

This event occurred in the same incident sequence, but I am not claiming that it has been proven to be the sole cause of every later symptom.

3. The previous fault state was automatically restored during startup

After repair or relaunch attempts, Codex attempted to restore the state that had been active when the Browser Use failure occurred.

The restored state included:

  • the original task in which the Browser Use operation failed,
  • the previous Codex window state,
  • the associated in-app Browser session,
  • the Bing / Microsoft Store-related browser tab,
  • and possibly an unfinished Browser Use operation.

When this previous state was restored, Codex could crash again shortly after startup.

This created a repeated startup-crash loop:

  1. Codex was repaired or relaunched.
  2. The previous task/window/browser state was restored.
  3. The faulting browser state appeared again.
  4. Codex became unstable or exited again.

---

Recovery required two separate measures

The startup recovery was not achieved by one generic reset.

Two different actions were required, and they addressed different parts of the failure.

A. Windows application Repair

Windows Repair was used to recover the Codex MSIX application itself.

Before Repair:

  • Codex could not be launched normally.
  • Windows displayed the “Unable to open this app” dialog.
  • The package had reported an abnormal remediation state.

After Repair:

  • the application could launch again,
  • application activation was restored,
  • and the package later returned to a normal status.

Repair recovered the application package and startup ability.

It did not restore Browser Use functionality.

B. Isolation of the restored fault state

Separately, the original faulting state was prevented from automatically loading again.

The isolated state included:

  • the task where the Browser Use failure occurred,
  • the old application window state,
  • the associated in-app Browser session,
  • and the restored Bing / Microsoft Store browser tab.

After this state was isolated, the repeated startup-crash loop stopped.

This establishes that restoration of the old task/window/browser state was an important condition for the repeated crash-after-launch behavior.

It does not prove that the restored state caused the original Code Integrity, GPU, Chromium, or package failure.

Recovery result

The combination of Repair and state isolation achieved the following:

  • Windows Repair restored application activation and startup.
  • State isolation prevented the faulting task/window/browser state from being restored and retriggering the startup loop.
  • Codex became launchable again.
  • Existing project files remained intact.
  • After the original project was added again, the existing project conversations were visible.

The startup incident was therefore recovered.

However, Browser Use itself was not repaired.

---

Browser Use behavior after startup recovery

After the main application could launch normally again, the in-app Browser could still perform some surface-level actions:

  • initialize the Browser Use runtime,
  • create and close tabs,
  • navigate to a public webpage,
  • visibly display the page,
  • read basic tab metadata such as URL or title in some tests.

However, deeper browser-control operations repeatedly hung or timed out.

Affected operations included:

  • reading the first h1,
  • reading DOM content,
  • Playwright evaluation,
  • Runtime.evaluate,
  • Page.getFrameTree,
  • Browser.getVersion,
  • Target.getTargets,
  • Page.captureScreenshot.

The failure normally ended with:

js execution timed out; kernel reset, rerun your request

This destroyed and recreated the node_repl environment instead of returning a recoverable Browser Use error.

---

Minimal reproduction after clean reinstall

The final reproduction was performed after:

  • normal uninstall,
  • deletion of %USERPROFILE%\.codex,
  • official Microsoft Store reinstall,
  • Windows reboot,
  • and creation of a fresh projectless task.

No old task, rollout, browser state, cache, or project data was restored before this test.

Steps

  1. Start Codex Desktop.
  2. Open a fresh projectless task.
  3. Initialize the in-app Browser.
  4. Create a new tab.
  5. Navigate to:
https://example.com
  1. Read the first h1 element.

Actual result

  • Tab creation succeeded in approximately 883 ms.
  • Navigation succeeded in approximately 21.5 seconds.
  • The page was visibly displayed.
  • Reading the h1 never returned.
  • After approximately 30 seconds, the operation failed with:
js execution timed out; kernel reset, rerun your request
  • node_repl was automatically reset.

This minimal run did not first use:

  • screenshot capture,
  • raw CDP,
  • DOMSnapshot,
  • repeated retries,
  • or a complex webpage.

A neutral example.com page and one element read were sufficient.

Expected result

The h1 text should be returned promptly:

Example Domain

The browser-control call should either succeed or return a bounded, recoverable error without destroying the JavaScript kernel.

---

Chrome extension route comparison

The bundled Chrome extension route was also tested.

The following operations succeeded:

openTabs()
claimTab()

However, reading the page element from the claimed tab timed out after approximately 15 seconds.

This suggests that the remaining problem is not limited to rendering or loading inside the Codex in-app WebView.

Both the IAB and Chrome routes can establish part of a browser session, but deeper page-control requests fail.

A shared Browser Use / browser-client / native bridge / response path is therefore a possible affected layer.

---

Troubleshooting already completed

The following actions were performed during the full investigation:

  • isolated the original faulting task/window/browser state,
  • Windows application Repair,
  • Windows application Reset,
  • normal uninstall,
  • deletion of %USERPROFILE%\.codex after uninstall,
  • official Microsoft Store reinstall,
  • Windows reboot,
  • fresh projectless-task testing,
  • IAB and Chrome route comparison.

One Reset attempt appeared to restore Browser Use temporarily, but the failure returned after restarting Windows.

The final clean reinstall did not resolve the deep-control timeout.

No old browser state or project task was restored before the final reproduction.

---

Network observation

During some Browser Use attempts, requests involving:

https://ab.chatgpt.com

or Statsig initialization timed out.

This may explain part of the slow browser initialization or navigation delay.

However, causality is not confirmed.

The deeper Browser Use failure also occurs after:

  • the browser backend has initialized,
  • a tab has been created,
  • the page has navigated,
  • and the tab has been discovered or claimed.

Therefore, the Statsig timeout should not currently be treated as the confirmed root cause of the DOM/CDP failure.

---

Confirmed findings

The following points are directly supported by the observed behavior and diagnostics:

  • The incident began during a normal request to inspect Microsoft Store update information.
  • A Browser Use page/DOM operation timed out and reset the JavaScript kernel.
  • Codex later crashed and became unlaunchable.
  • Windows displayed an application activation / Microsoft Store assistance dialog.
  • The package entered an abnormal remediation state during the incident.
  • Code Integrity Event 3033 involving the packaged vk_swiftshader.dll was observed.
  • Repair restored the application package/startup path.
  • Restoring the previous task/window/browser state was associated with repeated crash-after-launch behavior.
  • Isolating that state stopped the repeated startup loop.
  • The project data was not lost.
  • Browser Use remained broken after startup recovery.
  • Browser Use remained broken after clean uninstall, deletion of .codex, reinstall, reboot, and fresh-task testing.
  • Both IAB and Chrome routes can perform some surface actions but fail on deeper page-control operations.
  • The failure can end by resetting node_repl.

---

High-probability interpretation

The remaining Browser Use failure appears to be below the prompt or instruction layer.

Possible affected areas include:

  • the shared browser-client runtime,
  • the Codex Browser Use bridge,
  • the native messaging or IPC response path,
  • CDP request/response mapping,
  • target/session association,
  • or a lower-level pending request that is not bounded by the wrapper timeout.

The repeated startup loop and the persistent deep-control failure may involve the same broader browser subsystem, but they should not be assumed to have an identical root cause without further evidence.

---

Not yet proven

The following points remain unconfirmed:

  • Whether the original Code Integrity / GPU / package incident and the current DOM/CDP timeout have exactly the same root cause.
  • Whether vk_swiftshader.dll rejection alone caused the initial application failure.
  • Whether restored Browser Use state caused the original crash, rather than only retriggering instability during later startup.
  • Whether Statsig / ab.chatgpt.com timeouts are causal or incidental.
  • Which exact bridge layer stops returning the DOM/CDP response.

---

Related public reports

Potentially related reports include:

  • #35290 — same Windows app version; opening an in-app webpage followed by Modified, NeedsRemediation and inability to relaunch.
  • #34311 — sidebar browser use followed by app termination and repeated NeedsRemediation.
  • #34133 — Page.captureScreenshot, Code Integrity Event 3033, vk_swiftshader.dll, GPU failure, and later startup problems.
  • #32683 — opening example.com through IAB reliably crashes the Windows application.
  • #30841 — basic tab actions succeed while Playwright and raw CDP deep-control calls hang and can reset the JavaScript kernel.

These issues may represent different root causes, but they show that Browser Use failures on Windows can affect both the browser-control layer and the stability of the main desktop application.

---

Severity and impact

Severity: High.

The in-app Browser is currently unsafe and unusable for frontend inspection on this machine.

The impact is not limited to one failed browser request:

  • the initial incident made the whole Codex application unlaunchable,
  • recovery required both application Repair and isolation of the restored fault state,
  • Browser Use still cannot reliably read or control a loaded page,
  • and failed browser operations can destroy the JavaScript kernel and interrupt the task.

A Browser Use failure should degrade into a recoverable browser error.

It should not:

  • terminate the main desktop application,
  • leave the MSIX package requiring remediation,
  • recreate a startup-crash loop through restored browser state,
  • or leave a browser-control request pending until node_repl is reset.

---

Diagnostic material available

The following can be provided privately if requested:

  • screenshot of the Windows “Unable to open this app” dialog,
  • Codex desktop logs,
  • Windows Event Viewer / Code Integrity Event 3033 records,
  • package-status diagnostics,
  • minimal Browser Use reproduction transcript,
  • operation timing results,
  • and the recovery timeline.

Large state archives and raw process-memory dumps are not attached publicly because they may contain session or workspace information.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35290
  • #35132
  • #34133
  • #34311

Powered by Codex Action

Luqm76 · 1 month ago

Independent reproduction on Windows with the same Codex Desktop build, but the failure occurs even earlier than the browser/Computer Use initialization described above.

Environment

  • Codex Desktop: 26.721.4979.0 (Microsoft Store/MSIX, Windows x64)
  • Computer Use plugin: 26.721.41059
  • cua_node runtime: f8d2abcb7481383b
  • System Node: v24.15.0
  • Codex bundled Node: v24.14.0

Minimal reproduction

In a fresh Node REPL call, without importing or initializing Browser Use or Computer Use:

nodeRepl.write("ok")

With timeout_ms values of 10, 15, and 30 seconds, the call consistently ends with:

js execution timed out; kernel reset, rerun your request

This occurs before setupComputerUseRuntime() is called and before Edge or any webpage is accessed.

Troubleshooting completed

The same minimal reproduction was repeated after each of the following:

  1. Fully restarting Codex.
  2. Windows Repair for the Codex app.
  3. Renaming the local cua_node runtime directory and allowing Codex to generate a fresh runtime.
  4. Windows Reset for the Codex app.

The failure remained identical after every step.

Process inspection confirmed that each retry created fresh node_repl.exe and node.exe ./mcp/server.cjs --stdio processes. The processes remained alive, but the JS execution never returned before the tool timeout. Repeated timeouts could leave additional fresh process pairs.

Windows Application Event Log did not contain a corresponding application crash in the tested time window.

As a comparison, direct Windows UI automation using SendInput and screen capture could focus Microsoft Edge, navigate, scroll, and save screenshots successfully. This suggests that Edge and the Windows UI APIs were functional; the failure was isolated to the Codex Node REPL/runtime path.

No usernames, account details, conversation IDs, browser history, or private logs are included here.

GrahLnn · 1 month ago

Additional independent reproduction of the restored-state crash path on the same Microsoft Store build, with a session-switching trigger and correlated Crashpad/AppX evidence.

Environment:

  • Codex Desktop/MSIX: 26.721.4979.0
  • Internal browser release in logs: 26.721.41059
  • Windows 11 Pro x64, build 26200
  • Hardware acceleration enabled
  • NVIDIA RTX 4090 (32.0.16.1074) and Intel Graphics (32.0.101.8801)

Trigger and sequence:

  1. Rapidly switch among several existing conversations, including conversations with persisted in-app-browser state.
  2. Logs show repeated thread_stream_view_activity_changed, maybe_resume_started, browser-sidebar WebView creation/rebinding, and Conversation state not found from the avatar-overlay renderer.
  3. The Chromium GPU child crashes and its replacement fails immediately:
warning Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed serviceName=GPU
warning Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed serviceName=GPU
  1. At the same timestamp, AppModel-Runtime logs 0x3CFC, refusing process creation because the machine-level package state check failed.
  2. Event 217 then destroys the Codex AppX container. The next launch offers session restore, and the interrupted turn is restored.

Additional diagnostics:

  • Crashpad produced a 45 MB minidump at the same timestamp.
  • Exception: EXCEPTION_BREAKPOINT; the exception address resolves inside packaged chrome.dll.
  • No memory-exhaustion event and no Windows display-driver TDR/reset were present.
  • The package subsequently reported Modified, NeedsRemediation and underwent Store/AppX remediation.

This independently supports the state-lifecycle problem already described here: conversation state and embedded-browser state currently share a failure boundary. A failed WebView/GPU restore can terminate the desktop container and interrupt an otherwise valid conversation.

The recovery invariant should be product-owned:

  • Open the conversation even when its persisted browser tab cannot be restored.
  • After abnormal browser/GPU termination, automatically quarantine or skip the failed browser state.
  • Preserve conversation, authentication, project, and configuration data.
  • Surface a recoverable browser error without requiring users to edit .codex-global-state.json, delete thread-browser-tabs-v1:* entries, reset app data, or repair/reinstall the Store package.

The raw dump and full logs are not attached because they contain process memory, conversation identifiers, local paths, and project metadata.

lukashanes · 1 month ago

Follow-up: exact GPU child-process failure and MSIX remediation sequence on 26.721.4979.0

I reproduced another Browser Use incident on the same Codex Desktop build on 2026-07-26 at 21:49:15 CEST. This reproduction adds an exact Codex-log and Windows-event correlation that was not available in the original report.

Trigger

The in-app Browser sidebar created and attached a WebView for a ManageWP dashboard. The site redirected to its login page and reached DOM ready. Less than one second later, the Chromium GPU child process crashed and its relaunch failed:

2026-07-26T19:49:12.430Z IAB_LIFECYCLE renderer created browser sidebar webview hostKind=right-panel
2026-07-26T19:49:12.446Z IAB_LIFECYCLE queued browser sidebar webview route hostGeneration=41 instanceId=97
2026-07-26T19:49:12.452Z mcp_app_sandbox.attach_unmatched guestWebContentsId=74 url=undefined urlProtocol=invalid
2026-07-26T19:49:12.455Z IAB_LIFECYCLE runtime attached browser sidebar webview
2026-07-26T19:49:14.211Z browser sidebar dom-ready interactionMode=browse url=[redacted login URL]
2026-07-26T19:49:15.199Z Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed serviceName=GPU
2026-07-26T19:49:15.208Z Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed serviceName=GPU

101457950 is 0x060C201E; 18 is 0x00000012.

The same failure pattern has occurred with unrelated public and local-development pages, so it does not appear specific to ManageWP.

Windows package state immediately afterward

At the same local timestamp, Windows AppModel Runtime destroyed the Codex AppX container. AppModel Runtime Event ID 6 was then recorded repeatedly:

0x3CFC: The process cannot be created because an error occurred while checking
the machine-level package status. The application cannot be started.
Try reinstalling the application.

Windows subsequently ran RegisterByPackageFullName with RepairAppRegistrationOption.

AppX Deployment Event ID 649 reported:

Trying to repair ACLs for the OpenAI.Codex package
ACLs repaired successfully

AppModel Runtime Event ID 68 later reported:

Package state updated to 0x0 (previous state = 0x2)

The package then launched successfully again. This confirms the temporal sequence:

IAB DOM ready
→ GPU child crash
→ GPU relaunch failure
→ Codex AppX container destroyed
→ package status blocks activation with 0x3CFC
→ package registration/ACL repair
→ state cleared from 0x2 to 0x0
→ successful launch

The event sequence does not by itself prove why the package enters state 0x2, but it confirms that the Browser Use/GPU incident and the package-remediation requirement occur in one tightly correlated sequence.

--disable-gpu does not remove the GPU-process path

After recovery I launched the main Codex process with --disable-gpu. Renderer processes correctly received --disable-gpu-compositing, but Chromium still created a software GPU child process with:

--type=gpu-process --use-gl=angle --use-angle=d3d11-warp-webgl

The latest crash above occurred in the previous normally launched instance, so I am not claiming this reproduction proves that --disable-gpu fails to mitigate the crash. It does show that the flag does not fully eliminate the Chromium GPU-process path; it changes that path to software ANGLE/WARP. Therefore it should not yet be treated as a complete or verified workaround.

Environment additions

  • Windows 11 Pro x64, build 10.0.26200
  • Codex Desktop 26.721.4979.0
  • Embedded Chromium 150.0.7871.128
  • Display scale 150%
  • NVIDIA GeForce RTX 4060, driver 32.0.16.1062
  • AMD Radeon Graphics, driver 32.0.21043.5001
  • Parsec Virtual Display Adapter disabled during the latest tests

The full log and Windows event export contain local URLs and identifiers, so they are available privately rather than attached publicly.

jcostello092604 · 1 month ago

I can independently confirm the same failure pattern on the Microsoft Store package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0.

Environment:

  • Windows 11 x64, build 26100.8872
  • NVIDIA GeForce RTX 4090
  • NVIDIA driver 32.0.16.1074

Observed sequence:

  1. Codex launches normally, then exits unexpectedly during normal startup/use. Two sessions this morning lasted approximately 23 seconds and 42 seconds.
  2. Immediately before each exit, Windows Code Integrity records Event ID 3033:

```text
ChatGPT.exe attempted to load vk_swiftshader.dll that did not meet the Microsoft signing level requirements.

  1. Codex’s own desktop log then records:

Recoverable Chromium child process gone
processType=GPU
reason=crashed
exitCode=101457950 (0x060C201E)

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

The Desktop AppX container is then destroyed. Microsoft Store Restore or Windows Repair re-registers the same package and clears the AppModel runtime state from 0x2 to 0x0, but the crash recurs.

Relevant Code Integrity timestamps:
2026-07-26 09:08:49
2026-07-26 14:19:14
2026-07-26 14:22:12
2026-07-26 15:53:20
2026-07-27 05:52:22
2026-07-27 05:57:24

I found no corresponding Windows Display, nvlddmkm, DxgKrnl, WHEA, or GPU-reset event. This makes the Code Integrity rejection of the bundled SwiftShader DLL strongly correlated with the GPU-process failure and package-remediation loop, though I am not claiming it proves sole causality.

liufangru · 1 month ago

I independently reproduced the same Browser/GPU/AppX termination path described in this issue on Windows with the same Codex Desktop build.

This is more than a superficially similar application exit: the Browser lifecycle, Chromium GPU-process failure, AppX package-state failure, and container-destruction events are directly correlated in time.

However, I have not captured the persistent DOM/CDP/node_repl timeout or Code Integrity Event 3033 on this machine. I am therefore reporting this as a strong partial reproduction of the failure chain described here, rather than claiming that every symptom or the exact root cause is identical.

Environment

  • Codex MSIX package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Package version: 26.721.4979.0
  • Architecture: x64
  • Windows: Windows 11, build 26200
  • GPU: NVIDIA GeForce RTX 5080
  • GPU driver: 32.0.15.9636
  • Package status when the diagnostics were collected: Ok

Reproduction

I used the in-app Browser to open an ordinary public webpage.

During one occurrence, the Codex desktop log recorded:

2026-07-26T06:41:52.086Z
[browser-sidebar-manager] browser sidebar dom-ready
interactionMode=browse
url=<PUBLIC_WEB_PAGE>

2026-07-26T06:41:56.925Z
Recoverable Chromium child process gone
exitCode=101457950
processType=GPU
reason=crashed
serviceName=GPU

2026-07-26T06:41:56.932Z
Recoverable Chromium child process gone
exitCode=18
processType=GPU
reason=launch-failed
serviceName=GPU

Windows AppModel-Runtime recorded the corresponding events at the same time:

Event ID 6
0x3CFC: Windows could not create a process because an error was encountered
while checking the machine-level package state.

Event ID 217
The Desktop AppX container for
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
was destroyed.

The same sequence occurred again in two separate sessions:

Occurrence 2

2026-07-26T07:00:24.488Z
Browser sidebar reached dom-ready.

2026-07-26T07:00:28.705Z
GPU child crashed with exitCode=101457950.

2026-07-26T07:00:28.714Z
GPU child relaunch failed with exitCode=18.

The corresponding AppModel-Runtime events were:
Event ID 6 with 0x3CFC, followed approximately one second later by Event ID 217.
Occurrence 3

2026-07-27T02:44:36.052Z
Browser sidebar reached dom-ready.

2026-07-27T02:44:39.747Z
GPU child crashed with exitCode=101457950.

2026-07-27T02:44:39.757Z
GPU child relaunch failed with exitCode=18.

The corresponding AppModel-Runtime events were again:
Event ID 6 with 0x3CFC, followed approximately one second later by Event ID 217.

In all three occurrences, the Browser page reached dom-ready, the Chromium GPU child crashed a few seconds later, its replacement failed immediately, Windows reported a package-state process-creation failure, and the Codex AppX container was then destroyed.

Recovery behavior

The AppX deployment log shows that a repair-registration operation was initiated for the affected Codex package after one of the incidents:

RepairAppRegistrationOption

The operation completed and the package currently reports:

Status: Ok

However, the Browser/GPU/AppX sequence reproduced again afterward. Repairing the package registration therefore restored its state but did not eliminate the recurrence risk.

Evidence not observed

The following evidence was not present in the collected diagnostic window:

  • no matching Code Integrity Event 3033;
  • no event explicitly showing that vk_swiftshader.dll was blocked;
  • no Crashpad report;
  • no matching Windows Application Error, WER, or Application Hang event;
  • no literal js execution timed out or kernel reset message in the collected desktop logs.

The packaged vk_swiftshader.dll reports NotSigned, but without a corresponding Event 3033 I do not consider that sufficient evidence that it caused these incidents.

The lack of Crashpad and Application Error records appears consistent with Windows destroying the AppX container rather than the application producing a conventional crash report.

Assessment

My results strongly reproduce the Browser/GPU/AppX-termination portion of this issue:

Browser dom-ready
→ GPU child crash (101457950)
→ GPU relaunch failure (18)
→ AppModel-Runtime 0x3CFC
→ AppX container destruction

They do not yet confirm the separate persistent Browser Use deep-control timeout, restored-state crash loop, or the exact Code Integrity/SwiftShader root cause.

I can provide sanitized Codex desktop logs, AppModel-Runtime event details, AppX deployment events, package information, and GPU-driver information privately if maintainers need the complete diagnostic set.

liufangru · 1 month ago

Tested temporary workaround: use standalone Playwright instead of Browser Use

I found a temporary operational workaround that allows external webpage access without initializing the affected Codex Browser Use path.

This is not a fix for this issue, and it does not demonstrate that the in-app Browser bug has been resolved. It only provides a way to continue browser-related work while avoiding the in-app Browser and shared Browser Use bridge.

Tested environment

  • Codex Desktop/MSIX: 26.721.4979.0
  • Windows x64
  • Node.js: 24.15.0
  • npm/npx: 11.12.1
  • Playwright CLI: 0.1.17
  • Browser mode: headless, isolated in-memory profile

Workaround

Use the official $playwright skill with standalone playwright-cli:

$playwright
→ terminal
→ standalone playwright-cli
→ isolated Playwright-managed browser

Explicitly prohibit fallback to:

  • Browser Use;
  • the Codex in-app Browser / iab;
  • the Browser sidebar;
  • the Browser Use Chrome extension;
  • Computer Use;
  • node_repl / js_repl;
  • playwright-interactive.

A concise global or project-level AGENTS.md rule is sufficient:

## External web access

- For webpage access, use only `$playwright` with standalone `playwright-cli`.
- Never use or fall back to Browser Use, IAB, the Browser sidebar, the Browser Use Chrome extension, Computer Use, `node_repl`/`js_repl`, or `playwright-interactive`.
- Use an isolated session, always close it, and stop with an error if Playwright fails.

Smoke-test result

I tested an isolated named Playwright session against https://example.com.

The following operations succeeded:

  • page navigation;
  • page snapshot;
  • reading document.title;
  • reading the first h1;
  • full-page screenshot;
  • screenshot file verification;
  • clean session shutdown.

Returned values:

Title: Example Domain
H1: Example Domain
Screenshot size: 13,441 bytes

During the test:

  • Browser Use was not initialized;
  • iab was not initialized;
  • no Browser sidebar appeared;
  • the Browser Use Chrome extension was not used;
  • Computer Use was not used;
  • node_repl and js_repl were not used.

After the test:

  • the Codex package status remained Ok;
  • no new AppModel Event 6 or Event 217 was observed;
  • no new 0x3CFC event was observed;
  • no GPU child crash or relaunch-failure log was observed;
  • no js execution timed out or kernel reset occurred.

Important limitations

This workaround avoids the affected Browser Use route; it does not repair it.

It may not work in environments where standalone Playwright cannot launch because of sandbox, policy, dependency, or network restrictions. Playwright failure must not trigger an automatic fallback to Browser Use or iab.

Based on this single-machine test, standalone Playwright appears to be a usable temporary alternative for navigation, DOM extraction, screenshots, downloads, and frontend checks while this issue is investigated.

raq-dureaux · 1 month ago

I can confirm the same issue on Windows 10.

Environment:

  • Windows 10 Pro 22H2, build 19045.7548
  • App-reported version: 26.721.41059
  • MSIX package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Installed through Microsoft Store

The issue has occurred repeatedly:

  1. The application crashes during normal use.
  2. Windows then displays “This app can’t open” and redirects to Microsoft Store.
  3. Get-AppxPackage OpenAI.Codex reports:

Status: Modified, NeedsRemediation

  1. The Code Integrity log contains Event ID 3033:

ChatGPT.exe attempted to load vk_swiftshader.dll that did not meet the Microsoft signing level requirements.

  1. One to two seconds later, the Desktop AppX container for the package is destroyed.
  2. Using Repair or Update in Microsoft Store temporarily restores the application.
  3. Microsoft Store stages or re-registers the same package version, so neither the MSIX version nor the app-reported build changes.
  4. After further use, the same failure occurs again.

Two captured occurrences:

  • 18:58:01 — Code Integrity Event ID 3033
  • 18:58:03 — Desktop AppX container destroyed
  • 19:06:58 — Code Integrity Event ID 3033
  • 19:06:59 — Desktop AppX container destroyed

This appears to be the same failure described in this issue.

----

Additional confirmed reproduction with the Beta channel:

  • App-reported Beta version: 26.715.31251
  • MSIX package: OpenAI.CodexBeta_26.715.3651.0_x64__2p2nqsd0c76g0
  • Windows 10 Pro 22H2, build 19045.7548

The Beta application also failed while performing browser-control operations
through Microsoft Edge with the browser extension installed.

After the failure:

Get-AppxPackage reported:

OpenAI.CodexBeta_26.715.3651.0_x64__2p2nqsd0c76g0
Status: Modified, NeedsRemediation

Windows Code Integrity logged Event ID 3033:

ChatGPT (Beta).exe attempted to load the packaged vk_swiftshader.dll,
which did not meet the Microsoft signing level requirements.

The same confirmed failure mechanism therefore occurs in both channels:

  • OpenAI.Codex_26.721.4979.0
  • OpenAI.CodexBeta_26.715.3651.0

In both cases, the failure occurred during active browser-control operations.

yuziri-open · 29 days ago

Additional occurrence with exact Windows AppX/Store evidence from Codex Desktop 26.721.4979.0 (Microsoft Store/MSIX, Windows x64).

Originating Codex task/thread ID for internal correlation:

019fa739-a350-7b03-b562-7266f2b59cc8

The same task used the Chrome extension during an earlier audit and the Codex in-app Browser during the later re-search. Browser operations reached rendered Google AIO/AI Mode results before the package incident.

At approximately 2026-07-28 20:59 JST, Windows recorded the following for OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0:

0x80070020: AppxManifest.xml could not be opened because another process was using it
0x80073CF0: AppX deployment/registration failed
0x80073CF2: StageUserDataAsync could not operate on the installed package

Microsoft Store also recorded StageUserData failure ignored for the same package. AppXDeploymentServer repeatedly reported seven files under its deleted-package area that could not be removed. Earlier that day, AppModel-Runtime recorded several 0x3CFC process-creation failures with the reinstall/repair guidance.

Negative evidence:

  • no matching Windows Application Error
  • no matching WER AppCrash or MoAppCrash
  • no Chrome Crashpad report dated July 28
  • Chrome processes were responsive when inspected

The package later returned Status=Ok, and Codex could run again. This evidence does not prove that either the Chrome extension or IAB alone caused the failure. It does support the broader failure mode described here: browser/session activity can coincide with Store/MSIX registration or remediation errors, while the desktop app disappears or becomes dependent on package repair without producing a normal application-crash record.

Expected behavior is that a browser-control failure or restored browser state remains isolated and recoverable. It should not race with package registration, damage the app launch path, or require Microsoft Store repair.

Sanitized Windows event details and the local task transcript are retained and can be provided privately if maintainers need a narrower timestamp or event sequence.

User1122113 · 29 days ago

Update: full teardown evidence moved to the more specific issue

After comparing the exact trigger and failure boundary, this reproduction belongs more directly under #35210 (browser.tabs.finalize() silently terminates the Windows desktop app). The full 26.721.11231.0 timeline and diagnostics are now posted here:

The reproduction is also closely related to the direct tab-close/WebView-teardown family in #34239.

This issue (#35311) remains broadly related at the Windows IAB/app-termination level, but its primary failure chain includes deep-control timeouts, GPU/package remediation, and startup recovery behavior that were absent from my two occurrences. I am keeping this short cross-reference here instead of duplicating the full report.