fix(codex): drop unsupported pro defaults

[yungchentang]

Summary

• Remove the ChatGPT-account-rejected gpt-5.6-sol-pro, gpt-5.6-terra-pro, and gpt-5.6-luna-pro slugs from the curated Codex OAuth fallback list.
• Stop forward-compat model synthesis from surfacing those -pro slugs while keeping the non-pro GPT-5.6 Sol/Terra/Luna entries available.

Root Cause

• PR Complete GPT-5.6 (Sol/Terra/Luna) support, end-to-end #61616 added public-API-style -pro GPT-5.6 slugs to the Codex OAuth curated fallback/template list.
• The chatgpt.com Codex backend rejects those slugs for ChatGPT accounts with HTTP 400, so offline fallback or live discovery failures could expose dead model choices.

Live Evidence

• Reporter tested the chatgpt.com/backend-api/codex/responses OAuth Codex route on a ChatGPT Pro account on 2026-07-10.
• Accepted on that route: gpt-5.5, gpt-5.4, gpt-5.3-codex-spark, gpt-5.6-sol, and gpt-5.6-terra.
• Rejected on that route with HTTP 400: gpt-5.6-sol-pro, gpt-5.6-terra-pro, and gpt-5.6-luna-pro.
• The rejection message says those models are not supported when using Codex with a ChatGPT account, which makes them unsafe curated fallback entries even if they exist in a public API catalog.

Tests

• scripts/run_tests.sh tests/hermes_cli/test_codex_models.py -q
• python3 -m py_compile hermes_cli/codex_models.py tests/hermes_cli/test_codex_models.py
• git diff --check

Fixes #61660

[teknium1]

Thanks for the focused Codex fallback correction. Current main still inserts the three -pro slugs in both hermes_cli/codex_models.py:18-22 and the forward-compat templates at hermes_cli/codex_models.py:56-60; the PR removes both sources while leaving the direct openai catalog untouched. The gateway's curated Codex picker derives from these same definitions at hermes_cli/models.py:99-107.

No correctness or scope issues found in the two-file diff. This is an automated hermes-sweeper review.

[sunstrike228]

Independent verification on the released v0.19.0 confirms this PR is still needed.

Environment

• Hermes Agent: v0.19.0 (2026.7.20), upstream d7b36070
• Provider: openai-codex
• Account: ChatGPT Pro
• OpenAI SDK: 2.24.0
• Host: Linux

Live authenticated evidence

The raw GET https://chatgpt.com/backend-api/codex/models?client_version=1.0.0 catalog for this Pro account advertises only:

gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna

Current unpatched Hermes expands that live list to:

gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna
gpt-5.6-sol-pro
gpt-5.6-terra-pro
gpt-5.6-luna-pro

The three -pro entries are synthetic-only; they are not returned by the authenticated backend.

Fresh CLI differential repro:

hermes chat -q 'Reply with exactly: PRO_OK' \
  -m gpt-5.6-sol-pro --provider openai-codex -t safe -Q

Result:

HTTP 400: {"detail":"The 'gpt-5.6-sol-pro' model is not supported when using Codex with a ChatGPT account."}

Control request with the same account/provider:

hermes chat -q 'Reply with exactly: BASE_OK' \
  -m gpt-5.6-sol --provider openai-codex -t safe -Q

Result: BASE_OK (exit 0).

PR verification against the released 0.19 tree

I applied commit 0bed68426 with --no-commit on top of d7b36070 in an isolated worktree and ran:

scripts/run_tests.sh tests/hermes_cli/test_codex_models.py -q

Result:

21 tests passed, 0 failed

I also exercised the patched resolver against the live GPT-5.6 base slug set. Before the patch it synthesizes all three -pro values; after the patch it resolves exactly:

gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna

No -pro leakage remains, while the direct API/OpenRouter catalogs are untouched by this two-file change.

This bug is user-visible in the v0.19.0 release: the picker advertises a model that the selected provider deterministically rejects. The patch is focused, applies cleanly to the release tree, and has fresh local verification. Please consider merging #61665.

[teknium1]

Fixed by PR #89194 (merged, commit 7d780cc) — same fix, maintained against current main.

You were the first to submit this fix (July 9), and your diagnosis of the ChatGPT Codex OAuth backend rejecting the synthetic -pro fallbacks was correct — thank you. Your branch had gone stale against main, so the maintained successor landed instead. First-submitter credit to you; the PR body of #89194 and this comment record it.