[Bug][死循环]: Codex Desktop tool-call dead loop — OpenAI passthrough drops assistant/tool_call from previous_response_id replay #334

Summary

On OpenCodex 2.7.34 (and still present in 2.7.35 stock relay.ts before a local hotfix), the ChatGPT/OpenAI passthrough path can lose assistant / reasoning / custom_tool_call items when replaying multi-turn tool use via previous_response_id.

Codex Desktop then only re-injects tool results into the next model call. The model does not see that it already decided to call the tool, so it re-plans and re-calls the same tool (e.g. the same web search 10–13 times in one turn). This presents as a hard agent tool dead loop and burns large amounts of tokens.

Environment

• OpenCodex: 2.7.34 → upgraded to 2.7.35 (stock still needs the same fix)
• Codex Desktop / app-server: 0.145.0-alpha.30 (also seen with nearby 0.14x)
• OS: macOS (Apple Silicon)
• Route: Design B loopback inject
  openai_base_url = "http://127.0.0.1:10101/v1"
  model: gpt-5.6-sol (passthrough, not a third-party adapter)
• Effort: xhigh (also reproducible as a failure mode when the state hole exists; not required as the sole cause)

Repro (observed in production)

1. Install/start OpenCodex so Codex points at the local proxy.
2. In Codex Desktop, start a simple research task that needs web search (example: “查一下茅台最新资讯”).
3. Watch a single user turn (turn/start once only).
4. Observe many nearly identical “I’m checking…” assistant plans + repeated web searches, no final answer, until the user aborts.
5. Inspect OpenCodex usage.jsonl: many gpt-5.6-sol / provider=openai requests (HTTP 200) aligned with each re-plan.
6. Inspect ~/.opencodex/responses-state.json during the loop:

Interpretation: each passthrough continuation stores tool results but drops the model’s just-produced decision items (reasoning / message / custom_tool_call). Next expansion of previous_response_id therefore cannot show the model that the search already happened.

Offline sandbox against installed 2.7.34 source (no live model keys required for the state-capture path) reproduced:

• SSE actually emits 3 output items (reasoning + assistant + tool call)
• OpenCodex final capture: output = 0
• After bad replay: only tool returns remain; orphan tool results appear

Root cause (code-level)

Passthrough path strips previous_response_id before forwarding to ChatGPT Codex REST (upstream rejects it), and relies on local responses-state.json expansion as the only continuation mechanism (documented in src/server/responses.ts around the passthrough / rememberResponseState comments).

In src/server/relay.ts, SSE consumption can complete with an empty response.completed.response.output while individual items were already delivered as response.output_item.done. Those done items are not always accumulated into the final response object used by rememberResponseState, so the continuation cache loses assistant/reasoning/tool_call history.

Relevant stock behavior (2.7.34/2.7.35 before hotfix):

• openai-responses adapter strips previous_response_id on forward
• local replay is the only chain continuity for passthrough
• empty completed output + missing accumulation of output_item.done ⇒ broken tool loops in Codex Desktop

Expected behavior

After each model step that emits:

• response.output_item.done for reasoning / message / function_call

…the object recorded for previous_response_id expansion must include those items in order, so the next turn sees:

1. prior assistant plan
2. prior tool call
3. tool result

and can stop instead of re-calling the same tool.

Fix that worked locally

Minimal hotfix in src/server/relay.ts (and any parallel consume path used for inspection/logging):

1. Maintain Map<output_index, item> per SSE stream.
2. On response.output_item.done, store event.item by output_index.
3. On response.completed, if response.output is empty, backfill from the map sorted by index.
4. Ensure both consumeForInspection and consumeForResponseLogMetadata paths use the accumulator before rememberResponseState.

Sketch:

const completedItems = new Map<number, unknown>();

if (event.type === "response.output_item.done") {
  completedItems.set(event.output_index, event.item);
}

if (
  event.type === "response.completed" &&
  Array.isArray(event.response?.output) &&
  event.response.output.length === 0
) {
  event.response.output = [...completedItems.entries()]
    .sort(([a], [b]) => a - b)
    .map(([, item]) => item);
}

Local verification after hotfix:

• Offline regression: related suite 101/101 + new cases for empty-completed backfill
• Live multi-tool chain metrics closed as 1/0 → 2/1 → 3/2 → 3/3 with 0 orphan tool results
• No more “return to first plan / re-run first tool” loops on the same research tasks

Note: upgrading package version alone to 2.7.35 (stock) did not remove the defect; a source-level fix in relay.ts (or equivalent) is required.

Impact

• High: Codex Desktop + OpenCodex OpenAI passthrough + multi-step tools (web search, shell, etc.)
• Symptom: “dead loop” of repeated plans/tools inside one user turn; large token burn; user must abort
• Provider field still shows openai (passthrough), so the bug is easy to mis-attribute to the model alone

Request

Please fix empty response.completed.output handling so output_item.done items are always merged into the continuation state for OpenAI passthrough, with regression tests covering:

1. SSE stream with non-empty output_item.done sequence but empty response.completed.output
2. Multi-tool continuation where tool_call must remain paired with tool_result across previous_response_id expansions
3. No orphan tool results after N continuations

Happy to provide redacted responses-state snapshots / usage timestamps if useful.

Related local notes

• Design B inject (openai_base_url → loopback) is required for this path to be in use.
• This is separate from third-party model ladders (Kimi/Grok reasoning effort UI mapping).