Repository navigation
macOS desktop unexpectedly switches an existing chat to New Chat; hidden Pages prewarm navigation suspected #53570
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT desktop 26.1007.30912 (build 20156); bundle com.openai.codex
What subscription do you have?
Not provided; this report concerns desktop window navigation.
What platform is your computer?
macOS — uname -mprs: Darwin 25.6.0 arm64 arm
What issue are you seeing?
While an existing conversation is open, the desktop app spontaneously switches the visible main window to the New Chat screen. No keyboard input or window switching is required. This has recurred over two days. Four matching sequences were found in local app logs, including one checked immediately after another occurrence was reported.
Latest observed sequence (2026-10-13, UTC)
- 03:52:30.334 — Hidden window 9 / webContents 32:
Statsig: error while bootstrapping post-login client, attemptNumber=6,Timed out while fetching post-login Statsig bootstrap; visible=false, focused=false. - 03:53:03.150 — Same hidden window:
browser_use_availability_resolved available=false reason=statsig-disabled. - 03:53:03.373 — Same hidden window:
app routes mounted after 96722ms; still visible=false. - 03:53:03.527 — Main window 1:
ownerRoutePath=/ conversationId=client-new-thread:<redacted>, just 154ms after the hidden window's routes-mounted log. The main window had previously reported/local/<existing-conversation>. - 03:53:26.457 —
[page-window-prewarm] Timed out preparing Page window claimed=false editorReady=false.
The browser_use gate log supports a configuration failure but is not direct evidence of the Pages gate value.
Other matching observations (UTC)
| Main-window homepage event | Nearby hidden-window initialization | Surrounding failures |
|---|---|---|
| 2026-10-12 09:40:47.814 | Window 5 routes-mounted 51ms earlier | Statsig bootstrap timeout; later unclaimed Page prewarm timeout |
| 2026-10-13 03:05:26.929 | Window 7 routes-mounted 43ms later | Same pattern |
| 2026-10-13 03:14:55.988 | Window 8 routes-mounted 160ms earlier | Same pattern |
These are correlated logs, not a captured runtime stack proving the cross-window call.
What steps can reproduce the bug?
- Open an existing conversation in the macOS desktop app.
- Leave it open without keyboard input or switching windows.
- During intermittent network/configuration request failures, the app can switch the main window to New Chat while an invisible Page prewarm window initializes.
This describes observed conditions, not a deterministic reproduction. No network fault injection or controlled reproduction was performed.
Suggested controlled reproduction for maintainers: keep an existing chat open, allow the hidden Pages prewarm window to start, then force that window's Statsig bootstrap to time out or its Pages capability to become unavailable. Check whether its fallback navigation to / reaches the visible main window. This proposed test has not been run.
What is the expected behavior?
The active conversation, draft, and window focus should remain unchanged when an unclaimed hidden prewarm window fails to initialize or cannot access a feature. Failure handling should stay within that background window.
Additional information
Suspected code path in the installed bundle
Read-only inspection of this installed build found a path that explains the observed behavior:
- Page prewarming creates a primary window with
show:false,trackPrimaryOnShow:true, and initial route/space/<local-page-id>?window=page&prewarm=1. The owner is set only whenopenNewPageclaims it. - Pages availability depends on the chatgpt capability and Statsig gate
2200939124. The/space/:pageIdroute guard redirects to/withreplace:truewhen availability is disabled. A bootstrap timeout alone does not prove the final Pages gate is disabled. - Page-window detection checks
window=pagewithout excludingprewarm=1. The router interceptor hands non-Page, non-auth destinations, including/, towindowNavigation.navigateInOwnerWindow. - Without a valid main-window owner,
getOrCreateNavigationWindowselects the most recently active main window.navigateInOwnerWindowsendsnavigate-to-routeand callsshowWindowwithstealFocus:true.
This appears to allow an unclaimed hidden Page window's fallback navigation to change the user's visible conversation. This is a high-confidence hypothesis; the actual handoff call stack has not been captured.
Build and implementation pointers
The installed app is branded ChatGPT, bundle ID com.openai.codex, version 26.1007.30912, build 20156, build commit a993bdbe5bb9503cb84de1e67d5635cf186a959f.
main-CqEoQDOU.js:nHe.createWindow/openNewPage,getOrCreateNavigationWindow,navigateInOwnerWindow.app-initial-6350d04672d0.js:XPs(Pages route guard),rZ/nZ(Page-window detection),Mlc/SHa/THa(navigation interception and handoff).app-shared-8bd9d0399038.js:t3r, exported asSUand imported asic(Pages availability).
Suggested fix and verification
Reject navigation handoffs from dormant/unclaimed prewarm windows at the main-process boundary. Keep unavailable-feature handling local to the prewarm window. Add origin/destination window, route, and prewarm/claimed state to navigation-handoff logs. Regression-test that bootstrap/capability failures do not change an existing main-window conversation or steal focus.
Limits / redaction
The main process remained running across these incidents. Concurrent HTTP 500/504 failures were observed, but their ultimate network/server origin is not established. No patch or workaround has been verified. Conversation text, account identifiers, local usernames/paths, tokens, session transcripts, and raw logs are omitted.
Activity
github-actions commentedon Oct 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
RowNine commentedon Oct 14, 2026
Additional observation on desktop version 26.1007.71326 (build 20398), macOS: the unexpected return from an existing chat to Home / New chat still occurs after updating.
The following sequence was captured immediately after an occurrence was reported. All times are UTC on 2026-10-14:
This sample adds a capability-request error immediately preceding the main-window navigation; the redirect occurred about 10 seconds after the hidden window's routes-mounted event, rather than at mount time.
Read-only inspection of the newer installed bundle supports the same suspected cross-window fallback path:
No runtime navigation call stack was captured, so the exact originating guard remains unconfirmed. No application files or settings were modified. Transient service errors may trigger this, but should not allow a hidden prewarm window to navigate the user's active chat.
This comment includes only sanitized technical observations. Raw logs, conversation contents/identifiers, email, account details and private filesystem paths are omitted.
0xdevalias commentedon Oct 17, 2026
Connecting this report to the more detailed navigation investigation and a newer settings/account failure sample. Your HTTP 500 / 76 ms follow-up is particularly relevant to the availability-error path. Our October 16 macOS occurrence on 26.1007.71326/build 20398 instead logged HTTP 503 “Unable to fetch authentication verification keys” on settings/account endpoints while the active chat repeatedly switched to Home. The selected diagnostic timeline is posted in #53901:
Further read-only inspection on October 17 verified a more specific branch in our installed 26.1007.71326/build 20398 bundle: the Pages/Spaces availability calculation (
t3rinapp-shared-8340f229c2b3.js) explicitly returnsdisabledwhen thechatgptcapability result hasisError. This branch runs before the later feature-gate checks, so a capability error can disable availability without a feature flag itself defaulting off. The inspectedZPsroute guard redirects disabled availability to/; the Page navigation interceptor can forward that destination tonavigateInOwnerWindow.That strengthens the proposed error → disabled availability → Home redirect path. It remains static code evidence: we have not captured the capability state and navigation caller together for our October 16 occurrence, or proven which guard initiated each jump. Regardless of why availability is disabled, an unclaimed hidden prewarm's automatic redirect should not navigate/focus the user's active chat.
Main investigation and detailed diagnostics
See also: related reports
These links group matching symptoms, error responses, and suspected mechanisms for comparison. They do not label every report as a confirmed duplicate or establish a single backend cause.
Only selected technical observations are included. No raw logs, credentials, account/conversation identifiers, private paths, or screenshots are attached. No new live reproduction or verified fix is claimed.