[codex] fix Responses null output recovery

[Goncalo009]

Summary

• omit tools from Codex Responses requests when no tools are present
• recover Codex Responses streams when the SDK sees response.output == null
• apply the same recovery to auxiliary/title-generation Codex streams

Root Cause

OpenAI SDK 2.24 can raise TypeError: 'NoneType' object is not iterable when the Codex backend
emits a terminal Responses stream event whose response.output is null.

Hermes treated that SDK parser failure as a local non-recoverable error, and its backfill path
only handled an empty output list rather than null. This breaks the pure Hermes openai-codex
provider with models such as gpt-5.5, and also surfaces through auxiliary title generation because
it uses the same Codex Responses stream shape.

Fix

• omit the tools key from Codex Responses requests when no converted tools exist
• handle response.output == null the same way as an empty output list
• recover streamed Codex responses after the SDK parser error when text/items were already
  received
• apply the same recovery to the auxiliary Codex adapter

Validation

• 129 affected Codex transport/runtime/auxiliary tests passed locally
• manual Hermes pure openai-codex gpt-5.5 CLI verification
• manual Hermes pure WebUI verification after restart

[alt-glitch]

Duplicate of #32884. Same Codex null output recovery (also includes tools=None guard). Competing with many other PRs for same root cause #11179.

[Goncalo009]

Thanks for pointing that out. If #32884 already covers the same recovery path and the tools=None guard, I'm happy to close this PR as a duplicate.

The issue was actively affecting Codex users, and I opened this after reproducing it locally. If any part of this implementation or the extra tests around auxiliary/title-generation streams is still useful, feel free to fold it into #32884.

[andyylin]

Field-tested the same failure class on a live Hermes gateway using the Codex provider (openai-codex, gpt-5.5).

Observed symptom before the fix:

TypeError: 'NoneType' object is not iterable
Non-retryable error (HTTP None) — trying fallback...

This was triggered after the stream had already emitted usable content; the SDK then failed while materializing the terminal snapshot with response.output == null.

A local hotfix matching this PR's approach — detect the null-output parser TypeError and recover from collected stream output/text before surfacing a provider failure — restored gateway responsiveness. Targeted regression covering the parser-error recovery path passed locally on the affected runtime:

tests/agent/test_codex_ttfb_watchdog.py .... [100%]
4 passed

So the root-cause analysis here matches production behavior. The important part is preserving streamed deltas/items as authoritative when the terminal Responses snapshot is malformed/null, rather than treating the SDK parser crash as an HTTP/provider failure.

[Goncalo009]

Thanks for field-testing this on a live Codex gateway and for spelling out the exact failure mode.

That matches the root cause this PR was aimed at: Codex can stream usable assistant content, then the SDK raises while materializing/parsing the terminal Responses snapshot because response.output is null. The important invariant is exactly the one you called out: preserve collected streamed output items/text as authoritative, instead of surfacing the SDK parser crash as an HTTP/provider failure.

Since this PR is already closed as a duplicate, the active fix path is #32884. This field report is useful production validation for that PR.