[codex] guard null output_text validation

[CharlonTank]

Summary

• Avoid reading the Responses output_text convenience property unless response.output is a list.
• Treat response.output is None and other non-list shapes as invalid Codex responses so the existing retry/fallback path can handle them.
• Add a regression with an SDK-like output_text property that would otherwise raise TypeError: NoneType object is not iterable.

Why

The main Codex stream path now avoids the known null-output terminal event by consuming SSE events directly. This keeps the later validation fallback defensive if a malformed Response-like object still reaches it, including third-party Responses-compatible providers or future SDK shape drift.

No issue was opened because the broader null-output problem already has existing reports and fixes. This PR is intentionally narrow hardening.

Validation

pytest tests/run_agent/test_run_agent_codex_responses.py -k "empty_output or none_output"

Result: 3 passed, 65 deselected.

[alt-glitch]

Related to merged #32963 which already landed the canonical Codex null-output recovery. This PR adds a narrower defensive guard (checking isinstance(response.output, list) before reading output_text) as additional hardening in the validation fallback path. Complementary safety-net, not a direct duplicate — covers the same code path but with a different defensive strategy.

[teknium1]

Thanks for this — closing as already fixed on main.

The Codex null-output crash (response.completed with output: null from the chatgpt.com backend → TypeError: 'NoneType' object is not iterable → surfaced as "non-retryable HTTP None") is resolved by commits already on main:

• cb38ce28c — drop the SDK responses.stream() helper and consume events directly, rebuilding output from response.output_item.done events so the null terminal-event output is never iterated (refactor(codex): drop SDK responses.stream() helper; consume events directly #33042).
• 43a3f119f — recover Codex streams with null output.
• dc9d677d5 — classify TypeError('NoneType … not iterable') as a retryable provider-shape error so retry/fallback runs instead of killing the turn.

Your fix targets the same path that's now hardened upstream, so there's nothing left to merge here. Your authorship is preserved in your branch; I'm crediting your report in the umbrella issue #33932 (now closed). Appreciate the contribution.