responses.stream crashes with TypeError: 'NoneType' object is not iterable when server emits response.completed with output=None

[fauzandotme]

Confirm this is an issue with the Python library and not an underlying OpenAI API

• This is an issue with the Python library

Describe the bug

client.responses.stream(...) raises TypeError: 'NoneType' object is not iterable when the server emits a response.completed event in which response.output is None. The SDK's accumulator unconditionally calls parse_response() on the completed event, and parse_response does for output in response.output: without tolerating None.

I hit this against https://chatgpt.com/backend-api/codex/responses (the ChatGPT Codex backend used by Codex CLI / IDE integrations and OAuth-token clients). On that backend, the real output items are delivered as preceding response.output_item.done events, and the final response.completed event carries output=None. The official api.openai.com/v1/responses endpoint populates response.output in the completed event, so this only reproduces against the Codex backend.

To Reproduce

Minimal reproducer (requires a ChatGPT Codex OAuth access token; the same client config Codex CLI uses):

from openai import OpenAI

client = OpenAI(
    api_key="<codex-oauth-access-token>",
    base_url="https://chatgpt.com/backend-api/codex",
)

with client.responses.stream(
    model="gpt-5.5",
    input=[{"role": "user", "content": "hello"}],
    instructions="You are helpful.",
    store=True,
    reasoning={"effort": "medium", "summary": "auto"},
    include=[],
    tool_choice="auto",
    parallel_tool_calls=True,
    prompt_cache_key="repro",
) as stream:
    for _ in stream:
        pass
    stream.get_final_response()

Traceback:

File ".../openai/lib/streaming/responses/_responses.py", line 49, in __iter__
  for item in self._iterator:
File ".../openai/lib/streaming/responses/_responses.py", line 57, in __stream__
  events_to_fire = self._state.handle_event(sse_event)
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

Code snippets

The fix is a one-line defensive change in openai/lib/_parsing/_responses.py:

- for output in response.output:
+ for output in (response.output or []):

I've applied this locally and the stream completes cleanly; the actual output is still recoverable from the prior response.output_item.done events (which is how the Codex backend delivers it in the first place).

OS

macOS 15 (Darwin 25.4.0)

Python version

Python 3.11

Library version

openai==2.24.0

[brucexu-eth]

Confirming another reproduction of this from a Hermes Agent gateway setup. Sanitized details:

• openai Python SDK: 2.24.0
• Provider/backend: OpenAI Codex-compatible Responses endpoint (chatgpt.com/backend-api/codex)
• Model observed: gpt-5.5
• Failure mode: multiple normal gateway/cron turns failed before application-level response handling with:

TypeError: 'NoneType' object is not iterable\n```\n\nAt the application layer this appeared as a non-retryable client error with no HTTP status. The failures were not tied to a specific prompt or user data; simple follow-up turns and scheduled jobs both hit it after the stream request was created.\n\nA local Hermes-side mitigation that helped was to treat this specific `TypeError` from `responses.stream()` as a recoverable Codex stream-parser failure and fall back to the raw `responses.create(stream=True)` recovery path, where streamed output items can be collected/backfilled. Also worth defensively stripping `tools=None` before calling `responses.stream()`, because SDK 2.24.0 also iterates `tools` eagerly when that kwarg is present as `None`.\n\nNo personal paths, chat IDs, prompts, or account identifiers included here, but this confirms the same issue in a live gateway environment.

[brucexu-eth]

Follow-up after testing the mitigation in a Hermes Agent integration.

There appear to be two adjacent failure paths that surface the same user-visible error:

1. responses.stream() / stream accumulation raises TypeError: 'NoneType' object is not iterable when the terminal response has output: null.
2. If an application receives or constructs a terminal response object with output=None, later access to the SDK-provided response.output_text helper/property can also raise the same TypeError during application-level normalization.

Sanitized environment where this was observed:

• openai Python SDK: 2.24.0
• Responses backend: Codex-compatible endpoint
• Model observed: gpt-5.5
• App: Hermes Agent gateway using Responses streaming

The Hermes-side defensive patch that stopped the error from leaking to chat was:

• strip tools=None before calling responses.stream()
• treat terminal response.output is None the same as an empty output list and backfill from streamed response.output_item.done / response.output_text.delta events
• guard reads of response.output_text because that property can itself throw this TypeError when the underlying output is null

No personal paths, chat IDs, prompts, or account identifiers included here.

[Chosen9115]

Confirming the same crash on a newer SDK — bug persists across at least the 2.24.0 → 2.32.0 range.

• openai Python SDK: 2.32.0 (verified from openai import __version__)
• Backend: chatgpt.com/backend-api/codex/responses
• Model: gpt-5.5
• Auth: ChatGPT Plus plan OAuth (chatgpt-account mode)
• Trace (deepest frame):

File ".../openai/lib/_parsing/_responses.py", line 61, in parse_response
    for output in response.output:
TypeError: 'NoneType' object is not iterable

In our case the failure ran from a long-running session (~168 messages in input[]) but a fresh session also reproduces it on first call. A 1-character guard at parse_response's line 61 — for output in (response.output or []): — restores normal operation; the SDK's own normalizer downstream already handles empty-output gracefully.

[siyu-hu]

Confirmed same crash in a Hermes Agent gateway setup. Sanitized details:

• openai Python SDK: 2.24.0
• Backend: chatgpt.com/backend-api/codex/responses
• Model: gpt-5.4
• Deepest frame: _parsing/_responses.py:61 — for output in response.output: → TypeError: 'NoneType' object is not iterable

The root cause is the Codex backend's response.completed SSE event no longer includes output (now null), and the SDK parser doesn't guard against None. The one-character fix for output in (response.output or []): at line 61 restores normal operation.

Hermes Agent has a defensive workaround merged via NousResearch/hermes-agent#33450 that catches this TypeError upstream and backfills from collected stream events, but the SDK itself should be fixed here.

As a regression test sketch: mock a response.completed event where response.output = None and assert parse_response() returns an empty output list instead of raising.