Persisted function_call without matching function_call_output in resumed session

Summary

In a long Codex session, the local rollout persisted assistant function_call items for apply_patch, but no matching function_call_output items were persisted. Every later resumed turn logs:

Function call output is missing for call id: call_gvk6lf6jpooc73szk0ezst3d
Function call output is missing for call id: call_5hln5qbxp2yt3bugadxrtr3x

This leaves the session transcript in an inconsistent Responses-style state and appears to make subsequent long-running turns less stable.

Environment

• Codex CLI version: 0.142.0
• OS: Ubuntu 24.04
• Model provider: custom Responses-compatible provider at http://localhost:8317/v1
• Model: gpt-5.4
• Session source: Codex TUI

Evidence

The local rollout contains an assistant tool call:

{
  "type": "response_item",
  "payload": {
    "type": "function_call",
    "id": "fc_call_gvk6lf6jpooc73szk0ezst3d",
    "name": "apply_patch",
    "call_id": "call_gvk6lf6jpooc73szk0ezst3d",
    "arguments": "{\"mode\":\"patch\",\"path\":\"/home/.../src/pages/PptWorkspacePage.tsx\",\"command\":\"diff --git ...\"}"
  }
}

And later another one:

{
  "type": "response_item",
  "payload": {
    "type": "function_call",
    "id": "fc_call_5hln5qbxp2yt3bugadxrtr3x",
    "name": "apply_patch",
    "call_id": "call_5hln5qbxp2yt3bugadxrtr3x",
    "arguments": "{\"mode\":\"patch\",\"path\":\"/home/.../src/pages/PptWorkspacePage.tsx\",\"command\":\"diff --git ...\"}"
  }
}

But the rollout has no corresponding function_call_output item for either call id.

Every later turn logs:

codex_core::context_manager::normalize: Function call output is missing for call id: call_gvk6lf6jpooc73szk0ezst3d
codex_core::context_manager::normalize: Function call output is missing for call id: call_5hln5qbxp2yt3bugadxrtr3x

Expected behavior

Once Codex accepts and persists an assistant function_call, it should always persist a matching function_call_output, even if:

• tool execution fails,
• argument parsing fails,
• the tool schema is invalid,
• the tool does not exist,
• the local executor aborts before producing normal output.

For example, Codex could persist a synthetic failed tool output:

Tool execution failed before producing output: invalid apply_patch arguments.

Alternatively, when preparing a resumed turn, Codex should repair or omit orphan function calls rather than carrying an inconsistent transcript forward indefinitely.

Actual behavior

The orphan tool calls remain in the session history. Later turns repeatedly log missing function call outputs during context normalization.

Notes

The suspicious part is that the model emitted apply_patch as a JSON function call with fields like mode, path, and command, while the local apply_patch tool appears to expect a freeform patch. Even if those arguments are invalid, Codex should record a tool error output instead of leaving the call without output.

I am not attaching the full rollout because it contains a large amount of private project context, but the issue is reproducible from the transcript invariant above: a persisted assistant tool call without a matching tool output.