›_ Codex Issues
Codex Issues / #40256

web_search = "live" silently omits web.run for custom OpenAI-auth providers

Open 💬 0 comments Opened Aug 23, 2026 by Lang45

What issue are you seeing?

With a ChatGPT-authenticated custom Responses provider, web_search = "live" can be accepted while Codex silently omits the standalone first-party Search tool (web.run; exposed as tools.web__run in code mode).

The provider below is an HTTPS-only equivalent of the built-in OpenAI route. It is needed because Responses WebSocket connections repeatedly time out in this environment while HTTPS succeeds.

model_provider = "openai_http"
web_search = "live"

[features]
standalone_web_search = true

[model_providers.openai_http]
name = "OpenAI HTTP"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

Codex starts normally, but the Search tool is absent. An explicit canary call fails with:

TypeError: tools.web__run is not a function

There is no startup, thread-creation, or effective-config warning explaining that web_search = "live" did not result in a usable Search capability.

Adding the following provider capability and starting a fresh task makes the same configuration work:

supports_standalone_web_search = true

After that change, App Server emitted a real first-party webSearch event with a non-empty structured result set (title, snippet, domain, ref_id, and URL), and the canary completed successfully.

Environment:

  • Codex Desktop package: 26.818.5229.0
  • Codex CLI/App Server: 0.149.0-alpha.4.1
  • Windows x86_64; OS build reported as 10.0.26200
  • Responses API with ChatGPT/OpenAI authentication
  • Model used for the canary: gpt-5.6-luna

What steps can reproduce the bug?

  1. Configure a custom Responses provider exactly as above, without supports_standalone_web_search.
  2. Restart Codex and start a fresh local task.
  3. Ask Codex to use its first-party Search tool for a simple current-information query.
  4. Inspect the effective tool catalog or App Server events. web.run is absent even though web_search = "live" and features.standalone_web_search = true are set.
  5. Add supports_standalone_web_search = true to the same provider, restart Codex, and start another fresh task.
  6. Repeat the canary. web.run is now exposed and produces a normal webSearch event with results.

Control observations from the same machine:

  • The custom HTTPS provider plus the capability declaration completed one canary in about 13 seconds.
  • Switching to the built-in model_provider = "openai" also exposed first-party Search, confirming that authentication and Search access were available. That single run first incurred five WebSocket request timeouts, then fell back to HTTPS and completed in about 133 seconds.

The timings are observations from single validation runs, not benchmark claims.

What is the expected behavior?

At minimum, when web_search is not "disabled" but the selected provider does not advertise the capability needed to expose Search, Codex should emit a clear diagnostic such as:

web_search = "live" was requested, but provider "openai_http" does not advertise
supports_standalone_web_search; web.run will not be exposed.

It would also help to:

  • Show the effective Search availability and the gating reason in codex doctor, /status, or App Server configuration diagnostics.
  • State clearly whether a restart and/or fresh task is required after changing this capability, since already-open tasks retain their previous tool catalog.
  • Consider inferring this capability when a custom provider uses OpenAI authentication and the default compatible OpenAI endpoint, or provide another supported way to preserve all built-in OpenAI capabilities while selecting HTTPS-only transport.

Additional information

The current documentation now describes model_providers.<id>.supports_standalone_web_search and notes that standalone Search remains under development:

PR #34846 intentionally added the opt-in capability with a default of false. This report is therefore not claiming that the key is undocumented; it is about the lack of an effective-state diagnostic when an explicitly enabled global Search mode is silently gated off.

Related but distinct reports found during duplicate search:

  • #34956 requests selecting the Search backend independently from the active model provider.
  • #28954 concerns native Search events with OSS/local providers.
  • #27381 requests an HTTPS-only transport option for the built-in provider.

No existing issue found in open or closed search reports this exact configuration mismatch and verified before/after behavior.

View original on GitHub ↗