Windows Codex Desktop 26.506.31421: config saves fail and Chrome plugin state/capability is broken
Open 💬 3 comments Opened May 13, 2026 by abocha
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.31421
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.8457 x64
What issue are you seeing?
Windows 11, Codex Desktop 26.506.31421.
Problems:
- Settings -> Configuration cannot save changes:
Unable to save. config.tomlis writable manually from PowerShell. ACLs are fine.- Workspace Dependencies diagnose as healthy.
- Chrome plugin cannot be uninstalled from Codex app:
Failed to uninstall plugin. - Chrome/plugin capability is not exposed in new Codex sessions.
- JS REPL works.
- In-app browser/browser use works.
- Shell can launch
chrome.exeand read the window title, but this is not the Chrome plugin.
Likely broken layer: Desktop app config/plugin state management, not filesystem permissions or workspace dependencies.
What steps can reproduce the bug?
Observed on Windows 11 with Codex Desktop 26.506.31421.
- Open Codex Desktop Settings -> Configuration.
- Try to save a settings/configuration change.
- Observe the UI error:
Unable to save. - From PowerShell, manually edit or write
$CODEX_HOME/config.toml. - Observe that the file is writable manually, so this does not appear to be a basic filesystem permission or ACL problem.
- Run Workspace Dependencies diagnostics.
- Observe that Workspace Dependencies diagnose as healthy.
- Open the Codex app plugin UI and try to uninstall the bundled Chrome plugin.
- Observe the UI error:
Failed to uninstall plugin. - Start a new Codex session and request
@chrome/ Chrome plugin capability. - Observe that the Chrome/plugin capability is not exposed in the new session.
- In the same environment, verify that JS REPL works.
- Verify that the in-app browser / browser-use capability works.
- As a control, use shell/PowerShell to launch
chrome.exeand read the Chrome window title. This succeeds, but it is OS shell automation, not the Codex Chrome plugin.
What is the expected behavior?
- Settings -> Configuration should save changes successfully when
config.tomlis writable. - If a config write fails, the UI should surface the concrete app-server/config error instead of only
Unable to save. - The Chrome plugin uninstall action should either uninstall successfully or clearly explain why it cannot.
- If the Chrome plugin is installed/enabled, new Codex sessions should expose the Chrome plugin capability.
- Workspace Dependencies health should not be implicated when diagnostics report healthy and JS REPL/browser-use are working.
Additional information
This looks related to existing Windows Desktop config/plugin state issues, but this report combines both failure modes on the same current Desktop build:
- Settings/config saves fail even though
config.tomlis manually writable. - Plugin state management also fails: Chrome plugin uninstall fails and Chrome capability is not exposed in new sessions.
- Other runtime layers appear healthy: Workspace Dependencies, JS REPL, in-app browser/browser-use, and shell process launch all work.
Possibly related open issues:
- #20538
- #20856
- #21670
- #22114
- #22462
3 Comments
same
Windows & Mac bug: https://github.com/openai/codex/issues/23169#issuecomment-4479972132
Disclosure: I maintain WinBridge Recovery, an independent Windows Codex Desktop recovery utility.
Only part of this issue is within the project’s scope. A Settings UI/config-save failure can be an app-server/config-management bug even when
config.tomlis writable, and WinBridge should not pretend to fix that layer.The Chrome/plugin-state portion is more relevant: uninstall fails, the capability is not exposed in new sessions, while other runtime pieces remain healthy. WinBridge Recovery can compare the currently installed official package with the user-side bundled marketplace/cache,
latesttarget and Chrome native-host registration, preserve a rollback copy, and repair verified local state drift when those components are incomplete or stale.I think the useful diagnostic split is: first prove whether the local Chrome plugin/host state is internally consistent; if it is clean and Settings still cannot save or the session still does not receive Chrome capability, stop local repair and report that as an upstream Desktop/app-server problem rather than changing more files.