Repository navigation
[macOS][26.1002.52244] Active chat unexpectedly navigates to new-chat page during scrolling or foreground activation #52491
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT/Codex desktop 26.1002.52244, build 13536, bundle identifier com.openai.codex. Version verified from installed application metadata.
What subscription do you have?
Not disclosed in this public report.
What platform is your computer?
macOS 27.0. Local desktop chats.
What issue are you seeing?
The existing main window intermittently leaves the active Codex chat and opens the blank new-chat page under the saved local project. This has occurred when bringing the app to the foreground, and also while scrolling/reading an already-open chat. Focus switching is therefore not a necessary condition; scrolling has not been established as the cause.
The problem affects more than one existing chat. The original chat remains accessible by selecting it again, but repeated unexpected navigation interrupts reading and work. The user reported two consecutive occurrences, and the log captured two route resets approximately 11.335 seconds apart, both returning to the same existing new-chat draft.
No visible error dialog was reported for these navigation events.
What steps can reproduce the bug?
Observed repeatedly in the affected installation on 2026-10-09; a deterministic clean-profile reproduction has not been established.
- Open an existing local Codex chat in the desktop app.
- Read or scroll the conversation, or switch to another application and return to Codex. Cmd+Tab, Dock activation and clicking an existing window have all been reported as possible contexts.
- Intermittently, the main window unexpectedly shows the blank new-chat page for the saved local project.
- Select the original chat again. It remains accessible.
- Continue using the app; the unexpected navigation can recur. A captured pair occurred about 11 seconds apart in another existing chat, without a full application restart.
What is the expected behavior?
The app should preserve the active chat while reading, scrolling, returning focus, initializing background windows or refreshing feature availability. It should navigate to a new chat only when requested by the user.
Additional information
Sanitized timeline of the consecutive pair
Times are relative to the first unexpected new-chat navigation. Real conversation/draft identifiers, project names, usernames, filesystem paths and absolute wall-clock times are omitted.
| Elapsed | Observation |
|---|---|
| +0.000 s | Main window windowId=1, originWebContentsId=1 reports ownerRoutePath=/ with client-new-thread:<draft-A>. |
| +0.024 s | A different hidden primary window, windowId=22, rendererWebContentsId=58, reports app routes mounted after 96537ms, rendererWindowVisible=false, rendererWindowFocused=false. |
| +2.390 s | Main window returns to the original existing chat. |
| +8.504 / +8.921 s | Main-window log entries still record rendererWindowFocused=true. |
| +11.280 s | The same hidden window reports browser_use_availability_resolved available=false reason=statsig-disabled. |
| +11.335 s | Main window again reports ownerRoutePath=/ and the same client-new-thread:<draft-A>. |
| +14.324 s | Main window returns to the original chat again. |
Selected log excerpts, with timestamps normalized and the draft identifier replaced consistently:
[+0.000s] IAB_LIFECYCLE received browser sidebar owner sync browserTabId=null conversationId=client-new-thread:<draft-A> originWebContentsId=1 ownerRoutePath=/ windowId=1
[+0.024s] [startup][renderer] app routes mounted after 96537ms rendererWebContentsId=58 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=22 rendererWindowVisible=false
[+11.280s] browser_use_availability_resolved available=false browserPane=true platform=macOS reason=statsig-disabled release=26.1002.52244 rendererWebContentsId=58 rendererWindowAppearance=primary rendererWindowFocused=false rendererWindowId=22 rendererWindowVisible=false
[+11.335s] IAB_LIFECYCLE received browser sidebar owner sync browserTabId=null conversationId=client-new-thread:<draft-A> originWebContentsId=1 ownerRoutePath=/ windowId=1
Earlier examples in the same app run also placed a hidden primary-window route mount within approximately 203 ms, 78 ms and 37 ms of main-window navigation to /. Another recent example had a 119 ms gap. These are correlations, not proof of causality.
Interpretation and limits
- The main-window route change is recorded; its direct navigation caller is not.
- The second event in the pair has no new route-mount record of its own. Not every reset can be attributed simply to a mount event.
- No corresponding main-window React-root startup, route-mount or renderer-failure record was found near this pair. No matching new crash record was found in the checked locations. Missing records do not conclusively rule out a renderer failure.
- Read-only inspection of the installed bundle shows that the browser-availability log and
electron-desktop-features-changeddispatch occur in the same effect. The main-process handler can update application-wide feature availability, but includes a dormant-window filter. It is not established whether this hidden window's message was accepted or whether it caused navigation. ResizeObserver loop completed with undelivered notifications.appears elsewhere during conversation browsing, but is not established as the trigger for these route resets.- A background-window initialization / feature-state synchronization interaction is a hypothesis for investigation, not a confirmed root cause.
- No application-package patch, settings reset, profile deletion or app restart was performed during diagnosis.
Related reports
- [Windows][Desktop] Returning from browser or tool activity opens project home instead of active chat #47853 reports returning from an external browser or tool activity to the project home instead of the active chat, on Windows. The symptoms are close; this report adds macOS 27.0, desktop build 13536 and the consecutive-pair timeline.
- [Windows] Desktop renderer reloads every time app loses and regains focus - 26.917.51856 #47449 reports focus-triggered renderer reloads on Windows. A shared root cause has not been established.
- [ChatGPT Mac desktop] Reopening a running Codex task repeatedly crashes renderer and opens an empty new chat #44787 reports renderer crashes recovering into an empty new chat on macOS. This report does not establish corresponding renderer crashes.
Only these reviewed, sanitized observations and excerpts are included. No raw logs, session transcripts, private conversation content, real session identifiers, account credentials or screenshots are attached.
Activity
Liiiszt commentedon Oct 13, 2026
Additional occurrences on 26.1007.30912 (build 20156), macOS (
Darwin 25.6.0 arm64 arm), plus a possible concrete Pages prewarm → owner-window navigation path. The observed symptom and hidden-window timing closely match this issue; a shared root cause is not yet proven.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)
Statsig: error while bootstrapping post-login client, attemptNumber=6,Timed out while fetching post-login Statsig bootstrap; visible=false, focused=false.browser_use_availability_resolved available=false reason=statsig-disabled.app routes mounted after 96722ms; still visible=false.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>.[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)
These are correlated logs, not a captured runtime stack proving the cross-window call.
Suspected code path in the installed bundle
Read-only inspection of this installed build found a path that explains the observed behavior:
show:false,trackPrimaryOnShow:true, and initial route/space/<local-page-id>?window=page&prewarm=1. The owner is set only whenopenNewPageclaims it.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.window=pagewithout excludingprewarm=1. The router interceptor hands non-Page, non-auth destinations, including/, towindowNavigation.navigateInOwnerWindow.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, version26.1007.30912, build20156, build commita993bdbe5bb9503cb84de1e67d5635cf186a959f.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.
highsun16 commentedon Oct 13, 2026
I am also experiencing unexpected navigation to a blank New Chat screen on macOS.
Environment
Observed behavior
Reproduction status
The behavior has recurred during normal use, but I do not have deterministic steps to reproduce it. The actions above describe observed occurrences rather than a confirmed trigger.
Expected behavior
The app should preserve the current conversation while I read it or change its model settings, and should not switch to New Chat or become the foreground application without a user action requesting that behavior.
brantshin commentedon Oct 15, 2026
Adding a current macOS production-build report at the affected user's request (2026-10-15).
Environment: ChatGPT/Codex desktop 26.1007.71326, build 20398, bundle ID
com.openai.codex. The in-app updater reports up to date; the installed application's signature verifies successfully.The user repeatedly sees the active chat replaced with the blank New Chat screen without intentionally requesting navigation. This interrupts normal reading and work, including when the app is left untouched.
Read-only local diagnostics captured these sequences on October 15. All times below are UTC; conversation identifiers and local paths are omitted:
/local/chat to/, with aclient-new-threadidentifierThe same run also records
Timed out preparing Page window claimed=false editorReady=false. No corresponding repeated renderer-crash records were found in the inspected interval. These are correlations, not a captured navigation call stack.Read-only inspection of this current build still finds the previously described candidate path: an unclaimed hidden Pages prewarm window can fall back to
/; the Page-window navigation interceptor forwards that destination tonavigateInOwnerWindow; without a valid owner, the main process selects the most recently active main window. The actual runtime handoff has not been captured, so the cause remains unconfirmed. No application patch, re-signing, settings reset, or chat-data deletion was performed.Could the desktop team please triage this navigation issue and provide a signed fix or a supported way to disable only background Pages prewarming while preserving existing chat data and normal New Chat behavior? Rejecting owner-window navigation from dormant/unclaimed prewarm windows and logging the origin/target window plus prewarm/claimed state would help validate this path.
0xdevalias commentedon Oct 17, 2026
Cross-reference and additional failure context from macOS 26.6 (25G72), ChatGPT/Codex desktop 26.1007.71326, build 20398, on October 16.
Our active chat repeatedly switched to Home/New Chat while the app also displayed “Couldn’t load workspace settings / Retry to continue chatting”. The settings/account endpoints returned HTTP 503 with
{"detail":"Unable to fetch authentication verification keys."}.The detailed timeline is now at #53901 (comment) . It records a hidden window failing settings/account checks and mounting routes shortly before the visible window leaves an existing chat, plus an unclaimed Page-prewarm timeout. This is correlation; the current navigation caller was not captured.
Regardless of why availability is disabled, a hidden, unclaimed prewarm's automatic redirect should not change the user's active conversation or steal focus. That client isolation problem should be addressed even if the upstream request failures are fixed separately.
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.