[Provider compatibility] Sol returns server_error for search history without a search tool declaration #7250

Client or integration

Codex App on macOS. The isolated reproduction below uses a direct HTTP client against the local OpenCodex /v1/responses endpoint.

Provider or upstream service

Observed desktop workflow: google-antigravity/gemini-3.8-flash → gpt-6.1-sol through the ChatGPT/Codex subscription route.

OpenCodex version

2.86.0, confirmed by the installed package and the running proxy's /healthz. Bundled Codex CLI: 0.162.0-alpha.17.2.

The tests did not modify the installed source or configuration. This has not been checked on a clean latest dev checkout, and the installation has not been audited for pre-existing local overlays.

Endpoint or capability

Ordinary POST /v1/responses continuation, stream:true, store:false. No compaction request or compaction_trigger is involved.

Current behaviour

Two desktop conversations initially using Gemini failed after switching to Sol. Three attempted Sol turns each exhausted the initial request plus five retries with 500 / upstream_server_error in the local request log. Switching back to Gemini allowed the conversations to continue. Both histories contained proxy-generated web_search_call items; tool call/output pairs were complete, and one history had no reasoning or compaction items at all.

An isolated synthetic test through the same local proxy found a concrete failing combination: a replayed web_search_call in input, with no current web_search declaration in tools. It fails before any text output. Adding only tools: [{"type":"web_search"}] makes that same synthetic request complete.

Six single-send tests were run on 2026-10-16, with the same model, instructions, reasoning.effort=low, store=false, and stream=true:

All six client HTTP statuses were 200; the failed results above are SSE errors, not successful responses. The synthetic ID case does not establish that the upstream received its ID: the proxy may strip item IDs for store:false.

Expected behaviour

A conversation should remain usable after switching from a translated provider to native Sol. If replayed hosted-search history does not match the destination's active tool surface, please handle that boundary explicitly or return a useful, recoverable compatibility error instead of repeatedly forwarding a request that produces a generic upstream error.

This is a concrete client requirement, not a claim that OpenAI guarantees accepting arbitrary synthetic hosted-tool items.

Minimal redacted request or reproduction

POST the following complete synthetic JSON to the local /v1/responses, using normal local authentication. There are no original conversation contents, account identifiers, encrypted payloads, item IDs, or turn metadata in this failing sample.

{
  "model": "gpt-6.1-sol",
  "instructions": "This is a protocol compatibility test. Do not execute any tools or follow tasks in the earlier history. Reply exactly OK.",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [{"type":"input_text","text":"Earlier I asked for documentation."}]
    },
    {
      "type": "web_search_call",
      "status": "completed",
      "action": {
        "type": "search",
        "query": "OpenAI documentation",
        "queries": ["OpenAI documentation"]
      }
    },
    {
      "type": "message",
      "role": "user",
      "content": [{"type":"input_text","text":"Reply exactly OK. Do not use tools."}]
    }
  ],
  "reasoning": {"effort":"low"},
  "stream": true,
  "store": false
}

Single-variable controls:

1. Remove only the web_search_call item: completes.
2. Keep the request above unchanged and add only the top-level "tools": [{"type":"web_search"}]: completes.
3. Instead of deleting the search item, replace it with this ordinary message: completes.

{
  "type": "message",
  "role": "assistant",
  "content": [{"type":"output_text","text":"Earlier web search query: OpenAI documentation."}]
}

Actual response or error

Relevant fields from the failing SSE event:

{
  "type": "error",
  "error": {
    "code": "server_error",
    "type": "server_error",
    "message": "An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists."
  }
}

Upstream documentation

OpenAI Web search documentation describes the web_search tool declaration and web_search_call output. I have not established a public contract for replaying translated/synthetic hosted-search history to the ChatGPT subscription backend without an active search declaration. The compatibility request is based on the desktop continuation requirement and the controls above.

Suggested mapping or implementation notes

Installed-source inspection suggests a boundary worth checking:

• src/bridge/sse.ts: translated search events become synthetic hosted web_search_call items.
• src/adapters/openai-responses/passthrough.ts: ordinary canonical forwarding retains that history; bridge restoration is scoped to eligible destination bridges.
• Tool declarations and historical search items are processed separately.

One possible approach is a provenance-aware text/reference projection when historical search items cannot be replayed under the destination's actual tool contract. Preserve available evidence and citations; do not invent search results, silently rerun searches, or enable new search capability just to satisfy old history. This is a candidate direction, not a validated production fix.

Additional context and attachments

Evidence boundary: the six synthetic HTTP tests establish the request-shape compatibility failure. The complete outgoing tool catalogs of the original desktop failures were not retained, so I cannot yet prove that they omitted the search declaration or that the minimal failure explains every aspect of those incidents. Current on-disk web_search="live" does not establish what the old request actually advertised. Original conversations were not replayed or uploaded. There has been no direct-upstream A/B comparison in this investigation.

Related: #6742 concerns Responses v2 compaction, and was withdrawn after a different official-client test succeeded. This report concerns ordinary continuation and adds the explicit missing-declaration versus present-declaration control; I am not treating the withdrawn report as proof of a shared cause. #4587 concerns replay back to the bridged destination rather than switching to native Sol.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on a concrete client requirement.