parse_response crashes on null output from Codex backend stream

[MikeBrew123]

Bug

parse_response() in openai/lib/_parsing/_responses.py:61 crashes with TypeError: 'NoneType' object is not iterable when response.output is null.

# Line 61 — no null guard
for output in response.output:  # crashes when output is None

Reproduction

When streaming via the ChatGPT Codex backend (chatgpt.com/backend-api/codex) with model gpt-5.5, the response.completed SSE event contains output: null instead of an empty list. The SDK's stream accumulator calls accumulate_event() → parse_response() which iterates response.output without checking for None.

Affected versions: Tested 2.24.0, 2.25.0, 2.30.0, 2.38.0 — all have the same unguarded loop.

Stack trace:

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

# Line 61
for output in (response.output or []):

Environment

• OpenAI Python SDK: 2.24.0–2.38.0
• Python: 3.11.15
• Provider: openai-codex (chatgpt.com/backend-api/codex)
• Model: gpt-5.5
• Client: Hermes Agent v0.14.0

[agoticobran]

We observed the same failure today in a production Hermes Agent Telegram gateway using the ChatGPT/Codex backend.

Environment:

• Provider/backend: openai-codex
• Model: gpt-5.5
• Base URL: https://chatgpt.com/backend-api/codex
• Date observed: 2026-05-27 around 09:00 WEST

Observed impact:

• Requests failed with:
  TypeError: 'NoneType' object is not iterable
• The failure was reported by the application as a non-retryable client error with HTTP None.
• It affected both normal user-triggered requests and cron/gateway-triggered requests.
• We saw it on both large and small contexts, so context size did not appear to be the primary trigger.

Observed root cause:

• The terminal response.completed SSE frame from the Codex backend had response.output = null.
• The SDK then attempted to iterate response.output in the response parser, which raised before the application could access a final response or perform its own fallback/backfill logic.

A local application-level workaround was effective: retain already-received stream items/text deltas and synthesize the final assistant response if the parser crashes on the terminal null-output frame. After applying that workaround, the same gateway/provider/model continued responding successfully, while logs still showed the parser TypeError being recovered from.

So this appears consistent with the parser needing to tolerate response.output is None on terminal streaming frames, or the backend needing to avoid emitting null for that field.

[drrozen-med]

Adding one more downstream confirmation: in drrozen-med/NurseBridge-prep#4136 we traced the same crash end-to-end, patched the SDK line locally to use , and verified the live Codex path no longer crashes when the backend emits on .\n\nSo this seems to be a real backend/parser compatibility issue, not just a one-off repro. The minimal guard at is sufficient to keep the stream alive and lets the app handle the empty terminal response normally.\n\nIf helpful, I can also add a tiny regression test sketch here that mocks a terminal response with .

[drrozen-med]

Correction to my previous comment: the exact guard is for output in (response.output or []):.

I verified this downstream in drrozen-med/NurseBridge-prep#4136 against the live Codex path. With the guard in place, the backend's terminal response.completed payload can carry output: null without crashing the SDK parser, and the application continues normally.

So the minimal fix at openai/lib/_parsing/_responses.py:61 appears sufficient. A small regression test that mocks response.output = None on a completed stream event would be a good addition.