Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Responses API: unrecognized input item type (e.g. Codex CLI's additional_tools) aborts the whole request instead of being skipped

Open Beginner friendly
  • Is something wrong?
#30,859 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
api, backend

Research direction

Read tools/server/server-chat.cpp, especially server_chat_convert_responses_to_chatcmpl and its handling of unsupported top-level tool types. Follow how unknown input items reach the final else, then check the existing Responses API tests for a suitable place to add a regression fixture with an additional_tools item. Done means that item is skipped with a warning and the rest of the request is processed successfully.

Written by the indexing model from the issue text.

Description

Summary

The Responses API → Chat Completions translation layer in tools/server/server-chat.cpp (server_chat_convert_responses_to_chatcmpl) throws and aborts the whole request when the input array contains an item type it doesn't recognize:

} else {
    throw std::invalid_argument("Cannot determine type of 'item'");
}

This currently breaks every request sent by recent Codex CLI builds, regardless of the model being served, because OpenAI has server-side-enabled a newer Codex capability ("Code Mode" / unified_exec) that adds a new input item to announce an additional tool namespace:

{
  "type": "additional_tools",
  "role": "developer",
  "tools": [
    {
      "type": "namespace",
      "name": "functions",
      "tools": [
        { "type": "custom", "name": "exec", "...": "..." }
      ]
    }
  ]
}

llama-server's parser doesn't know this shape, falls into the final else, and throws, which surfaces to the Codex client as HTTP 400: Cannot determine type of 'item' — failing the request before the model ever sees it.

Notably, the top-level tools array in the same endpoint already has a lenient fallback for unsupported tool types a few lines below (SRV_WRN("unsupported Responses tool type '%s' skipped\n", ...); continue;), so there's existing precedent in this file for "skip with a warning" instead of "abort the whole request" when encountering something from a newer/evolving client that isn't critical to answering the user's actual message.

Why this matters

This isn't model-specific or configuration-specific — any user running llama-server as a Codex CLI backend via the Responses API will hit this the moment Codex (any installed version — this is gated by a server-side feature flag, not the CLI version) decides to send this item. It silently breaks previously-working setups with no local change on the user's side, which makes it hard to diagnose without inspecting the raw request body (llama-server's own verbose logging does not log raw request bodies).

Repro
  1. Run llama-server with --jinja serving any model via the Responses API (/v1/responses), as Codex CLI's wire_api = "responses" config expects.
  2. Use a Codex CLI build where the server-side code_mode_host / unified_exec feature flags are enabled (check with codex features list) and run any codex exec command.
  3. The request fails with HTTP 400: Cannot determine type of 'item'.
Proposed fix

Mirror the existing lenient handling already used for unsupported top-level tools entries: treat unrecognized input item types as skippable instead of fatal.

             } else {
-                throw std::invalid_argument("Cannot determine type of 'item'");
+                const std::string item_type = json_value(item, "type", std::string("<missing>"));
+                SRV_WRN("unsupported Responses input item type '%s' skipped\n", item_type.c_str());
+                continue;
             }

We applied this locally (on commit 2145525a4081d66ff1a87cf43ef809f95a85ac0c) and confirmed it resolves the issue end-to-end with a real Codex CLI session: the additional_tools item is now skipped with a warning log line, and the rest of the conversation (actual user message, tool calls, tool results) is processed normally.

Happy to open a PR with this change (plus a regression test fixture using the additional_tools item shape above) if that's useful — just wanted to flag the root cause and the minimal fix first in case there's a reason it wasn't handled this way already (e.g. if there's a reason some unrecognized item types should be fatal).

Environment
  • llama.cpp commit: 2145525a4081d66ff1a87cf43ef809f95a85ac0c
  • Server: llama-server, started with --jinja
  • Client: Codex CLI (wire_api = "responses"), server-side feature flags code_mode_host / unified_exec
  • OS: Ubuntu 24.04 LTS
Dominant language
C++
Stars
132k
Forks
24.6k
Avg merge
2d 2m
Merged PRs (30d)
498

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ggml-org/llama.cpp

All issues in ggml-org/llama.cpp

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.