Intermittent 400 on first gpt-5.6-sol turn: Responses Lite requires reasoning.context=all_turns

[catallactics]

What version of Codex CLI is running?

The failures occurred on codex-cli 0.144.4.

The installation updated to 0.144.5 afterward. I have not yet reproduced the error on 0.144.5, but the relevant Responses Lite request-building code appears unchanged between the two release tags:

rust-v0.144.4...rust-v0.144.5

What subscription do you have?

ChatGPT Pro.

Which model were you using?

gpt-5.6-sol with reasoning effort ultra.

What platform is your computer?

macOS on Apple Silicon.

What terminal emulator and version are you using (if applicable)?

Apple Terminal.

Codex doctor report

The report below was generated after the installation updated to 0.144.5; the observed failures occurred on 0.144.4.

{
  "overallStatus": "warning",
  "codexVersion": "0.144.5",
  "auth": {
    "status": "ok",
    "stored auth mode": "chatgpt"
  },
  "config": {
    "status": "ok",
    "model": "gpt-5.6-sol",
    "model provider": "openai"
  },
  "installation": {
    "status": "ok",
    "install method": "npm",
    "platform": "macos-aarch64"
  },
  "network.provider_reachability": {
    "status": "ok",
    "summary": "active provider endpoints are reachable over HTTP"
  },
  "network.websocket_reachability": {
    "status": "ok",
    "summary": "Responses WebSocket handshake succeeded",
    "auth mode": "chatgpt",
    "wire API": "responses"
  }
}

A brief report containing the error text was also sent through /feedback; it may not have included the full diagnostic context below.

What issue are you seeing?

Codex intermittently rejects a new gpt-5.6-sol turn with this server-side 400:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "unsupported_value",
    "message": "X-OpenAI-Internal-Codex-Responses-Lite requires `reasoning.context` to be `all_turns`.",
    "param": "reasoning.context"
  },
  "status": 400
}

In the clearest occurrence, the startup WebSocket prewarm failed with the same error, followed by the main first-turn request failing. The WebSocket itself connected successfully, so this was not a connection or authentication failure.

The same prompt was submitted again in the same fresh session 42 seconds later. It then succeeded on the same gpt-5.6-sol / ultra settings, produced reasoning output, and invoked a tool. This suggests an intermittent startup/model-metadata/request-construction mismatch rather than a permanently broken session.

The error occurred in multiple independent CLI sessions.

What steps can reproduce the bug?

The issue is intermittent:

1. Sign in to Codex CLI using ChatGPT authentication.
2. Use gpt-5.6-sol with reasoning effort ultra.
3. Start a fresh CLI session.
4. Submit an ordinary first prompt.
5. Observe that startup prewarm and/or the first turn may fail with the Responses Lite reasoning.context 400 above.
6. Wait briefly and submit the identical prompt again in the same session.
7. The retry may succeed without changing the model, reasoning effort, configuration, or authentication.

The prompt was ordinary text and did not specify any Responses API or reasoning parameters.

What is the expected behavior?

When Codex enables X-OpenAI-Internal-Codex-Responses-Lite, every request path—including startup WebSocket prewarm and the first user turn—should consistently send the required reasoning.context: "all_turns" value.

A fresh session should not intermittently fail depending on startup timing or model-catalog state.

Additional information

Local evidence:

• Codex configuration contains model = "gpt-5.6-sol" and model_reasoning_effort = "ultra".
• It does not contain a user override for reasoning.context.
• HTTP reachability, ChatGPT authentication, and the Responses WebSocket handshake all passed codex doctor.
• The identical retry succeeded on the same model and settings.

Possible client-side failure path, based on rust-v0.144.4 source:

• The Responses Lite header is controlled by model_info.use_responses_lite.
• The entire reasoning payload is gated separately by model_info.supports_reasoning_summaries.
• If effective model metadata temporarily has use_responses_lite = true but supports_reasoning_summaries = false, Codex can construct a Lite request without reasoning.context.

I could not capture the raw outbound request body, so the exact mismatch remains unverified.

The main-branch commit below removes that reasoning capability gate and always constructs reasoning parameters, but it is not present in release 0.144.5:

d2d00b6

I searched existing issues for the exact reasoning.context / all_turns error and did not find a matching report. Existing Responses Lite reports such as #31882 cover different providers and different validation errors.