Skip to content

core-plugins: route curated startup sync through HTTP client factory#31924

Open
bolinfest wants to merge 1 commit into
pr31828from
pr31924
Open

core-plugins: route curated startup sync through HTTP client factory#31924
bolinfest wants to merge 1 commit into
pr31828from
pr31924

Conversation

@bolinfest

@bolinfest bolinfest commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

Why

Curated-plugin startup sync has HTTP fallback paths for GitHub metadata/archives and a ChatGPT export archive. Those requests bypassed the effective HttpClientFactory, so features.respect_system_proxy could be enabled for the rest of Codex while startup sync still failed on PAC/OS-proxy-only networks.

RemotePluginServiceConfig is also the handoff point for remote-plugin traffic. Making its factory mandatory in this foundation PR ensures callers cannot construct service state without consulting the effective proxy policy, while the child PR can stay focused on converting request families.

This is split from #31837 so reviewers can evaluate shared configuration and startup sync independently from the remote-plugin request migration.

What changed

  • Thread the effective HttpClientFactory through PluginsConfigInput into the background curated-repository sync.
  • Make RemotePluginServiceConfig construction require that factory, create its privacy-safe route-aware pool, and convert all construction sites. The child PR begins using the pool for remote-plugin requests.
  • Route GitHub metadata, GitHub zipball, export metadata, and backend-issued archive download URLs through request-level route selection.
  • Use no-request-diagnostics pools so signed download URLs and response headers are not logged.
  • Keep git transport and fallback ordering unchanged.
  • Add recording-selector coverage for startup-sync routing and preserve the effective proxy policy in service-config equality checks.

Review guide

  1. Start with the factory handoff in manager.rs, core/src/config/mod.rs, and RemotePluginServiceConfig::new in remote.rs.
  2. Review only the HTTP fallback functions in startup_sync.rs; the git path is unchanged.
  3. startup_sync_tests.rs covers the two-hop export archive flow, while the config tests verify the effective proxy policy reaches plugin service state.
  4. core-plugins: route remote requests through HTTP client factory #31837, stacked above this PR, consumes the service pool for remote catalog/mutation/upload/bundle traffic.

Validation

  • The commit builds independently with cargo check -p codex-core-plugins -p codex-core -p codex-app-server --tests.
  • Startup-sync URL-routing and existing fallback tests.

Stack created with Sapling. Best reviewed with ReviewStack.

@chatgpt-codex-connector

Copy link
Copy Markdown
Contributor

💡 Codex Review

http = { workspace = true }
url = { workspace = true }

P2 Badge Update the Bazel lockfile for dependency changes

This manifest adds new Rust dependencies, and the commit also changes Cargo.lock, but MODULE.bazel.lock is not included in the diff. That leaves Bazel's crate lock stale and should fail the lockfile drift check; please run just bazel-lock-update from the repo root and include the generated MODULE.bazel.lock update.

AGENTS.md reference: AGENTS.md:L37-L39


http_clients
.request(Method::GET, url)
.timeout(CURATED_PLUGINS_HTTP_TIMEOUT)
.header("accept", GITHUB_API_ACCEPT_HEADER)
.header("x-github-api-version", GITHUB_API_VERSION_HEADER)

P2 Badge Send a User-Agent on GitHub fallback requests

When curated plugin sync falls back to the GitHub HTTP path, these requests used to go through build_reqwest_client(), which attaches Codex's default User-Agent; after this migration the route-aware request only adds the GitHub accept/version headers. GitHub REST API requests without a User-Agent are rejected or throttled, so machines where git sync fails can stop refreshing the curated plugins repo. Add the Codex UA/default headers to this route-aware GitHub request.


use sha2::Digest;
use sha2::Sha256;

P1 Badge Move sha2 out of target-specific dependencies

On Linux and other non-macOS/non-Windows targets, system_proxy_cache_key now always uses Sha256, but codex-http-client still declares sha2 only under the macOS/Windows target dependency section. That makes default Linux builds of this crate fail to resolve sha2; move the dependency to the common dependency list or keep the non-target code path free of sha2.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant