Skip to content

fix(codex): force codex_responses api_mode for openai-codex provider#10044

Closed
saamuelng601-pixel wants to merge 1 commit into
NousResearch:mainfrom
saamuelng601-pixel:fix/openai-codex-api-mode-priority
Closed

fix(codex): force codex_responses api_mode for openai-codex provider#10044
saamuelng601-pixel wants to merge 1 commit into
NousResearch:mainfrom
saamuelng601-pixel:fix/openai-codex-api-mode-priority

Conversation

@saamuelng601-pixel

Copy link
Copy Markdown

Summary

  • openai-codex provider targets chatgpt.com/backend-api/codex/*, but Cloudflare started issuing managed challenges (403) on /chat/completions on 2026-04-14.
  • The correct path (/responses, aka api_mode="codex_responses") is not yet challenged, and is already the documented transport for this provider in hermes_cli/providers.py:57.
  • However, AIAgent.__init__ honored a caller-passed api_mode before applying the provider requirement. A stale api_mode="chat_completions" could leak in via tools/delegate_tool.py:325 (subagent inherits parent's post-switch api_mode) or resolve_runtime_provider() cache from a previous OpenRouter/etc. session, routing openai-codex to the blocked endpoint.
  • Fix: flip the resolution order so provider == "openai-codex" (or base_url = chatgpt.com/backend-api/codex) always forces api_mode="codex_responses" before considering caller overrides.

Verified symptom in local logs: 111+ CF challenge pages captured on /backend-api/codex/chat/completions?__cf_chl_tk=… in a 24h window.

Upstream references: openclaw/openclaw#66633, #62142, #62087 — parallel Cloudflare blocker across ecosystems.

Test plan

  • Unit: existing test_auth_codex_provider.py / test_codex_models.py pass
  • Integration: run a gpt-5.4 turn; verify request URL = .../codex/responses, not /chat/completions
  • Regression: confirm anthropic_messages / chat_completions still selectable for non-codex providers when caller explicitly passes api_mode

🤖 Generated with Claude Code

The openai-codex provider targets `chatgpt.com/backend-api/codex/...`,
which Cloudflare began blocking on `/chat/completions` with a managed
challenge (403) on 2026-04-14. The `/responses` endpoint (aka
codex_responses api_mode) is the correct path and is not yet challenged.

Previously, the AIAgent.__init__ resolution order honored a caller-
passed api_mode before applying the provider-specific requirement, so a
stale `api_mode="chat_completions"` value inherited from tools/delegate_tool.py
(parent agent's api_mode after a model switch) or resolve_runtime_provider()
would leak into the openai-codex agent and route it to the blocked
endpoint.

This change flips the order so that `provider == "openai-codex"` (or a
base_url pointing at `chatgpt.com/backend-api/codex`) always forces
api_mode="codex_responses", with caller overrides applied only for
other providers.

Refs: openclaw/openclaw#66633 (same upstream CF blocker).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Zijie-Tian added a commit to Zijie-Tian/hermes-agent that referenced this pull request Apr 18, 2026
The main OpenAI client path was injecting a custom httpx transport that
bypassed proxy-aware defaults, while the raw Codex path ignored
runtime-resolved base URLs and openai-codex callers could still pin
chat_completions. This packages the minimal local fixes and regression
tests needed to make Hermes reliably use Codex gpt-5.4 behind the
user's configured proxy.

Constraint: Must preserve unrelated local edits in the repo
Constraint: Must keep Hermes on the Codex Responses path for openai-codex
Rejected: Commit workspace-level ~/.hermes/.env changes | outside repo scope
Rejected: Wait for upstream PR merges | user needs a working fork branch now
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: If upstream merges NousResearch#11733/NousResearch#10044/NousResearch#5988, rebase this branch against their final versions before reusing it
Tested: pytest tests/run_agent/test_create_openai_client_reuse.py -q
Tested: pytest tests/run_agent/test_run_agent_codex_responses.py -q
Tested: pytest tests/agent/test_auxiliary_client.py -q
Tested: hermes chat --provider openai-codex -m gpt-5.4 -Q --max-turns 1 -q "Reply with exactly OK."
Tested: hermes chat -Q --max-turns 1 -q "Reply with exactly OK."
Not-tested: gateway / IM platform flows
Related: NousResearch#11609
Related: NousResearch#11733
Related: NousResearch#10044
Related: NousResearch#5988
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the submission @saamuelng601-pixel. Closing as superseded — already on main — see run_agent.py lines 873-874, which forces api_mode = codex_responses when provider == 'openai-codex'.

Hermes's Codex auth design was reworked in #12360 ("Hermes owns its own Codex auth; stop touching ~/.codex/auth.json") to stop sharing refresh tokens with the Codex CLI / VS Code extension (they rotate on every use, so shared access caused refresh_token_reused races). Users who want to adopt Codex CLI credentials get a one-time explicit prompt via hermes auth openai-codex instead.

The valid adjacent fixes from this batch (error parsing, fallback chain on auth failure, reauth UX) landed together in #15104.

@teknium1 teknium1 closed this Apr 24, 2026
@alt-glitch alt-glitch added type/bug Something isn't working P1 High — major feature broken, no workaround comp/agent Core agent loop, run_agent.py, prompt builder provider/openai OpenAI / Codex Responses API labels Apr 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/agent Core agent loop, run_agent.py, prompt builder P1 High — major feature broken, no workaround provider/openai OpenAI / Codex Responses API type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants