Configure Codex web search independently from the active model provider

Start with codex-rs/ext/web-search/src/extension.rs and tool.rs to trace how the active model provider supplies the search endpoint and authentication, then read history.rs for context disclosure. Define the configuration and capability boundaries needed for an independently selected live-search backend, preserving one canonical search surface, explicit failures, provider visibility, and query-only disclosure by default.

What variant of Codex are you using?

Codex CLI and Codex App. The request concerns the shared Codex search layer.

What feature would you like to see?

Please allow the backend used by Codex's first-class live web-search capability to be selected independently from the active model provider.

The target use case is keeping OpenAI/ChatGPT as the model provider while explicitly selecting a separate search service, without exposing two competing search tools to the model.

OpenAI-hosted search should remain the unchanged default. A separately configured backend should be optional and should have its own authentication and declared capabilities.

Minimum expected behavior:

• Model and live-search backend can be selected independently.
• Codex continues to expose exactly one canonical search capability.
• Native search progress, source information, results, and errors remain available to Codex clients.
• The selected provider is visible, and failures do not silently fall back to another provider.
• Unsupported features fail clearly rather than being ignored.
• Credentials remain outside prompts and normal transcripts.
• Conversation history, approximate location, or other additional context is not sent to a separate provider without an explicit, inspectable setting.

This request is limited to live search initially. It does not require third parties to reproduce the existing cached or indexed search modes.

This is also not a request to enable search by default, change when Codex decides to search, hard-code a particular search vendor, or create a provider marketplace. It asks only that the search route not be inseparable from the model route.

Additional information

I searched open and closed issues, pull requests, and Discussions on July 23, 2026 and did not find an exact request for independently selecting the live-search backend while keeping the model provider unchanged.

The closest historical issue is #2563, which included an illustrative provider setting but primarily requested automatic search based on recency intent. It was closed in favor of #3139, which was completed when search was enabled by default, not when provider selection was added.

The closest current implementation is #34846, which added supports_standalone_web_search to model-provider configuration. That supports a model provider that also implements Codex's standalone search endpoint, but current source still copies the active model provider into the search extension and obtains the search endpoint and authentication from that provider:

• Search extension configuration
• Search client construction

The current standalone request can also include recent conversation context. If a separate provider is supported, query-only disclosure should be the default, with explicit configuration for any additional context:

• Standalone search history selection

Related but distinct reports:

• #30343 concerns configured MCP tools missing from Desktop threads even though Tavily works in the CLI.
• #28954 concerns native search events with a local model provider.
• #33250 concerns native search-tool injection for particular models through a custom provider.
• #28168 concerns a collision between hosted and standalone search surfaces.

These reports show nearby capability and presentation boundaries, but none requests an OpenAI model with an independently selected live-search backend.

This is a source-backed feature request rather than a runtime bug report. I have not claimed comparative MCP/native quality or rendering results. I can add a sanitized runtime comparison if that would help define the expected contract.