macOS Codex Desktop Settings show "Unable to save" for sandbox/approval config writes due to configVersionConflict

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

• #23169
• #22481

Powered by Codex Action

I can reproduce the same config write conflict on a newer macOS Codex Desktop build, and I have a bit more evidence that the setting may be partially persisted even while the UI keeps showing the stale-version error.

Environment:

• Codex Desktop: 26.519.31651 (CFBundleVersion 3017)
• Bundled CLI: codex-cli 0.133.0-alpha.1
• macOS: 26.5 (25F71)
• Architecture: arm64
• Host: local Codex Desktop, user config scope

Reproduction:

1. Open Codex Desktop Settings.
2. Go to custom config.toml settings / user config.
3. Toggle Allow network access under Workspace write.
4. The UI shows:

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

Observed behavior:

• The UI continues to show the red error and does not appear to recover by fetching the latest config version.
• However, the attempted toggle can still partially or fully persist underneath.
• After toggling network access off in the UI, I observed all three local state sources change consistently to disabled:

# ~/.codex/config.toml
[sandbox_workspace_write]
network_access = false

// ~/.codex/.codex-global-state.json, current workspace/thread state
"networkAccess": false

-- ~/.codex/state_5.sqlite, active thread row
select json_extract(sandbox_policy, '$.network_access') ...
-- result: 0

Earlier in the same session I manually set the same three sources to enabled and verified:

• config.toml had network_access = true
• .codex-global-state.json had no bad current-workspace networkAccess != true records
• state_5.sqlite had no current-workspace workspace-write thread rows with network_access != 1
• codex doctor reported config load OK and sandbox network enabled

After using the Settings UI again, the value changed to false but the UI still displayed the config version conflict. That suggests the core issue is not just a file permission or SQLite persistence problem. The UI/app-server path appears to perform a write with a stale expectedVersion, then does not refresh/retry after the conflict, leaving the settings page stuck even when the underlying setting has changed.

I also inspected the packaged frontend bundle locally and found the Settings page path keeps a layer expectedVersion and passes it to write-config-value for the network toggle (sandbox_workspace_write.network_access). On conflict, the UI displays the error, but from observed behavior it does not refresh the config layer/version and retry.

Expected behavior:

• On configVersionConflict, the Settings page should re-read the latest config layer/version and retry, or invalidate/refetch the config query before allowing another save attempt.
• If a write has partially succeeded, the UI should reconcile with the actual persisted config instead of continuing to show a stale error state.
• The user should be able to turn this setting on/off from Settings without needing manual edits or app restarts.

This is still reproducible in 26.519.31651 / 0.133.0-alpha.1.

I can reproduce this on a newer macOS Codex Desktop build, with an additional symptom: the Settings UI can partially persist the change, then keep rejecting subsequent user-initiated edits with the stale-version error.

Environment:

• Codex Desktop: 26.521.10419
• Codex CLI: 0.134.0
• macOS: 26.5 (25F71)
• Architecture: arm64
• Scope: local Desktop app, User configuration (~/.codex/config.toml)

Reproduction observed:

1. Open Codex Desktop Settings > Configuration.
2. Select User configuration.
3. Change approval policy / sandbox settings through the dropdowns.
4. The UI shows:

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

1. Closing and reopening Settings does not reliably recover the form state.
2. Subsequent attempts to change the dropdowns can keep failing with the same stale-version message.

Observed state transitions from the local config file:

• Initial intended state was:

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

• After trying to change values in the Settings UI, the config reached intermediate/changed states such as:

``toml
approval_policy = "on-request"
sandbox_mode = "danger-full-access"
``

and later:

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

• codex doctor --summary then reported the changed effective mode, e.g. restricted fs + enabled network · approval OnRequest, confirming the file was modified despite the UI still showing the stale-version error.

Expected behavior:

• If the Settings page writes one config value successfully, it should update its internal config version/revision before the next write.
• If another process changes config.toml, the UI should provide a visible reload/refetch action or automatically refetch and retry the requested single-field update.
• User-initiated dropdown changes in the official Settings UI should not leave approval_policy and sandbox_mode in a partially changed state.

This seems like the Settings page is keeping the original config read-version after either its own write or a nearby background config update, then treating the next user action as a configVersionConflict.