Skip to content

Codex Desktop project list disappears or reasoning levels are reduced - CC Switch configuration issue

Quick fix

Most related issues remain unresolved. After upgrading CC Switch or switching providers, changes to Codex’s model_provider field can make project history…

Error output
升级 CCSwitch 到最新版本后,从其它 provider(如 DeepSeek)切换到 GPT (packycode) profile 后,Codex Desktop UI 的项目列表完全为空,所有历史项目/会话"消失"。切回 DeepSeek 后项目列表立刻恢复。
English translation

After upgrading CCSwitch to the latest version, switching from another provider (such as DeepSeek) to a GPT (packycode) profile makes the Codex Desktop UI project list completely empty, and all historical projects/sessions appear to have “disappeared.” Switching back to DeepSeek immediately restores the project list.

In v3.16.1 and earlier, CC Switch wrote inconsistent `model_provider` internal keys for different third-party providers (for example, GPT used `packycode`, while DeepSeek used `custom`). Codex Desktop uses the `model_provider` field as the namespace filter key for the threads table in the `state_5.sqlite` database. When the provider changes, the changed string prevents the UI from finding historical records. This was fixed in v3.19.1 by standardizing on `model_provider = "custom"`. A related issue is that not all reasoning levels appear: levels declared in `cc-switch-model-catalog.json` (such as /high/max) may be filtered by Codex Desktop’s hard-coded allowlist, which excludes `max` by default, or the generated catalog template may contain only the none and high levels. In addition, switching providers without correctly clearing or restoring `auth.json` may invalidate the official login session.

  1. Upgrade CC Switch to v3.19.1 or later. This version standardizes `model_provider` for third-party providers as "custom" and fixes the disappearing project list after switching.

  2. If the project list is still missing, manually edit `~/.codex/config.toml`. Ensure that all third-party providers use "custom" for the `model_provider` field and that the `[model_providers.custom]` section exists.

    ~/.codex/config.toml
    model_provider = "custom"
    [model_providers.custom]
    name = "packycode" # 或其他供应商名称
    base_url = "http://127.0.0.1:8085/v1"
  3. If fewer reasoning levels are available, open Codex Desktop settings → Configuration → Model Features → Available Reasoning Effort, then select all the levels you need, including Max.

  4. For v3.19.1 and earlier, manually edit `~/.codex/cc-switch-model-catalog.json` and add the `medium` and `xhigh` levels to `supported_reasoning_levels` (these are included in Codex Desktop’s default allowlist).

    ~/.codex/cc-switch-model-catalog.json
    "supported_reasoning_levels": [
    { "effort": "low" },
    { "effort": "medium" },
    { "effort": "high" },
    { "effort": "xhigh" },
    { "effort": "max" }
    ]
  5. Fully quit and restart Codex Desktop to apply the configuration changes.

  6. If you cannot log in after switching to OpenAI Official, manually delete `~/.codex/auth.json` and reopen Codex Desktop, or clear the authentication state in CC Switch before switching providers.

ToolCodex Desktop
Versionv3.16.1 - v3.19.0(v3.19.1 修复了 model_provider 统一问题)
PlatformsWindowsmacOS
Why did my Codex project list disappear after upgrading CC Switch?
Older versions of CC Switch wrote different `model_provider` strings for different providers (such as packycode vs custom), and Codex Desktop uses this field to filter historical records. Upgrade to v3.19.1+ or manually standardize `model_provider` to "custom" in config.toml to restore the list.
Why can I select only two reasoning levels for my DeepSeek model in Codex when the catalog declares three?
This is a Codex Desktop client limitation. By default, it shows only levels on its allowlist: `low/medium/high/xhigh/ultra/persistent`. `max` is not on the default allowlist. You can select Max manually in Codex settings → Model Features → Available Reasoning Effort, or modify the catalog to add `medium` and `xhigh`.
What should I do if my official OpenAI login stops working after switching providers?
Switching providers may corrupt or clear auth.json. Try manually deleting `~/.codex/auth.json` and restarting Codex Desktop, or make sure CC Switch has correctly cleared the old authentication information before switching.
Why does Codex bypass the proxy when local routing is enabled?
Check whether `base_url` in `~/.codex/config.toml` points to `http://127.0.0.1:15721/v1` (or your local routing port), and confirm that local routing is enabled in CC Switch. If config.toml is correct but requests are not going through the proxy, try restarting Codex and CC Switch.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.