[Provider] kimi: no requiresAdjacentResponsesToolResults → 400 when hook-injected developer context splits a tool call from its result #4726

Client or integration

Codex App (desktop). Also reproduced with a direct HTTP client against the local proxy, so this is not client-specific.

Provider or upstream service

kimi — Kimi Code Plan (OAuth, authMode: "oauth"), used over the Responses wire (adapter: "openai-responses", baseUrl: https://api.kimi.com/coding/v1).

OpenCodex version

2.56.0 (npm @bitkyc08/opencodex@2.56.0), macOS (arm64), default provider kimi. Behaviour is identical on main as of this report: the only requiresAdjacentResponsesToolResults: true in the registry is DeepSeek's.

Endpoint or capability

/v1/responses → Kimi https://api.kimi.com/coding/v1/responses, tool calls (tool result adjacency).

Current behaviour

Kimi's Responses endpoint requires a tool result to follow its call immediately. When any other item sits in between — most commonly hook-injected developer context such as LSP diagnostics — Kimi rejects the whole request with HTTP 400:

Invalid request: an assistant message with 'tool_calls' must be followed by tool
messages responding to each 'tool_call_id'. The following tool_call_ids did not
have response messages: exec:0

OpenCodex already implements exactly this repair — normalizeResponsesToolResultAdjacency() in src/adapters/openai-responses/tool-output-recovery.ts — but it is gated per provider in src/adapters/openai-responses/passthrough.ts:

if (provider.requiresAdjacentResponsesToolResults === true) {
  outBody = normalizeResponsesToolResultAdjacency(outBody);
}

That flag is seeded only by the DeepSeek registry entry (src/providers/registry/entries-core.ts, the requiresAdjacentResponsesToolResults: true line whose comment cites "DeepSeek rejects a valid Codex continuation when hook-provided developer context splits a call from its result (#1292)" — the identical failure shape).

No Kimi entry carries it:

• entries-core.ts → id: "kimi" (adapter: "openai-chat") — no adjacency flag;
• entries-extended.ts → id: "kimi-code" (adapter: "openai-chat") — no adjacency flag;
• there is no Kimi entry on the Responses wire at all, so a user who switches Kimi to adapter: "openai-responses" (the same hand-configuration pattern the registry comment at entries-extended.ts acknowledges for other providers) inherits no adjacency normalization and every affected session 400s permanently, because statelessResponses: true replays the broken history on every turn.

Workaround currently applied locally: "requiresAdjacentResponsesToolResults": true in the kimi provider block of config.json — this resolves it (see verification below).

Expected behaviour

The kimi provider should get the same adjacency normalization DeepSeek gets, i.e. the registry entry should set:

requiresAdjacentResponsesToolResults: true,

The flag is inert for chat-wire bodies (it is only read in the openai-responses adapter path), so it is safe on the current openai-chat entries and would also be correct if a Kimi Responses-wire entry is added later.

Minimal redacted request or reproduction

Sent to the local proxy (loopback bind, no token required). Tool declared as the client declares Codex code mode (custom/exec), which the routed path lowers to a function.

{
  "model": "kimi/k3-256k",
  "stream": false,
  "max_output_tokens": 16,
  "tools": [{
    "type": "custom",
    "name": "exec",
    "description": "code mode exec",
    "format": { "type": "grammar", "syntax": "lark", "definition": "start: /[\\s\\S]+/" }
  }],
  "input": [
    { "type": "message", "role": "user", "content": [{ "type": "input_text", "text": "reply with the single word ok" }] },
    { "type": "custom_tool_call", "call_id": "exec_900_ocxtest", "name": "exec", "input": "text('hi')" },
    { "type": "message", "role": "developer", "content": [{ "type": "input_text", "text": "[hook] LSP diagnostics: none" }] },
    { "type": "custom_tool_call_output", "call_id": "exec_900_ocxtest", "output": [{ "type": "input_text", "text": "hi" }] }
  ]
}

curl -s -o out.json -w '%{http_code}' -X POST http://127.0.0.1:10100/v1/responses \
  -H 'content-type: application/json' --data-binary @body.json

Deterministic contrast, same body except the two lines noted:

So the variable is purely the intervening item.

Actual response or error

HTTP/1.1 400
{"error":{"code":"invalid_request_error","message":"Invalid request: an assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: exec:0", "type":"invalid_request_error"}}

Note on the id: the request above uses call_id: "exec_900_ocxtest", yet Kimi reports exec:0. The <tool-name>:<ordinal> form is Kimi's own label for the call, not something OpenCodex rewrote. Real sessions show the same form (exec:17, collaboration__spawn_agent:0), which may be worth knowing when triaging similar reports.

Upstream documentation

No public specification documents this adjacency requirement for the Kimi Responses endpoint — Kimi Code Plan's documented surface is the Chat endpoint (https://platform.kimi.com/docs/api/chat, as cited in the registry entry). The requirement is therefore evidenced by the reproduction above (the 400 comes from https://api.kimi.com/coding/v1/responses), and by the fact that the same shape already required a workaround for DeepSeek in this repo.

Suggested mapping or implementation notes

• Minimal: add requiresAdjacentResponsesToolResults: true to both Kimi registry entries (kimi, kimi-code).
• Optional hardening: consider deriving the flag from the wire/capability rather than a hand-seeded entry, since providers whose Responses implementation is OpenAI-compatible-but-stricter will keep hitting this (the same class already produced [Provider compatibility] DeepSeek V4 Flash returns 400 when developer message is interleaved between function_call and function_call_output #1292-style workarounds).

Additional context and attachments

Real-world trigger in Codex App: the desktop LSP hook inserts a developer message ("LSP diagnostics after editing …") between a code-mode exec call and its result. The session then 400s on every subsequent turn while the model is Kimi; switching the same thread to DeepSeek (which has the flag) resumes normally — consistent with the flag being the only difference.

Local verification after applying the flag to the kimi provider config on a stock 2.56.0 install (installed src/ is byte-identical to the published 2.56.0 tarball): the repro body above returns 200, with the tool result reordered adjacent to its call. Restart + /healthz clean.

Checks

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