Files
codex/codex-rs/codex-api
andrewgu-oai 888be42a20 Support explicit provider model catalog URLs (#46561)
## Why

Providers need to serve Codex model metadata independently of their inference endpoint. A custom inference `base_url` alone should not opt API-key sessions into remote catalog discovery.

## What changed

- Add `model_catalog_url` to provider configuration and thread-config serialization. Fetch the full catalog URL with provider authentication, headers, query parameters, and `client_version`, while preserving inference routing.
- Require an explicit catalog URL for API-key discovery with a custom base URL. Keep default OpenAI discovery on the Codex backend, and apply `api_key_model_discovery` gating to provider API keys and cached catalogs.
- Include the catalog URL in cache identity so different catalogs do not share cached metadata.
- Limit explicitly configured catalog responses to 1 MiB, reject redirects, and suppress URL and response diagnostics that could expose credentials.

## Testing

Add coverage for catalog configuration round-trips, query encoding, authentication and header reuse, cache identity and discovery gating, oversized responses, and redirect rejection without credential forwarding. Add an integration test verifying that catalog model metadata and instructions reach conversation requests.

GitOrigin-RevId: 7f6ac5eec257278685e1867a6bcebae6514a365a
2026-09-19 01:36:53 +00:00
..

codex-api

Typed clients for Codex/OpenAI APIs built on top of the generic transport in codex-client.

  • Hosts the request/response models and request builders for Responses and related Codex APIs.
  • Owns provider configuration (base URLs, headers, query params), auth header injection, retry tuning, and stream idle settings.
  • Parses SSE streams into ResponseEvent/ResponseStream, including rate-limit snapshots and API-specific error mapping.
  • Serves as the wire-level layer consumed by codex-core; higher layers handle auth refresh and business logic.

Core interface

The public interface of this crate is intentionally small and uniform:

  • Responses endpoint

    • Input:
      • ResponsesApiRequest for the request body (model, instructions, input, tools, parallel_tool_calls, reasoning/text controls).
      • ResponsesOptions for transport/header concerns (conversation_id, session_source, extra_headers, compression, turn_state).
    • Output: a ResponseStream of ResponseEvent (both re-exported from common).
  • Memory summarize endpoint

    • Input: MemorySummarizeInput (re-exported as codex_api::MemorySummarizeInput):
      • model: String.
      • raw_memories: Vec<RawMemory> (serialized as traces for wire compatibility).
        • RawMemory includes id, metadata.source_path, and normalized items.
      • reasoning: Option<Reasoning>.
    • Output: Vec<MemorySummarizeOutput>.
    • MemoriesClient::summarize_input(&MemorySummarizeInput, extra_headers) wraps JSON encoding and retry/telemetry wiring.

All HTTP details (URLs, headers, retry/backoff policies, SSE framing) are encapsulated in codex-api and codex-client. Callers construct prompts/inputs using protocol types and work with typed streams of ResponseEvent or other endpoint-specific response values.