codex - 💡(How to fix) Fix 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