Bug: `web_search_call` items in conversation history crash when switching to Ollama/custom provider

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.41501 (3044)

What subscription do you have?

Plus

What platform is your computer?

_No response_

What issue are you seeing?

Summary

When a thread uses an OpenAI model (e.g. GPT-5.5) that invokes the web search tool, the conversation history accumulates web_search_call input items. If you then switch to an Ollama/custom model provider in the same thread, Codex forwards the entire history — including those web_search_call items — to the new provider. The provider rejects the request with:

{"error":{"message":"input[14]: unknown input item type: \"web_search_call\"","type":"invalid_request_error","param":null,"code":null}}

Steps to Reproduce

1. Start a Codex thread using an OpenAI model (e.g. GPT-5.5)
2. Ask a question that triggers a web search (e.g. "search the web for today's news")
3. Switch the model to an Ollama/custom provider (e.g. glm-5.1:cloud via Ollama)
4. Send another message in the same thread
5. Request fails with unknown input item type: "web_search_call"

Root Cause

Codex uses wire_api = "responses" for all providers (the "chat" wire API is no longer supported). When sending conversation history to a model provider, Codex does not strip or convert Responses API-specific input item types (web_search_call, web_search_call_output) that the target provider doesn't support.

The model catalog correctly marks supports_search_tool: false for Ollama models, but this flag only prevents Codex from initiating new web searches — it does not cause Codex to strip existing web search items from the history before forwarding.

Expected Behaviour

Codex should filter out web_search_call and web_search_call_output items from the conversation history when sending to a provider where supports_search_tool is false (or where the provider otherwise cannot handle those item types).

Workaround

Start a new conversation thread when switching from an OpenAI model to an Ollama/custom provider. A fresh thread has no web_search_call items in the history.

Environment

• Codex CLI v0.130.0
• macOS (Apple Silicon)
• Custom model provider: Ollama (wire_api = "responses", base_url = "http://127.0.0.1:11434/v1/")
• Model catalog includes supports_search_tool: false and supports_parallel_tool_calls: false

Config Snippet

[profiles.ollama-launch-codex-app]
model = "glm-5.1:cloud"
openai_base_url = "http://127.0.0.1:11434/v1/"
model_provider = "ollama-launch-codex-app"
model_catalog_json = "/Users/username/.codex/ollama-launch-models.json"

[model_providers.ollama-launch-codex-app]
name = "Ollama"
base_url = "http://127.0.0.1:11434/v1/"
wire_api = "responses"

What steps can reproduce the bug?

1. Start a Codex thread using an OpenAI model (e.g. GPT-5.5)
2. Ask a question that triggers a web search (e.g. "search the web for today's news")
3. Switch the model to an Ollama/custom provider (e.g. glm-5.1:cloud via Ollama)
4. Send another message in the same thread
5. Request fails with unknown input item type: "web_search_call"

What is the expected behavior?

Codex should filter out web_search_call and web_search_call_output items from the conversation history when sending to a provider where supports_search_tool is false (or where the provider otherwise cannot handle those item types).

Additional information

_No response_

pub(crate) fn strip_web_search_when_unsupported(
    supports_search_tool: bool,
    items: &mut Vec<ResponseItem>,
) {
    if supports_search_tool {
        return;
    }
    items.retain(|item| !matches!(item, ResponseItem::WebSearchCall { .. }));
}