VS Code Codex extension overrides configured `service_tier` to None before the first user turn

Resolved 💬 3 comments Opened Mar 26, 2026 by PommesPeter Closed Mar 26, 2026

What version of the IDE extension are you using?

Environment:

  • VS Code Codex extension: 26.324.21329
  • Bundled Codex CLI used by the extension: 0.117.0-alpha.12
  • Remote / VS Code Server environment
  • Config file used by the extension: ~/.codex/config.toml

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.8.0-49-generic x86_64 x86_64

What issue are you seeing?

I found what looks like a bug in the VS Code Codex extension where the configured service_tier is read from ~/.codex/config.toml, but then gets cleared before the first real
user turn is sent.

My config includes:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
service_tier = "fast"

I am not setting chatgpt.cliExecutable, so the extension is using its bundled Codex binary.

What I verified:

  1. The VS Code extension does read ~/.codex/config.toml
  2. The bundled Codex binary supports service_tier
  3. The main conversation thread correctly inherits other values from config / IDE context, such as:
    - model = gpt-5.4
    - working directory
    - approval policy
    - sandbox policy
  1. However, immediately before the first real UserInput is processed, the extension sends an OverrideTurnContext where:
  • service_tier: Some(None)

Because of that, the final /responses request does not include the configured service tier, and on the provider side I do not see the expected priority behavior.

Important detail:
This is not just the title-generation helper thread.

I separated the title-generation helper threads from the real main conversation threads:

  • helper/title threads use a different request path and often run with gpt-5.4-mini
  • The bug also happens on the real main conversation threads
  • on those main threads, the model is still gpt-5.4, but service_tier is explicitly cleared to None

Observed sequence on main conversation threads:

  1. VS Code webview starts the thread
  2. session is initialized
  3. An OverrideTurnContext is submitted
  4. that override contains service_tier: Some(None)
  5. then the first real UserInput is submitted
  6. then the /responses request is sent without service_tier

Representative log evidence from ~/.codex/logs_1.sqlite:

Main thread examples where service_tier is cleared:

  • id=125351, thread_id=xxx
  • id=123465, thread_id=yyy
  • id=123153, thread_id=zzz

These entries contain:

OverrideTurnContext { ... service_tier: Some(None) ... }

And the corresponding real user prompt entries still show the correct main-thread model:

  • id=125355 -> model=gpt-5.4
  • id=123468 -> model=gpt-5.4
  • id=123191 -> model=gpt-5.4

Expected behavior:
If service_tier = "fast" is configured in ~/.codex/config.toml, the main conversation thread should inherit that value, or at minimum, it should not be explicitly overridden to
None.

Actual behavior:
The VS Code extension sends a turn-context override that explicitly clears service_tier, so the final model request does not contain the configured service tier.

Current hypothesis:
This looks like a webview -> app-server -> turn-context serialization issue in the VS Code extension.
It appears that serviceTier is being sent as null / empty in the main thread override payload, instead of being omitted and allowing the config default to apply.

What steps can reproduce the bug?

  1. Open a Remote / VS Code Server workspace with the VS Code Codex extension installed.
  2. Do not set chatgpt.cliExecutable, so the extension uses its bundled Codex binary.
  3. In the remote ~/.codex/config.toml, set:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
service_tier = "fast"

  1. Reload the VS Code window so the extension restarts with the updated config.
  2. Open the Codex sidebar and start a brand new main conversation thread.
  3. Send a simple prompt such as "test".
  4. Inspect the final /responses request on the provider side and observe that it does not contain service_tier.
  5. Inspect ~/.codex/logs_1.sqlite and observe that, before the first real UserInput, the extension submits an OverrideTurnContext containing service_tier: Some(None).
  6. Confirm that the same thread still uses the correct main-thread model (gpt-5.4), which shows that the issue is specifically with service_tier being cleared rather than the config file not being read at all.

What is the expected behavior?

If service_tier = "fast" is configured in ~/.codex/config.toml, the VS Code Codex extension should preserve that value for the main conversation thread and include it in the final model request, or at minimum, it should not explicitly override it to None. In other words, the main thread should inherit the configured service tier in the same way it already inherits other settings, such as the model, working directory, approval policy, and sandbox policy.

Additional information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗