Windows Codex Desktop 26.429.3425.0: Settings saves fail with configVersionConflict, and Fast mode default is reset to Standard/null on startup

Open 💬 5 comments Opened May 3, 2026 by wei-er582
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop

What subscription do you have?

pro 20×

What platform is your computer?

_No response_

What issue are you seeing?

Title:
Windows Codex Desktop 26.429.3425.0: Settings saves fail with configVersionConflict, and Fast mode default is reset to Standard/null on startup

What version of the Codex App are you using?

Microsoft Store / MSIX package:

  • Package name: OpenAI.Codex
  • Package full name: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
  • Package version: 26.429.3425.0
  • SignatureKind: Store
  • InstallLocation: C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0

Observed Desktop client version in logs:

  • 26.429.30905

Observed bundled app-server version:

  • 0.128.0-alpha.1

What platform is your computer?

Windows x64, Microsoft Store installation.

Please fill exact Windows version here:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture

What issue are you seeing?

There are two related problems in Codex Desktop on Windows.

  1. Settings changes fail with Unable to save.

Changing settings such as Approval policy or Sandbox / Permissions in the Codex Desktop Settings UI frequently fails with:

Unable to save

Logs show the underlying app-server error is:

configVersionConflict
Configuration was modified since last read. Fetch latest version and retry.

This does not appear to be a filesystem permission issue. The config file is writable, CLI reads the config correctly, and there are no stable EACCES, EPERM, or Access is denied errors associated with the failed saves.

  1. Fast mode cannot remain the default.

C:\Users\<user>\.codex\config.toml contains:

service_tier = "fast"

[features]
fast_mode = true

C:\Users\<user>\.codex\.codex-global-state.json can be manually set to:

{
  "electron-persisted-atom-state": {
    "default-service-tier": "fast",
    "has-user-changed-service-tier": true
  }
}

However, when the official Codex Desktop app starts, it resets:

"default-service-tier": "fast"

back to null / empty. The UI then shows Standard instead of Fast, even though config.toml still contains service_tier = "fast".

Steps to reproduce

  1. Install Codex Desktop from Microsoft Store.
  2. Ensure C:\Users\<user>\.codex\config.toml contains:
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
plan_mode_reasoning_effort = "xhigh"
model_verbosity = "high"
service_tier = "fast"

approval_policy = "never"
sandbox_mode = "danger-full-access"
default_permissions = ":danger-no-sandbox"
personality = "pragmatic"

[features]
fast_mode = true

[windows]
sandbox = "elevated"

[notice]
hide_full_access_warning = true
  1. Start official Codex Desktop.
  2. Open Settings.
  3. Try changing Approval policy or Sandbox / Permissions.
  4. Observe Unable to save.
  5. Check logs and observe configVersionConflict.
  6. Manually set .codex-global-state.json persisted atom state to Fast.
  7. Restart official Codex Desktop.
  8. Observe that default-service-tier is reset back to null / empty and the UI shows Standard.

Expected behavior

  • Settings should save successfully.
  • If configVersionConflict occurs, the Settings UI should reload the latest config version and retry, or otherwise recover without requiring a restart.
  • If the user has explicitly selected Fast mode and config.toml contains service_tier = "fast", Codex Desktop should not reset default-service-tier to null during startup.
  • Desktop and CLI should agree on the effective service tier.

Actual behavior

  • Settings UI shows Unable to save.
  • App-server logs show:
configVersionConflict
Configuration was modified since last read. Fetch latest version and retry.
  • Official Codex Desktop startup rewrites Electron persisted state and clears:
"default-service-tier": "fast"

to null / empty.

  • UI shows Standard even though config.toml still says:
service_tier = "fast"

Diagnostic observations

This was tested after a clean reinstall:

  1. Backed up .codex and Codex Desktop user state.
  2. Stopped all Codex Desktop processes.
  3. Removed the official Store/MSIX package using Remove-AppxPackage.
  4. Removed Desktop/user-state/cache paths:
  • C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0
  • C:\Users\<user>\AppData\Local\Codex
  • C:\Users\<user>\AppData\Roaming\Codex
  • C:\Users\<user>\.cache\codex-runtimes
  1. Reinstalled the official Microsoft Store package with:
winget install --id 9PLM9XGG6VKS --source msstore --accept-source-agreements --accept-package-agreements
  1. Verified the official package was installed again:
Name: OpenAI.Codex
PackageFullName: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
Version: 26.429.3425.0
SignatureKind: Store
Status: Ok

The problem still reproduced after the clean reinstall.

Log evidence

Relevant log entries include:

configVersionConflict
Configuration was modified since last read. Fetch latest version and retry.

App-server request methods observed around the issue:

config/value/write
config/batchWrite

During startup, Codex Desktop also rewrites config.toml by adding marketplace/plugin/runtime entries such as:

[marketplaces.openai-bundled]
...

[marketplaces.openai-primary-runtime]
...

[plugins."browser-use@openai-bundled"]
enabled = true

This appears to update the config after Settings has already loaded an expectedVersion, causing later Settings writes to be rejected as stale.

Suspected root cause

There appear to be two related Desktop-side issues:

  1. Settings writes use a stale expectedVersion.

The Settings page reads config.toml and stores an expectedVersion. During startup, marketplace/plugin/runtime sync modifies config.toml, changing the config version. The Settings page then attempts to save with the stale expectedVersion, and the app-server rejects the write with configVersionConflict.

Expected fix: on configVersionConflict, reload latest config and retry, or avoid using stale expectedVersion for user Settings writes.

  1. Fast mode persisted state is cleared during startup.

The official Desktop app resets Electron persisted atom state:

"default-service-tier": "fast"

to null / empty during startup, even when:

service_tier = "fast"

is present in config.toml.

Expected fix: do not clear explicit user-selected Fast mode unless the account truly cannot use Fast mode, and if clearing is necessary, show a clear reason in the UI/logs.

Workaround

Using the Codex CLI works correctly with the same config.toml.

A local patched copy of Codex Desktop was used for testing, without modifying the official C:\Program Files\WindowsApps package. The workaround confirms that:

  • ignoring stale expectedVersion for Settings writes avoids the Unable to save problem;
  • preserving default-service-tier = fast in Electron persisted state avoids the Fast/Standard reset problem.

The official Microsoft Store package remains unmodified.

Privacy note before submitting

Do not attach raw auth.json, full .codex-global-state.json, or full logs_2.sqlite publicly without redacting account identifiers, tokens, emails, and private paths.

What steps can reproduce the bug?

  1. Install the official Codex Desktop app from Microsoft Store.
  1. Verify the installed package is the official Store package:

```powershell
Get-AppxPackage -Name OpenAI.Codex |
Select-Object Name,PackageFullName,Version,InstallLocation,SignatureKind,Status |
Format-List

Observed:

Name: OpenAI.Codex
PackageFullName: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
Version: 26.429.3425.0
SignatureKind: Store
Status: Ok

  1. Ensure C:\Users\<user>\.codex\config.toml contains Fast mode and full-access settings:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"
plan_mode_reasoning_effort = "xhigh"
model_verbosity = "high"
service_tier = "fast"

approval_policy = "never"
sandbox_mode = "danger-full-access"
default_permissions = ":danger-no-sandbox"
personality = "pragmatic"

[features]
fast_mode = true

[windows]
sandbox = "elevated"

[notice]
hide_full_access_warning = true

  1. Start the official Codex Desktop app.
  2. Open Settings.
  3. Try changing Approval policy or Sandbox / Permissions.
  4. Observe that the Settings UI shows:

Unable to save

  1. Check recent logs in C:\Users\<user>\.codex\logs_2.sqlite.

The relevant error is:

configVersionConflict
Configuration was modified since last read. Fetch latest version and retry.

  1. Manually set the Electron persisted state in C:\Users\<user>\.codex\.codex-global-state.json so that

Fast mode is selected:

{
"electron-persisted-atom-state": {
"default-service-tier": "fast",
"has-user-changed-service-tier": true
}
}

  1. Restart the official Codex Desktop app.
  2. Observe that Codex Desktop resets:

"default-service-tier": "fast"

back to null / empty, and the UI shows Standard instead of Fast, even though config.toml still
contains:

service_tier = "fast"

  1. I also reproduced this after a clean reinstall:
  • backed up .codex and Desktop state
  • stopped all Codex Desktop processes
  • removed the official Store/MSIX package using Remove-AppxPackage
  • removed Desktop user-state/cache paths:
  • C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0
  • C:\Users\<user>\AppData\Local\Codex
  • C:\Users\<user>\AppData\Roaming\Codex
  • C:\Users\<user>\.cache\codex-runtimes
  • reinstalled with:

winget install --id 9PLM9XGG6VKS --source msstore --accept-source-agreements --accept-package-
agreements

The same two issues still reproduced after the clean reinstall.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20538
  • #20769

Powered by Codex Action

wei-er582 · 3 months ago

Additional retest with TUN disabled:

I disabled TUN / Meta Tunnel and confirmed that the 198.18.0.x route was gone. Get-NetRoute
-AddressFamily IPv4
no longer showed any 0.0.0.0/0 -> 198.18.0.x route. The only default route was
0.0.0.0/0 -> 192.168.3.1.

Because ChatGPT/Codex is not reachable from my network without proxy, I kept the normal Windows system
HTTP proxy enabled at 127.0.0.1:7897.

Using the official Microsoft Store Codex Desktop package OpenAI.Codex 26.429.3425.0, I tried saving a
setting twice in a row.

Both attempts failed immediately with "Unable to save" and both returned configVersionConflict from
local config/value/write.

Log file:
C:
\Users\Samsung\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\03
\codex-desktop-7faad3fd-615c-4dc9-813e-384657ecfa21-9260-t0-i1-081713-0.log

First save attempt:
2026-05-03T08:17:41.551Z
requestId: 420c255b-0b88-4292-a098-3a7b5687a1a9
durationMs: 6
error: config_write_error_code=configVersionConflict

Second immediate save attempt:
2026-05-03T08:17:43.898Z
requestId: 5f78b604-f010-4b02-bdb2-0dae44ceac27
durationMs: 20
error: config_write_error_code=configVersionConflict

The second immediate save attempt did not recover. It failed with the same configVersionConflict.

This reproduces after removing the 198.18.0.x TUN route, which further suggests a Codex Desktop local
config versioning/sync bug rather than a VPN/TUN routing issue or Fast-mode entitlement issue.

wei-er582 · 3 months ago

Clarification on the two consecutive write failures:

The official Microsoft Store Codex Desktop app was freshly launched for this retest at about 2026-05-
03 16:17:12 UTC+08
.

No patched Desktop instance was running, and Codex Web was not open. A Codex CLI session was still
running at the time.

With TUN / Meta Tunnel disabled and no 198.18.0.x default route present, I attempted two consecutive
settings saves in the official Desktop app.

Both writes failed immediately with configVersionConflict:

  1. First save attempt:
  • timestamp: 2026-05-03T08:17:41.551Z
  • requestId: 420c255b-0b88-4292-a098-3a7b5687a1a9
  • durationMs: 6
  • error: config_write_error_code=configVersionConflict
  1. Second immediate save attempt:
  • timestamp: 2026-05-03T08:17:43.898Z
  • requestId: 5f78b604-f010-4b02-bdb2-0dae44ceac27
  • durationMs: 20
  • error: config_write_error_code=configVersionConflict

The second write did not recover after the first conflict. This suggests the Desktop client is not
refreshing the config write version after configVersionConflict, or it is reading from one config
state/store and writing against another stale write target.

wei-er582 · 3 months ago

I added one more isolation run that should rule out CLI interference. At 2026-05-03 16:33 UTC+08,
before launching Desktop, PowerShell confirmed there were no Codex, Codex.exe, or codex.exe processes
running. I then launched only the official Microsoft Store Codex Desktop package
OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0 / package version 26.429.3425.0 / Desktop client version
26.429.30905 / app-server 0.128.0-alpha.1. Two immediate Settings save attempts both failed with Unable
to save. In the official Desktop log C:
\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\03\
codex-desktop-fa88f738-c74c-4c2e-8440-d0957c31a901-26052-t0-i1-083322-0.log, the first failed save was
2026-05-03T08:33:37.280Z, requestId ce045629-37c8-430f-8638-35ee35ecdf08, and the second failed save
was 2026-05-03T08:33:38.969Z, requestId 44499cd3-1b5a-4052-92c9-ad9efd613b4d; both were local config/
value/write calls returning errorCode=-32600 with config_write_error_code=configVersionConflict and
message Configuration was modified since last read. Fetch latest version and retry. Both failures
returned in about 5 ms, and the immediate second retry did not recover, which strongly suggests a
Desktop-side stale config version lifecycle bug rather than CLI interference or a network timeout.

jeffreymor · 3 months ago

I’m seeing this in both the Codex App and the VS Code extension.

I mainly use the VS Code extension, and rolling back to 26.5422.71525 fixes it for me.

On newer versions, Speed resets from Fast to Standard after restarting VS Code.