Repository navigation
Codex desktop crashes/reloads into blank chat while a local task is running #48480
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.924.22138 / build 11645. Earlier crash reports from the same day also show 26.924.20706 / build 11431.
What subscription do you have?
Unknown / not sure
What platform is your computer?
Darwin 25.1.0 arm64 arm; macOS 26.1 (25B78)
What issue are you seeing?
The ChatGPT/Codex desktop app repeatedly crashes or reloads while an active Codex local chat is running.
Observed behavior:
- While a Codex chat is processing a request, the desktop app suddenly reloads or crashes.
- The UI exits the active chat and returns to a blank/new chat.
- The previous Codex task may continue in the background, but the visible chat context is lost.
- This happened multiple times on the same day.
Crash report evidence from macOS DiagnosticReports:
- ChatGPT-2026-09-26-171125.ips
- ChatGPT-2026-09-26-172831.ips
- ChatGPT-2026-09-26-181342.ips
The latest crash report shows:
- app: ChatGPT
- bundleID: com.openai.codex
- app_version: 26.924.22138
- build_version: 11645
- exception: EXC_BREAKPOINT / SIGTRAP
- faulting thread: 0
- thread name: CrBrowserMain
Codex app logs around the reload/crash include patterns such as:
- ipc-connection-reset
- write EPIPE
- Authenticated workspace changed
I have not attached raw logs here because they may contain sensitive information, but the local paths are listed in the additional information section.
What steps can reproduce the bug?
I do not have a fully deterministic minimal reproduction yet, but this is the workflow that triggered it several times:
- Open ChatGPT/Codex desktop on macOS.
- Work in a local Codex chat connected to a local project/workspace.
- Send a normal coding/debugging request and wait while Codex is processing.
- Observe that the desktop app sometimes reloads or crashes.
- After the reload/crash, the app may show a blank/new chat instead of the active chat.
The issue occurred multiple times on 2026-09-26. The most recent crash was at 18:13:42 local time on app version 26.924.22138 / build 11645.
What is the expected behavior?
The desktop app should keep the active Codex chat open while a task is running. If a recoverable renderer/app-server reset happens, the UI should restore the same chat instead of dropping the user into a blank/new chat. The running task state should remain visible and recoverable.
Additional information
Relevant local files/paths:
Crash reports:
~/Library/Logs/DiagnosticReports/ChatGPT-2026-09-26-171125.ips
~/Library/Logs/DiagnosticReports/ChatGPT-2026-09-26-172831.ips
~/Library/Logs/DiagnosticReports/ChatGPT-2026-09-26-181342.ips
Codex app logs:
~/Library/Logs/com.openai.codex/2026/09/26
Repeated log patterns observed:
ipc-connection-reset
write EPIPE
Authenticated workspace changed
Crash metadata observed in the latest report:
exception: EXC_BREAKPOINT / SIGTRAP
faultingThread: 0
thread name: CrBrowserMain
bundleID: com.openai.codex
app_version: 26.924.22138
build_version: 11645
os_version: macOS 26.1 (25B78)
Activity
github-actions commentedon Sep 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
astro-automation commentedon Oct 5, 2026
Confirming the same issue on macOS after updating to ChatGPT desktop/Codex 26.930.51102 (build 13100). The UI repeatedly leaves the active local Codex chat and navigates to a blank new chat; the active task may continue.
Feedback/session ID:
01a109c7-e48e-7053-8fde-305dbab84f07Selected log correlation (UTC, Oct 5, 2026):
02:02:39.270Z[statsig-refresh-diagnostics] React root render requested02:02:41.253Zbrowser/sidebar route sync reportsownerRoutePath=/with aclient-new-threadID02:09:15.728Zanother primary-window React root render request02:09:17.543Zanother reset toownerRoutePath=/The same behavior occurred on the previous build 26.930.31730 at
01:54:52.013Zand01:55:36.602Z. The new build and a restart did not resolve it. Around resets, logs also contain repeatedConversation state not foundandResizeObserver loop completed with undelivered notifications.The timing suggests the app’s feature/config refresh or root rerender may be losing the selected chat route, but this is only a correlation, not a confirmed root cause. Raw logs are not attached because they may contain private chat data.
astro-automation commentedon Oct 5, 2026
Additional reproduction evidence from build 26.930.51102 (13100): the resets appear tied to in-app-browser sidebar ownership while a browser-heavy Codex thread is active.
Observed sequence on Oct 5, 2026 (UTC):
03:55:20.622Z:IAB_LIFECYCLEbrowser-sidebar owner sync carried aclient-new-threadconversation identity whileownerRoutePathstill pointed to the active local thread.03:55:28.176Z–03:55:28.185Z: burst of repeatedConversation state not founderrors during renderer/bootstrap thread hydration.03:55:28.346Z: anotherIAB_LIFECYCLEowner sync changed to a differentclient-new-threadidentity withownerRoutePath=/, matching the visible redirect to the blank/new-chat screen.03:55:30.172Z–03:55:30.384Z: the app resumed the original active thread and recaptured browser-use session routes while its turn remained in progress.The affected thread was actively using the in-app browser through
cua_replto inspect several sites. This points more specifically to an in-app-browser/sidebar ownership or route-restoration race during renderer/bootstrap refresh. It is still a temporal correlation, not a confirmed source-level root cause. Full conversation IDs and raw logs are withheld for privacy; the earlier feedback/session ID can be used to correlate them internally.