VS Code Codex extension overrides configured `service_tier` to None before the first user turn
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:
- The VS Code extension does read
~/.codex/config.toml - The bundled Codex binary supports
service_tier - The main conversation thread correctly inherits other values from config / IDE context, such as:
- model = gpt-5.4
- working directory
- approval policy
- sandbox policy
- 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:
- VS Code webview starts the thread
- session is initialized
- An OverrideTurnContext is submitted
- that override contains service_tier: Some(None)
- then the first real UserInput is submitted
- 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?
- Open a Remote / VS Code Server workspace with the VS Code Codex extension installed.
- Do not set
chatgpt.cliExecutable, so the extension uses its bundled Codex binary. - In the remote
~/.codex/config.toml, set:
model = "gpt-5.4"
model_reasoning_effort = "xhigh"
service_tier = "fast"
- Reload the VS Code window so the extension restarts with the updated config.
- Open the Codex sidebar and start a brand new main conversation thread.
- Send a simple prompt such as "test".
- Inspect the final
/responsesrequest on the provider side and observe that it does not contain service_tier. - Inspect
~/.codex/logs_1.sqliteand observe that, before the first real UserInput, the extension submits an OverrideTurnContext containingservice_tier: Some(None). - 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_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗