fix(codex_responses): recover from SDK parse_response TypeError when output is None

[domnul-baz]

Summary

Fixes a runtime crash where the openai-codex provider raises TypeError: 'NoneType' object is not iterable mid-stream when the ChatGPT Codex backend emits a response.completed event with output=None (not []).

Refs #5678.

Root cause

OpenAI SDK's parse_response (openai/lib/_parsing/_responses.py:61) iterates response.output without a None guard:

for output in response.output:
    ...

When the backend at chatgpt.com/backend-api/codex emits response.completed with output=None, this crashes inside accumulate_event before Hermes' existing empty-output workarounds (run_codex_stream lines 248-266) can fire — those only handle output == [] after get_final_response(), which never returns because the SDK raises first.

Full traceback (captured from gpt-5.5 Discord conversation):

File "agent/codex_runtime.py", line 196, in run_codex_stream
    for event in stream:
File "openai/lib/streaming/responses/_responses.py", line 248, in handle_event
    self.__current_snapshot = snapshot = self.accumulate_event(event)
File "openai/lib/streaming/responses/_responses.py", line 360, in accumulate_event
    self._completed_response = parse_response(...)
File "openai/lib/_parsing/_responses.py", line 61, in parse_response
    for output in response.output:
TypeError: 'NoneType' object is not iterable

Fix

Catch TypeError in the stream loop. If we have accumulated text deltas and aren't in a tool-call stream, synthesize a SimpleNamespace response from the deltas — mirrors the existing pattern at lines 256-262. If recovery is unsafe (tool calls, or zero deltas), fall back to _run_codex_create_stream_fallback so the outer retry loop has something useful to work with.

Test plan

• Reproduce on gpt-5.5 via Discord gateway with openai-codex provider — confirmed NoneType traceback before patch.
• Apply patch, restart gateway, retry same conversation — confirmed clean response and single WARNING agent.codex_runtime: Codex stream parse_response TypeError (SDK bug on output=None) — recovered by synthesizing response from N streamed deltas (M chars) log line.
• Repro on gpt-5.3-codex, gpt-5.4-mini — same provider, expected same fix coverage.
• Tool-call stream coverage — when has_tool_calls=True, the patch falls through to _run_codex_create_stream_fallback (existing path). Worth a deliberate test if a reviewer can craft one.

Notes

• The title_generator aux client appears to hit the same SDK bug on a different code path — out of scope here, but worth a follow-up patch with the same recovery pattern in the auxiliary client wrapper.
• Local Hermes harness was running into this on every conversation on the ChatGPT Codex backend; this patch unblocks it.

🤖 Generated with Claude Code

[domnul-baz]

Closing as redundant — origin/main already has a more comprehensive fix for the same root cause (_responses_null_output_iterable_error + _codex_backfilled_response + the _codex_stream_last_event_ts watchdog), apparently merged shortly before I cut this branch. My local clone was on a stale feature branch and I missed the merged work when crafting the PR.

Updated locally by pulling agent/codex_runtime.py from origin/main and verifying recovery on the same gpt-5.5 Discord reproducer. Thanks for already shipping the fix.

[alt-glitch]

Duplicate of #32963 (merged) which already landed the same TypeError guard for Codex null-output streams in run_codex_stream(). The merged fix adds except TypeError handling in both the main stream path and the fallback path via _responses_null_output_iterable_error() + _responses_backfilled_response() helpers. This PR is a late-arriving fix for an already-resolved crash. See also #33050 (same late duplicate).