ocx start auto-injects openai_base_url and overwrites provider config, breaking Codex Desktop on networks that cannot reach chatgpt.com

[majia3592]

Client or integration

Codex CLI + Codex App (Desktop)

Area

CLI

Summary

ocx start auto-injects openai_base_url and overwrites provider config, breaking Codex Desktop on networks that cannot reach chatgpt.com.

When model_provider is already set to a custom provider (e.g. "deepseek"), ocx start should not inject openai_base_url. The injection forces Codex to treat the openai provider as the primary route, which conflicts with the user's explicit provider choice.

Reproduction

Attempt 1: ocx sync (recommended approach)

1. Set model_provider = "deepseek" in config.toml
2. Run ocx sync
3. Observe: model_provider changed from "deepseek" to "openai", and openai_base_url = "http://127.0.0.1:10100/v1" injected
4. Restart Codex Desktop → ChatGPT OAuth login required → corporate network blocks chatgpt.com → locked out

Attempt 2: Manual provider config (Design B)

1. Manually add [model_providers.opencodex] to config.toml (without ocx sync)
2. CLI works: codex -p opencodex routes through proxy
3. Desktop works: model_provider = "deepseek" uses API Key auth

Attempt 3: Make Desktop also use opencodex

1. Set model_provider = "opencodex" in config.toml
2. Run ocx start
3. Observe: ocx start auto-injects openai_base_url, causing Codex Desktop to show ChatGPT login page again
4. During injection, model and model_provider lines removed from config.toml → config destroyed

Version

@bitkyc08/opencodex v2.10.0

Operating system

Windows 11 x64, Node.js v24.16.0, Codex CLI v0.146.0

Provider and model

deepseek / deepseek-v4-flash

Logs or error output

# When using sandbox = "elevated" on Windows:
SetTokenInformation(TokenDefaultDacl) failed: 1344

# Workaround: change to sandbox = "unelevated"

Screenshots and supporting files

N/A

Redacted configuration

{
  "model": "deepseek-v4-flash",
  "model_provider": "deepseek",
  "model_providers": {
    "opencodex": {
      "name": "opencodex",
      "base_url": "http://127.0.0.1:10100/v1",
      "wire_api": "responses",
      "env_key": "CODEX_DEEPSEEK_API_KEY"
    }
  },
  "windows": {
    "sandbox": "unelevated"
  }
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

---

Note: This issue was generated with AI assistance. The author is not a developer but a power user exploring opencodex integration on corporate networks.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[lidge-jun]

Status after investigation on current dev:

Attempt 1 (model_provider = "deepseek" overwritten): an external-provider guard has been in place since v2.7.36 (externalCodexModelProvider in src/codex/inject.ts): when the effective root model_provider is anything other than openai/opencodex, injectCodexConfig returns before any write and config.toml is left byte-for-byte untouched. We could not reproduce the overwrite with your redacted config shape — including a CRLF Windows-style file with the [model_providers.opencodex] table and [windows] section present — and we added a permanent regression test for exactly that shape (CRLF + deepseek + coexisting opencodex table, asserted byte-for-byte).

One thing that would explain what you saw: if your real config contains a profile = "..." key whose selected [profiles.<name>] section sets model_provider = "openai" or "opencodex", that profile takes precedence over the root key — the root deepseek line is then inactive and injection proceeds by design. Could you check whether a profile key (or a [profiles.*] section) exists in your unredacted config.toml?

Attempt 3 (model_provider = "opencodex"): this is routed mode working as designed — opencodex routes through the proxy, so ocx start takes ownership: it removes the root model / model_provider lines and installs the openai_base_url override, and restores native config on shutdown. It is not config destruction, but we agree the Desktop login symptom on a network that cannot reach chatgpt.com is the real pain here — that part is tracked in #1091 (custom upstream URLs for the OAuth provider).

Keeping this open pending your reply on the profile question. If you can still reproduce attempt 1 on the current release with no profile override, please attach the unredacted (secrets-stripped) config.toml and the exact ocx version — that would make this a hard bug and we will treat it as one.

[majia3592]

澄清需求

Thanks for the investigation. To clarify — the core issue is not about config being overwritten (I can confirm no profile key exists, and I can no longer reproduce the overwrite on v2.10.0).

The real use case is: on a corporate network where chatgpt.com is blocked, I want Codex Desktop to work with third-party models via opencodex proxy, without requiring OpenAI OAuth login.

Current situation:

• CLI: Works perfectly — codex -p opencodex routes through the local proxy, no chatgpt.com needed ✅
• Desktop: Any model_provider other than "deepseek" triggers the OAuth login page, which fails because chatgpt.com is unreachable ❌

What I am looking for: a way to either:

1. Skip the OAuth check when using a custom provider (e.g. opencodex) that does not need ChatGPT credentials, or
2. Allow Desktop to authenticate once on a reachable network, then work offline with cached credentials + opencodex proxy

This is more of a feature request than a bug report. Should I close #1090 and open a new issue for this?

---

Note: This comment was drafted with AI assistance. The author is a power user, not a developer.

[lidge-jun]

Closing this per your own read of it — thank you for the careful follow-up, and especially for confirming that no profile key exists and that the overwrite no longer reproduces on v2.10.0. That was the load-bearing question, and your answer settles it.

To record what the investigation established, so this issue stays useful to anyone who finds it later:

The reported overwrite (attempt 1) is guarded and now permanently tested. externalCodexModelProvider (src/codex/inject.ts) has returned before any write since v2.7.36 whenever the effective root model_provider is anything other than openai/opencodex. We added a regression test for your exact config shape — CRLF Windows-style file, model_provider = "deepseek", a coexisting [model_providers.opencodex] table and a [windows] section — asserted byte-for-byte. It is on dev and shipped in v2.10.2, which is now on npm as latest.

Attempt 3 is by design. With model_provider = "opencodex" you are in routed mode, so injection is supposed to run and rewrite those lines. That is the configuration working as intended, not config destruction.

Your actual need is the third-party-only Desktop path, and it is a real gap. Codex Desktop's ChatGPT OAuth requirement is enforced by Codex itself, not by opencodex, which is why codex -p opencodex works on your blocked network and Desktop does not. That is worth tracking, but it is a different request from the title here, and it does not belong under a bug report about config overwriting.

So: yes, please open a new Feature proposal for the Desktop-without-ChatGPT-OAuth case. Use the template chooser so it lands with the right form. Two things that would make it strong:

• which of your two options you actually want — skipping the OAuth check for a custom provider, or authenticating once and running on cached credentials afterwards
• what Desktop does today on the blocked network at the point of failure, since anything we do has to work against Codex's own auth gate rather than around it

#1091 covers the adjacent but distinct problem of pointing the ChatGPT OAuth provider at a custom upstream URL; it is open and has a design note on why it needs an explicit trust model. Your case is not the same thing, so it deserves its own issue rather than a comment there.

Reopen this one if the overwrite ever comes back on v2.10.2 or later — with the unredacted config, that would be a genuine regression and we would want it.