Repository navigation
[Windows Desktop 26.818.5229.0] Repeated browser/main crashes when reopening oversized browser-heavy tasks #40349
Description
What version of the Codex App are you using?
- Microsoft Store package:
OpenAI.Codex 26.818.5229.0 - Previous package immediately before the update:
26.818.2441.0
What platform are you using?
Windows 11 x64, OS build 10.0.26100.6584.
What issue are you seeing?
Codex Desktop has repeatedly terminated over several days. The most clearly diagnosed occurrence is a real Electron main/browser-process crash shortly after an existing task restored two persisted in-app-browser sidebar tabs.
The whole desktop app disappeared without a crash dialog, interrupted active work, and had to be relaunched.
Crashpad recorded:
capture_kind=crash
ptype=browser
osarch=x86_64
local_report_uuid=8df12fb5-3221-4673-9b55-53de63445d56
A separate earlier exit during the same session was caused by the Microsoft Store/MSIX update path using ForceTargetApplicationShutdownOption. That update-driven exit is distinguished from the later Crashpad crash below.
Sanitized timeline
Local time (UTC+08:00), 2026-08-23:
17:31:37 AppX destroys the old 26.818.2441.0 container with
ForceTargetApplicationShutdownOption.
17:31:45 Package update registers 26.818.5229.0.
17:31:47 Updated app relaunches.
17:40:47 Existing task restores two persisted in-app-browser sidebar tabs;
both webviews attach and become DOM-ready.
17:41:12 Main desktop log stops.
17:41:28 Crashpad records capture_kind=crash, ptype=browser.
17:41:29 AppX container is destroyed.
17:43:35 App is manually relaunched.
There was no second package deployment/update at 17:41, so the later termination was not another forced-update shutdown.
What steps can reproduce the bug?
This is intermittent, but the observed sequence was:
- Launch or relaunch Codex Desktop on Windows with one or more tasks active.
- Open an existing task that has two persisted in-app-browser sidebar tabs.
- Allow both browser webviews to restore, attach, and become DOM-ready.
- Continue working or leave the task active.
- Roughly 40 seconds later, the entire Codex Desktop process exits.
Immediately before the crash, the desktop logs showed the two browser sidebar guests attaching and repeated mcp_app_sandbox.attach_unmatched warnings. The timing suggests an in-app-browser restore/lifecycle regression, but the available evidence does not prove the faulting native module.
What is the expected behavior?
- Restoring persisted in-app-browser tabs should not crash the Electron browser/main process.
- A stale or failed webview should be isolated and recoverable while the desktop host remains alive.
- App updates should warn about and coordinate shutdown when active tasks are running.
- Active turns should resume cleanly after an update or crash.
Additional diagnostics
- No matching Windows
Application Error, WER, or.NET Runtimeevent was recorded for the Crashpad occurrence. - No Resource Exhaustion Detector event was present.
- Approximately 24.6 GB of 39.6 GB physical memory was free.
- No GPU reset, WHEA, or Kernel-Power signal occurred in the same window.
- Session JSONL remained parseable after restart; task state was not corrupted.
- An older renderer Crashpad record also exists from the preceding day, consistent with repeated desktop instability rather than a single update event.
- Raw logs and dumps are intentionally not attached publicly because they can contain local paths, browsing history, prompts, and project data. Sanitized excerpts can be provided if maintainers request them.
Potentially related, but not exact duplicates:
- Windows: pausing Goal Mode still injects a continuation; restoring its in-app browser silently closes Codex #33827 — restoring an in-app browser silently closes Codex in a Goal Mode lifecycle case
- Codex Desktop crashes when the in-app Browser opens with multiple side chats running #33202 — browser creation with multiple active tasks
- [Windows][Codex Desktop] In-app browser crashes Codex when opening localhost #38175 — in-app browser crash during localhost navigation
Activity
github-actions commentedon Aug 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
RuipsStars commentedon Aug 24, 2026
Follow-up: complete 7-day scan and two newer crashes
The original report understated the frequency because only two events had been correlated at that point. A complete scan of Crashpad, desktop logs, AppModel/AppX events, and the affected session files found 8 Crashpad captures from 2026-08-22 through 2026-08-24:
reason=oomSanitized list of the six main-process crashes (local time UTC+08:00):
Every one has
capture_kind=crash,ptype=browser, andosarch=x86_64.AppModel confirms container destruction immediately after the two newest captures and automatic relaunch about three seconds later:
New high-confidence trigger: oversized browser-heavy session state
The repeatedly affected task has a rollout JSONL of approximately:
A second browser-heavy task involved in the 17:58 crash is:
When the 1.87 GiB task is opened, the desktop logs show two concurrent
thread/readrequests taking 20–29 seconds. The requests complete shortly before the main-process crash. The task also restores persisted in-app-browser state.The two newest reproductions were nearly identical:
mcp_app_sandbox.attach_unmatched.thread/readcalls take approximately 27–29 seconds.ptype=browserand the whole AppX container is destroyed.The earlier renderer capture at 2026-08-22 04:00:41 is especially relevant:
During that long browser-heavy session, the desktop reached a maximum of 19 in-app-browser tabs and emitted 62
attach_unmatchedwarnings. The 17:58 main-process crash session reached 16 browser tabs and emitted 17attach_unmatchedwarnings.The two newest main-process sessions also produced large bursts of
ResizeObserver loop completed with undelivered notifications(365 occurrences before the 15:07 crash and 77 before the 15:21 crash). This may be a symptom of renderer/UI churn rather than the native root cause.Updated assessment
The strongest evidence now points to an interaction between:
thread/readprocessing when reopening a very large task,There was no Windows Resource Exhaustion Detector event and no system-wide low-memory condition, so the explicit renderer
reason=oomis more consistent with a Chromium/Electron renderer or V8/process-level limit than exhaustion of all physical RAM.Suggested product-side protections:
Raw files are not attached because they contain prompts, local paths, browsing history, and project data. The sizes, counts, timings, UUIDs, and warning names above are sanitized.
[-][Windows Desktop 26.818.5229.0] Browser/main process crashes after restoring two persisted in-app-browser tabs[/-][+][Windows Desktop 26.818.5229.0] Repeated browser/main crashes when reopening oversized browser-heavy tasks[/+]Ernest-NA commentedon Aug 24, 2026
Adding a second, independent Windows reproduction with the same current build.
Sanitized evidence
26.818.5229.026.818.5229.0. Two earlier reports had the same lifecycle signature on26.818.2872.0and26.818.3698.0, so the current update appears to increase frequency rather than introduce the entire bug.Every crash report correlated with a main desktop log that stopped less than one second earlier. All nine logs ended during the same in-app-browser teardown sequence:
Shortly before teardown, the logs repeatedly contained:
Persisted browser-tab state grew across restarts: the app-level count observed at crash time increased from 6 to 10. The next restart restored 11 browser tabs across two tasks and spawned 21 desktop subprocesses. The machine still had ample free memory, with no matching Windows Application Error, resource-exhaustion event, or system instability, so this does not look like system-wide memory pressure.
The persistence behavior suggests the app crashes before committing tab removal, then restores the stale route on the next launch. A targeted workaround is to fully quit Codex, back up the global state file, and remove only the affected
thread-tab-routes-v1:*entries.No raw logs, session transcripts, task IDs, report UUIDs, local paths, URLs, prompts, repository names, or account information are included here because those artifacts may contain private data.
Ernest-NA commentedon Aug 24, 2026
Follow-up (2026-08-24): another crash occurred with the same capture_kind=crash, ptype=browser signature. Immediately before exit, the desktop log shows 12 restored in-app browser tabs, repeated "No ChatGPT browser route is available for browser session" warnings, and then "iab rejected tab for route" with tabRouteKey=null followed by webview teardown. No raw logs or user data are attached.
Important correction: the previously attempted local persisted-tab reset did not actually apply, so this recurrence should not be treated as evidence that the workaround failed.
khalidovicGPT commentedon Aug 26, 2026
Adding another independent Windows reproduction with the same Crashpad main/browser-process signature.
Sanitized evidence
26.818.5229.0: 3 crash records26.818.8289.0: 5 crash records26.820.7780.0: 2 crash records after reinstallcapture_kind=crashptype=browserosarch=x86_6426.820.7780.0.The first post-reinstall crash occurred about 14 seconds after reinstall completion, before any intentional use of Google Chrome or the in-app Browser. Therefore, although the Crashpad signature matches this issue, I cannot confirm restored browser tabs or browser navigation as the trigger. Here,
ptype=browseridentifies the Electron/Chromium main process and does not by itself establish the root cause.No native stack or minidump is available. The two post-reinstall sidecars are still present; the eight earlier sidecars were removed by the uninstall, but their timestamps, versions, and signatures were preserved in sanitized diagnostic notes.
No raw logs, local paths, project names, task/conversation IDs, browsing data, or report UUIDs are included publicly. I can provide targeted sanitized excerpts if maintainers indicate what would be useful.
WHC97 commentedon Aug 31, 2026
Adding another independent Windows reproduction on a newer build.
OpenAI.Codex 26.820.9563.026.818.8289.0capture_kind=crash ptype=browser osarch=x86_64This reproduction does not establish that an in-app browser tab is the trigger. Here,
ptype=browseridentifies the Electron/Chromium main process. No raw logs, local paths, task IDs, browsing data, or report UUIDs are included publicly.WHC97 commentedon Aug 31, 2026
Follow-up from the same independent Windows reproduction: the crash loop has now continued on an even newer Microsoft Store build.
OpenAI.Codex 26.825.6671.0capture_kind=crash ptype=browser osarch=x86_6426.825.6671.0throughout these two crashes; there was no concurrent package-version switch between them.This is a high-frequency browser/main-process crash loop that persists beyond the previously reported
26.820.9563.0build. No raw logs, local paths, task IDs, report UUIDs, browsing data, or document contents are included publicly.WHC97 commentedon Sep 6, 2026
Additional Windows desktop crash evidence for issue #40349
Ten distinct historical Crashpad sidecar report IDs were recovered from locally retained diagnostic command output. Each reports capture_kind=crash and ptype=browser. These are a lower bound, not the total number of crashes.
Local timestamps (UTC+08:00):
The 14:43:27 and 14:44:30 crashes occurred approximately 63 seconds apart. Main desktop logs were correlated against these timestamps; final logged operations vary and do not establish a single causal operation.
Current state verified September 6:
Please provide a supported way to retain local MAIN/BROWSER-process crash dumps and identify the relevant fix/build, if available. The user has experienced repeated work interruption. Neither ordinary log-tail correlation nor assuming oversized task history is the cause is sufficient to establish a root-cause fix.
No private conversation content, user files, account identifiers, browsing history, or raw dumps are included in this update.
linan109 commentedon Sep 24, 2026
Related observation on Windows x64, 2026-09-24, package
OpenAI.Codex 26.917.8451.0(desktop build10789). This did not involve persisted in-app-browser tabs, so it may indicate a broader Electron browser/main-process failure during oversized local-session recovery.Sanitized timeline (UTC+08:00):
09:22:49Crashpad recordedcapture_kind=crash,ptype=browser, report80e5bf7f-8858-4ed1-9da3-b77c215de637; the desktop instance had stopped logging abruptly and a new instance started about five seconds later.09:23:56a secondptype=browserCrashpad report was recorded:8c78ea2c-1bab-4295-be6e-9ff898f31e01, again immediately after the desktop log stopped.Immediately before both crashes, the client was restoring an existing local task that the sidebar classified as
notLoaded. Its transcript was517,388,820bytes. The logs contained repeatedConversation state not foundwhilethread/readactivity targeted that task. I did not attach the task ID, title, transcript, project path, or raw logs.This transcript has zero occurrences of
data:image/,image_generation,base64,,input_image, orfunction_call_output, so it appears distinct from the inline-image/base64 mechanism in #28531.Checks around the crashes:
ptype=browsersidecars, not a readable stack dump.Expected behavior: recovery/list hydration must bound or lazily page very large text-only session JSONL data, and a failed/stale task state must not terminate the Electron browser/main process.
mchelen-gov commentedon Oct 6, 2026
Adding a matching Windows reproduction.
Environment:
Four beta sessions terminated while restoring a persisted right-panel
in-app-browser tab. Each affected log ended abruptly at:
[browser-sidebar-manager] IAB_LIFECYCLE browser sidebar will attach webview
The affected state was one saved SharePoint browser tab under:
electron-persisted-atom-state.thread-browser-tabs-v1:
Stable and beta were both affected because they read the same
%USERPROFILE%.codex.codex-global-state.json state.
A targeted recovery succeeded:
This broke the restart/crash loop without resetting chats, authentication,
cookies, projects, or either app package.
No matching Application Error or Crashpad dump was generated. Longer sessions
had renderer RSS peaks around 2.3–3.3 GB, but one fresh restart also terminated
after approximately 44 seconds at the same webview-attachment transition.
I can provide sanitized logs and the state-repair details privately.
Feedback/session ID: 01a1128b-602e-7d72-9c87-d12c38e8cb72