[Windows][Codex App] Intermittent loss of custom model reasoning capabilities after configuration refresh

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

Codex App 26.901.5280.0; bundled codex-cli 0.153.4

What subscription do you have?

A ChatGPT account using a third-party OpenAI-compatible provider configured through CC-Switch.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I am using a third-party OpenAI-compatible Responses API provider through CC-Switch.

The provider exposes this custom model:

gpt-6-astra

The same provider endpoint and the same API key can be used normally in Claude Code to select Astra, send requests, and select different reasoning levels, including the highest available level. Another user using the same provider and the same CC-Switch version can also use Astra and select different reasoning levels.

In the Codex App, the behavior is intermittent:

• Sometimes Astra appears in a newly created chat and the reasoning selector is available.
• At other times, Astra cannot be used after selecting it, or the reasoning selector disappears.
• Switching to an existing chat can cause the problem to affect newly created chats as well.
• The problem is not limited to one conversation.
• Restarting Windows or restarting Codex does not reliably restore the working state.

The latest test is important: after another full Windows restart, Astra did not become usable and the reasoning selector was still unavailable. Therefore, restarting is not a reliable workaround.

An earlier run showed this sequence:

1. Immediately after a Windows restart, Astra was available in a newly created chat and its reasoning level could be changed.
2. Later, after CC-Switch was started, I switched to an existing chat.
3. Astra then became unavailable, including in newly created chats.

I cannot confirm whether CC-Switch was already running at the exact moment when Codex initially launched. However, it was definitely running later when the failure was observed. This is a correlation, not a confirmed root cause.

This appears to be specific to Codex App model discovery, capability metadata, configuration refresh, or Desktop state synchronization rather than a general provider or model-access problem.

What steps can reproduce the bug?

The issue is intermittent, so I cannot provide a deterministic reproduction yet.

1. Configure a third-party OpenAI-compatible Responses API provider through CC-Switch.
2. Configure gpt-6-astra as the active model.
3. Start the Codex App.
4. Create a new chat and check whether Astra and the reasoning selector are available.
5. Start CC-Switch or allow it to start through Windows Startup.
6. Allow provider synchronization to complete.
7. Switch to an existing chat.
8. Create another new chat.
9. Check whether Astra and the reasoning selector are still available.
10. Compare the contents and modification times of:
    • config.toml
    • models_cache.json
    • .codex-global-state.json
11. If possible, capture the actual /v1/responses request and verify whether reasoning.effort is present.

What is the expected behavior?

For a configured custom Responses API provider:

• The custom model should remain consistently available.
• Available reasoning levels should be derived from the active model metadata.
• Switching between existing and new chats should not change model capability state unexpectedly.
• Background configuration or catalog refreshes should not silently downgrade a model from xhigh-capable to none-only.
• If Codex cannot verify custom-model reasoning support, it should show a clear warning instead of silently disabling the selector.
• The selected reasoning level should either be included in the actual Responses API request or Codex should clearly report that it was ignored.

Additional information

Local investigation:

1. In a previously captured active state, config.toml contained:

model = "gpt-6-astra"
model_reasoning_effort = "xhigh"
base_url = "<redacted>"
wire_api = "responses"

2. In the same investigation, models_cache.json contained an Astra entry with:

default_reasoning_level = "none"
supported_reasoning_levels = ["none"]
input_modalities = ["text"]

This conflicted with config.toml, which specified model_reasoning_effort = "xhigh".

3. The Codex thread database contains Astra threads, including threads with reasoning_effort = "none". Other threads use models with high, xhigh, or ultra.

4. The SQLite databases were checked with PRAGMA integrity_check and were valid. This suggests the issue is not caused by corrupted chat history.

5. After fully exiting Codex and re-importing the provider configuration through CC-Switch, I inspected the imported TOML. It did not contain gpt-4-32k-struct and did not contain model_catalog_json. Therefore, the earlier hypothesis that these entries were explicitly written into the imported TOML was not confirmed.

6. CC-Switch is configured with:

launchOnStartup = true
enableLocalProxy = true
sessionAutoSyncEnabled = true

There is also a Windows Startup shortcut for CC-Switch.

7. In one observed run, config.toml, models_cache.json, and .codex-global-state.json changed after Codex/CC-Switch startup. Approximate local timestamps were:

• Codex startup: 22:01:18-22:01:19
• config.toml: 22:01:55
• models_cache.json: 22:10:28
• .codex-global-state.json: 22:10:54

Possible explanations include stale or incomplete model metadata, a background catalog refresh overwriting custom-model capabilities, multiple app-server processes sharing the same CODEX_HOME, an additional Desktop filter, or thread switching rehydrating inconsistent model/provider state. I cannot yet identify which component is responsible.

Related issues:

• #42853
• #42868
• #42996
• #29156
• #30697
• #33593
• #31625

All API keys, tokens, account identifiers, provider URLs, and private conversation content will be redacted from any attached logs or configuration files.

Start by reproducing the intermittent behavior with CC-Switch and compare config.toml, models_cache.json, and .codex-global-state.json before and after startup, synchronization, and chat switching. Inspect the related issues and capture the /v1/responses request if possible. Done means identifying the state or refresh transition that changes model capabilities and verifying that the selected reasoning level remains consistent.