codex - 💡(How to fix) Fix [VS Code extension] Fast speed preference periodically resets to Standard; default-service-tier is cleared despite user selection

What version of the IDE extension are you using?

26.519.32039

What subscription do you have?

ChatGPT Enterprise

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The VS Code Codex/OpenAI extension periodically resets my Speed setting from Fast to Standard. This is a recurring regression pattern: it tends to get fixed, then reappears ~1-2 months later.

This is not isolated to one remote machine: I have seen the same Fast-to-Standard reset behavior when using the extension through WSL2 and multiple HPC supercomputing systems.

Environment:

• Local VS Code client platform: Windows
• Local platform detail from PowerShell: Microsoft Windows NT 10.0.26200.0 x64
• Reproduces across multiple VS Code remote targets:
  • WSL2: Linux 5.15.167.4-microsoft-standard-WSL2 x86_64 x86_64
  • Remote SSH #1: Linux 6.4.0-150600.23.92_15.0.23-cray_shasta_c x86_64 x86_64
  • Remote SSH #2: Linux 4.18.0-477.10.1.el8_8.x86_64 x86_64 x86_64
• Example remote extension package observed on HPC system: openai.chatgpt-26.519.32039-linux-x64
• Example remote home config path: ~/.codex/config.toml
• This example is for a multi-root workspace that includes 3 separate repositories. However, the issue is not specific to multi-root workspaces; I have observed it both in multi-root workspaces and when opening a single folder.

Relevant config: ~/.codex/config.toml contains:

service_tier = "fast" default-service-tier = "fast"

[features] fast_mode = true

Observed behavior:

1. I manually select Speed = Fast in the Codex VS Code UI.
2. The UI later periodically collapses back to Standard, sometimes after reload/restart or during normal extension use.
3. This happens even though ~/.codex/config.toml still requests Fast.

Verified extension state from the Codex webview console:

Healthy state immediately after manually selecting Fast: { "settingValue": "priority", "atomDefaultServiceTier": "priority", "atomHasUserChangedServiceTier": true }

Failure state when the UI later shows Standard: { "settingValue": null, "atomDefaultServiceTier": null, "atomHasUserChangedServiceTier": true }

Interpretation:

• In this extension build, "priority" appears to be the internal/backend id for the Fast speed tier.
• The problem does not look like config.toml being missing or unread.
• The extension persisted atom/state for "default-service-tier" is being cleared to null while "has-user-changed-service-tier" remains true.
• Standard appears to be represented as null.
• That means the extension knows the user has changed the tier, but the selected tier itself is being removed.

Additional evidence:

• Recent extension logs showed requests using serviceTier=priority when Fast was active.
• The extension's contributed VS Code settings do not expose a normal VS Code setting for speed/service tier.
• Inspecting the bundled webview code showed default-service-tier is a persisted atom, not a regular VS Code configuration key.
• The bundled code also appears to contain an enterprise/defaulting path that can call setServiceTier(null, "enterprise_default"). I suspect a requirements/account/model/workspace refresh path may be clearing the tier even after the user has explicitly selected Fast.

Expected behavior: Once the user manually selects Fast, the extension should persist that preference and should not clear default-service-tier to null unless the user explicitly selects Standard or Fast is genuinely unavailable. If Fast is unavailable, the UI should explain why rather than silently resetting.

Actual behavior: default-service-tier is periodically cleared to null, causing the UI to show Standard, while has-user-changed-service-tier remains true.

Temporary workaround: From the Codex webview console, restoring the persisted setting makes Fast return:

await host.l("set-setting", { params: { key: "default-service-tier", value: "priority" } });

Requested fix: Please check any automatic defaulting / enterprise_default / requirements refresh / account-info refresh / model metadata refresh path that can clear default-service-tier. A useful regression test would be:

If a user has explicitly selected Fast, refresh/defaulting logic should preserve that selection and must not reset the stored tier to Standard/null unless the user selects Standard or the extension clearly reports that Fast is unavailable.

What steps can reproduce the bug?

1. Open VS Code with the Codex/OpenAI extension in a remote environment such as WSL2 or Remote SSH.
2. Open the Codex panel and manually set Speed to Fast.
3. Confirm from the Codex webview console that the persisted state is: default-service-tier = "priority" has-user-changed-service-tier = true
4. Continue using Codex normally, or reload/restart VS Code.
5. Observe that the Speed UI periodically returns to Standard.
6. Re-check the Codex webview state and observe: default-service-tier = null has-user-changed-service-tier = true

What is the expected behavior?

Once the user manually selects Fast, the extension should persist that preference and should not clear default-service-tier to null unless the user explicitly selects Standard or Fast is genuinely unavailable. If Fast is unavailable, the UI should explain why rather than silently resetting.

Additional information

The details above are from VS Code running on my Windows work computer, launched through WSL2 / remote development workflows. I also use a personal MacBook Pro with an M1 Max chip, and I have not yet noticed this Fast-to-Standard reset behavior there.