mirror of
https://github.com/openai/codex.git
synced 2026-08-23 13:09:46 +00:00
0e19d5e908
## Why Codex Apps file parameters use a three-step upload flow: create a file record, PUT bytes to a returned signed URL, and finalize the upload. Each step still constructed a default `reqwest` client, so the flow could bypass `features.respect_system_proxy` even after model API requests honored it. This stack entry makes the resolved client policy a required input to the upload API and resolves each concrete destination independently. ## What changed - Require `HttpClientFactory` in `upload_openai_file`. - Build clients for the create, signed upload, and finalize URLs through the shared API route policy. - Pass the factory derived from the turn configuration at the Apps/MCP call site. - Return a destination-aware `ClientBuild` error when enabled route selection cannot construct a client. - Preserve the legacy logged fallback for the feature-off `ReqwestDefault` policy. ## Review guide 1. `codex-api/src/files.rs` changes the upload API and centralizes route-aware client construction. 2. The three request stages each supply their actual URL, including the separately hosted signed blob URL. 3. `core/src/mcp_openai_file.rs` is the only production caller and supplies the turn configuration factory. ## Validation - `cargo check --tests -p codex-api -p codex-core` - `just test -p codex-api files` (1 matching upload test passed; 135 tests skipped by filter) - `just fix -p codex-api -p codex-core` ## Follow-up Other direct HTTP clients remain separate migration slices. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31363). * #31637 * #31431 * __->__ #31363
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 Compact 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:
ResponsesApiRequestfor the request body (model,instructions,input,tools,parallel_tool_calls, reasoning/text controls).ResponsesOptionsfor transport/header concerns (conversation_id,session_source,extra_headers,compression,turn_state).
- Output: a
ResponseStreamofResponseEvent(both re-exported fromcommon).
- Input:
-
Compaction endpoint
- Input:
CompactionInput<'a>(re-exported ascodex_api::CompactionInput):model: &str.input: &[ResponseItem]– history to compact.instructions: &str– fully-resolved compaction instructions.
- Output:
Vec<ResponseItem>. CompactClient::compact_input(&CompactionInput, extra_headers)wraps the JSON encoding and retry/telemetry wiring.
- Input:
-
Memory summarize endpoint
- Input:
MemorySummarizeInput(re-exported ascodex_api::MemorySummarizeInput):model: String.raw_memories: Vec<RawMemory>(serialized astracesfor wire compatibility).RawMemoryincludesid,metadata.source_path, and normalizeditems.
reasoning: Option<Reasoning>.
- Output:
Vec<MemorySummarizeOutput>. MemoriesClient::summarize_input(&MemorySummarizeInput, extra_headers)wraps JSON encoding and retry/telemetry wiring.
- Input:
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 compacted ResponseItem values.