Scheduled tasks fail with custom Responses providers when standalone function_call_output omits call_id #42376

Description

Scheduled tasks fail before model output when Codex uses a custom Responses API provider and the task history contains a standalone function_call_output generated by app-server.

The provider rejects the request with:

Invalid Responses API request

This reproduced on Codex desktop 26.901.20858 with bundled CLI 0.153.0-alpha.5 using a custom provider that validates requests against the public Responses API schema.

Reproduction

1. Configure Codex to use a custom Responses API provider.
2. Create a scheduled task in the desktop app.
3. Run the task after the task history includes the standalone result of the app-server automation_update tool.
4. Observe that the provider rejects the request before the model returns any output.

The request history contains an item with this shape:

{
  "type": "function_call_output",
  "id": "fco_example",
  "name": "automation_update",
  "namespace": "codex_app",
  "output": "Automation: Daily brief\n..."
}

The item has no call_id.

Expected behavior

Codex should send a request compatible with the public Responses API schema when using a custom provider. The scheduled task should start normally.

Actual behavior

Codex sends the standalone app-server item unchanged. The custom provider rejects it because the public Responses API schema requires call_id on function_call_output items.

Root cause

Codex intentionally supports a named standalone function_call_output without call_id as an internal app-server extension. The app-server documentation documents this shape and the protocol model makes call_id optional.

In build_responses_request, the non-OpenAI compatibility branch clears internal message metadata and encrypted function arguments. It does not normalize standalone function outputs before sending them across the custom-provider boundary.

This means an internal Codex history item that is valid for app-server is passed to a provider that only accepts the public Responses API schema.

Proposed behavior

For non-OpenAI providers, normalize named standalone FunctionCallOutput items that have no call_id into a public-schema-compatible developer message before serializing the request. Preserve normal paired function outputs and existing OpenAI-provider behavior.

The normalized message should retain the tool name, optional namespace, and textual output so the model receives the same history context without an invalid wire item.

Regression coverage

Can we add tests that verify:

• A non-OpenAI provider receives a developer message instead of a named standalone function output with no call_id.
• A paired function output with a call_id remains unchanged.
• OpenAI providers retain the existing standalone function output behavior.
• Scheduled-task history containing an automation_update result builds a valid custom-provider Responses request.