What version of the Codex App are you using?
Codex desktop 26.727.6591.0, installed from the Microsoft Store (OpenAI.Codex_26.727.6591.0_x64).
What platform is your computer?
Windows 11 x64, OS build 26100. Local timezone: America/Denver (MDT).
What issue are you seeing?
The Codex desktop window repeatedly refreshes/soft-reloads during normal use. The main ChatGPT.exe process and the codex.exe app-server remain alive, but the primary renderer is destroyed and recreated in the same renderer-client slot. Active chats and browser routes then rehydrate, causing a visible interruption.
This is a renderer lifecycle/reload loop, not a Windows process crash.
Evidence
- Sustained loop on 2026-08-03 from 10:02:54 AM to 7:25:32 PM MDT.
- 405 primary React-root bootstrap cycles.
- Mean interval: 83.56 seconds; observed range: 67.8–101.05 seconds.
- Each cycle repeatedly logged:
[statsig-refresh-diagnostics] React root render requested[startup][renderer] app routes mounted- chat/browser route rehydration
app_server_restart_recovery_done
- After a full app relaunch, the user observed another visible refresh at about 7:40 PM MDT.
- The main process had been unchanged since 7:25:46 PM and the app-server since 7:25:49 PM, but a new renderer was created at exactly 7:40:04 PM in the same renderer-client slot (
--renderer-client-id=5).
- Windows Reliability Monitor and the Windows Application event log contained no Codex application crash, hang, or Windows Error Reporting event.
- Crashpad contained no crash dump.
- At the end of the earlier long-running session, the log showed browser-route “window not live” warnings and IPC
write EPIPE, followed by a complete app relaunch about nine seconds later.
- In the current session, the new Codex desktop log files remain zero bytes even though the renderer reload reproduced.
Steps to reproduce
The initiating trigger has not been isolated, but the failure reproduces under this workload:
- Start Codex desktop for Windows version
26.727.6591.0.
- Keep several local chats active; at least one uses Browser Use.
- Continue normal work or leave the app running.
- Observe a visible UI refresh.
- Inspect the process tree: the main process and app-server remain alive, while the renderer in the primary client slot is replaced.
The sustained session began after a successful Microsoft Store update and the behavior reproduced after a normal app relaunch, so it is not just a one-time updater restart.
What is the expected behavior?
The primary renderer and UI should remain stable while chats and Browser Use sessions are active. App-server recovery should not repeatedly reload the entire UI.
What is the actual behavior?
The primary renderer is repeatedly recreated. The UI visibly refreshes and then rebinds active chats and browser routes. One prolonged cycle eventually ended with IPC EPIPE and a full app relaunch.
Additional context
Multiple local chats were active/streaming. Browser Use was enabled, and an avatar overlay was active. These are correlations, not a confirmed root cause.
Raw logs are not attached because they contain private task and local-path data. Sanitized excerpts or an in-app diagnostic report can be provided if maintainers request them.
What version of the Codex App are you using?
Codex desktop
26.727.6591.0, installed from the Microsoft Store (OpenAI.Codex_26.727.6591.0_x64).What platform is your computer?
Windows 11 x64, OS build 26100. Local timezone: America/Denver (MDT).
What issue are you seeing?
The Codex desktop window repeatedly refreshes/soft-reloads during normal use. The main
ChatGPT.exeprocess and thecodex.exe app-serverremain alive, but the primary renderer is destroyed and recreated in the same renderer-client slot. Active chats and browser routes then rehydrate, causing a visible interruption.This is a renderer lifecycle/reload loop, not a Windows process crash.
Evidence
[statsig-refresh-diagnostics] React root render requested[startup][renderer] app routes mountedapp_server_restart_recovery_done--renderer-client-id=5).write EPIPE, followed by a complete app relaunch about nine seconds later.Steps to reproduce
The initiating trigger has not been isolated, but the failure reproduces under this workload:
26.727.6591.0.The sustained session began after a successful Microsoft Store update and the behavior reproduced after a normal app relaunch, so it is not just a one-time updater restart.
What is the expected behavior?
The primary renderer and UI should remain stable while chats and Browser Use sessions are active. App-server recovery should not repeatedly reload the entire UI.
What is the actual behavior?
The primary renderer is repeatedly recreated. The UI visibly refreshes and then rebinds active chats and browser routes. One prolonged cycle eventually ended with IPC
EPIPEand a full app relaunch.Additional context
Multiple local chats were active/streaming. Browser Use was enabled, and an avatar overlay was active. These are correlations, not a confirmed root cause.
Raw logs are not attached because they contain private task and local-path data. Sanitized excerpts or an in-app diagnostic report can be provided if maintainers request them.