Settings > Linux desktop can crash with generic error after GNOME lock/unlock

[psypeal]

Summary

After returning from a prolonged GNOME screen lock, opening Settings > Linux desktop can render only the generic error boundary:

Oops, an error has occurred

This was observed on the same session where tray Quit later stopped responding. The two symptoms may share a damaged Electron/WebContents resume lifecycle, but they are reported separately because that relationship is not yet proven.

Environment

• OS: Ubuntu 24.04.4 LTS
• Desktop: Ubuntu GNOME
• Session: X11
• Kernel: 6.8.0-134-generic
• Package format: deb
• codex-desktop-linux: 0.9.5 at 2e04d928babaf09b321c870f4d8b9befd28921a5
• Installed package version: 2026.07.12.122632
• Electron: 42.1.0
• Upstream Codex app: 26.707.51957
• Optional Linux features: none

Steps observed

1. Start Codex Desktop normally.
2. Lock the GNOME desktop for an extended period.
3. Unlock and return to the existing app instance.
4. Open Settings.
5. Select Linux desktop.

Actual behavior

The settings route displays only:

Oops, an error has occurred

Expected behavior

The generated Linux Desktop settings page should render its launcher, tray, warm-start, update, and build-information controls after session resume.

Build and static checks

The installed patch report records keybinds-settings as applied. The generated asset:

/opt/codex-desktop/content/webview/assets/linux-desktop-settings-linux.js

• passes node --check;
• has all referenced module exports present;
• imports successfully in an ESM runtime;
• returns a valid React element when LinuxDesktopSettings({}) is evaluated.

The existing generated-page unit test also passes, but it renders simplified mocked components and does not exercise the real Electron suspend/resume lifecycle.

Runtime observations

The launcher log contains repeated lifecycle errors around affected sessions:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 destroyed listeners added to [WebContents]
Error occurred in handler for 'codex_desktop:message-from-view': TypeError: Object has been destroyed

The generic error boundary does not currently log the renderer exception or component stack to launcher.log, which prevents identifying the exact crashing component.

Possible direction

• Log the Linux Desktop route error-boundary exception and component stack.
• Validate or recreate destroyed auxiliary WebContents after unlock/resume.
• Add a real-browser/runtime smoke test for the generated settings route instead of relying only on mocked component rendering.
• Expose recent Linux lifecycle diagnostics on the page when it can render.

[PinguuSS]

Since this report, #913 merged a separate Linux Desktop Settings fix: the generated route now takes React/JSX from the module that actually owns the active settings route, and the patch composition is transactional. That can independently explain a generic route error boundary, but it does not prove the suspend/resume lifecycle warnings are fixed. #897's tray resume recovery is also a separate ownership path.

Could you please retry the prolonged lock/unlock reproduction on 413e484 or a newer main build? If it still reproduces, the most useful next evidence is the exact launcher-log timestamp around opening Linux desktop, whether the same app instance/WebContents survived the lock, and any renderer exception/component stack from DevTools. I found no open PR currently covering this lifecycle failure. A reproduced current-main failure should start with focused error-boundary/WebContents observability before changing listener or resume behavior.

[PinguuSS]

Additional current-main evidence: the lifecycle signals are reproducible on KDE Plasma Wayland at startup, without lock or suspend.

I tested two isolated builds at 413e484 against DMG a66a0645fd4de6f4f22e75ca87bedb1585aeb57f3457a3df55509bf8da110879 (26.707.51957, Electron 42.1.0): one pre-existing post-#919 build and one local build containing an unrelated Remote Mobile descriptor retarget. Both used clean Electron state, copied isolated Codex auth, separate XDG roots and CDP ports. Both emitted three MaxListenersExceededWarning events for destroyed listeners followed by TypeError: Object has been destroyed, then remained on the splash while routes mounted and backend RPCs completed.

This does not yet reproduce the Linux Desktop route error after prolonged GNOME/X11 lock, so I would keep route-error observability separate. It does show that the listener/WebContents failure survives #913, is broader than the original suspend-only scenario, and predates the unrelated local feature correction. I am keeping code changes out of this issue until the active PR queue clears and the owning WebContents/listener can be identified.

[psypeal]

Confirmed: the Linux Desktop settings failure still reproduces on current main after #913.

Tested build:

• codex-desktop-linux commit: 413e484f47d300243397280338f19beb187025b2
• includes Fix Linux desktop settings React runtime #913 (c9c5ee3, Fix Linux desktop settings React runtime)
• upstream Codex app: 26.707.61608
• upstream DMG SHA256: d4fc717a53fdecfa76a73147faa609f65e1bbaf52d5b43446ccca4c21a430347
• Electron: 42.1.0
• Ubuntu 24.04.4 / GNOME / X11
• optional Linux features: none
• build metadata reports dirty: false

After the affected lock/unlock session, opening Settings > Linux desktop still reaches the generic error boundary. The newer build now logs the renderer exception and component stack, which gives a focused failure:

errorMessage="Cannot read properties of null (reading 'useState')"
errorName=Error
componentStack="
    at LinuxToggle (http://127.0.0.1:5175/assets/linux-desktop-settings-linux.js:1:1813)
    at n (http://127.0.0.1:5175/assets/linux-settings-group-linux.js:1:181)
    at n.Content (http://127.0.0.1:5175/assets/linux-settings-section-linux.js:1:422)
    at n (http://127.0.0.1:5175/assets/linux-settings-section-linux.js:1:181)
    at t (http://127.0.0.1:5175/assets/linux-settings-page-linux.js:1:181)
    at LinuxDesktopSettings"

The stack ultimately enters the app message bridge through Object.postMessage / dispatchMessage, but the first generated component shown is LinuxToggle. The same log still contains repeated:

TypeError: Object has been destroyed

So #913 did not fix this reproduced failure on 413e484. The new observability suggests the next investigation should focus on why LinuxToggle's bridge-backed state path reaches a null React hook dispatcher in the active route runtime, and whether that runtime becomes invalid or duplicated across the surviving WebContents after lock/unlock.

[PinguuSS]

Thanks, this confirms that #913 fixed the normal route-runtime case but did not fix the post-lock lifecycle failure. The exact LinuxToggle stack is the evidence we needed.

I am going to keep two signals separate until the generated assets/runtime prove a shared owner: (1) LinuxToggle calling useState with a null React dispatcher, and (2) the repeated destroyed-WebContents errors in the same affected session. The published DMG also changed, so the next inspection will use the exact 26.707.61608 artifact identity you recorded and verify which active settings route exports the React/JSX bridge after patching.

I rechecked the open PR queue and found no PR currently covering #892. I will keep any code change behind a focused reproduction and test rather than infer a lifecycle fix from the stack alone.

[PinguuSS]

I independently downloaded the same DMG and confirmed SHA-256 d4fc717a53fdecfa76a73147faa609f65e1bbaf52d5b43446ccca4c21a430347 and size 615702561. A clean no-feature build at 413e484 was accepted with keybinds-settings: applied and no warnings.

There is one important mismatch to resolve before changing code: in my generated linux-desktop-settings-linux.js, LinuxToggle is a class and contains no useState; column 1813 falls inside its update method. The generated fallback group/section/page/toggle assets also contain no hooks. The webview server forces no-store, so a normal HTTP cache explanation is unlikely.

Could you provide these two values from the exact installed tree that produced the error?

sha256sum /path/to/codex-app/content/webview/assets/linux-desktop-settings-linux.js
head -c 2400 /path/to/codex-app/content/webview/assets/linux-desktop-settings-linux.js

If locating the installed tree is inconvenient, the asset response body from http://127.0.0.1:5175/assets/linux-desktop-settings-linux.js in DevTools is equally useful. I want to prove whether the affected renderer loaded the class-based current asset or a function-based variant before attributing the null dispatcher to the bridge/WebContents lifecycle.

[PinguuSS]

More current-DMG evidence from an isolated KDE/Wayland run:

• NODE_OPTIONS=--trace-warnings identifies the warning owners. The 11th listener is not enough to identify a leak by itself: the unified app currently has roughly 13 distinct destroyed owners on the primary WebContents (window registration, app-server surface, IPC client, native context menu, SQLite, AppHost, AppView, shared objects, power-save lifecycle, etc.). Raising the listener limit would only hide useful evidence.
• registerAppView does register another cleanup when the same WebContents registers a replacement AppView. A test-first local patch reduced the startup count by one, but the warning remained because the current shell legitimately exceeds the default limit. I am not proposing that partial patch as the Settings > Linux desktop can crash with generic error after GNOME lock/unlock #892 fix.
• I instrumented every destroyed registration and then forced a renderer recreation with CDP Page.crash in the isolated build. The same WebContents survived and createAppHost added one additional lifecycle listener. This confirms a host/port lifecycle leak across renderer recreation.
• Despite that stronger transition, Settings > Linux desktop reopened correctly. The served asset remained the 9,423-byte class-based implementation with zero useState occurrences, and there was no renderer console error or error boundary.

So the listener/AppHost lifecycle is real, but it still does not explain the reported null hook dispatcher. I am keeping the local code unpublished until we compare the exact affected linux-desktop-settings-linux.js response or reproduce the visible error for the right reason.

[psypeal]

Here are the exact values from the installed tree that produced the error. I also compared the live port-5175 response with the installed file.

$ sha256sum /opt/codex-desktop/content/webview/assets/linux-desktop-settings-linux.js
f416ed5169e23f1427b5e18c66cf72a2e3278e8738937417177a82f9f3c30bcc  /opt/codex-desktop/content/webview/assets/linux-desktop-settings-linux.js

$ head -c 2400 /opt/codex-desktop/content/webview/assets/linux-desktop-settings-linux.js
import{codexLinuxReact as React,codexLinuxJsx as $}from"./app-initial~app-main~page-CMpPiY3-.js";import{u as __post}from"./app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js";import{n as SettingsRow}from"./linux-settings-row-linux.js";import{n as SettingsSection}from"./linux-settings-section-linux.js";import{n as SettingsGroup}from"./linux-settings-group-linux.js";import{t as SettingsPage}from"./linux-settings-page-linux.js";import{t as Toggle}from"./linux-settings-toggle-linux.js";var KEYS={promptWindow:"codex-linux-prompt-window-enabled",systemTray:"codex-linux-system-tray-enabled",warmStart:"codex-linux-warm-start-enabled",autoUpdateOnExit:"codex-linux-auto-update-on-exit"};function codexLinuxChecked(next){return next&&typeof next=="object"&&next.target&&typeof next.target.checked=="boolean"?next.target.checked:next===!0}class LinuxToggle extends React.Component{constructor(props){super(props),this._alive=!1,this.state={value:props.defaultValue??!0,isLoading:!0,error:null},this.load=this.load.bind(this),this.update=this.update.bind(this)}componentDidMount(){this._alive=!0,this.load()}componentDidUpdate(previous){(previous.settingKey!==this.props.settingKey||previous.defaultValue!==this.props.defaultValue)&&this.load()}componentWillUnmount(){this._alive=!1}load(){let{settingKey:key,defaultValue=!0}=this.props;this.setState({isLoading:!0}),__post("get-global-state",{params:{key}}).then(result=>{this._alive&&this.setState({value:result?.value??defaultValue,error:null})}).catch(err=>{this._alive&&this.setState({error:err instanceof Error?err.message:String(err)})}).finally(()=>{this._alive&&this.setState({isLoading:!1})})}update(next){let value=codexLinuxChecked(next),previous=this.state.value,{settingKey:key}=this.props;this.setState({value,error:null}),__post("set-global-state",{params:{key,value}}).catch(err=>{this._alive&&this.setState({value:previous,error:err instanceof Error?err.message:String(err)})})}render(){let{label,description}=this.props,{value,isLoading,error}=this.state,details=error?$.jsxs("div",{className:"flex flex-col gap-1",children:[$.jsx("span",{children:description}),$.jsx("span",{className:"text-token-error-foreground",children:error})]}):description;return $.jsx(SettingsRow,{label,description:details,control:$.jsx(Toggle,{checked:value,disabled:isLoading,onChange:this.upda

The live response is identical:

GET http://127.0.0.1:5175/assets/linux-desktop-settings-linux.js
Content-Length: 9423
Cache-Control: no-store, max-age=0
Pragma: no-cache
Expires: 0
SHA256: f416ed5169e23f1427b5e18c66cf72a2e3278e8738937417177a82f9f3c30bcc

Structural checks on both the installed file and live response:

LinuxToggle declarations: 1 class LinuxToggle
function LinuxToggle: 0
useState occurrences: 0

Installed file metadata:

size=9423
mtime=2026-07-12 19:22:58 -0700
owner=root:root
mode=0644

So the affected renderer loaded the current class-based asset, not a function-based or HTTP-cached variant. Since the logged null-dispatcher stack appears while LinuxToggle is class-based and hook-free, the next likely boundary to inspect is the imported __post binding (u from ...muth998c-HZz8cbLQ.js) or another imported bridge/runtime invoked by the class lifecycle, rather than LinuxToggle directly calling useState.

[PinguuSS]

Thanks, that resolves the asset mismatch completely: your installed file and live response are byte-identical to mine (f416ed5169e23f1427b5e18c66cf72a2e3278e8738937417177a82f9f3c30bcc).

I also resolved the two remaining bridge/runtime hypotheses locally:

• __post export u is async function kI(...); it calls the imperative VS Code bridge and is not a React hook.
• I temporarily exported and initialized the current Mk, nearby Settings R0, and route-root n2 React bindings in the isolated renderer. Their namespace wrappers are different objects, but their useState, Component, and __CLIENT_INTERNALS... dispatcher object are strict-equal. Retargeting Fix Linux desktop settings React runtime #913 from Mk to another alias would therefore not change the dispatcher.
• Three cycles of real Electron powerMonitor events (lock-screen, unlock-screen, suspend, resume) left the same WebContents and listener count stable, and the route remained healthy. A renderer crash/recreation also recovered. The missing condition is still the real GNOME/X11 session transition.

The next decisive artifact is the JavaScript error.stack, not only React's componentStack. The component stack tells us where React caught the failure; the JS stack identifies which function actually invoked useState while the dispatcher was null. Does the structured error-boundary log contain an errorStack, stack, or a preceding multiline stack for the same timestamp? If so, please paste that exact field/block. Also useful: whether the route recovers via the error-boundary retry/back action without restarting the app.

[psypeal]

The structured log does contain the decisive JavaScript errorStack. Here is the exact field from launcher-log line 48199:

errorName=Error
errorMessage="Cannot read properties of null (reading 'useState')"
errorStack="Error: Cannot read properties of null (reading 'useState')
    at Object.postMessage (http://127.0.0.1:5175/assets/app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js:100:25700)
    at e.dispatchMessage (http://127.0.0.1:5175/assets/app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js:100:26854)
    at http://127.0.0.1:5175/assets/app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js:100:27337
    at rI (http://127.0.0.1:5175/assets/app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js:100:25230)
    at oI (http://127.0.0.1:5175/assets/app-initial~app-main~plugin-detail-page~new-thread-panel-page~settings-page~appgen-library-~muth998c-HZz8cbLQ.js:100:25296)
    at qee (http://127.0.0.1:5175/assets/app-initial~app-main~onboarding-page-D9sPBwim.js:9:117844)
    at Tl (http://127.0.0.1:5175/assets/app-initial~app-main~onboarding-page-D9sPBwim.js:9:112881)
    at wl (http://127.0.0.1:5175/assets/app-initial~app-main~onboarding-page-D9sPBwim.js:9:112386)
    at Qee (http://127.0.0.1:5175/assets/app-initial~app-main~onboarding-page-D9sPBwim.js:9:123629)
    at au (http://127.0.0.1:5175/assets/app-initial~app-main~onboarding-page-D9sPBwim.js:9:122456)"
rendererWebContentsId=1
rendererWindowId=1
rendererWindowAppearance=primary

There is also an important timing correction. The structured record has no timestamp of its own, but it is immediately preceded by asset requests timestamped 12/Jul/2026 19:25:02. Electron PID 2137839 started at 19:24:13, less than one minute earlier. There is no later Starting ChatGPT launcher / electron_spawned marker after this error, and PID 2137839 is still the current app process.

So this particular captured failure occurred on a freshly started app instance and does not require a prolonged lock/unlock transition. The original lock/unlock correlation may have conflated this settings-route failure with the separate stuck-tray behavior.

For recovery behavior: the app remained usable on other routes without restarting, but we did not explicitly test the error-boundary retry/back action against the Linux Desktop route while preserving the failure. I cannot claim whether that route itself recovers without restart from this occurrence.

The JS stack points into Object.postMessage and dispatchMessage, then through rI / oI, rather than into LinuxToggle or a React hook in the generated asset. This should provide the actual caller chain needed to locate the null-dispatcher invocation.

[PinguuSS]

Thanks. The timing correction is useful and removes lock/unlock as a prerequisite, but I found an important limitation in the new errorStack evidence.

On current main (bce8d36) with a clean no-feature build from 26.707.62119, several unrelated Remote Control failures such as Connection for host ID ... not found were logged with the same stack shape:

at Object.postMessage (...)
at e.dispatchMessage (...)
at ...
at Ihe (...)
at ap (...)

Those errors originate from failed Remote Control status requests, not from React or Linux Desktop Settings. This proves that the launcher-log errorStack is being reconstructed or reserialized on the renderer logger / Electron bridge path; it does not preserve the original throw site. The postMessage -> dispatchMessage -> logger frames in the reported useState error therefore identify the logging transport, not the function that dereferenced the null dispatcher.

I then ran a direct current-DMG probe that logged the same Error both as a nested object and as the primitive string error.stack. The nested errorStack again pointed at the logger bridge, while the primitive field retained the original issue892OriginalThrowSite frame. That gives us a narrow way to collect the missing evidence without changing React or WebContents lifecycle behavior.

The current active assets are:

• Settings runtime: app-initial~app-main~settings-page-DgWsFfJq.js
• request/logger bridge: app-initial~app-main~quick-chat-window-page~work-home-page~chatgpt-conversation-page-BqLP6EDd.js
• generated Linux Settings SHA-256: 599204ffdfd55fca9170dc0e69cef744e3dc5d8df8e7855fa0a915cbfb27530a

I opened #933 to preserve originalErrorStack as a primitive string in the current renderer error boundary. It is intentionally observability-only: it does not claim to fix this issue. The descriptor applied against DMG 26.707.62119, stayed byte-stable on a second pass, and the isolated build passed current-DMG acceptance. Once a failing run built from that PR records originalErrorStack, we should have the actual caller needed for a focused behavior fix.

[PinguuSS]

Following the maintainer review on #933, I am closing the diagnostic PR rather than proposing this observability probe for the default core. The tested branch will remain available here:

• PR: Preserve renderer error stacks in structured logs #933
• branch: https://github.com/PinguuSS/codex-desktop-linux/tree/build/preserve-renderer-error-stacks

@psypeal, could you build or install that branch, reproduce the Linux Desktop Settings failure, and paste the resulting originalErrorStack field from the structured renderer error record? That primitive field is the artifact needed to identify the original null-dispatcher call site. The branch is diagnostic only and does not claim to fix the failure.

[ilysenko]

PR #940 has been merged with content-versioned URLs for the generated Linux Desktop settings route and its local fallback components. This should prevent Electron from reusing a stale incompatible module after rebuilds or updates.

We are intentionally keeping this issue open while the fix gets real-world coverage. Please report if Settings > Linux desktop reaches the error boundary again on a build containing merge commit 5c5d5f5b05058ebac62c8a117deb2b4dacdf76cd, together with the build metadata and relevant launcher logs.

The separate destroyed-WebContents and tray lifecycle symptoms discussed above were not changed by #940 and should not be considered resolved by this merge.