Codex Desktop macOS: Azure gpt-5.6-sol automations fail because bootstrap output has no call_id

Summary

On macOS, Codex Desktop cron automations using an Azure/OpenAI-compatible Responses provider and gpt-5.6-sol fail before the saved prompt reaches the model.

The app-server starts the automation turn by injecting a standalone function_call_output for codex_app/automation_update with both id: None and call_id: None. Azure rejects the Responses request with HTTP 400:

Invalid Value: 'input.call_id'. Function call output requires call_id.

This is related to #41690, but this reproduction is on macOS with Azure and affects multiple unrelated production automations, not only the reported Windows/DeepSeek configuration.

Environment

• Codex Desktop: 26.825.51511 (build 7377)
• Bundled Codex CLI/app-server: 0.151.0-alpha.7.2
• OS: macOS 26.6.2, Apple Silicon
• Model: gpt-5.6-sol
• Provider: Azure OpenAI-compatible endpoint (hostname redacted)
• Provider auth: environment-variable API key
• wire_api = "responses"
• Automation kind: standalone local cron

The Azure API key, endpoint hostname, local username, project names, and production prompt contents are intentionally omitted.

Minimal reproduction

Create an active local automation with:

kind = "cron"
prompt = "say hi to me"
rrule = "RRULE:FREQ=MINUTELY;INTERVAL=1"
model = "gpt-5.6-sol"
execution_environment = "local"

Use a custom provider configured as:

model_provider = "azure"

[model_providers.azure]
name = "Azure"
base_url = "https://<redacted>.services.ai.azure.com/openai/v1"
env_key = "<redacted>"
wire_api = "responses"

Wait for the scheduled occurrence.

Actual result

The scheduler creates a run and thread, but the first turn fails in about two seconds. The automation prompt never reaches the model.

The local log shows the exact invalid item:

Submission ... TurnInputRequest {
  input: ResponseItem(FunctionCallOutput {
    id: None,
    call_id: None,
    name: Some("automation_update"),
    namespace: Some("codex_app"),
    output: ...
  })
}

It is immediately followed by:

Turn error: {
  "error": {
    "message": "Invalid Value: 'input.call_id'. Function call output requires call_id.",
    "type": "invalid_request_error",
    "param": "input"
  }
}

Local state after each occurrence:

• automation remains ACTIVE
• last_run_at and next_run_at advance
• an automation_runs row is created
• the run is left as PENDING_REVIEW
• the created thread has systemError
• no assistant response or automation work occurs

The same error occurs for multiple unrelated cron automations with different prompts, projects, and reasoning levels. Normal interactive gpt-5.6-sol turns through the same Azure provider succeed.

Regression evidence

• Last known successful scheduled automation before the desktop update: 2026-08-30 14:46:55 +04
• Codex Desktop application updated: 2026-08-30 21:32:46 +04
• Repeated failed scheduled runs observed after the update, including from 2026-08-31 01:00:39 +04 onward

Changing the RRULE, prompt, workspace, or reasoning effort does not affect the failure.

Verified local workaround

A localhost reverse proxy was placed between Codex and the same Azure endpoint. It performs one narrowly scoped transformation:

• find a function_call_output where name == "automation_update", namespace == "codex_app", and call_id is absent;
• convert that orphan item into a developer message containing the same text;
• forward all other request fields and all responses unchanged.

Results:

1. A synthetic request containing the exact malformed bootstrap shape completed through Azure with gpt-5.6-sol.
2. A real one-minute Codex Desktop cron automation then completed successfully and replied Hi! 👋.

This isolates the failure to the automation bootstrap serialization rather than the scheduler, model deployment, credentials, network, or automation prompt.

Expected behavior

Codex should not send a standalone function_call_output without a valid matching call_id to a strict Responses provider.

Possible fixes:

1. Represent the automation bootstrap as a normal user/developer message.
2. Preserve a real preceding function call and matching call_id.
3. Add provider capability normalization before serializing TurnToolOutput into a Responses request.

At minimum, a failed automation run should be marked failed with the provider error instead of remaining PENDING_REVIEW.

Start in the app-server automation bootstrap path and trace how the standalone automation_update TurnToolOutput becomes a Responses request item. Check the serialization or provider-normalization entry point and the automation run error-state handling. Done means strict Responses providers receive a valid message or matching call_id, and provider failures are recorded as failed rather than PENDING_REVIEW.