fix(providers): use hostname comparison for api.openai.com api_mode detection

[cjakma]

What changed and why

determine_api_mode was using "api.openai.com" in url_lower (string containment) which can match URLs that merely include that string as a substring — for example a reverse-proxy whose hostname ends with .api.openai.com.evil.com.

Switch to base_url_hostname(base_url) == "api.openai.com" so only the exact hostname triggers codex_responses mode.

How to test

from hermes_cli.providers import determine_api_mode
assert determine_api_mode("openai", "https://api.openai.com/v1") == "codex_responses"
assert determine_api_mode("openai", "https://proxy.api.openai.com.evil.com/v1") != "codex_responses"
assert determine_api_mode("openai", "https://my-api.openai.com.proxy.internal/v1") != "codex_responses"

Platforms tested

• Linux (Ubuntu 22.04)

Changes

• hermes_cli/providers.py: 1-line change, in url_lower → base_url_hostname(base_url) ==

[alt-glitch]

Duplicate of #41136 — that open PR makes the identical api.openai.com hostname-hardening change in the same determine_api_mode known-provider branch ("api.openai.com" in url_lower → base_url_hostname(...) == "api.openai.com"), and additionally hardens the sibling api.kimi.com/coding and api.anthropic.com checks in the same branch. #41136 is the earlier, more comprehensive fix.

[liuhao1024]

Verification

Reviewed the diff — this is a clean and correct fix.

Before: substring match "api.openai.com" in url_lower would match any URL containing that string (e.g. https://my-proxy.com/api.openai.com/v1, https://api.openai.com.evil.com).

After: exact hostname comparison via base_url_hostname(base_url) == "api.openai.com" restricts to the actual OpenAI endpoint.

Single-line change with clear security improvement. LGTM.

[teknium1]

Thanks for the focused hostname hardening. The submitted line correctly addresses a live false positive in the known-provider branch at hermes_cli/providers.py:560.

Problems

• No regression test covers this branch: tests/hermes_cli/test_determine_api_mode_hostname.py:15-43 uses provider="", while this PR changes the get_provider(provider) path at hermes_cli/providers.py:550-562.
• The same branch still has raw substring checks for Kimi and Anthropic at hermes_cli/providers.py:556-558. The earlier open PR #41136 applies parsed-host matching to all three sibling checks while preserving /anthropic behavior.

Suggested changes

• Add known-provider cases for the native OpenAI host, a path-style proxy, and a lookalike hostname.
• Consolidate the sibling hostname hardening so this branch has one consistent parsed-host policy.

This is an automated hermes-sweeper review.

[teknium1]

Please add a regression test through the known-provider path (get_provider(provider) is not None); the existing hostname tests use provider="" and only cover the adjacent unknown-provider branch.

[teknium1]

Thanks @cjakma — you had this right: substring matching on api.openai.com was the spoofable pattern, and hostname-parsed comparison is the correct fix.

Current main already carries the exact-hostname check in host_mandated_api_mode() (landed via the #32243 hardening), and as of PR #74958 (merged in 008f1ef) the whole lane now routes through a shared is_official_openai_host() predicate that keeps the hostname-parsed spoof rejection you proposed while also recognizing OpenAI's data-residency regional hosts (us./eu.api.openai.com).

Closing as implemented on main — your PR identified the right defect first. Appreciated!