OpenAI Codex OAuth path sends non-streaming Responses request; ChatGPT account requires stream=true

[MTG-Thomas]

Summary

After the Codex OAuth work in #667, Stakpak can authenticate with a ChatGPT/Codex OAuth token, list/validate models, and pass autopilot doctor, but task execution fails because the Codex backend sends a non-streaming Responses API request.

Environment

• Stakpak: 0.3.81
• Host: Debian 13 x86_64 VM
• Auth: stakpak auth login --provider openai --profile default --access ... --refresh ... --expiry ... using ChatGPT/Codex OAuth tokens from a ChatGPT account
• Autopilot: stakpak autopilot doctor passes with 0 blocking and 0 warnings

Repro

stakpak -p --max-steps 1 --model gpt-5.2 "Say OK only."
stakpak -p --max-steps 1 --model openai/gpt-5.2 "Say OK only."
stakpak --async --max-steps 2 --model gpt-5.2 "Say OK only."

Actual

All commands that reach the provider fail with:

OpenAI Responses API error 400 Bad Request: {"detail":"Stream must be set to true"}

Model behavior observed:

• gpt-5.2, openai/gpt-5.2, and stakpak/gpt-5.2 reach the Codex provider path and fail with the stream=true error.
• gpt-5.1, gpt-5, and gpt-5-codex are rejected earlier as unsupported for the ChatGPT account path.

Expected

The Codex OAuth backend should either:

1. use the streaming Responses request path for ChatGPT/Codex accounts, including in CLI/privacy/async task execution paths, or
2. fail earlier with an actionable error explaining that the current path does not support ChatGPT account execution.

Notes

A quick source read suggests OpenAIProvider::generate() uses build_responses_request(&request, false) for Responses mode, while OpenAIProvider::stream() uses build_responses_request(&request, true) and already has Codex-specific SSE headers/transport. The runtime error looks like the Codex backend requires that streaming path.

Impact: Codex OAuth can be configured successfully, but no Stakpak task can currently run against a ChatGPT/Codex subscription from this setup.

[MTG-Thomas]

"Writing" a patch for my local version. Will open a draft PR if everything checks out.

[MTG-Thomas]

I also tested a local patch on the same Debian VM. The narrow fix that worked was Codex-backend only: route OpenAIProvider::generate() through the existing streaming Responses transport, then fold stream events back into a normal GenerateResponse.

Validation:

cargo test -p stakai providers::openai::provider::tests

passes locally, including a new mock SSE regression test for Codex generate() using Accept: text/event-stream, OpenAI-Beta: responses=experimental, and stream: true request construction.

After installing the patched CLI on the VM, this live probe succeeded against the ChatGPT/Codex OAuth account:

stakpak -p --max-steps 1 --model gpt-5.2 "Say OK only."

Result:

OK

Session usage showed openai/GPT-5.2, so the stream=true path appears to clear the execution blocker.