[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

[lby0707]

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

6. 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:

• Windows Store Codex enters "Modified, NeedsRemediation" after opening any webpage and becomes unlaunchable #35290 — same Windows app version; opening an in-app webpage followed by Modified, NeedsRemediation and inability to relaunch.
• Windows app: package repeatedly enters NeedsRemediation state - crash 0xc06d007f when using sidebar browser (Chrome) #34311 — sidebar browser use followed by app termination and repeated NeedsRemediation.
• [Windows][Codex 26.715.4045.0] Page.captureScreenshot crashes GPU process after Code Integrity Event 3033 rejects bundled vk_swiftshader.dll #34133 — Page.captureScreenshot, Code Integrity Event 3033, vk_swiftshader.dll, GPU failure, and later startup problems.
• [Windows] Codex App crashes in CrBrowserMain when Browser Use opens a page (0xC0000005 at chrome.dll+0x2e08f46) #32683 — opening example.com through IAB reliably crashes the Windows application.
• Chrome extension deep control hangs while direct chrome.debugger works; ambient network adds ~30s delay #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.

[github-actions]

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

• Windows Store Codex enters "Modified, NeedsRemediation" after opening any webpage and becomes unlaunchable #35290
• Codex App (Windows/Store) self-terminates ~60s after launch on older GPUs: app CIG policy blocks bundled vk_swiftshader.dll; package left "Modified/NeedsRemediation" #35132
• [Windows][Codex 26.715.4045.0] Page.captureScreenshot crashes GPU process after Code Integrity Event 3033 rejects bundled vk_swiftshader.dll #34133
• Windows app: package repeatedly enters NeedsRemediation state - crash 0xc06d007f when using sidebar browser (Chrome) #34311

Powered by Codex Action

[Luqm76]

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]

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

4. At the same timestamp, AppModel-Runtime logs 0x3CFC, refusing process creation because the machine-level package state check failed.
5. 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]

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]

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:

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

3. 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.