You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ocx start auto-injects openai_base_url and overwrites provider config, breaking Codex Desktop on networks that cannot reach chatgpt.com #1090
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)
Set model_provider = "deepseek" in config.toml
Run ocx sync
Observe: model_provider changed from "deepseek" to "openai", and openai_base_url = "http://127.0.0.1:10100/v1" injected
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.
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.
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:
Skip the OAuth check when using a custom provider (e.g. opencodex) that does not need ChatGPT credentials, or
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.
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.
Activity
github-actions commentedon Aug 6, 2026
Automated translation bookkeeping — detected language: unknown.
lidge-jun commentedon Aug 6, 2026
Status after investigation on current
dev:Attempt 1 (
model_provider = "deepseek"overwritten): an external-provider guard has been in place since v2.7.36 (externalCodexModelProviderinsrc/codex/inject.ts): when the effective rootmodel_provideris anything other thanopenai/opencodex,injectCodexConfigreturns before any write andconfig.tomlis 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 setsmodel_provider = "openai"or"opencodex", that profile takes precedence over the root key — the rootdeepseekline is then inactive and injection proceeds by design. Could you check whether aprofilekey (or a[profiles.*]section) exists in your unredactedconfig.toml?Attempt 3 (
model_provider = "opencodex"): this is routed mode working as designed —opencodexroutes through the proxy, soocx starttakes ownership: it removes the rootmodel/model_providerlines and installs theopenai_base_urloverride, 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.tomland the exactocxversion — that would make this a hard bug and we will treat it as one.Merge pull request #1097 from lidge-jun/codex/260806-disposition-sweep
test(codex): lidge-jun#1090 regression — CRLF external-provider confi…
docs(devlog): wp2 ledger — lidge-jun#1090 regression test landed, iss…
majia3592 commentedon Aug 6, 2026
澄清需求
Thanks for the investigation. To clarify — the core issue is not about config being overwritten (I can confirm no
profilekey exists, and I can no longer reproduce the overwrite on v2.10.0).The real use case is: on a corporate network where
chatgpt.comis blocked, I want Codex Desktop to work with third-party models via opencodex proxy, without requiring OpenAI OAuth login.Current situation:
codex -p opencodexroutes through the local proxy, no chatgpt.com needed ✅model_providerother than"deepseek"triggers the OAuth login page, which fails becausechatgpt.comis unreachable ❌What I am looking for: a way to either:
opencodex) that does not need ChatGPT credentials, orThis is more of a feature request than a bug report. Should I close #1090 and open a new issue for this?
lidge-jun commentedon Aug 6, 2026
Closing this per your own read of it — thank you for the careful follow-up, and especially for confirming that no
profilekey 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 rootmodel_provideris anything other thanopenai/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 ondevand shipped in v2.10.2, which is now on npm aslatest.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 opencodexworks 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:
#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.
test(codex): lidge-jun#1090 regression — CRLF external-provider confi…
docs(devlog): wp2 ledger — lidge-jun#1090 regression test landed, iss…
Merge pull request lidge-jun#1097 from lidge-jun/codex/260806-disposi…