fix(codex): route hosted web_search requests off the Responses Lite lane

[olegbrok]

Fixes #26.

Problem

On the Responses Lite lane (gpt-5.6-sol / -terra / -luna), every tool is moved into the AdditionalTools developer prefix and the top-level tools param is sent as null. A hosted web_search_20250305 tool therefore never registers upstream:

• Forced search — Claude Code sends tool_choice: {type: "tool", name: "web_search"}, which translates to a top-level web_search tool_choice referencing no registered tool. Upstream rejects with 502 Tool choice 'web_search_preview' not found in 'tools' parameter (the exact error in Tool choice 'web_search_preview' not found in 'tools' parameter. #26).
• Unforced search — the search never engages real web infrastructure, so Claude Code's WebSearch reports zero results / the model claims it has no live search (the lingering symptom in web search result in zero #10).

Registering web_search top-level on the lite lane is not an option — upstream rejects the request with X-OpenAI-Internal-Codex-Responses-Lite only supports function tools, custom tools, and client-executed tool search. (verified empirically).

Fix

• has_hosted_web_search(): requests carrying a hosted web_search_20250305 tool skip the lite lane and use the full Responses API, where web_search registers top-level and executes for real.
• Fail-safe in translate_request: if a web_search tool_choice would be emitted without a registered web_search tool (e.g. anything still on the lite lane), it downgrades to auto — no request shape can reproduce the 502.

Testing

• 3 new unit tests (detection, lite-lane downgrade, full-lane registration); full suite passes (410 passed).
• Verified live against the ChatGPT backend with ANTHROPIC_MODEL=gpt-5.6-sol: forced and unforced WebSearch return real results in Claude Code, e.g. Web Search("raine claude-code-proxy github") → the repo/issues/releases URLs. WebFetch unaffected (client-side) and confirmed working alongside.

🤖 Opened by Barsik — generated with Claude Code

[olegbrok]

One follow-up observation from live testing (kept out of this PR to stay focused on the 502): with the lane routing in place, search result relevance through the Codex backend is noticeably better with external_web_access: true on the web_search tool. With false, queries like raine claude-code-proxy github intermittently return unrelated results; with true the same query comes back with the correct repo and utm_source=openai live-search markers on result URLs. The backend accepts the flag on the full Responses lane. Happy to send that as a separate PR if you want it.

[olegbrok]

Second live finding, same caveat (not in this PR): the Codex backend appears to zero out results when filters are present on web_search. Deterministic repro on gpt-5.6-sol via the full lane — query raine claude-code-proxy repository with allowed_domains: ["github.com"] → 0 results; identical query without filters → the correct repo URL. Locally I've stopped forwarding filters for codex (model self-filters from titles/URLs), which restored domain-scoped searches. Consider whether the README's "including non-empty domain filters" claim still holds for the current backend.

[raine]

Thank you

[thesobercoder]

@olegbrok @raine Not sure if this is happening to you as well, but web searches are returning 0 results. Is this expected after the fix?

[raine]

I'm seeing it also, have to look into it a bit

[raine]

Should be fixed in latest