Windows app 26.915.4065.0: repeated main-process crashes during embedded browser tab lifecycle

Environment

Windows x64; Codex package version 26.915.4065.0.
Bundled ChatGPT.exe file version 153.0.8010.48.
Local website development with built-in browser interaction/visual tests.

Actual behaviour

Six browser/main-process crash sidecars and one renderer crash sidecar were recorded during 19–20 September 2026. The application repeatedly exits during embedded-browser testing, interrupting the task and its local test processes.

For all six main-process incidents, the last desktop log entry precedes the crash-sidecar modification time by approximately 0.4–0.6 seconds and concerns the browser sidebar being rebound/created or a browser-use tab being closed.

Times below are UTC; sidecar times are file modification times, not native exception timestamps:

Date	Last desktop log	Crash metadata	Last action
2026-09-19	17:44:25.840	17:44:26.302	Browser sidebar window rebound
2026-09-19	19:00:31.015	19:00:31.487	Browser sidebar window rebound
2026-09-19	20:57:10.245	20:57:10.661	Hidden browser-use webview created; window rebound
2026-09-19	22:06:47.933	22:06:48.345	Browser sidebar synced/window rebound
2026-09-20	02:39:38.254	02:39:38.774	Browser-use tab closed
2026-09-20	03:29:32.775	03:29:33.290	Browser-use tab closed

Sidecars contain capture_kind: crash, osarch: x86_64, ptype: browser. A separate page-renderer crash at 2026-09-19 17:29:29 UTC logged reason=crashed, exitCode=-2147483645; its sidecar reports ptype: renderer.

Observed workflow / expected behaviour

Use the embedded browser to inspect a loopback-only development website, switch between browser tabs and close completed test tabs. The desktop application should stay running. This is a recurring observed association, not an isolated minimal reproduction; I have not deliberately reproduced another crash after diagnosis.

Checks and limitations

Approximately 32 GB RAM; about 9 GB free at the diagnostic snapshot. No Windows System event2004 low-memory warnings in the preceding seven days. This does not rule out transient or per-process allocation failures.
No out-of-memory/heap-limit indicators found in the targeted terminated-session logs.
No matching recent display-driver reset found.
Only sidecar metadata remains in the inspected Crashpad report directory; no native stack trace available locally.
Embedded-browser lifecycle handling is the leading hypothesis, not a confirmed defective function. No evidence establishes context compaction or website source as the cause.
Proposed mitigation: external-browser testing; not yet established as a fix.

This report intentionally excludes project identifiers, paths, account details, conversation contents, screenshots, raw logs and private website data. Please advise whether this browser-lifecycle failure is known and what minimal additional diagnostic information would help.

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

Codex App browser process crashes during browser-use/webview lifecycle — reproduced twice with ResizeObserver storm #46472
[macOS 27][26.915.31945] CrBrowserMain EXC_BAD_ACCESS after in-app browser tab handoff #46650

Powered by Codex Action

Additional occurrence on Windows x64 with the same Codex package version 26.915.4065.0.

Local time: 2026-09-21 16:59:59 America/Los_Angeles (Crashpad sidecar modification time).
Sidecar: capture_kind=crash, osarch=x86_64, ptype=browser.
Immediate workflow: a long-running local repository task had just completed authenticated visual QA of a loopback Mainframe page in the in-app browser; the temporary browser-use tab was closed after QA, and the desktop app exited. The task was recoverable after restart and its git/runtime state was intact.
App processes restarted around 17:00:14-17:00:49 local time.
No native dump remains locally beyond the 60-byte sidecar, so this is an observed lifecycle association rather than a minimal reproduction.

This matches the issue's browser-tab-close pattern closely. No project paths, account data, conversation content, or raw private logs are included here.

Follow-up: renderer crashes on Windows app 26.924.2738.0

Repeated crashes continue on a newer package, but the latest records have a different process type from the original report. I am adding this for triage continuity, not claiming a confirmed shared root cause.

Verified observations

Windows x86_64; installed Codex package version: 26.924.2738.0.
Three Crashpad sidecars inspected on 26 September 2026 report:
{"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}
Their last-write times, converted to UTC:
- 2026-09-26 18:34:50.332 UTC
- 2026-09-26 18:38:26.837 UTC
- 2026-09-26 18:55:28.414 UTC
These are sidecar file modification times, not native exception timestamps.
At the post-incident process check, the main ChatGPT.exe process was still running with a start time predating all three records. This differs from the earlier main/browser-process exits.
A desktop log entry at 18:34:52.482 UTC reports a React root render request for the primary Electron window. This is subsequent activity, not evidence of the cause.

Activity and impact

The user reports repeated interruptions while working in a long-running coding conversation. Recent activity included small local source edits and local tests/build checks. No new development dependency or software was installed as part of that recent work.

Following the earlier mitigation, external Chrome was used for recent desktop testing; no in-app test tabs were created, switched or closed in that recent work. An external-browser control attempt separately stopped at a URL safety guard. That tool stop must not be confused with, or assumed to explain, the recorded renderer crashes.

Expected: the desktop conversation remains usable during ordinary coding and local verification.
Actual: repeated user-visible interruptions, with three renderer-crash sidecars recorded during this interval.

Diagnostic limits

No deterministic minimal reproduction or native stack trace/exception code has been obtained for these new incidents.
Targeted desktop-log inspection did not find an actual native crash diagnostic explaining these three incidents. Conversation text mentioning crashes was excluded from the evidence.
A post-incident snapshot showed approximately 31.6 GiB physical RAM with 5.7 GiB free. This does not rule out transient or per-process memory exhaustion.
The current package version is verified; an update regression is not established.
The exact failing renderer and relationship to the original browser-lifecycle issue remain unconfirmed.

Would you prefer this renderer signature tracked separately, and what minimal additional diagnostic would distinguish the cause?

Only this sanitised summary is submitted. No source code, project identifiers or paths, account/session identifiers, raw logs, crash dumps, screenshots, or conversation contents are attached.

Further evidence from a fresh check on 26 September: two additional renderer-crash sidecars are now present, with last-write times 19:01:23.742 UTC and 19:05:51.643 UTC. Both contain capture_kind=crash, osarch=x86_64, ptype=renderer.

This brings the verified count for the inspected 26 September records to five, not three. The earlier comment described the three records available at that inspection, not a total of all user-experienced crashes. The user reports further repeated crashes; retained sidecars should not be assumed to capture every interruption. These remain file modification timestamps, not native exception timestamps. No additional causal conclusion is established, and no raw logs or private data are attached.

Complaint / escalation: at least 18 recorded renderer crashes today; work stopped

I am escalating the continuing instability as a complaint. Repeated interruptions and restarts have made reliable use of Codex impossible for my current work, and I have now had to stop development. Please acknowledge this escalation and help establish a supported route to stable use.

Verified count and environment

18 distinct retained Crashpad renderer-crash records on 26 September 2026, verified by reading each sidecar. This is 13 additional records beyond the five in my previous update.
Evidence snapshot: 26 September 2026, 21:42:36 UTC / 22:42:36 Europe/Dublin.
Windows x64; running Codex package 26.924.2738.0, verified from the running executable's package path.
Every one of the 18 records contains {"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}.
The first and last retained records are approximately 3 hours 6 minutes apart.

Timestamp evidence

All dates below are 26 September 2026. These are sidecar file last-write times, displayed to the second, not native exception timestamps. Europe/Dublin is UTC+1 on this date.

Record	UTC	Europe/Dublin
1	18:34:50	19:34:50
2	18:38:26	19:38:26
3	18:55:28	19:55:28
4	19:01:23	20:01:23
5	19:05:51	20:05:51
6	19:09:40	20:09:40
7	19:11:50	20:11:50
8	19:18:48	20:18:48
9	19:22:13	20:22:13
10	19:27:10	20:27:10
11	20:28:47	21:28:47
12	20:40:00	21:40:00
13	21:03:07	22:03:07
14	21:19:11	22:19:11
15	21:31:11	22:31:11
16	21:34:33	22:34:33
17	21:37:20	22:37:20
18	21:41:12	22:41:12

Counting method and limits

The count is of distinct sidecar files with unique names, not repeated text matches in logs. Each file was parsed and confirmed to identify a renderer crash. The day filter begins at 25 September 23:00 UTC (midnight in Ireland) and ends at the stated snapshot.

This is a confirmed minimum from retained records, not necessarily every interruption. It also does not establish 18 exits of the entire application's main process. These renderer records differ from the original main/browser-process signature in this issue; a common cause has not been established. No deterministic reproduction, native stack trace or confirmed update regression is available.

Activity and impact

The latest interrupted work involved ordinary local coding and local test/build checks, including scoped coding agents. In-app browser tabs were not created, switched or closed during that unit, and no deliberate crash reproduction was attempted. The earlier browser workaround therefore has not eliminated the user-visible instability; that observation does not identify the cause.

I have had to interrupt work, restart repeatedly and finally request a safe stop. Development is now paused. This level of instability is preventing dependable use of the app.

Requested response

Please acknowledge the complaint and triage this repeated renderer-crash pattern on 26.924.2738.0.
Please advise whether there is a known regression and a supported workaround or stable-version option.
Please identify the minimum additional diagnostic needed. If dumps or sensitive logs are necessary, provide an appropriate private submission route; I do not authorise public upload of my source or conversation.
Please say whether these newer renderer crashes should be tracked in a separate issue. I am updating this existing report for continuity rather than opening a duplicate without guidance.

Only this sanitised summary is being posted. No project source, local paths, account/session identifiers, raw logs, crash dumps, screenshots or conversation transcripts are attached.

Escalation: 143 retained Windows crash records; repeated interruptions continue

Please triage this as an ongoing reliability problem on OpenAI.Codex 26.924.2738.0. Repeated user-visible crashes are interrupting normal work. This is an additional affected-machine report, not an update to the original reporter's counts.

Verified local evidence

Installed Windows package: 26.924.2738.0; internal release 26.924.22138, build 11645.
Windows 11 Pro Insider Preview, build 26340, x64.
143 unique retained Crashpad crash sidecars at the 2026-09-30 03:35:19 UTC inspection: 142 renderer and one browser/main-process.
Counts by local date (America/New_York): September 26: 29 renderer; September 27: 24 renderer; September 28: 22 renderer; September 29: 67 renderer plus one browser/main-process.
Latest renderer record: 2026-09-30 03:34:38.164 UTC (September 29, 23:34:38 EDT). Metadata: capture_kind=crash, ptype=renderer, osarch=x86_64.
The main application process remained running, with its start time preceding this latest incident. These are not 143 whole-application exits.
The browser/main-process sidecar was last written at 2026-09-29 18:39:01.075 UTC.
Timestamps above are sidecar file last-write times, not native exception timestamps. Counts represent distinct retained files, not text matches or every possible interruption.

No current native dumps remain in the inspected Crashpad report directory, so no crash stack establishes the cause. One post-incident memory snapshot showed approximately 28.7 GiB free physical RAM out of 63.7 GiB usable. This does not rule out transient/per-process allocation failure or prove a leak. The targeted recent Windows System-event query found no matching low-memory/display-reset events.

Additional tab-restoration symptom in two chats

Closed in-app tabs return with the same underlying tab IDs. This occurs within the same running main-process session; a full app restart is not necessary. The user has closed the affected tabs repeatedly.

Sanitized lifecycle evidence, all 30 September UTC:

Chat A: one tab closed at 03:20:09.193, reopened with the same ID at 03:21:27.368, closed again at 03:21:36.503, and reopened at 03:22:00.569. The close is explicitly recorded as tabType=closed. The working agent reports it did not reopen the tab.
Chat B: one tab closed at 02:26:37.542 and reopened at 02:28:46.949. Another closed at 02:29:54.802 and reopened with the same ID at 02:29:54.812, 10 ms later.
At inspection, Chat B's persisted thread-tab-routes-v1 routes and right-panel membership still included both affected tabs. Chat A's saved routes/right-panel membership were empty. Therefore a single stale on-disk route entry does not explain both cases.

Related tab reports: #45004 and #46045. A shared cause between tab restoration and renderer crashes is not established. The lifecycle opened event does not establish who requested the opening.

Requested response

Please acknowledge and triage the repeated renderer crashes on 26.924.2738.0.
Is there a supported fixed build or rollback path? A read-only updater check could not establish Windows Store update eligibility, so we are not claiming this is the latest available build.
What minimum additional diagnostic would identify the crashing renderer and its cause? Please provide a private route if native dumps or sensitive logs are needed.
Should this Windows same-ID tab-restoration evidence be tracked separately, and is there a supported workaround that does not require repeatedly closing tabs or clearing the user's whole profile?

Only this sanitized summary is submitted. Private project names/URLs, local user paths, conversation/tab IDs, raw logs, source code and conversation contents are omitted. No reinstall, profile reset or app restart was performed as part of this diagnostic investigation.

Supplemental diagnostic evidence

Adding concrete build and event details to the escalation above.

Build identification

Running packaged ChatGPT.exe file/product version: 154.0.8037.57.
Desktop logs identify build 11645, release 26.924.22138, build commit 2e782921399a788a842b74ee1944a2e1e6e003a1.
Windows package remains 26.924.2738.0.
Main process PID 54004 started at 2026-09-29 18:42:36 UTC and was still running at the latest process check.

Recent Crashpad record identifiers

These are local sidecar basenames; we have not verified whether corresponding reports were uploaded or are retrievable server-side. All are ptype=renderer; times are UTC sidecar last-write times on September 30.

Time	Record ID
03:12:28.221	4918be56-7949-422d-94bc-3579c4782692
03:15:36.552	b92d184b-2897-4303-a7e3-a6a364c7d1bb
03:17:56.296	8b751d16-e38a-4637-abac-a11a0583333e
03:20:29.933	72c16505-5b6e-4401-bc5f-3570f350abb9
03:24:10.979	9e50c1ea-d311-4dc7-b63b-36d522515abb
03:30:52.276	a5bb824c-dd0f-4a75-b8dc-0346c7b5f974
03:34:38.164	19ffba48-17a3-4197-8cf4-9deb6fc869bb

The separate browser/main-process record is 6f2f4dba-685e-4324-82c3-9f5c95577049, last written September 29 at 18:39:01.075 UTC.

Narrow log excerpt around immediate tab recreation

Below, CHAT_B and browser-use:TAB_B2 consistently replace the real conversation/tab IDs. Unrelated fields are omitted; timestamps and retained field values are unchanged.

2026-09-30T02:29:54.802Z [browser-sidebar-manager]
  IAB_TAB_ANALYTICS action=closed browserTabId=browser-use:TAB_B2
  conversationId=CHAT_B isBrowserUseTab=false ownerWebContentsId=1 threadBrowserTabCount=2

2026-09-30T02:29:54.803Z [electron-message-handler]
  IAB_LIFECYCLE received browser sidebar owner sync browserTabId=null
  conversationId=CHAT_B originWebContentsId=1 windowId=1

2026-09-30T02:29:54.803Z [browser-session-registry]
  IAB_LIFECYCLE rebound browser sidebar window
  ownerWebContentsId=1 previousOwnerWebContentsId=1 windowId=1

2026-09-30T02:29:54.811Z [browser-session-registry]
  IAB_LIFECYCLE rebound browser sidebar window
  ownerWebContentsId=1 previousOwnerWebContentsId=1 windowId=1

2026-09-30T02:29:54.812Z [browser-session-registry]
  IAB_LIFECYCLE registered browser sidebar thread conversationId=CHAT_B windowId=1

2026-09-30T02:29:54.812Z [browser-sidebar-manager]
  IAB_TAB_ANALYTICS action=opened browserTabId=browser-use:TAB_B2
  conversationId=CHAT_B isBrowserUseTab=false ownerWebContentsId=1 threadBrowserTabCount=3

The browser-use: prefix and isBrowserUseTab=false coexist in the original logs; this is not a transcription change. Subsequent entries at 02:29:55.201–.202 show the renderer disposing/removing that webview with tabType=closed. We are not inferring a durable final state from the 10 ms transition alone; there are also later same-ID reopening observations.

Saved-state comparison timing
The exported comparison was captured at 03:33:21.906 UTC:

Chat A: routes=[], topology.right.tabIds=[], topology.right.open=false.
Chat B: both affected browser routes and right-panel membership remained present.

This was a later snapshot, not a synchronized capture at the instant of closing. Reconciliation, missed writes, and competing live/persisted state remain hypotheses.

Relevant diagnostic history
Earlier in this session, a separate Computer Use startup failure (failed to write kernel assets ... os error 3) was traced to missing live-runtime temporary directories under %LOCALAPPDATA%\\Temp\\.tmpXXXXXX. Missing empty directories belonging to the affected project's live runtimes were recreated, and browser inventory initialization then succeeded in four chats. No runtime binaries were replaced and the app was not restarted. Renderer crashes continued afterward. We do not claim this repair caused or resolved the crashes/tab recurrence; it is included so triage has the relevant local intervention history.

Raw local inventories, Windows event exports, selected desktop lifecycle records, and saved-state snapshots have been retained. Please specify a private upload channel if you need those or full conversation identifiers to correlate telemetry. A deterministic minimal reproduction and native crash stack are still unavailable.

Further crash while this escalation was being submitted
At the 2026-09-30 03:39:13 UTC inspection, the retained count increased to 144: 143 renderer crashes and one browser/main-process crash. The additional renderer record is dfaaa74f-8ff4-41b4-894f-b8a6568f0b0a, last written at 03:37:34.5605083 UTC (September 29, 23:37:34 EDT), less than three minutes after the previously reported renderer crash. This raises the September 29 local-day renderer count to 68.

The user explicitly requests escalation and is willing to provide whatever relevant diagnostics engineering needs. Please provide an actionable diagnostic collection/submission route and a supported stability workaround. The repeated interruptions are ongoing during the reporting process, not merely historical.

Navigation Menu

Repository navigation

Windows app 26.915.4065.0: repeated main-process crashes during embedded browser tab lifecycle #46767

Environment

Actual behaviour

Observed workflow / expected behaviour

Checks and limitations

Follow-up: renderer crashes on Windows app 26.924.2738.0

Verified observations

Activity and impact

Diagnostic limits

Complaint / escalation: at least 18 recorded renderer crashes today; work stopped

Verified count and environment

Timestamp evidence

Counting method and limits

Activity and impact

Requested response

Escalation: 143 retained Windows crash records; repeated interruptions continue

Verified local evidence

Additional tab-restoration symptom in two chats

Requested response

Supplemental diagnostic evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows app 26.915.4065.0: repeated main-process crashes during embedded browser tab lifecycle #46767

Description

Environment

Actual behaviour

Observed workflow / expected behaviour

Checks and limitations

Activity

github-actions commented on Sep 20, 2026

jp-quant commented on Sep 22, 2026

vinnymorgan commented on Sep 26, 2026

Follow-up: renderer crashes on Windows app 26.924.2738.0

Verified observations

Activity and impact

Diagnostic limits

vinnymorgan commented on Sep 26, 2026

vinnymorgan commented on Sep 26, 2026

Complaint / escalation: at least 18 recorded renderer crashes today; work stopped

Verified count and environment

Timestamp evidence

Counting method and limits

Activity and impact

Requested response

iknyc commented on Sep 30, 2026

Escalation: 143 retained Windows crash records; repeated interruptions continue

Verified local evidence

Additional tab-restoration symptom in two chats

Requested response

iknyc commented on Sep 30, 2026

Supplemental diagnostic evidence

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions