Skip to content

fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synthesis fallback#76428

Merged
vincentkoc merged 3 commits intoopenclaw:mainfrom
arniesaha:fix/codex-synthesis-honor-provider-baseurl
May 3, 2026
Merged

fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synthesis fallback#76428
vincentkoc merged 3 commits intoopenclaw:mainfrom
arniesaha:fix/codex-synthesis-honor-provider-baseurl

Conversation

@arniesaha
Copy link
Copy Markdown
Contributor

@arniesaha arniesaha commented May 3, 2026

Summary

When the openai-codex provider is configured with a custom baseUrl (e.g. a local proxy that forwards Codex traffic) and the model registry has no template row to clone for the requested id, resolveCodexForwardCompatModel synthesizes a ProviderRuntimeModel with a hardcoded OPENAI_CODEX_BASE_URL. The configured proxy URL is silently dropped, traffic goes to chatgpt.com / api.openai.com directly, and the call typically fails the auth contract — without any model.attempt event reaching the user (since the failure happens before session.started).

Fix

resolveCodexForwardCompatModel now reads ctx.providerConfig?.baseUrl and uses it as the synthesis baseUrl when present, falling back to OPENAI_CODEX_BASE_URL when not. This affects both synthesis fallbacks in the function (the gpt-5.5 path and the gpt-5.4/pro/mini/legacy path).

const synthBaseUrl = ctx.providerConfig?.baseUrl ?? OPENAI_CODEX_BASE_URL;

The template-clone (cloneFirstTemplateModel) and registry-find (ctx.modelRegistry.find) paths are unchanged — they already inherit the configured baseUrl through the cloned/found model. This is the smallest fix that closes the silent-bypass behavior without touching catalog or transport normalization.

Why now

Reproduced on a real deployment: a custom ~/.openclaw/agents/<id>/agent/models.json with providers["openai-codex"].baseUrl = "http://192.168.1.70:30400" and models = []. With this config the gateway silently routed every call to chatgpt.com instead of the proxy, then fell back to a different provider after the codex attempt failed — with no observable trajectory event explaining why. After the patch, traffic flows through the configured proxy as expected.

Test plan

  • Added two unit tests in openai-codex-provider.test.ts:
    • honors providerConfig.baseUrl in the gpt-5.5 synthesis fallback
    • honors providerConfig.baseUrl in the gpt-5.4 synthesis fallback
  • Existing 29 codex-provider tests still pass (31 total in file).
  • pnpm tsgo:extensions clean.
  • pnpm lint clean (extensions + core + scripts shards).
  • pnpm exec oxfmt --check clean.
  • pnpm check:import-cycles clean.
  • Verified end-to-end against the affected deployment — POST /codex/responses 200 OK now lands at the configured proxy.

🤖 Generated with Claude Code

@arniesaha
fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synt…
13085b0 
…hesis fallback

The synthesis fallback in resolveCodexForwardCompatModel hardcoded
OPENAI_CODEX_BASE_URL when the model registry had no template row to
clone, which meant openai-codex providers configured with a custom
baseUrl (e.g. a local proxy that forwards Codex traffic) silently
fell back to api.openai.com / chatgpt.com - bypassing the proxy and
typically failing the auth contract.

Synthesis now reads ctx.providerConfig.baseUrl when present, with the
existing OPENAI_CODEX_BASE_URL constant as the fallback. No effect on
template-clone or registry-find paths, which already inherit the
configured baseUrl through the cloned template.
@clawsweeper
Copy link
Copy Markdown
Contributor

clawsweeper Bot commented May 3, 2026 •
edited
Loading

Codex review: needs maintainer review before merge.

Summary
The PR changes OpenAI Codex dynamic-model synthesis fallback to prefer ctx.providerConfig?.baseUrl for synthesized gpt-5.5/gpt-5.4-family models and adds provider unit tests plus an Unreleased changelog entry.

Reproducibility: yes. for the hook-level issue: call the OpenAI Codex provider dynamic-model hook with an empty/no-template registry and providerConfig.baseUrl; current main returns a synthesized model with the hardcoded Codex base URL. The broader deployment bypass was not live-reproduced in this read-only review.

Next step before merge
No repair lane is needed; there are no actionable review findings, and the remaining action is normal maintainer review and CI.

Security
Cleared: The diff only changes provider metadata selection, provider tests, and changelog text, with no dependency, workflow, script, permission, or secret-handling change.

Review details

Best possible solution:

Merge the narrow provider-hook fix after normal CI; add an embedded-runner regression only if maintainers want explicit proof for the reported end-to-end routing path.

Do we have a high-confidence way to reproduce the issue?

Yes for the hook-level issue: call the OpenAI Codex provider dynamic-model hook with an empty/no-template registry and providerConfig.baseUrl; current main returns a synthesized model with the hardcoded Codex base URL. The broader deployment bypass was not live-reproduced in this read-only review.

Is this the best way to solve the issue?

Yes. Reading providerConfig.baseUrl only in the synthesis fallback is the narrow provider-owned fix and preserves the existing registry/template clone paths; the PR now includes focused tests and the required changelog entry.

What I checked:

Likely related people:

  • vincentkoc: Current checked-out blame points to Vincent Koc for resolveCodexForwardCompatModel and the embedded-runner provider override path, and adjacent Codex/plugin changelog history repeatedly credits @vincentkoc in this area. (role: introduced behavior and recent maintainer; confidence: medium; commits: 85520f664d02, d1c5e750ed2a; files: extensions/openai/openai-codex-provider.ts, extensions/openai/openai-codex-provider.test.ts, src/agents/pi-embedded-runner/model.ts)

Remaining risk / open question:

  • The PR validates the provider hook directly; it does not add an end-to-end embedded-runner or gateway regression for the reported deployment routing path.

Codex review notes: model gpt-5.5, reasoning high; reviewed against b258c3fc6578.

@arniesaha
Copy link
Copy Markdown
Contributor Author

arniesaha commented May 3, 2026

Added the missing Unreleased Fixes entry per the Codex review (a67d996). pnpm test src/infra/changelog-unreleased.test.ts passes.

@vincentkoc vincentkoc merged commit b83b2e3 into openclaw:main May 3, 2026
79 checks passed
@vincentkoc
Copy link
Copy Markdown
Member

vincentkoc commented May 3, 2026

@arniesaha perfect PR, zero fixes needed. Straight merge ;)

@github-actions github-actions Bot mentioned this pull request May 3, 2026
Open
@arniesaha arniesaha deleted the fix/codex-synthesis-honor-provider-baseurl branch May 4, 2026 21:29
@clawsweeper clawsweeper Bot mentioned this pull request May 6, 2026
Closed
lxe pushed a commit to lxe/openclaw that referenced this pull request May 6, 2026
@arniesaha @lxe
fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synt…
cf70399 
…hesis fallback (openclaw#76428)

* fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synthesis fallback

The synthesis fallback in resolveCodexForwardCompatModel hardcoded
OPENAI_CODEX_BASE_URL when the model registry had no template row to
clone, which meant openai-codex providers configured with a custom
baseUrl (e.g. a local proxy that forwards Codex traffic) silently
fell back to api.openai.com / chatgpt.com - bypassing the proxy and
typically failing the auth contract.

Synthesis now reads ctx.providerConfig.baseUrl when present, with the
existing OPENAI_CODEX_BASE_URL constant as the fallback. No effect on
template-clone or registry-find paths, which already inherit the
configured baseUrl through the cloned template.

* docs(changelog): add Unreleased Fixes entry for openclaw#76428 codex synthesis baseUrl honor
@arniesaha arniesaha mentioned this pull request May 8, 2026
Open
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 9, 2026
@arniesaha
fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synt…
08b7877 
…hesis fallback (openclaw#76428)

* fix(openai-codex): honor providerConfig.baseUrl in dynamic-model synthesis fallback

The synthesis fallback in resolveCodexForwardCompatModel hardcoded
OPENAI_CODEX_BASE_URL when the model registry had no template row to
clone, which meant openai-codex providers configured with a custom
baseUrl (e.g. a local proxy that forwards Codex traffic) silently
fell back to api.openai.com / chatgpt.com - bypassing the proxy and
typically failing the auth contract.

Synthesis now reads ctx.providerConfig.baseUrl when present, with the
existing OPENAI_CODEX_BASE_URL constant as the fallback. No effect on
template-clone or registry-find paths, which already inherit the
configured baseUrl through the cloned template.

* docs(changelog): add Unreleased Fixes entry for openclaw#76428 codex synthesis baseUrl honor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

extensions: openai size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@arniesaha @vincentkoc