[codex] recover from SDK NoneType stream errors

[llwhite1]

Summary

Fixes a Codex Responses streaming failure where the OpenAI SDK can raise TypeError: 'NoneType' object is not iterable after the ChatGPT Codex backend has already streamed usable output.

The main Codex runtime and auxiliary Codex adapter now recover only when stream content has already been collected. They synthesize the final response from streamed output items or text deltas so Hermes does not abort after a successful Codex generation.

Root Cause

The chatgpt.com/backend-api/codex streaming path can emit valid response.output_text.delta / response.output_item.done events, but SDK stream iteration or finalization can still raise a NoneType iterable TypeError. Previously Hermes treated that as a non-retryable client error even though the model output was already available.

Validation

• ./venv/bin/python -m pytest tests/run_agent/test_run_agent_codex_responses.py::test_run_codex_stream_recovers_from_iteration_nonetype_after_text_delta tests/run_agent/test_run_agent_codex_responses.py::test_run_codex_stream_recovers_from_finalization_nonetype_after_output_item tests/agent/test_auxiliary_client.py::TestCodexAuxiliaryAdapterTimeout::test_recovers_from_iteration_nonetype_after_text_delta -q
• scripts/run_tests.sh tests/run_agent/test_run_agent_codex_responses.py tests/agent/test_auxiliary_client.py
• Live canary: hermes chat -q "Reply exactly: OK" --provider openai-codex -m gpt-5.5 --ignore-rules -Q

Notes

The recovery remains narrow: unrelated TypeErrors still propagate, and this path only synthesizes a completed response when Hermes has already observed usable streamed output.

[alt-glitch]

Duplicate of #32884 (canonical) — same Codex Responses null output recovery. 10+ competing PRs already open for root cause #11179.

[llwhite1]

Thanks for pointing me to #32884. Agreed that the main agent/codex_runtime.py recovery overlaps with the canonical fix there.

One difference here is that this PR also applies the same recovery pattern to _CodexCompletionsAdapter in agent/auxiliary_client.py, so auxiliary Codex calls do not hit the same SDK NoneType stream failure. If that path is useful, I can split this down to an auxiliary-only follow-up after #32884 lands; otherwise I’m happy to close this as duplicate.

[teknium1]

Closing as duplicate — the Codex null-output fix has been merged via #32963 (cherry-picked from @carltonawong's PR #32890). Thanks for the help during the outage. Closes #11179.