After updating my Codex today, it simply opened up to the screen shown in the attachment. Clicking the buttons does nothing; I’ve already tried clearing the cache, reinstalling, repairing, removing the package, etc., but nothing worked. Can anyone shed some light on this?
Have you tried installing an earlier version?
As I do not know how you originally installed it can not be more specific.
How can I do that? Those options aren’t available on the official website or the Microsoft Store.
I’m on Windows 11 and downloaded it from the Microsoft Store.
I do not know of a supported way to select or reinstall a specific older version of the Codex desktop app. There is an open issue requesting that capability:
You might get lucky and find files from an older version still present somewhere on your computer. Possible locations to check include:
%LOCALAPPDATA%\OpenAI\Codex\bin
%LOCALAPPDATA%\Codex
%USERPROFILE%\.codex
%LOCALAPPDATA%\Temp
%TEMP%
%USERPROFILE%\Downloads
%ProgramFiles%\WindowsApps
Within %LOCALAPPDATA%\OpenAI\Codex\bin, check the hash-named subdirectories, as different Codex executables may be stored in separate directories.
You can also search the computer for:
codex.exe
*.msix
*.msixbundle
*.appx
*.appxbundle
However, finding an older codex.exe or cached package does not necessarily mean that it can be safely installed or used to downgrade the app. I would back up any files before experimenting.
Here is an additional technical update for my support request:
After further investigation, I was able to access the Codex logs and identify the actual renderer error. The desktop application launches successfully, the Windows AppX container is created normally, and the account appears to authenticate correctly. However, the main interface crashes inside the primary application route before the sidebar, projects, chat history, or input area can render.
The key error found in the logs is:
Error: process is not defined
The failing component is reported as:
name=AppRoutes
Affected application version:
OpenAI.Codex 26.721.3996.0
Bundled CLI version:
codex-cli 0.146.0-alpha.3.1
I have already tried the following without success:
-
Repairing and resetting the application through Windows Settings
-
Fully uninstalling and reinstalling the Microsoft Store package
-
Removing all local package data
-
Clearing the Chromium cache, code cache, GPU cache, session storage, local storage, cookies, and local state
-
Moving the entire packaged Chromium profile
-
Resetting persisted window, layout, and Electron state
-
Verifying that the configured local project paths still exist
-
Testing the “Update ChatGPT” and “Try again” buttons
-
Restarting Windows and reinstalling the current package
The Codex processes remain alive and responsive at the operating-system level, so this is not a full application crash. It appears to be a renderer-level exception caught by the application’s generic error boundary.
The logs also show:
authenticatedAccountPresent=true
This suggests that the issue is not caused by authentication or missing local projects.
Based on the evidence, this appears to be a regression or compatibility issue in the packaged renderer for version 26.721.3996.0, possibly caused by application code attempting to access the Node.js global process from an isolated browser renderer context.
Could you please confirm whether this is a known issue in the current Windows release and whether a patched build or official rollback package is available?
I believe my issue is directly related to GitHub issue #35195. The error started immediately after I created or selected a multi-root project containing these two repositories:
C:\_Projetos\Projeto A\Projeto B
C:\_Projetos\Projeto A\Projeto C
My logs show the same renderer exception described in the issue:
Error: process is not defined
The failure also occurs inside AppRoutes, and the desktop app remains stuck on the full-screen error boundary after every restart.
Previous troubleshooting preserved the local-projects and selected-project entries in .codex-global-state.json, which may explain why clearing the Chromium profile, caches, layout state, and Electron state did not resolve the problem.
This strongly suggests that the selected multi-root project is repeatedly triggering the renderer crash during application startup. I am now testing by removing the affected project entry, or temporarily renaming .codex-global-state.json, and reopening the two repositories as separate single-root projects.
Temporary workaround found
We were able to recover the desktop application by removing the persisted multi-root project entry from the Codex global state file.
The issue started after creating or selecting a project that contained more than one root folder. After that, Codex Desktop repeatedly reopened the same invalid project state during startup and crashed inside AppRoutes with:
Error: process is not defined
The affected state was stored in:
%USERPROFILE%.codex.codex-global-state.json
The temporary workaround was:
- Close all Codex Desktop processes.
- Create a backup of
.codex-global-state.json. - Open the file and locate the project entry containing multiple root paths.
- Remove the affected project from
local-projects. - Clear
selected-projectif it points to that project. - Remove only related workspace or writable-root references associated with the affected multi-root project.
- Validate that the edited file is still valid JSON.
- Reopen Codex Desktop.
- Add the repositories again as separate single-root projects.
Renaming the entire .codex-global-state.json file can also be used as a broader recovery method, but this resets the locally registered projects and some UI state. The project files themselves are not deleted.
This workaround restored access to the desktop application, but multi-root projects should be avoided until the underlying issue is fixed.
Using the bundled Codex executable for recovery
The Windows desktop installation also contains a bundled codex.exe that can be used from Command Prompt or PowerShell to inspect and repair the local state when the graphical interface is no longer accessible.
A more generic location is:
%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
The build folder name may be different between installations or versions. It can be located with PowerShell using:
Get-ChildItem “$env:LOCALAPPDATA\OpenAI\Codex\bin” -Recurse -Filter codex.exe |
Select-Object FullName
Or from Command Prompt:
where /r “%LOCALAPPDATA%\OpenAI\Codex\bin” codex.exe
Once found, it can be launched directly:
“<full-path-to-codex.exe>”
We used this bundled executable to investigate the desktop logs and safely edit the persisted state while the desktop UI was stuck on the generic error screen.
Important: create a backup before editing .codex-global-state.json, and do not delete the actual project directories.
