›_ Codex Issues
Codex Issues / #28954

OSS local provider: web_search produces zero web_search events on 0.141.0

Open 💬 4 comments Opened Jun 18, 2026 by SproutSeeds

What version of Codex CLI is running?

codex-cli 0.141.0

codex doctor --json reports:

  • codexVersion: 0.141.0
  • install context: standalone Windows x86_64
  • current executable: C:\Users\codyr\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
  • PATH codex #2: older WinGet link for 0.140.0, but the standalone 0.141.0 binary is first on PATH

What subscription do you have?

Not applicable to the repro. This is codex exec --oss --local-provider ollama against local UMBRA Ollama models.

Which model were you using?

Reproduced with:

  • qwen3-coder:30b
  • devstral-small-2:24b

Both are served by Ollama and invoked through Codex OSS mode.

What platform is your computer?

Windows 11 Professional x64 on the remote machine running Codex:

Windows 10.0.26200 (Windows 11 Professional) [64-bit]

The harness is launched over SSH from macOS, but Codex itself runs on the Windows host.

What terminal emulator and version are you using?

Non-interactive SSH into Windows PowerShell. The benchmark uses codex exec, not the interactive TUI.

Codex doctor report

Available on request. Relevant non-secret summary:

  • install: ok
  • runtime provenance: 0.141.0, standalone, windows-x86_64
  • mcp servers: 0
  • network env: ok, no proxy vars
  • default user CODEX_HOME has API-key auth warnings because that profile contains a dummy OpenAI key, but this repro uses CODEX_HOME=.codex-oss-umbra and --oss --local-provider ollama.

What issue are you seeing?

When codex exec is run in OSS local-provider mode with web search enabled/configured, local models do not produce a native Codex web_search event. The run exits successfully, but the JSONL stream contains 0 web_search events.

Observed on 0.141.0:

  • qwen3-coder:30b: score 0.500, web_search_event_count: 0
  • devstral-small-2:24b: score 0.429, web_search_event_count: 0

The failure modes are useful signals:

  • qwen3-coder:30b attempted a blocked shell fetch path rather than using web_search.
  • devstral-small-2:24b attempted an unsupported planner/tool-style call rather than using web_search.

This may be one of two things:

  1. web_search is not intended to be available to OSS/local-provider models. In that case, the CLI/docs should clarify that boundary because --search and web_search = "cached" | "live" look like general Codex CLI capabilities.
  2. web_search is intended to be available in OSS/local-provider mode. In that case, this looks like a custom/local-provider tool-call routing bug, related in spirit to #19871 but focused on Codex's built-in web-search tool rather than MCP tools.

What steps can reproduce the bug?

With Ollama running local models, run:

codex exec `
  --oss `
  --local-provider ollama `
  --model qwen3-coder:30b `
  --sandbox read-only `
  --skip-git-repo-check `
  --ephemeral `
  --cd <empty-temp-workdir> `
  --config 'web_search="cached"' `
  --json `
  --output-last-message last-message.txt `
  "Benchmark instruction: answer the task directly using only the details below. Do not ask for clarification. Do not describe your process.

Use Codex web search for this benchmark. Search for an official OpenAI Codex documentation page that discusses web search or internet access. Return exactly four bullets: searched, title, url, and finding. If web search is unavailable, write NO_SEARCH."

Repeat with:

--model devstral-small-2:24b

Expected repro signal:

  • process exits 0
  • answer is produced
  • JSONL contains no real web_search event
  • local model either refuses, tries shell/network behavior, or attempts an unsupported non-web-search call

In my harness I count web-search events from codex exec --json stdout by looking for web_search in event type, kind, name, tool_name, or nested item/tool/call objects.

What is the expected behavior?

If web_search is supported for --oss --local-provider ollama, an explicit web-search prompt should produce a real Codex web_search event in the JSONL stream, just as cloud Codex runs do.

If web_search is not supported for OSS/local-provider models, Codex should make that boundary explicit in CLI help/docs and ideally expose a clearer machine-readable failure reason so harnesses can route to retrieval-prefetch instead of treating it as a model failure.

Additional information

I have a workaround that succeeds consistently: prefetch trusted sources outside the OSS model, inject them as Source Context, and disable native web search for the model run.

On the same 0.141.0 host:

  • native web_search canary:
  • artifact: 2026-06-18T18-30-09-811Z-web-search
  • qwen3-coder:30b: web_search_event_count: 0
  • devstral-small-2:24b: web_search_event_count: 0
  • source-prefetch workaround:
  • artifact: 2026-06-18T18-31-41-698Z-web-prefetch
  • qwen3-coder:30b: score 1.000, 3 injected sources
  • devstral-small-2:24b: score 1.000, 3 injected sources

That workaround is useful, but it is deliberately a different benchmark: it measures whether an OSS model can use supplied evidence, not whether Codex's native web_search tool works through the local-provider harness.

Related issue: #19871 reports custom/local-provider tool invocation regressions for MCP tools. This report is narrower: built-in Codex web_search under --oss --local-provider ollama on 0.141.0.

View original on GitHub ↗

4 Comments

SproutSeeds · 2 months ago

I traced this to provider capabilities and pushed a candidate patch here:

What it changes:

  • Adds an OSS provider capability override for configured providers named gpt-oss.
  • Keeps namespace tools enabled for OSS providers.
  • Disables hosted web_search and image generation for local OSS providers, so Ollama/LM Studio do not get advertised hosted tools they cannot service.
  • Adds coverage in codex-model-provider plus the hosted-tool planner regression for Ollama with web_search="live".

Validation on fresh upstream main:

  • cargo fmt --check (passes; stable rustfmt prints the existing imports_granularity nightly-only warnings)
  • git diff --check HEAD~1..HEAD
  • just test -p codex-model-provider-info -> 21/21 passed
  • just test -p codex-model-provider -> 40/40 passed
  • just test -p codex-core hosted_tools_follow_provider_auth_model_and_config_gates -> 1/1 passed

Runtime canary on UMBRA with patched Codex + Ollama + qwen3-coder:30b:

  • codex exec --json --oss --local-provider ollama --config 'web_search="live"' ...
  • final response: NO_SEARCH
  • JSONL contained 0 web_search events and 0 unsupported-tool events

I attempted to open this as an upstream PR, but the current GitHub token path is blocked on PR creation for openai/codex; the fork branch above is ready to PR or cherry-pick.

SproutSeeds · 2 months ago

Follow-up after building and verifying a local workaround.

I published the working local/free search adapter here:

https://github.com/SproutSeeds/codex-local-search-adapter

This is separate from the conservative upstream capability-gating patch:

Current read after testing:

  1. Native hosted web_search
  • OSS/local providers should either not be offered hosted web_search, or

Codex needs a local/provider adapter that can service it.

  • The branch above takes the conservative capability-gating path.
  1. Local/free search for OSS models
  • The standalone adapter uses a localhost search broker plus CLI/MCP bridge.
  • On Codex 0.141.0, hosted Codex paths can call the MCP bridge, but

--oss --local-provider ollama can still reject MCP-shaped calls as
unsupported call: mcp__....

  • The reliable route today is:

local model -> Codex shell_command -> local search CLI -> local broker

Verified local canary:

  • A local qwen3-coder:30b Codex run invoked the shell command fallback.
  • The command returned a current/public search result.
  • No ChatGPT auth or hosted OpenAI web-search tool was required.

The reference adapter repo itself was also checked with:

  • npm run check
  • npm run smoke
  • LOCAL_SEARCH_CLI_URL=http://127.0.0.1:8877 ./bin/codex-local-search health
  • LOCAL_SEARCH_CLI_URL=http://127.0.0.1:8878 ./bin/codex-local-search search --response-length short --max-output-tokens 800 sunflower conjecture arxiv

So this issue still looks like a real native hosted-tool capability/routing
boundary for OSS/local providers. The reference adapter is not meant as the
core upstream fix; it is a working local/free workaround and a concrete design
point for anyone who wants local models to search while the upstream behavior is
decided.

ropepop · 1 month ago

Source update, not a runtime retest:

PR #34846 merged on July 23, 2026 and adds supports_standalone_web_search for custom model providers. Current main still stores the active model provider in the search extension and uses that provider's endpoint and authentication for the standalone search request.

This does not appear to give an Ollama or another local model native standalone search unless that same active provider opts in and implements the expected search endpoint. It does, however, clarify the capability boundary described in this issue.

I opened #34956 for the distinct feature of selecting a live-search backend independently from the model provider. That would allow a local or OpenAI model to remain the model provider while a separately configured service supplies live search. I am linking it for architectural overlap, not claiming that these reports have the same root cause.

I have not retested #28954 against a build from current main.

SproutSeeds · 1 month ago

Current-main retesting confirms the default OSS capability bug is still present after #34846.

On upstream main 322d5b96, built-in Ollama has supports_standalone_web_search = false, but its configured runtime provider still inherits web_search = true. A planner regression fails before the fix because hosted web_search remains visible for Ollama.

I refreshed the existing patch so it composes with #34846: configured gpt-oss providers keep namespace tools, disable hosted image generation, and set their web-search capability from the explicit supports_standalone_web_search flag. Built-in Ollama/LM Studio therefore stop advertising hosted search, while an explicitly opted-in custom OSS provider retains the standalone path.

Exact results:

  • before-fix current-main planner regression: fails with hosted web_search visible for Ollama;
  • codex-model-provider-info: 24/24 passed;
  • codex-model-provider: 57/57 passed;
  • targeted codex-core planner regression: passed;
  • UMBRA Ollama qwen3-coder:30b canary: exact NO_SEARCH, with zero web_search, command-execution, or unsupported-tool events.

Updated branch:
https://github.com/SproutSeeds/codex/tree/cody/oss-web-search-28954

Compare:
https://github.com/openai/codex/compare/main...SproutSeeds:codex:cody/oss-web-search-28954

This keeps #34956 separate: choosing an independent search backend is still a larger feature than correcting the built-in OSS provider capability.