Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to 2026.6.1, OpenAI models via ChatGPT OAuth fail: gpt-5.5 requests to openai-chatgpt-responses return HTTP 200 with an empty content-type, which the stream guard rejects as invalid_provider_content_type.

Steps to reproduce

1. Authenticate OpenAI via ChatGPT OAuth only, no OPENAI_API_KEY: openclaw models auth login --provider openai.

2. Set model to openai/gpt-5.5.

3. Run: OPENCLAW_DEBUG_MODEL_TRANSPORT=1 openclaw models status --probe --probe-provider openai.

4. Observe the POST to https://chatgpt.com/backend-api/codex/responses returns HTTP 200 with an empty content-type and the turn fails.

Expected behavior

The probe/turn succeeds and gpt-5.5 returns output, as it did on the prior installed build 2026.5.28 (same OAuth profile and config).

Actual behavior

Request fails. With OPENCLAW_DEBUG_MODEL_TRANSPORT=1:

[model-fetch] response status=200 elapsedMs=680 contentType=     (empty content-type)
[responses] error api=openai-chatgpt-responses model=gpt-5.5 causeCode=invalid_provider_content_type

Retried 3x, all 200/empty content-type. Gateway turns fail identically (FailoverError: network connection error) and fall back to non-OpenAI providers.

OpenClaw version

2026.6.1 (git tag v2026.6.1)

Operating system

macOS (Darwin 25.5.0)

Install method

Source checkout at 2026.6.1 (git tag v2026.6.1)

Model

openai/gpt-5.5

Provider / routing chain

openclaw -> openai (ChatGPT OAuth) -> https://chatgpt.com/backend-api/codex (api=openai-chatgpt-responses)

Additional provider/model setup details

• Auth: ChatGPT OAuth profile only (openai/oauth), no OPENAI_API_KEY. auth list -> openai: [openai/oauth; expires +10d]; probe -> profiles=1 (oauth=1) ok.

• No baseUrl override: models.providers.openai unset; no openai entry in models.json.

• Auth is healthy (not the cause): same OAuth token -> POST /backend-api/wham/usage returns 200 application/json; quota 5h/week 100%.

• A full auth purge + fresh openclaw models auth login --provider openai did NOT fix it.

Logs, screenshots, and evidence

OPENCLAW_DEBUG_MODEL_TRANSPORT=1 openclaw models status --probe --probe-provider openai


[openai-transport] [responses] start api=openai-chatgpt-responses model=gpt-5.5 baseUrl=https://chatgpt.com/backend-api/codex stream=true
[provider-transport-fetch] [model-fetch] start method=POST url=https://chatgpt.com/backend-api/codex/responses proxy=none policy=custom
[provider-transport-fetch] [model-fetch] response status=200 elapsedMs=680 contentType=
  (retried 3x, identical: 200 / empty content-type)
[openai-transport] [responses] error api=openai-chatgpt-responses model=gpt-5.5 causeName=ProviderHttpError causeCode=invalid_provider_content_type message=Connection error.


Healthy control (same token): POST /backend-api/wham/usage -> 200 application/json.

Impact and severity

Affected: all OpenAI (ChatGPT-OAuth) users on 2026.6.1 without an OPENAI_API_KEY fallback.

Severity: High - OpenAI provider fully unusable; only non-OpenAI fallback models work.

Frequency: Always (3/3 probe retries; every gateway turn).

Consequence: gpt-5.5 unavailable; forced onto fallback providers.

Additional information

Code-level analysis (grounded in installed 2026.6.1 source, file:line cited):

• Failing path uses OpenAI SDK responses.create({stream:true}) in dist/openai-transport-stream-*.js (client built ~L2283, defaultHeaders: buildOpenAIClientHeaders). That file sets NO Accept header -> SDK default Accept: application/json on a streaming request.

• Guard assertOpenAISdkStreamContentType (dist/openai-transport-stream-*.js:727) rejects any 2xx whose content-type is not text/event-stream or JSON (including missing).

• Working paths DO set it: buildSSEHeaders (dist/openai-chatgpt-responses-.js:951) -> accept: text/event-stream; image path (dist/image-generation-provider-.js:410) -> Accept: text/event-stream.

Likely fix: send Accept: text/event-stream on the SDK openai-chatgpt-responses stream path, mirroring buildSSEHeaders / the image path.

Regression: last known good = 2026.5.28; first known bad = 2026.6.1.

Note (possibly a separate issue): openclaw proxy run -- openclaw models status --probe --probe-provider openai cannot capture the /codex/responses body - the guarded streaming model-fetch (policy=custom) rejects the loopback debug proxy with SsrFBlockedError; only /wham/usage is captured.