OSS local provider: web_search produces zero web_search events on 0.141.0

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.