Desktop Preferences can get stuck showing "unable to save" after configVersionConflict on sequential config writes

I can confirm this still reproduces after today's Windows Desktop update.

Environment:

• Windows Desktop package: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
• Installed package version: 26.429.3425.0
• Bundled app/resources/codex.exe: 0.128.0-alpha.1
• app.asar timestamp on disk: 2026-05-02T10:36:23+08:00

Current user config parses and is read successfully:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"

Repro after the update:

1. Fully restart Codex Desktop.
2. Open Settings -> Configuration -> user config.
3. Try changing any of:

• approval strategy
• sandbox mode
• allow network access

1. Each control shows red Unable to save.

Log evidence from the same session:

2026-05-02T04:13:45.946Z ... method=config/read ... errorCode=null
2026-05-02T04:13:45.946Z ... method=configRequirements/read ... errorCode=null

2026-05-02T04:13:46.121Z ... unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

2026-05-02T04:13:48.616Z ... bundled_plugins_runtime_marketplace_written ...
2026-05-02T04:13:48.633Z ... bundled_plugins_marketplace_added ... marketplaceName=openai-bundled ...

After that marketplace sync, config.toml contains:

[marketplaces.openai-bundled]
last_updated = "2026-05-02T04:13:48Z"

All later Preferences writes fail with the same version conflict:

2026-05-02T04:14:05.384Z ... method=config/value/write ... config_write_error_code="configVersionConflict" ... "Configuration was modified since last read. Fetch latest version and retry."
2026-05-02T04:14:07.471Z ... same
2026-05-02T04:14:12.197Z ... same
2026-05-02T04:14:14.424Z ... same
2026-05-02T04:14:16.732Z ... same
2026-05-02T04:14:37.991Z ... same
2026-05-02T04:14:42.056Z ... same
2026-05-02T04:14:43.107Z ... same

Notes:

• This is not limited to one setting; all three user-config controls fail.
• Manual config.toml editing remains a workaround, but the Preferences UI cannot save.
• The startup sequence still appears to have a frontend/app-server mismatch around workspace_dependencies, and the bundled marketplace sync appears to modify config after the initial successful config/read, leaving the Preferences page with a stale config version.

Adding a macOS reproduction of the same Preferences/Configuration failure.

Environment:

• Codex Desktop: 26.429.30905 (CFBundleVersion 2345)
• Platform: macOS 26.4.1 (25E253)
• App path: /Applications/Codex.app
• Repo/tool context: Codex Desktop Configuration page, User config selected

Observed behavior:

• The Configuration page shows Unable to save whenever changing settings, including Approval policy and Sandbox settings.
• Screenshot state showed:
• Approval policy: Never
• Sandbox settings: Read only
• Error text: Unable to save
• The same local config.toml is writable outside the UI. A Codex agent was able to atomically rewrite it and parse it successfully as TOML.
• Current ~/.codex/config.toml already contains:

approval_policy = "never"
sandbox_mode = "danger-full-access"

So the UI appears out of sync with the effective config and is failing to persist changes, rather than hitting a basic filesystem permission issue.

Impact:

• Automations launched from Desktop may still run with read-only filesystem permissions even though the underlying config.toml says danger-full-access.
• This caused an automation that is supposed to update a local vault and automation memory file to report that it could not save files.

Workaround used locally:

• Manually moved the automation memory file into the workspace/vault and edited the automation prompt directly, avoiding the Settings UI.
• This does not fix the underlying Preferences save failure or the apparent UI/config mismatch.

This looks related to the existing stale config version / Preferences save path described here, but this reproduction is on macOS rather than Windows.

same problem.

It has been happening for a few weeks for me and it still is happening. I'm not sure how to proceed with that anymore except manually changing .toml which is fine, but it seems really weird for an app this complex to have issues writing it's own config.

Still happening. Windows and Mac. Fresh installs and existing installs.

Happening for me too on macOS

When I ask Codex, here is its suggestions:

Your ~/.codex/config.toml exists, is readable, and looks syntactically fine. That error is most likely a stale settings revision guard, not a bad reinstall. The app read config version A, then something wrote config version B, so the settings save refuses to overwrite it. Try this first: 1. Close the ~/.codex/config.toml tab in VS Code. 2. In Codex settings, use the Fetch latest version action if shown. 3. If that still loops, fully quit Codex with Cmd+Q, reopen it, wait ~30 seconds for plugin/runtime sync, then open Settings again. If it still happens after that, the “wipe” probably missed Electron app state. Reinstalling the app does not necessarily remove: ``bash ~/Library/Application Support/Codex ` A fuller reset would be: `bash osascript -e 'quit app "Codex"' mv ~/.codex ~/.codex.bak.$(date +%Y%m%d-%H%M%S) mv "$HOME/Library/Application Support/Codex" "$HOME/Library/Application Support/Codex.bak.$(date +%Y%m%d-%H%M%S) open -a Codex ` Caveat: that will clear Codex local app/session state and require setup/login again. The current ~/.codex/config.toml also has model = "gpt-5.5"` and the app is actively rewriting plugin/runtime entries, so after a fresh start let Codex finish initializing before changing settings.

Running it as administrator may solve this problem.

Reproduction notes and proposed fix path

I took a pass at reducing this to an actionable code path before suggesting a fix.

Breakdown:

• I treated the report as reproducible enough to trace against the current code instead of asking for more information.
• Root cause: codex-rs/app-server/src/config_manager_service.rs:229
• Impact: calibrated priority score 78.4

Proposed approach:

• Keep the patch scoped to the code path around codex-rs/app-server/src/config_manager_service.rs:229, so the behavior changes where the regression is introduced rather than broadening the surface area.
• Validation plan: add or update focused regression coverage and run the affected package test target before proposing the branch
• I will not open an unsolicited PR; if this direction matches maintainer expectations, I can open the prepared branch for review.

Precedent: #29189 Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy

How I shaped this comment from prior successful threads:

• Nearest successful examples considered: 3.
• The shared pattern was to show the repro/root-cause evidence first, state the smallest viable fix, defer to maintainers on direction, and disclose AI assistance.

This analysis was prepared with AI assistance.

<!-- fkst:codex-saga:engage:codex-triage:dup:openai/codex#20538 -->