Codex webviews turn grey: recurring mouse-up selection/layout renderer crash on Linux

Recurring Codex webview renderer crash: mouse-up selection commit re-enters style update during compositing

Codex webviews repeatedly become grey while the rest of VS Code remains usable. Earlier incidents affected editor tabs while the sidebar survived; the September 10 incident affected the sidebar while editor tabs survived. The user confirms approximate timing against the latest native dump. Recreating affected views has recovered earlier incidents; Developer: Reload Webviews did not recover a prior captured incident.

Environment: Linux x86_64, Pop!_OS 24.04 / COSMIC, VS Code 1.134.0, Electron 42.8.1 / Chromium 148.0.7778.280, X11/XWayland. Codex extension currently installed: 26.903.61454; earlier investigation inspected 26.901.22334. Installed version is not proof of the version loaded in every existing window.

17 retained native dumps match Code+0x3c9fdc7 with RAX=8. Latest: September 10 at 10:25:40 NZST. Code ELF build ID: 36f35204bf833d2fcd3272fe594fd9d8f3f18b80. Kernel independently records an invalid-opcode trap at the latest incident, without a GPU reset or OOM in the inspected interval.

Walking stored frame-pointer chains gives the same path across matching dumps:
MouseEventManager::HandleMouseReleaseEvent -> LocalFrameView::UpdateLifecyclePhases -> RunCompositingInputsLifecyclePhase -> LayoutView::CommitPendingSelection -> LayoutSelection::Commit -> FrameSelection::IsHidden -> FrameSelection::SelectionHasFocus -> Document::UpdateStyleAndLayout -> LocalFrameView::UpdateStyleAndLayoutInternal -> Document::UpdateStyleAndLayoutTreeForThisDocument -> StateAllowsTreeMutations fatal guard.

Symbol qualification: Microsoft exact-build symbols were unavailable. Function attribution comes from matching unique instruction windows around individual return addresses against public Electron 42.8.1, then looking up its symbols. The immediate fatal branch matches three independent byte signatures with the same offset delta. Chromium source and disassembly agree that state 8 is kInCompositingInputsUpdate and the guard rejects tree mutations in that state. This is corroborated binary/source analysis, not official exact-build symbolication.

A bounded synthetic retained-editor/sidebar test with periodic DOM updates, selection/focus changes and content-visibility:auto completed 100 cycles without reproducing the native crash. It is not a faithful Codex conversation reproduction, and does not establish a workaround. ResizeObserver warnings are present in real sessions but are not established as causal.

Could maintainers symbolicate the exact build and investigate why selection visibility checking forces style/layout while the document is in the compositing-inputs phase? A minimal reproduction or known fixed engine/extension build would allow a controlled verification. We have not established that a generic update, GPU change, or disabling reasoning summaries fixes this.

Related report: https://github.com/openai/codex/issues/33042
Related Windows lifecycle-guard report: https://community.openai.com/t/codex-vs-code-renderer-crashes-during-concurrent-agent-streaming/1389759

No raw dumps, private conversation content, credentials or workspace paths are included in this report. Original dumps remain local because they contain process memory.

Start with the 17 retained native dumps and the exact Code ELF build identified in the report, then inspect the documented MouseEventManager-to-StateAllowsTreeMutations call path. Run the bounded synthetic retained-editor/sidebar test as a baseline, while seeking exact-build symbolication or a faithful Codex reproduction. Done means the crash cause is verified and a minimal reproduction or known fixed engine/extension build supports controlled verification.