Skip to content

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

Open
Open
Bug: web_search_call items in conversation history crash when switching to Ollama/custom provider#24612
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcustom-modelIssues related to custom model providers (including local models)tool-callsIssues related to tool calling

Description

@Game3000-lab
Game3000-lab
opened on May 26, 2026

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

Activity

  1. Game3000-lab
    added
    appIssues related to the Codex desktop app
    on May 26, 2026
  2. github-actions
    added
    bugSomething isn't working
    custom-modelIssues related to custom model providers (including local models)
    tool-callsIssues related to tool calling
    on May 26, 2026

  3. JunJieLiu51520 commented on May 28, 2026

    @JunJieLiu51520
    JunJieLiu51520
    on May 28, 2026

    Root cause analysis

    I traced the conversation history flow from assembly to sending to the model provider.

    The gap in history normalization

    The for_prompt method in ContextManager (codex-rs/core/src/context_manager/history.rs, ~line 119) calls normalize_history, which currently performs three normalizations:

    1. Ensure call outputs exist
    2. Remove orphan outputs
    3. Strip images when unsupported (strip_images_when_unsupported in normalize.rs)

    There is no equivalent step to strip WebSearchCall / WebSearchCallOutput items when the target model doesn't support web search.

    Where supports_search_tool is checked (tool spec only)

    supports_search_tool is only checked in codex-rs/core/src/tools/spec_plan.rs (~line 267), which controls whether the web search tool spec is offered to the model in new turns. It is never used to filter existing history items.

    Similarly, ProviderCapabilities.web_search (codex-rs/model-provider/src/provider.rs, ~line 30) is only checked in spec_plan.rs for tool spec generation, not for history filtering.

    The flow when the bug triggers

    1. User uses an OpenAI model with supports_search_tool: true
    2. Model emits WebSearchCall items that are recorded into history via record_conversation_items
    3. User switches to Ollama/custom provider (supports_search_tool: false)
    4. run_turn calls sess.clone_history().await.for_prompt(...)
    5. normalize_history only strips images, not web search items
    6. Raw WebSearchCall items are sent to Ollama → provider rejects

    Proposed fix

    Following the existing strip_images_when_unsupported pattern in codex-rs/core/src/context_manager/normalize.rs (~line 295-345), add a strip_web_search_when_unsupported function:

    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 { .. }));
}

    Then update for_prompt signature to also accept supports_search_tool: bool and call this new function in normalize_history. Call sites in turn.rs (~lines 234, 953), compact.rs, compact_remote.rs, compact_remote_v2.rs, and prompt_debug.rs would pass turn_context.model_info.supports_search_tool.

    A more comprehensive approach would bundle input_modalities, supports_search_tool, and image_generation capability into a ModelCapabilitiesFilter struct to avoid continuously expanding the function signature — and also cover ImageGenerationCall filtering for providers where image generation is unsupported.

    Happy to submit a PR if the team would like me to implement this fix.

  4. pczerkas
    added a commit that references this issue on Jul 9, 2026

    docs: expand README with usage and configuration guide

    c67510c
  5. jisunchoii
    added a commit that references this issue on Jul 12, 2026

    refactor(responses): drop LiteLLM bridge, direct AIServices Responses…

    ac490f3

  6. radix commented on Aug 21, 2026

    @radix
    radix
    on Aug 21, 2026

    FWIW I'm getting this even without starting on an OpenAI model. It happens even when I start a fresh codex thread on ollama and get it to do some web searches. When it hits "Optimized the conversation" I get this error:

    {"error":{"message":"input[42]: unknown input item type: "web_search_call" (ref: 08ef8219-c120-48a6-a404-5943addac212)","type":"invalid_request_error","param":null,"code":null}}

  7. pczerkas
    added a commit that references this issue on Sep 21, 2026

    docs: expand README with usage and configuration guide

    f11cae5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcustom-modelIssues related to custom model providers (including local models)tool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions