Repository navigation
Windows Desktop: opening in-app Browser can hang/close Codex after Browser Use PiP failure #32040
Description
What version of the Codex App are you using?
Codex for Windows 26.707.3748.0 (Microsoft Store package OpenAI.Codex).
What platform is your computer?
Windows 11 x64, OS build reported by WER as 10.0.26200.2.
ChatGPT Desktop is also installed separately. This may be relevant because the Windows hang report was attributed to ChatGPT.exe.
What issue are you seeing?
Opening a Codex-controlled in-app Browser tab to inspect a local web application can cause the Codex desktop app to stop responding and close. The user then has to start Codex again.
The failure reproduced repeatedly while opening a localhost page through Browser Use. It is not caused by the local web application: the Codex desktop log ends during the in-app browser lifecycle, and the local app remains available independently in Chrome.
Steps to reproduce
- Open Codex Desktop on Windows.
- Work in a local coding thread with a dev server running on localhost.
- Ask Codex to inspect the application using the in-app Browser / Browser Use.
- Codex creates and attaches the browser sidebar webview.
- The Codex desktop application becomes unresponsive or closes.
- Restart Codex manually.
- Repeating the Browser Use flow can reproduce the same behavior.
Diagnostic evidence
Local timestamps below are Europe/Athens time (UTC+3).
At approximately 08:30:28, the Codex desktop log first reports:
IAB_LIFECYCLE iab backend info request failed
No ChatGPT browser route is available for browser session
The retry succeeds, then at 08:30:50-08:30:51 the log shows the webview being created, attached, mapped to a Browser Use tab, and navigated to the localhost page. The last relevant line is:
[browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1
The desktop log stops immediately afterward.
At 08:31:37, Windows records Application Hang event 1002 / WER MoAppHang:
The program ChatGPT.exe stopped interacting with Windows and was closed.
Hang Type: 2097152
The Codex package currently launches an executable named ChatGPT.exe, while a separate ChatGPT Desktop package is also installed. The WER package attribution referenced ChatGPT Desktop, so that package/executable identity interaction may be relevant, but the causality is not established.
The Codex processes subsequently have new start times, confirming the desktop host restarted.
Expected behavior
Opening or controlling an in-app Browser tab should not hang or terminate Codex. Failure to create the Browser Use PiP/sidebar route should be handled gracefully, and the main coding thread should remain usable.
Actual behavior
The in-app browser lifecycle reaches webview attachment and localhost navigation, then the PiP upsert fails and the desktop app closes or becomes unresponsive.
Workaround
Avoid the Codex in-app Browser and open the localhost URL in ordinary Chrome. Build and automated tests continue to run normally.
No full logs are attached because they contain local workspace and thread metadata. Sanitized excerpts or additional WER details can be provided if requested.
Activity
github-actions commentedon Jul 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
baarsik commentedon Jul 10, 2026
Adding another Windows data point that appears to match this issue closely.
Environment:
OpenAI.Codex_26.707.3563.0_x6426.707.3112310.0.26200I observed two consecutive full-app exits on 2026-07-10:
08:12:56Z(10:12:56Europe/Warsaw)08:15:12Z(10:15:12Europe/Warsaw)On both runs, Browser Use created and attached the browser-sidebar webview, navigated successfully to an HTTPS localhost page, and then ended with the same two records:
Those were the final two lines in each desktop log. In both cases, Windows AppModel-Runtime removed the Codex Desktop AppX container approximately two seconds later. A newly launched Codex process then had a different PID.
Unlike the original report, this machine recorded no matching Application Error/Hang/WER 1000, 1001 or 1002 event, no Crashpad report, and no resource-exhaustion event. The Codex backend also recorded no terminal panic at either boundary. This suggests that the same Browser Use/PiP sequence can terminate the desktop host without producing
MoAppHangor a crash dump.A short-lived recovery session subsequently restored the browser sidebar and repeatedly logged owner-sync/rebind activity before its log also ended. That session had no terminal exception, so I am treating it as a follow-on recovery observation rather than another confirmed PiP reproduction.
Separately, the desktop log contains handled warnings about a chat-process-notification record containing NUL bytes and failing JSON parsing. Those warnings were not the final event in either exit, so they may be unrelated.
Sanitized diagnostic evidence is attached below as
codex-browser-pip-repro-sanitized.txt. It contains the crash-correlated log tails, Windows AppModel event correlation, negative WER/Crashpad/resource-exhaustion checks, and sanitization details. Conversation IDs, browser IDs, local paths, repository information, and the localhost port have been removed.codex-browser-pip-repro-sanitized.txt
thiefuniverse commentedon Jul 10, 2026
Adding a native-crash data point that appears closely related to this issue.
Environment
26.707.3748.0(internal log release:26.707.31428)ChatGPT.exe/chrome.dllfile version:150.0.7871.10119041.1415Native crash signature
A Windows x64 minidump confirms that the desktop main process crashed (not a renderer or GPU child process):
CrBrowserMain0xC0000005read access violationchrome.dll+0x02EC6E66RCX = 0mov rax, qword ptr [rcx+0x558]0x558NULL_CLASS_PTR_READ_c0000005_chrome.dll!GetHandleVerifier{c519d649-9c8b-047c-3153-6d1cd407b31b}Private Chromium symbols for this build are unavailable, so
GetHandleVerifierappears to be only the nearest exported symbol. The module RVA and faulting instruction are the reliable identifiers.Sanitized Browser Use correlation
Local timestamps are HKT / UTC+8:
19:47:43.971— IAB backend info request failed:No ChatGPT browser route is available19:47:53.945— ahidden-browser-usewebview was created withinitialUrl=about:blank19:47:54.004—mcp_app_sandbox.attach_unmatched,url=undefined19:47:54.349— last main-process log: browser sidebar reached DOM-ready on a localhost page19:53:34— the access violation was capturedThere is about a 5 minute 40 second gap between the last app-log entry and the captured exception. Browser Use was active and the lifecycle resembles this report, but I am treating that as correlation rather than claiming the localhost navigation was the immediate cause. The exact final UI gesture has not yet been isolated.
Two dump files were captured 13 seconds apart from the same PID, thread, registers, and exception address; they are a small minidump and a full-memory snapshot of one crash, not two separate reproductions.
dda594922fcdca8fd3413b899ae92cb6b1ca85d8833797cdc6dd766982f0eb9dI am not attaching either dump publicly because even minidumps can contain stack memory and local metadata, while the full-memory dump may contain account or conversation data. I can provide the 323 KB minidump through a private OpenAI channel if a maintainer requests it.
funkel1989 commentedon Jul 10, 2026
Adding another independent Windows reproduction that matches this issue.
Environment
26.707.3748.0codex@26.707.3142810.0.2620032.0.15.9636Minimal reproduction
The target was a plain local React/Next.js dashboard served over HTTP. Before the final reproduction, both the page and its JSON data endpoint returned HTTP 200.
The final Browser Use operation was only:
No media, canvas, WebCodecs, upload, or page interaction was involved. Immediately afterward, the Codex desktop app closed and had to be reopened. The localhost server, which was running as a Codex terminal child process, was also terminated with the app process tree.
Repeated timestamp correlation
Local timestamps are America/New_York / UTC-4:
08:39:4808:39:5008:42:1908:42:2108:45:1508:45:1809:20:5809:21:00Each run used a different Codex process. The browser-related helper and the main Codex app-server both stopped logging at the failure boundary.
Negative diagnostics
For these reproductions I found:
Windows only recorded destruction of the full Codex AppX container, followed by a later manual activation with a new process ID.
This supports the observation that the in-app Browser lifecycle can terminate the current Windows build even for a basic localhost React page, without a WER/Crashpad artifact. I have not attached the full structured log database because it contains local thread and tool-call metadata, but I can provide narrowly sanitized rows if a maintainer requests them.
sonturk113 commentedon Jul 10, 2026
Adding another independent Windows reproduction that closely matches this issue, with one potentially useful variant: these three exits did not end with
Failed to upsert Browser Use PiP content. Instead, each desktop process ended at or immediately after the hidden IAB webview attach/createTab/debugger-listener lifecycle.Environment
26.707.3748.026.707.3142810.0.26200iab), not the Chrome extensionThree repeated silent exits
Local time zone: Europe/Istanbul (UTC+3).
12:32:1009:32:08.418Z14:36:1311:36:13.392Z17:04:0614:04:05.525ZNo power loss, Windows restart, or manual Codex exit occurred for these three incidents.
The repeated Browser lifecycle boundary was:
The affected sessions also contain
No ChatGPT browser route is available for browser sessionand conversation-state routing errors. In each case the desktop log then stopped without a clean shutdown marker, and Windows destroyed the Codex AppX container approximately 1–3 seconds later.Negative diagnostics
For these three exits I found no matching:
render-process-goneor GPU-process crashnvlddmkm/TDR or WHEA hardware eventThis appears consistent with a related non-PiP path through the IAB route/session/webview ownership lifecycle. Concurrent tasks or thread switching may make the race easier to trigger, but I am treating that as a hypothesis rather than claiming a confirmed root cause.
Sanitized evidence with the three lifecycle tails and negative checks is attached below. Conversation/thread/browser IDs, usernames, workspace paths, prompts, URLs, and page contents have been removed. Full raw logs are intentionally not public.
codex-browser-hidden-webview-repro-sanitized.txt
pompie26 commentedon Jul 10, 2026
I think I am hitting the same or a closely related issue.
In my case, the Codex Windows app crashes when using the internal
@Browsertool to open any URL. It is not limited to localhost.Reproduction:
Use @Browser to open https://example.com.Also reproduced with:
http://127.0.0.1:5173/running a Vite apphttp://localhost:5173/http://127.0.0.1:5174/running a minimal local Node HTTP serverhttps://example.comEnvironment:
26.707.3142819045.6466150.0.4078.48Troubleshooting already tried:
https://example.com.127.0.0.1:5174; Codex still crashed.codex-computer-use.exeexists in the Codex runtime folder.This started immediately after updating Codex.
This may also be related to #32094, but my case is broader because
@Browsercrashes the whole app with any navigation, includinghttps://example.com.sonturk113 commentedon Jul 11, 2026
Follow-up to my earlier data point in this comment: I now have a much tighter
file://reproduction on the same Windows machine.Environment
26.707.3748.026.707.314280.144.0-alpha.410.0.2620032.0.16.1074Minimal local page
The trigger was a generated local image gallery opened from a normal Markdown file link in a completed Codex task:
file:///C:/Users/<redacted>/Desktop/<redacted>/artifacts/image_batches/pilot-001/gallery/index.htmlThe gallery itself is intentionally simple:
index.html: 3,415 bytesThe associated parent rollout was only 11.39 MiB. The complete task tree, including 11 child-agent rollouts, was 48.59 MiB. This is therefore not the previously reported 500+ MiB image-history / V8 string-length failure mode.
Four repeated silent exits
Codex logs use UTC. Local time was Europe/Istanbul / UTC+3.
dom-readyon the local gallery21:50:04.639Z21:50:05.124Z21:50:05.947Z21:50:10.836Z21:50:46.969Z21:50:47.453Z21:50:48.014Z21:50:54.984Z21:51:16.068Z21:51:16.405Z21:51:17.371Z21:51:20.166Z21:53:10.355Z21:53:10.681Z21:53:11.275Z21:53:26.968ZSequence:
dom-ready.file://tab.Each attempt included this warning shortly before the successful webview attachment:
I am not claiming that warning is the root cause because similar attach warnings can occur during otherwise successful temporary
about:attachment flows. The stronger invariant is: right-panel webview creation -> runtime attachment -> gallerydom-ready-> abrupt end of the main desktop log.Negative evidence
Across the four exits I found:
Failed to upsert Browser Use PiP contentrecord in this reproductionRecoverable Chromium child process gone/processType=GPUrecordThis makes it another silent main-app exit variant, rather than evidence for the explicit GPU-child signature in #32094.
Why this may help narrow the issue
This reproduction indicates that neither Browser Use automation nor a complex localhost application is required. A user click on a small, script-free
file://page is enough, and restoring the same Browser tab after restart reproduces the exit. It closely overlaps #30558 and the WebContents attach/navigation path in #30178.The practical workaround remains to avoid the in-app Browser and open the gallery in external Chrome. I can provide sanitized log tails with the exact lifecycle records if a maintainer requests them; I am withholding raw logs because they contain local paths and thread metadata.
NoHaxJsut-Luck commentedon Jul 11, 2026
I can independently reproduce what appears to be the same Browser Use route/session failure on a different Windows version, using the same Codex Desktop build.
Environment
OpenAI.Codex_26.707.3748.0_x6426.707.3142826.707.31428v24.14.010.0.19045Reproduction and observed behavior
The browser runtime bootstraps and reports the IAB backend as available. Navigation then fails consistently:
https://xgaida.itch.io/bloodlines-uiand request a DOM snapshot.I then tried the bundled Chrome backend:
https://help.openai.com/— browser-control execution timed out and the JS tool session reset.https://openai.com/form/codex-project-showcase-and-feedback/— timed out and reset.Overall: 5/5 Browser Use navigation attempts failed. The desktop host stayed open in this case, but each affected browser-control execution was aborted or reset.
Network/control comparison
This does not appear to be ordinary DNS or network failure:
Invoke-WebRequest.Matching local log evidence
At
2026-07-11T04:10:12.973Z, the Codex desktop log records:The surrounding log confirms that:
ok;This looks consistent with a race or stale mapping between the Browser Use session, ChatGPT browser route, sidebar webview attachment, and the Node/browser client. The first
getInfosees no route, the route is recreated immediately afterward, and the client may continue with a stale page/tab binding or wait on an event belonging to the replaced route.Additional value compared with the original report
I have a longer sanitized report and can provide selected log excerpts if useful. I have intentionally not uploaded the full desktop log because it contains local paths and task/thread metadata.
sj-shi39 commentedon Jul 11, 2026
I can corroborate this issue on Codex Desktop for Windows, release
26.707.31428.The main Codex app exited twice while opening a loopback-hosted local page in the in-app Browser. The failure reproduced during the browser sidebar webview attachment sequence.
In both runs, the last relevant lifecycle sequence included:
The webview subsequently reported
dom-ready, and the Codex desktop log then ended without a normal shutdown record. A new Codex process appeared after each exit.The browser tab also appeared to be registered under a temporary
client-new-threadroute while its owner route pointed to an existing thread, suggesting a possible browser-tab/session routing race during webview attachment.The local page successfully reached
dom-ready, and no ordinary application error or crash dump was generated. I am intentionally not attaching full logs because they contain local workspace and thread metadata.yosima32 commentedon Jul 11, 2026
Additional confirmed reproduction from another affected Windows installation (2026-07-11, Asia/Bangkok, UTC+7).
Environment:
This installation has now exited at least six times today while the in-app Browser path was involved: approximately 08:12, 08:44, 12:25, 15:01, 21:07, and 21:43 local time. The latest reproduction was especially direct: the user manually clicked to open Browser inside Codex, and Codex closed immediately.
The repeated final lifecycle in the desktop logs is:
IAB_LIFECYCLEregisters/opens the browser sidebar.initialUrl=about:blank.mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid.browser sidebar dom-ready ... url=about:blank(on some runs it reacheshttp://localhost:5173/).No fresh Crashpad dump, native WER crash entry, OOM event, GPU reset, or Defender detection was found for these exits.
There is also a workaround/persistence issue: setting
[plugins."browser@openai-bundled"] enabled = falsedid not remain effective after restart. Bundled plugin marketplace sync later re-added Browser and rewrote the setting to
enabled = true, allowing another crash. A skill-level disable plus a global instruction to never use IAB is currently required as an emergency mitigation.Expected:
No full logs or local workspace/thread paths are included because they contain private metadata. Sanitized excerpts can be provided if maintainers request them.
JayCroghan commentedon Jul 11, 2026
Confirmed on the same Codex Desktop build,
26.707.3748.0, Windows x64 build10.0.26200.I observed the same failure three times. In every occurrence, the final two desktop log events were Browser Use PiP metadata followed immediately by:
[browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1Additional evidence: in all three runs, the
browserIDin the immediately preceding PiP metadata event appears truncated or malformed:-ca95-4794-ad0b-6f45fd4385c7-7e3e-41c1-971a-3bac88bffae9-9a75-4483-8711-91f4b27b9229Each value appears to be missing the first UUID segment.
The affected Browser Use thread also logged:
No ChatGPT browser route is available for browser session <redacted>The tab was successfully created and navigated to a localhost page before the PiP failure. The desktop log stopped immediately after the upsert warning and Codex exited without a crash dialog.
Unlike the original report, I did not find a corresponding WER/Application Hang event or Crashpad dump.
The original crash occurred during an already-active extensive task. Restarting Codex and resuming the task were recovery actions, not the original trigger.
The same Browser Use operation then caused the crash again after recovery.
Avoiding Browser Use, the in-app browser, and PiP prevents the observed failure. I have complete logs from all three occurrences and can provide them privately to OpenAI Support.
4 remaining items
pompie26 commentedon Jul 13, 2026
The issue still exists in ChatGPT 26.707.62119. Released 13 jul 2026
DominikKozak commentedon Jul 13, 2026
Confirming that this remains reproducible on the newer Codex Desktop build
26.707.8479.0.Environment:
OpenAI.Codex_26.707.8479.0_x6410.0.26200Minimal reproduction:
browser.tabs.new().about:blank.Reproduction rate: 2/2. No navigation or page DOM-ready event is required.
Windows AppModel-Runtime evidence:
2026-07-14 00:13:54Europe/Berlin — Event ID 217 destroyed the Desktop AppX container.2026-07-14 00:13:59— a new container and Codex process were created.2026-07-13 23:56:24.Feedback ID:
This was initially reported as #32885; closing that report as a duplicate of this issue.
DominikKozak commentedon Jul 13, 2026
Follow-up with a controlled old-profile vs fresh-profile A/B test. This produced a stable workaround and narrows the failure to inconsistent embedded Chromium profile/update state.
Environment
26.707.8479.026.707.62119150.0.7871.11510.0.26200iab)How we found it
about:blank, wait. No application page or Browser Use automation was required.23:46:03:5.6.5_2created -> Event 217 at23:46:0523:56:22:5.6.5_3created -> Event 217 at23:56:2400:13:51:5.6.5_4created -> Event 217 at00:13:5400:38:56:5.6.5_5created during the minimalabout:blankbaseline -> Event 217 at00:38:57fjoaledfpmneenckfbpdfhkmimnjocfa; its manifest identifies it as VPN for Chrome: NordVPN proxy protection, version5.6.5.Secure Preferenceshad not been updated since July 9 and still referenced:fjoaledfpmneenckfbpdfhkmimnjocfa\5.6.4_0even though the filesystem contained
5.6.5_0through5.6.5_5. This looks like an extension update/profile commit that repeatedly unpacks the new version but never commits the new path before the app exits.%APPDATA%\Codex\web\Codex) to a timestamped backup and let Codex create a fresh profile.about:blankhttps://example.com/domcontentloadedand theExample DomaintitleThe fresh-profile run stayed alive and loaded the page successfully. No new AppModel Event 217 was recorded after the test.
Important discriminator
The fresh profile automatically installed the same NordVPN 5.6.5 extension as
5.6.5_0, but this timeSecure Preferenceswas updated immediately to5.6.5_0, and Codex remained stable. Therefore the presence of NordVPN alone is not sufficient to reproduce the crash. The stronger discriminator is the stale/inconsistent extension update state in the old embedded profile.The fresh IAB session also still returned a malformed-looking Browser ID with a leading hyphen, yet it did not crash. That ID shape is therefore not sufficient by itself either.
One Event 217 at
00:44:02was deliberately induced while stopping Codex to release the profile lock for the A/B test and should be excluded from the natural-crash count.Current conclusion / workaround
This A/B result points to Chromium profile recovery or extension-update handling during IAB startup. A safe workaround is to fully close Codex, rename
%APPDATA%\Codex\web\Codexas a backup, and relaunch so a clean embedded Browser profile is created. This may reset embedded-browser sessions, so renaming is preferable to deleting.I am not claiming the extension is the root cause; the evidence points more specifically to how Codex/Chromium handles a stale, partially committed extension-update state during Browser webview startup.
ITGitM commentedon Jul 14, 2026
Independent 2/2 reproduction on 26.707.8479.0; previously implicated extension is absent
Adding another independent reproduction that matches this issue, with an additional profile-state discriminator.
Environment
OpenAI.Codex_26.707.8479.0_x6410.0.26220150.0.7871.11526.707.62119Exact reproduction timeline
The same operation was attempted twice. Each tool call created a new in-app Browser tab and then requested navigation to an external HTTPS URL.
First reproduction:
09:11:52.026- Browser call issued:browser.tabs.new()followed bytab.goto(...)09:11:53.346-mcp_app_sandbox.attach_unmatched guestWebContentsId=3 url=undefined urlProtocol=invalid09:11:53.431- browser sidebar reached DOM-ready atabout:blank09:11:56.811- AppModel-Runtime/Admin Event 217 destroyed the Codex Desktop AppX container09:12:03.654- Codex was launched againSecond reproduction after relaunch:
09:13:17.774- the same Browser call was issued again09:13:18.176- the sameattach_unmatchedwarning09:13:18.272- browser sidebar reached DOM-ready atabout:blank09:13:21.691- Event 217 destroyed the AppX container09:13:27.180- Codex was launched againReproduction rate: 2/2.
The target HTTPS page never reached a logged DOM-ready state. Because
tabs.new()andgoto()were issued in one tool call, this evidence narrows the failure to tab/WebView creation or very early navigation, but does not claim which individual API call causes the native termination.Before the first exit, Browser Use also logged:
The Browser sidebar route was associated with a temporary
client-new-threadidentifier while the tool request belonged to the permanent conversation ID. IDs are omitted here because they are not needed to reproduce the issue.Negative diagnostics
For both exits:
Embedded profile discriminator
I checked the active Codex embedded Chromium profile without modifying it:
fjoaledfpmneenckfbpdfhkmimnjocfa(the NordVPN extension discussed in a previous comment) is absentSecure Preferencescontains no reference to that extension ID_1,_2, etc. unpack patternNo profile reset or extension cleanup was attempted before these reproductions.
This shows that the stale/inconsistent NordVPN extension-update state described in the fresh-profile A/B workaround is not required for the crash on
26.707.8479.0. The broader IAB/WebView lifecycle or Chromium main-process path still appears to be affected.Full local logs are not attached because they contain local paths and conversation metadata. Sanitized excerpts can be provided if maintainers request them.
DominikKozak commentedon Jul 14, 2026
@ITGitM Thank you — this is important negative evidence and a useful correction to the scope of my A/B result.
I agree that your reproduction shows the stale NordVPN extension-update state is not required for this crash. The profile reset should therefore be treated as a local mitigation that worked on my machine, not as a universal fix or the underlying root cause.
After reading your result, I reran the same regression test on my currently cleaned profile:
26.707.8479.0about:blankopen for 5 secondshttps://example.com/and verify DOM/contentThe app remained alive, no new AppModel Event 217 appeared during the following 10-minute window, and the embedded profile still contains only
5.6.5_0with no duplicate extension directories.So the local profile-state A/B remains repeatable here, but your clean-profile 2/2 failure demonstrates that it cannot explain the broader issue. Across both machines, the stronger shared signals are now the Browser route/session mismatch and the WebView lifecycle around
attach_unmatched/about:blankDOM-ready immediately before the native app termination.Thanks for checking the profile state specifically — that materially narrows what maintainers should treat as a general cause versus a machine-local trigger.
gkfriend commentedon Jul 14, 2026
Adding an independent Windows reproduction from a local Vite game project.
Environment
OpenAI.Codex_26.707.9564.0_x6410.0.262007.3.6, TypeScript, Canvas + DOM UIhttp://127.0.0.1:5173/Reproduction
npm run dev.Expected
The embedded browser should load the localhost game without terminating the Codex host. A browser/webview failure should remain isolated from the main app.
Workaround
The project now explicitly prohibits opening the game in the Codex built-in Browser. Testing is done in Microsoft Edge or an external headless browser instead.
This comparison is useful because the same server and application operate normally in Edge; the failure appears specific to the Codex embedded browser path. No full logs are attached because they may include local workspace and thread metadata.
4damAce commentedon Jul 14, 2026
Additional corroboration from a separate Windows 10 22H2 x64 setup:
26.707.3351.0. The embedded Browser runtime configuration reported26.707.30751.127.0.0.1. The control channel successfully returns the page title and DOM, then the visible Codex desktop app silently restarts.Sanitized messages observed around the failure:
There was also a repeated chat-process notification JSON parse warning caused by an unexpected NUL character.
The user first noticed the problem after installing Playwright 1.57.0's Chromium headless shell, but the checks above do not establish Playwright as the cause; it is only a reported timing correlation.
Expected: a Browser/IAB or PiP attachment failure should be isolated to the browser surface and leave the main Codex task usable. Actual: the full desktop host restarts shortly after a simple localhost page is attached.
insominaTian commentedon Jul 14, 2026
I can reproduce a closely related silent restart on a newer Windows Store build.
Environment
OpenAI.Codex_26.707.9981.0 x64Observed incident (2026-07-15, local time about 00:29)
00:29:07: the desktop log began emitting rapid repeated failures:getInfocalls against the same stale session.00:29:10: the browser sidebar/guest was torn down andwebcontents-destroyedwas logged.00:29:11: Windows AppModel-Runtime recorded the Codex AppX container being destroyed.00:29:15: Codex automatically relaunched.00:31.The coding task continued, but the visible Codex desktop UI silently closed/restarted. There was no corresponding Windows Application Error, WER APPCRASH, or Crashpad dump, so this looks like a container/host restart rather than a conventional crash.
This happened repeatedly over roughly four to five days (three visible incidents). The common correlation is Codex's in-app Browser / Browser Use lifecycle, specifically stale IAB route retries followed by sidebar teardown.
I am intentionally not attaching raw logs because they include local paths, task metadata, and conversation identifiers. I can provide further sanitized lifecycle lines or targeted diagnostics through a private channel if maintainers request them.
Current workaround: avoid the Codex in-app Browser after a route-loss event; use external Chrome, API, or CLI for browser/data work, and do not keep retrying the invalid browser session.
CTCycle commentedon Jul 14, 2026
Platform: Windows 11, Codex Desktop
26.707.72221Independent confirmation of the same Browser Use PiP failure. Adding a variant that may help narrow the race condition:
My desktop log shows:
Note
tabID=undefinedrather than thetabID=1seen in most other reports. The PiP metadata arrived before any tab ID was assigned to the webview, suggesting the Browser Use PiP upsert is racing against the IAB tab lifecycle — the upsert fires before the webview/tab is fully initialised.The process ended without a clean shutdown ~24s later and auto-restarted. No crash event in Windows Application logs and no minidump generated — the exit may be an abrupt Chromium termination that WER doesn't capture.
The bundled Chromium version is
150.0.7871.115(same as reported elsewhere). See also #32683 for the native crash signature (CrBrowserMain null-pointer read in chrome.dll) which likely shares the same root cause.sonu07-star commentedon Jul 14, 2026
Summary
The Codex Windows desktop app repeatedly freezes/closes and then relaunches. This is happening several times within a short period, including while using a normal conversation.
Environment
Observed behavior
Windows AppModel lifecycle events show repeated destruction and recreation of the entire Codex application container:
The app disappears/freezes and comes back after several seconds. All ChatGPT.exe and codex.exe processes receive new start times after each incident, confirming that the whole application is restarting rather than only a conversation failing.
There is no standard Windows Application Error event or Crashpad dump for these recent restarts. Windows records them as controlled AppX container shutdowns.
Earlier related crash
An earlier Codex build also produced a native crash:
The app subsequently updated to 26.707.9981.0, but the repeated shutdown/relaunch behavior continues.
Expected behavior
The desktop app should remain open and the current task should continue without the entire application restarting.
Reproduction
The issue occurred repeatedly within approximately 20 minutes.
Additional information
Immediately after relaunch, all processes report as responding. Combined memory usage is approximately 1.2–1.3 GB. No recent Codex files appear in the Crashpad directory, and Windows Reliability Monitor does not show a conventional application crash for the latest incidents.
Codex feedback session ID: 019f6279-351a-7ff3-8c4a-adb77fb4f7b9
boooobly commentedon Jul 15, 2026
Adding another fully controlled reproduction on Windows 10. This also matches the route-mismatch symptoms reported in #33332.
Environment:
Minimal reproduction:
Relevant sanitized log messages:
Windows AppModel-Runtime records destruction of the Codex AppX container. There is no corresponding Application Error, WER APPCRASH, Crashpad report, GPU reset, Display/nvlddmkm event, or WHEA error.
Clean-profile test:
I fully exited Codex and moved Local Storage, Session Storage, Preferences, Cache, Code Cache, GPUCache, Dawn/Graphite caches, and shader caches to a backup. The reset moved 12 items with 0 failures. Codex then reinstalled/refreshed the bundled Browser plugin.
The first post-reset attempt reproduced the same exit after example.com loaded successfully. This makes stale profile data, browser cache, plugin cache, localhost behavior, and a hardware/GPU failure unlikely.
Expected behavior:
A route-binding or PiP failure should return a recoverable Browser error without terminating the Codex Desktop host.
Raw logs are not attached because they contain local paths and task/session identifiers. Sanitized excerpts can be provided if requested.
tiestononstop commentedon Jul 16, 2026
Additional reproduction on Windows 10 Pro 22H2 (10.0.19045), Codex Desktop 26.707.9981.0.
The crash/restart reproduced three consecutive times while Browser Use opened
http://127.0.0.1:4173/for visual QA. The Vite site stayed healthy and returned HTTP 200; only Codex Desktop exited. A full PC restart did not resolve it.Sanitized log evidence immediately around the failures:
There is also an unrelated-looking plugin sync warning in the same startup window:
Observed result: the main Codex window closes and must be reopened; the Browser Use tool call is reported as aborted. Workaround confirmed: avoid the in-app browser and run headless Playwright from the terminal.
No full log attached because it contains local paths/thread metadata, but the relevant desktop logs are timestamped 2026-07-16 around 03:32-03:38 UTC.
CTCycle commentedon Jul 17, 2026
Update — confirmed fixed in the latest build (July 17, 2026).
I updated the Codex Desktop App to the latest Microsoft Store version today and tested the in-app browser with multiple sites:
Codex remained responsive with 9 active processes throughout. Windows Event Viewer recorded 0 new ChatGPT.exe crash events.
The fix appears to have shipped silently through the Store auto-update mechanism — no changelog entry, but the crash that reproduced consistently on versions
26.707.3748.0through26.707.9981.0is no longer occurring on this machine.Closing this issue. Anyone still experiencing the crash should ensure they're on the latest Store build and re-open if it persists.
CTCycle commentedon Jul 17, 2026
Verified fixed on latest build — see comment above for test results.