openclaw - ✅(Solved) Fix GPT-5.5 OAuth requests fail with 401 Missing bearer auth header [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73559Fetched 2026-04-29 06:18:12
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×2closed ×1commented ×1cross-referenced ×1

After switching from openai-codex/gpt-5.4 to openai-codex/gpt-5.5, OpenClaw accepts UI messages, shows typing / starts an embedded run, but never returns a reply. The run fails with:

401 Unauthorized: Missing bearer or basic authentication in header

This persists even after re-running the OpenAI Codex OAuth login successfully.

Error Message

lane task error: lane=main durationMs=87316 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses" lane task error: lane=session:agent:main:main durationMs=87319 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses" Embedded agent failed before reply: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses

Root Cause

After switching from openai-codex/gpt-5.4 to openai-codex/gpt-5.5, OpenClaw accepts UI messages, shows typing / starts an embedded run, but never returns a reply. The run fails with:

401 Unauthorized: Missing bearer or basic authentication in header

This persists even after re-running the OpenAI Codex OAuth login successfully.

Fix Action

Fixed

PR fix notes

PR #73588: fix(agents): inject resolved OAuth bearer into boundary-aware embedded streams

Description (problem / solution / changelog)

Summary

  • Problem: Sending any UI message while the default model is openai-codex/gpt-5.5 causes the embedded run to fail before reply with unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses. Logs show three matching errors at the lane (lane=main), session-agent (lane=session:agent:main:main) and embedded-agent layers. The resolved Codex OAuth profile is present and validated (openclaw models status reports it as healthy), but the OpenAI Responses HTTP request goes out with no bearer header. The defect is in src/agents/pi-embedded-runner/stream-resolution.ts:124 (pre-fix), inside resolveEmbeddedAgentStreamFn.
  • Root Cause: resolveEmbeddedAgentStreamFn injects the resolved runtime apiKey (the OAuth bearer that the embedded run layer already resolved at src/agents/pi-embedded-runner/run.ts:867 and forwarded as params.resolvedApiKey from src/agents/pi-embedded-runner/run/attempt.ts:1611) only on the provider-owned branch. On the boundary-aware fallback branch — taken whenever a model resolves to a transport-aware API like openai-codex-responses without a registered provider stream — the function simply return boundaryAwareStreamFn; and the resolved key is dropped. createOpenAIResponsesTransportStreamFn at src/agents/openai-transport-stream.ts:738 then constructs the OpenAI client from options?.apiKey || getEnvApiKey(model.provider) || "". For OAuth-only providers like openai-codex there is no env var, options.apiKey was never injected, so the SDK is created with apiKey: "" and OpenAI rejects the request with the 401 above. gpt-5.5 is the first widely-used Codex model that takes this exact boundary-aware:openai-codex-responses lane (the openai-codex plugin does not register a provider-owned stream for the Codex Responses API — see extensions/openai/openai-codex-provider.ts:175), which is why the regression surfaces specifically on the openai-codex/gpt-5.5 upgrade and stays present after re-running OpenAI Codex OAuth login.
  • Fix: Extract the existing resolvedApiKey + run-signal injection logic from the provider-owned branch into a small private helper wrapEmbeddedAgentStreamFn, and apply the same wrapper to the boundary-aware fallback. The provider-owned branch keeps its stripSystemPromptCacheBoundary context normalization (passed in as the optional transformContext callback). The boundary-aware branch deliberately omits that callback because boundary-aware transports (createOpenAIResponsesTransportStreamFn, createAnthropicMessagesTransportStreamFn, etc.) already strip the cache boundary internally — see src/agents/openai-transport-stream.ts:254, :870, :1755 — so re-stripping would be a behavior change. Auth precedence inside the helper is preserved exactly: resolvedApiKey?.trim() wins, then authStorage.getApiKey(provider), then any pre-existing options.apiKey. This is the minimal change that closes the credential gap on every boundary-aware transport (Codex Responses, OpenAI Responses, OpenAI Completions, Azure OpenAI Responses, Anthropic Messages, Google Generative AI) without touching provider plugins, transport internals, OAuth refresh, or the Responses URL.
  • What changed:
    • src/agents/pi-embedded-runner/stream-resolution.ts: refactored resolveEmbeddedAgentStreamFn to delegate to a new private wrapEmbeddedAgentStreamFn helper; the boundary-aware fallback now wraps the resolved transport with the same auth/signal injection that the provider-owned branch already had.
    • src/agents/pi-embedded-runner/stream-resolution.test.ts: added four focused regression tests covering resolved-key injection, authStorage fallback, run-signal forwarding, and cache-boundary preservation on the boundary-aware fallback path. Existing tests (provider-owned auth/signal, fallback shape labels) are unchanged.
  • What did NOT change (scope boundary):
    • No change to extensions/openai/openai-codex-provider.ts, the OpenAI Codex OAuth login flow, model registry, or auth-profiles.json storage.
    • No change to createOpenAIResponsesTransportStreamFn or any of the boundary-aware transports — the apiKey || getEnvApiKey(model.provider) || "" chain remains exactly as it was.
    • No change to provider-owned stream behavior, system prompt cache boundary stripping, WebSocket transport, Anthropic Vertex stream, or the run / attempt control flow.
    • No new public API, no new exports, no any, no widened types — wrapEmbeddedAgentStreamFn is a file-local helper.
    • No change to gateway protocol, channels, plugins SDK, settings schema, or docs/changelog beyond what the regression test asserts.

Reproduction

  1. Configure OpenAI Codex OAuth on main.
  2. openclaw models set openai-codex/gpt-5.5
  3. openclaw models status — confirms the OAuth profile resolves cleanly.
  4. openclaw gateway --port 18789
  5. Send any message in the Control UI.
  6. Observe no assistant reply.
  7. Tail the gateway log:
    grep -Ei 'embedded|lane task|401|unauthorized|responses' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 40
    Expected (current main):
    lane task error: lane=main durationMs=87316 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
    lane task error: lane=session:agent:main:main durationMs=87319 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
    Embedded agent failed before reply: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses
  8. Apply this PR. Repeat steps 4–6 — the embedded run completes and the assistant reply renders normally.

The new unit test injects the resolved run api key into the boundary-aware Codex Responses fallback reproduces the credential drop deterministically without any network or live OAuth.

Risk / Mitigation

  • Risk: The wrapper is now applied to every boundary-aware transport (openai-responses, openai-codex-responses, openai-completions, azure-openai-responses, anthropic-messages, google-generative-ai). For non-OAuth providers that previously relied on getEnvApiKey(model.provider) inside the transport, an empty params.resolvedApiKey and missing params.authStorage would now still produce no options.apiKey — exactly as before. For env-keyed providers that do have an authStorage entry, authStorage.getApiKey(provider) returns the same key the transport would have read from env, so behavior is preserved. The auth precedence (resolvedApiKeyauthStorage → existing options.apiKey) is bit-identical to the provider-owned branch that has been in production since d12987d72.
  • Risk: The boundary-aware path now also forwards the run abort signal when callers do not pass one explicitly, mirroring the provider-owned branch added in d12987d72. Cancellation reaches the OpenAI SDK AbortSignal slot the same way; the existing test does not overwrite an explicit provider-owned stream signal proves explicit caller signals still win, and the new boundary-aware sibling test asserts the same precedence.
  • Mitigation: Four new regression tests in stream-resolution.test.ts lock the contract: resolved-key injection, authStorage fallback, run-signal forwarding, and cache-boundary preservation on the boundary-aware path. The cache-boundary test directly proves the fix did not silently start re-stripping <<openclaw-cache-boundary>> markers (which would corrupt prompt-cache hit rates on Codex Responses). Existing provider-owned coverage is untouched and continues to assert the prior behavior end-to-end.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Gateway / orchestration
  • Auth / tokens
  • Integrations

Linked Issue/PR

Fixes #73559

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-runner/stream-resolution.test.ts (modified, +155/-0)
  • src/agents/pi-embedded-runner/stream-resolution.ts (modified, +57/-31)

Code Example

lane task error: lane=main durationMs=87316 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
lane task error: lane=session:agent:main:main durationMs=87319 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
Embedded agent failed before reply: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After switching from openai-codex/gpt-5.4 to openai-codex/gpt-5.5, OpenClaw accepts UI messages, shows typing / starts an embedded run, but never returns a reply. The run fails with:

401 Unauthorized: Missing bearer or basic authentication in header

This persists even after re-running the OpenAI Codex OAuth login successfully.

Steps to reproduce

Configure OpenAI Codex OAuth auth. Set default model: openclaw models set openai-codex/gpt-5.5 Confirm model/auth status: openclaw models status Start gateway in foreground: openclaw gateway --port 18789 Open Control UI and send any message. Observe that the UI shows activity/typing but no assistant reply. Check logs: grep -Ei 'embedded|lane task|model_fallback|401|unauthorized|responses|reply|stream|completion' /tmp/openclaw/openclaw-2026-04-28.log | tail -n 160 Relevant logs

Expected behavior

Messages sent through the Control UI should complete using the configured OpenAI Codex OAuth profile, as they did previously with gpt-5.4.

Actual behavior

The UI appears to start the request, but the assistant never replies. Logs show the OpenAI Responses API request is made without an auth header:

OpenClaw version

2026.4.26

Operating system

macOS 26.4.1

Install method

npm

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenAI Codex OAuth

Additional provider/model setup details

This was working previously with openai-codex/gpt-5.4 via the OpenAI Codex OAuth route. Then I changed the default model to GPT-5.5 and also updated OpenClaw. After that, UI messages stopped producing replies. I also tried OpenRouter temporarily. That produced a separate provider-routing error: Codex agent harness failed; not falling back to embedded PI backend failed to load configuration: Model provider openrouter not found I then reverted the default model back to: openai-codex/gpt-5.5 and re-ran OpenAI Codex OAuth login successfully, but the 401 Missing bearer or basic authentication error persisted.

Logs, screenshots, and evidence

lane task error: lane=main durationMs=87316 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
lane task error: lane=session:agent:main:main durationMs=87319 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses"
Embedded agent failed before reply: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses

Impact and severity

This looks like the selected OpenAI Codex OAuth profile is present and valid according to models status, but the embedded agent / harness path for openai-codex/gpt-5.5 is not attaching the bearer token to the Responses API request. Possibly related to recent GPT-5.5 / provider routing / OAuth transport changes.

Additional information

lane task error: lane=main durationMs=87316 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses" lane task error: lane=session:agent:main:main durationMs=87319 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses" Embedded agent failed before reply: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses

extent analysis

TL;DR

The issue is likely due to the OpenAI Codex OAuth profile not being properly attached to the Responses API request for the openai-codex/gpt-5.5 model, resulting in a 401 Unauthorized error.

Guidance

  • Verify that the OpenAI Codex OAuth login was successful and the token is valid by checking the openclaw models status output.
  • Check the OpenClaw configuration to ensure that the OAuth profile is correctly set up for the openai-codex/gpt-5.5 model.
  • Investigate recent changes to the GPT-5.5 model, provider routing, or OAuth transport that may be causing the issue.
  • Consider reverting to the previous openai-codex/gpt-5.4 model to see if the issue persists.

Example

No code snippet is provided as the issue seems to be related to configuration and authentication.

Notes

The issue may be specific to the openai-codex/gpt-5.5 model and the OpenAI Codex OAuth profile. Further investigation is needed to determine the root cause.

Recommendation

Apply a workaround by reverting to the previous openai-codex/gpt-5.4 model until the issue with the openai-codex/gpt-5.5 model is resolved. This will allow the system to function as expected while the issue is being investigated.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Messages sent through the Control UI should complete using the configured OpenAI Codex OAuth profile, as they did previously with gpt-5.4.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix GPT-5.5 OAuth requests fail with 401 Missing bearer auth header [1 pull requests, 1 comments, 2 participants]