[Provider compatibility] ollama-native rejects Codex exec histories with more than one output per call, breaking routed compaction #6574

Client or integration

Codex App

Provider or upstream service

ollama-cloud (provider adapter: "ollama-native"), observed with ollama-cloud/deepseek-v4.1-flash. The failing function serves every routed Ollama model.

OpenCodex version

Observed on 2.75.0. Reproduced offline on dev 33185c2 (2.78.0).

Endpoint or capability

POST /v1/responses: remote compaction turns routed by compactionRouting, and any ordinary routed turn that replays Codex code-mode exec history.

Current behaviour

One Codex code-mode exec call can leave more than one custom_tool_call_output with the same call_id in the history:

• When the cell outlives yield_time_ms, Codex records the yield marker (Script running with cell ID N ...), and each notify() call adds another output for the same call_id.
• A still-running cell can record its notify() output after later items, for example after a wait function call and its function_call_output.

buildNativeMessages() rejects both shapes before anything is sent upstream (400, failureStage: headers-only):

• adjacent outputs: ollama-native duplicate tool result for <id>
• a late output after another call's batch: ollama-native tool result <id> has no originating call

The damage is largest with compactionRouting. When compaction for every session goes to an Ollama Cloud model, a session whose history contains such an exec call can no longer compact. Codex reports Error running remote compact task, and a retry fails the same way because the history does not change. On one installation, 3 of 49 routed compaction attempts over two days failed like this. The other 46 succeeded, with inputs of 340k to 590k tokens.

The anthropic, google and openai-chat adapters build a request from the same parsed history. Anthropic and Google pair the first result with its call and carry the extra outputs as explicit orphan-result text.

Expected behaviour

ollama-native should not fail a request just because Codex recorded more than one output for one exec call. Two acceptable behaviours:

• Merge additional outputs for a call into its result, as fix(kiro): coalesce adjacent outputs without losing tool identity #3750 did for Kiro in the adjacent case.
• Keep the first result paired and carry extra or late outputs as explicit user-side text, which is what the anthropic and google adapters already do.

A result whose call id never appeared in the history can stay an error if that is the intended policy. A late or additional output for a call that did appear earlier should not fail the request.

Minimal redacted request or reproduction

Run from the repository root on dev (no network, no credentials):

import { parseRequest } from "./src/responses/parser";
import { createOllamaNativeAdapter } from "./src/adapters/ollama-native";
import { createAnthropicAdapter } from "./src/adapters/anthropic";

const user = (text: string) => ({ type: "message", role: "user", content: [{ type: "input_text", text }] });
const execCall = (id: string) => ({ type: "custom_tool_call", call_id: id, name: "exec", input: "notify('progress')" });
const execOut = (id: string, output: string) => ({ type: "custom_tool_call_output", call_id: id, output });
const waitCall = (id: string) => ({ type: "function_call", call_id: id, name: "wait", arguments: JSON.stringify({ cell_id: "31" }) });
const waitOut = (id: string, output: string) => ({ type: "function_call_output", call_id: id, output });
const tools = [
  { type: "custom", name: "exec", description: "Run JavaScript" },
  { type: "function", name: "wait", description: "Wait on a yielded exec cell",
    parameters: { type: "object", properties: { cell_id: { type: "string" } }, required: ["cell_id"] } },
];
const yieldMarker = "Script running with cell ID 31\nWall time 31.0 seconds\nOutput:\n";
const shapes: Record<string, unknown[]> = {
  control: [user("start"), execCall("call_A"), execOut("call_A", "done"), user("continue")],
  adjacent: [user("start"), execCall("call_A"), execOut("call_A", yieldMarker), execOut("call_A", "progress 1"), user("continue")],
  late: [user("start"), execCall("call_A"), execOut("call_A", yieldMarker),
    waitCall("call_B"), waitOut("call_B", "Script completed\nOutput:\n"), execOut("call_A", "progress 2"), user("continue")],
};
const base = { authMode: "key", apiKey: "test-key", liveModels: false, models: ["deepseek-v4.1-flash"] } as any;
for (const [name, input] of Object.entries(shapes)) {
  const parsed = parseRequest({ model: "deepseek-v4.1-flash", stream: true, input, tools });
  for (const [label, adapter] of [
    ["ollama-native", createOllamaNativeAdapter({ ...base, adapter: "ollama-native", baseUrl: "https://ollama.com/v1" })],
    ["anthropic", createAnthropicAdapter({ ...base, adapter: "anthropic", baseUrl: "https://api.anthropic.com" })],
  ] as const) {
    try { await adapter.buildRequest(structuredClone(parsed)); console.log(name, label, "ok"); }
    catch (e: any) { console.log(name, label, "THROWS", e.message); }
  }
}

Output on 33185c2. The google and openai-chat adapters also return ok for every shape.

control ollama-native ok
control anthropic ok
adjacent ollama-native THROWS ollama-native duplicate tool result for call_A
adjacent anthropic ok
late ollama-native THROWS ollama-native tool result call_A has no originating call
late anthropic ok

The real history that failed had both shapes in one call: yield marker, notify() output, a wait call and result, then another notify() output for the first call.

Actual response or error

Error running remote compact task: {"error":{"message":"ollama-native duplicate tool result for toolu_<redacted>","type":"invalid_request_error","code":"invalid_request_error"}}

Usage log for the routed attempt: status 400, adapter ollama-native, failureStage headers-only, failureCause payload-rejected, sendCount 0.

Upstream documentation

No public Ollama specification covers more than one tool message per tool_call_id. The concrete client requirement is the Codex code-mode exec output sequence (notify() and yielded cells), the same requirement as #3734.

Suggested mapping or implementation notes

In buildNativeMessages():

• A toolResult for a call in the open batch that already has a result: append its content to that result in input order and keep error status if any part is an error (the fix(kiro): coalesce adjacent outputs without losing tool identity #3750 rule).
• A toolResult whose call id was issued in an earlier, already settled batch: emit it as explicit user-side text with a marker, as the anthropic adapter does ([tool_result without adjacent tool_use: ...]), instead of throwing.
• Keep the error for ids that never appeared in the history, if that policy should stay.

The existing tests a duplicate result for the same call is still refused, duplicate results remain rejected while commentary holds an unresolved batch and a result cannot cross a subsequent tool-call batch encode the current refusal, so this is a deliberate policy change for those cases.

Additional context and attachments

• [Kiro] Multiple outputs for one Codex exec call produce duplicate toolResult entries #3731 / [Kiro] Multiple outputs for one Codex exec call produce duplicate toolResult entries #3734: the same Codex shape on Kiro. fix(kiro): coalesce adjacent outputs without losing tool identity #3750 fixed adjacent outputs there; a late output after another call's result is still rejected by that rule.
• [Provider compatibility] ollama-native rejects a Codex replay whose tool result arrives after an injected mid-turn developer message #4842: an ollama-native replay-ordering fix for injected developer messages.
• Workaround in use: avoid notify() in code-mode cells, or route compaction to a provider whose adapter accepts this history.

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.