[Bug]: Built-in web_search results never reach anthropic/claude-opus-5-5 under Codex CLI (model repeats steps, invents URLs)

Start by tracing how Codex CLI Responses requests and web_search tool results are translated and replayed for Anthropic models; the issue does not name implementation files or tests. Compare the proxy request and response bodies with the resumed conversation history, then add a regression test for the reported prompt. Done when search results reach the model and the resumed turn can read the recorded URLs.

Client or integration

Codex CLI

Area

Tools / MCP / web search

Summary

With anthropic/claude-opus-5-5 routed through OpenCodex under Codex CLI, the built-in web_search tool never visibly returns results to the model. The codex exec --json stream shows web_search items that carry only a query, and the model's own later messages are consistent with it never having received results: it repeats shell steps it had already run, writes guessed URLs, and, when resumed, says it never searched.

What is measured (details under Reproduction):

• One turn emitted 18 web_search items and 18 identical shell commands; the model's own message says it ran the step "16 times".
• Two shorter runs emitted 6 and 5 web_search items; in both, a resumed turn says no search was performed, although the event stream shows web_search items.
• Each web_search item in the event stream holds only id, type, query, action (query text). No result field is present.

What is not established: whether results are lost in the proxy, never requested from the upstream, or never replayed to the model. codex exec --json may not include results for any provider, so the event stream alone does not prove the model received nothing. The model-behaviour evidence below is the stronger signal. On the same proxy, gpt-6.1-sol was reported to search fine through the native search tool by another measurement campaign; that comparison is not in the files quoted here.

Reproduction

Environment-independent steps (paths are examples):

1. ocx running, Claude account configured, Codex CLI pointed at the proxy.

2. Run a one-shot Codex turn with the built-in web search enabled:

   codex exec -C /tmp/ocx-h23 -m anthropic/claude-opus-5-5 \
     -c model_reasoning_effort=medium --skip-git-repo-check --json \
     "Do exactly these steps in order. 1) Use your web search tool once to search: 문피아 판타지 베스트 2026. 2) Write the URLs of the first three results you received, exactly as returned, into /tmp/ocx-h23/record.json as JSON {\"urls\": [...]} using a shell command. 3) Answer with those three URLs." \
     < /dev/null > /tmp/ocx-h23/t1_events.jsonl
   

3. Resume the same thread (codex exec resume <thread_id> ...) with: "Without searching again, read the file /tmp/ocx-h23/record.json and list its URLs exactly. If the file is missing, say NOT_RECORDED."

4. Count items: python3 -c over the JSONL, counting item.completed with item.type == "web_search".

Observed (OpenCodex 2.87.0, one run each; run-to-run variance was not measured):

Run	web_search items	Shell commands	What the model said
Three-step prompt: 1) search once, 2) run date > step2_done.txt, 3) answer with the first three result URLs (the prompt is from the harness script that produced this run; the events file does not store it). Shell command seen 18 times: date > step2_done.txt && test -f step2_done.txt && echo EXISTS && cat step2_done.txt	18	18, all identical	"I skipped step 1 and ran step 2's command 16 times"
File-record prompt above, turn 1	6	5	Said it wrote guessed URLs (one ending utm_source=openai) before searching, then that the search "returned only one result"
Same, turn 2 (resume, no search requested)	0 new	n/a	"I never called the search tool at all... it was never a search result"

An earlier run labelled pre286 (the exact proxy version is not recorded in the files; I am not claiming 2.84 or 2.86 from them) shows the same pattern: 5 web_search items, then on resume "There is no web search call anywhere in the earlier turn. I made up this URL".

Note the contradiction inside the 2.87.0 file run: turn 1 events contain 6 completed web_search items, yet turn 2 says the search tool was never called. That is consistent with the model never seeing a web_search call/result pair in its replayed history, but I did not inspect the proxy request bodies to confirm.

Event lines (query only, no result):

{"type":"item.completed","item":{"id":"ws_...","type":"web_search","query":"문피아 판타지 베스트 2026","action":{"type":"search","query":"문피아 판타지 베스트 2026","queries":["문피아 판타지 베스트 2026"]}}}

Not measured: OpenCodex 2.88.0 (released after these runs), other Claude models, proxy-side request/response bodies, the web-search sidecar configuration in use, whether the account pool or native Messages lane was serving the request.

I found no existing issue for this path. Related but different: #7250 (Sol server_error for search history), #6621 (batched search truncation, closed), and the merged #7251 / closed #7194 and #7201, which concern a Claude Code client on the translated lane rather than Codex CLI sending Responses requests to a Claude model.

Version

OpenCodex 2.87.0 (ocx --version prints opencodex 2.87.0); Codex CLI 0.163.0 (codex --version prints codex-cli 0.163.0)

Operating system

macOS 26.5.2 (build 25F84, sw_vers)

Provider and model

anthropic / anthropic/claude-opus-5-5 (reasoning effort medium). Comparison reported elsewhere: gpt-6.1-sol on the same proxy.

Logs or error output

The only startup message in the event streams is Codex's "Under-development features enabled: default_mode_request_user_input" warning. No proxy error was captured in these runs, and I did not read the proxy logs. Nothing was saved from ocx status; one run's model reported "ocx status exited null", which I did not verify.

Screenshots and supporting files

None attached. Event streams are available on request; they contain only the query text above and private paths.

Redacted configuration

Not captured.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.