Repository navigation
[Windows] Desktop renderer reloads every time app loses and regains focus - 26.917.51856 #47449
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.917.51856
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
Codex/ChatGPT Desktop for Windows version 26.917.51856 repeatedly reloads/crashes its renderer whenever the application loses focus and then regains focus.
The main application process remains alive, but multiple renderer processes are terminated and recreated. The UI reloads approximately one second after the application regains focus.
This is not a full application crash. Text already typed into the prompt is preserved, and the app recovers automatically.
However, if Codex/ChatGPT is actively thinking or generating a response when the renderer reload occurs, the active request fails with the error:
Authenticated workspace changed
A Retry button is then displayed, and I must manually retry the request.
The issue began after updating to desktop app version 26.917.51856 on September 22, 2026.
The older ChatGPT Desktop Classic client remains stable on the same Windows installation, hardware, GPU driver, and monitor configuration.
What steps can reproduce the bug?
This is effectively 100% reproducible for me.
Minimal reproduction:
- Launch Codex/ChatGPT Desktop version 26.917.51856.
- Allow the application to fully load.
- Click anywhere outside the Codex/ChatGPT window so the application loses focus.
- Click back inside the Codex/ChatGPT window so it regains focus.
- Wait approximately one second.
- The UI reloads and multiple renderer processes are replaced.
I originally noticed this while using other applications:
- Minimizing Brave reliably caused the Codex UI to reload approximately one second later.
- Notepad could also trigger it.
- Further testing showed that minimizing another application is not actually required.
The minimal trigger is simply:
Codex loses focus -> Codex regains focus -> renderer reload
I monitored ChatGPT.exe processes in Windows Task Manager with the Command Line column enabled.
There are normally six ChatGPT.exe processes with --type=renderer.
Each time the bug occurs, 3 of the 6 renderer PIDs disappear and are replaced by new renderer PIDs.
The main ChatGPT application process remains alive.
I also monitored renderer memory usage while reproducing the issue. I did not observe a large memory spike or multi-gigabyte renderer usage before the reload.
Representative Task Manager memory readings I observed included:
226,028 K
1,388 K
85,288 K
24,844 K
13,348 K
520,588 K
59,004 K
195,008 K
189,268 K
17,032 K
The highest value I observed in this sample was approximately 521 MB, so this does not appear to be the multi-GB renderer-memory/OOM failure described in some other reports.
If the renderer reload occurs while Codex/ChatGPT is actively thinking or generating a response, the active request fails with:
Authenticated workspace changed
The UI then presents a Retry button and I must manually retry the request.
What is the expected behavior?
Switching focus between Codex/ChatGPT Desktop and another Windows application should not terminate and recreate renderer processes or reload the application UI.
The application should remain stable when:
- Clicking another application
- Switching to a browser
- Switching to an IDE
- Switching to Unity
- Using File Explorer
- Returning focus to Codex/ChatGPT
This is especially important for Codex because normal development workflows require constantly switching between Codex and other applications.
An active thinking/generation request should continue normally when the user switches focus away from Codex and back.
Regaining focus should not cause the renderer to reload, should not change the authenticated workspace context, and should not terminate the request with:
Authenticated workspace changed
Additional information
Thinking/generation failure:
If the renderer reload occurs while Codex/ChatGPT is actively thinking or generating a response, the request is interrupted with the exact error:
Authenticated workspace changed
The UI then displays a Retry button.
This happens as part of the same focus-triggered renderer reload described above.
Activity
Scarik-Scarebear commentedon Sep 23, 2026
Update: I found a workaround that completely fixed the issue.
While investigating the install, I noticed that codex.exe inside the appserver\plugins folder appeared older than the other files in that folder.
I then:
After the plugins folder was rebuilt, the issue disappeared completely.
The desktop app is now stable.
The previous reproducible behavior:
Codex loses focus -> Codex regains focus -> renderer processes replaced -> UI reload -> "Authenticated workspace changed"
no longer occurs.
This strongly suggests the update left behind a stale or mismatched codex.exe/plugin payload, and forcing the app to regenerate the plugins directory resolved it.
It may be worth investigating whether desktop app updates are correctly replacing all files under appserver\plugins, especially codex.exe.
Scarik-Scarebear commentedon Sep 23, 2026
Additional forensic comparison:
I preserved the complete unstable plugin directory before applying the workaround and compared it against the newly regenerated/stable plugin directory.
I recursively compared 876 files using SHA-256 hashes, file sizes, and timestamps.
Result:
Total files compared: 876
Different files: 1
The ONLY differing file was:
.plugin-appserver\codex.exe
UNSTABLE codex.exe:
Modified: 2026-09-18 14:01:04
Size: 316,853,040 bytes
SHA-256:
BC45017E8239DC150258F69309CED9DF6BBCDF5B8E4F346DECF780AC0999E226
REGENERATED / STABLE codex.exe:
Modified: 2026-09-23 08:48:53
Size: 320,161,072 bytes
SHA-256:
A19F8F6C3C9DD5B71B6B1E3EB1EC55D75AAFB2FDFB686D9E1F7A5F47DB07D0D2
The regenerated codex.exe is 3,308,032 bytes larger.
All other 875 files in the compared plugin trees were identical by SHA-256.
This substantially narrows the issue.
The desktop app had updated to newer builds, but the unstable plugin directory still contained the older/different codex.exe dated Sep 18.
After forcing the plugins directory to regenerate, codex.exe was replaced with the Sep 23 binary above, and the following issues immediately stopped:
No other file in the 876-file comparison changed.
This strongly suggests that the desktop update process left a stale codex.exe in .plugin-appserver while updating the rest of the application/plugin state.
Forcing plugin regeneration replaced that binary and resolved the issue.
LionKingIsBack commentedon Sep 25, 2026
+1 — renderer crash/recycle loops, reproduced on both 26.917.9434.0 and 26.924.1866.0 (Windows 11, hybrid GPU)
App: MSIX package
OpenAI.Codex. Reproduced on 26.917.9434.0 and, after a Store update, still on 26.924.1866.0 (Electron/Chromium 153.0.8010.53).OS: Windows 10.0.26200 x64, 12 logical CPUs, 32 GB RAM, 3840x2160 @2.5 scaling.
GPU: Intel UHD Graphics 630 (driver 31.0.101.2130) + NVIDIA GeForce GTX 1650 (driver 32.0.15.7322).
I see the same behaviour as the OP: the main process never dies, while renderer processes are terminated and recreated, and the UI reloads.
Measured locally:
{"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}— no GPU- or browser-process crash was recorded.(Note the file count is not monotonic: Crashpad deletes reports after upload, so counts understate the real number.)
ChatGPT.exe(~62-64 MB) every ~10 s for several minutes — measured 21:48:21 to 21:53:12, and again 21:16 to 21:19. The main process stayed alive throughout, consistent with "3 of 6 renderer PIDs disappear and are replaced".Invalid message received errorMessage="Peer closed MessagePort connection." rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowVisible=true— 74 occurrences in 3 minutes — plus
Received item/started|completed for unknown conversation(up to 328 lines in a single instance) andConversation state not found. The window stays visible, so the user sees an in-place reload.for unknown conversationerrors referenced the same conversation id, which was stuck emittingautomatic approval reviewevents every 2-5 s for 40+ minutes. Archiving that thread locally and clearing its queued revision did not stop it from resuming on app restart.[sparkle] in_app_updates_policy_wait_started timeoutMs=300000→in_app_updates_policy_latch ... policy=pending→[windows-store-updater] hasUpdate=true canSilentlyDownload=true→ the app relaunched ~5 minutes later (launched 22:28:15, self-relaunch observed at 22:34:16 viaAppModel-Runtimeevent 201). Because the app must be closed for the MSIX to apply, and it keeps relaunching, this loops.0x80073D02("cannot install because the following apps must be closed: OpenAI.Codex"), 19 failures over 30 days, plus leftoverWindowsApps\Deleted\...entries failing to delete (0x12C). The pending update only applied once the app was fully closed.ChatGPT.exeorvk_swiftshader.dll(they come from an unrelated Bonjour DLL). Package status staysOk(noNeedsRemediation), so this is not the [Windows app] Opening any chat triggers Code Integrity 3033 for vk_swiftshader.dll, corrupts MSIX package, and prevents relaunch (0x3CFC) #35681 mechanism.26.924.1866.0, a renderer crash occurred at 22:59:09, about 3 minutes after launch.Asking: is a fix planned for the renderer recycle/state-desync behaviour? And if renderer minidumps would help, note that only
*_sidecar.jsonfiles remain locally (no.dmp) — a switch to retain dumps would make these reports actionable.Scarik-Scarebear commentedon Sep 25, 2026
Additional update: a separate authentication failure has now appeared.
Codex is entering:
Reconnecting... 1/5
...
Reconnecting... 5/5
and then failing with:
unexpected status 401 Unauthorized: Incorrect API key provided: sk-svcac...
The failing request is going to:
https://chatgpt.com/backend-api/codex/responses
I am NOT using API-key authentication.
Local authentication checks show:
auth_mode: chatgpt
OPENAI_API_KEY in auth.json: not present
OPENAI_API_KEY environment variable:
No relevant model-provider/auth override was found in .codex/config.toml.
I then fully regenerated ChatGPT authentication by preserving/removing .codex/auth.json, reopening the desktop app, and logging back into ChatGPT.
Result:
No change.
Immediately after the fresh login, Codex returned to the same Reconnecting... 5/5 behavior.
This suggests the invalid sk-svcac credential is not coming from a user-configured API key or stale local auth.json state.
The desktop app is apparently entering an incorrect auth/routing state at runtime despite being configured for ChatGPT authentication.
Scarik-Scarebear commentedon Sep 25, 2026
Another update, same failure pattern.
After installing the newest desktop update, the app again did not function correctly until I forced the plugins directory to regenerate.
This is now a recurring pattern across multiple desktop updates on this machine.
The previous occurrence was forensically compared:
The newest update again required the same plugins regeneration workaround.
This increasingly appears to be a recurring updater/plugin-refresh issue rather than an isolated renderer problem.
Scarik-Scarebear commentedon Sep 26, 2026
Final update / second independent reproduction:
The latest desktop update again left Codex unusable until I forced the plugins directory to regenerate.
Before regeneration, Codex repeatedly entered the reconnect loop and failed with:
401 Unauthorized: Incorrect API key provided: sk-svcac...
This persisted even after completely regenerating ChatGPT authentication. Local auth was verified as ChatGPT auth, with no user-configured OPENAI_API_KEY present.
After preserving the broken plugins directory, I forced the application to regenerate plugins again.
Codex immediately began working normally.
I then performed another recursive SHA-256 comparison between the preserved BROKEN plugin tree and the newly regenerated WORKING tree.
Results:
Broken tree files: 879
Regenerated tree files: 879
Total unique paths: 1081
Reported differences: 405
The numbers are important:
879 + 879 - 1081 = 677 paths exist in both trees.
Therefore 404 of the 405 reported differences are files that exist on only one side.
Those 404 path differences are primarily expected versioned cache directories, including cache generations such as:
26.909.12148
26.923.10815
That leaves exactly ONE file which exists at the same relative path in both trees but has different content/hash:
.plugin-appserver\codex.exe
This is now the SECOND independent occurrence where:
On the previous occurrence, I compared 876 files and all 875 other files were SHA-256 identical; only codex.exe differed.
On this occurrence, versioned cache directories changed as expected, but among files existing at the same path in both trees, again only codex.exe changed.
The symptoms have differed:
Previous occurrence:
Latest occurrence:
In BOTH cases, regenerating the plugins directory and thereby replacing codex.exe immediately restored normal operation.
At this point this appears highly reproducible and strongly suggests an updater/plugin lifecycle issue involving .plugin-appserver\codex.exe being left stale or otherwise inconsistent after desktop updates.
I have preserved:
I can provide those artifacts privately to OpenAI engineering if useful.
I am leaving this issue updated with the workaround for other affected users:
If the Windows desktop app becomes unstable or Codex authentication/runtime behavior breaks immediately after an update, preserve/rename the existing plugins directory, fully close the desktop app, then restart it and allow the plugins directory to regenerate.
Do not delete the original first if you want to preserve diagnostic evidence.
Scarik-Scarebear commentedon Oct 10, 2026
Long-term follow-up:
This plugin regeneration problem has continued on every desktop update I have received since the original report.
I have preserved each failed/pre-regeneration plugins directory rather than deleting it.
Current preserved sequence:
plugins.old1 - 2026-09-23
plugins.old2 - 2026-09-25
plugins.old3 - 2026-10-01
plugins.old4 - 2026-10-02
plugins.old5 - 2026-10-04
plugins.old6 - 2026-10-05
plugins.old7 - 2026-10-06
plugins.old8 - 2026-10-08
Each update has required me to rename/preserve the existing plugins directory and allow the desktop app to regenerate it before the updated client behaves correctly.
This is therefore no longer an isolated occurrence. Plugin regeneration has effectively become a required manual post-update step on this installation.
I have retained the historical plugin states and can provide them privately to engineering if requested.