Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: 2026.4.26 — auth resolver fails to attach Authorization header to OpenAI requests; all openai/* and codex/* models 401 with "Missing bearer" [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#74682•Fetched 2026-04-30 06:21:21
View on GitHub
Comments
1
Participants
2
Timeline
8
Reactions
2
Author
anonomouslylearning444anonomouslylearning444
Participants
anonomouslylearning444anonomouslylearning444clawsweeper[bot]clawsweeper[bot]
Timeline (top)
labeled ×2mentioned ×2subscribed ×2closed ×1

On OpenClaw 2026.4.26 with agentRuntime.id=codex, every outbound OpenAI request to https://api.openai.com/v1/responses returns 401 "Missing bearer or basic authentication in header" across both auth modes (api_key via openai:default and OAuth via openai-codex), causing the configured 3-model fallback chain to exhaust on every turn and the agent to surface "Something went wrong" to Telegram.

Error Message

Three log excerpts (all sk-* keys, OAuth tokens, and chat IDs redacted before posting):

  1. Live model_fallback_decision payload (subsystem model-fallback/decision) from
    /tmp/openclaw/openclaw-2026-04-29.log, 2026-04-29T22:29:06.962Z:

{
"event": "model_fallback_decision", "decision": "candidate_failed", "requestedProvider": "openai", "requestedModel": "gpt-5.5",
"candidateProvider": "openai", "candidateModel": "gpt-5.5",
"attempt": 1,
"total": 3, "reason": "auth",
"status": 401,
"errorPreview": "unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f41bd929b694612-DFW",
"fallbackStepFromModel": "openai/gpt-5.5", "fallbackStepToModel": "openai/gpt-5.4-mini",
"fallbackStepFromFailureReason": "auth",
"fallbackStepFinalOutcome": "next_fallback",
"isPrimary": true,
"fallbackConfigured": true
}

The two subsequent attempts (gpt-5.4-mini, then gpt-5.2) emit identical payloads with fresh cf-ray IDs, ending in
fallbackStepFinalOutcome="chain_exhausted".

  1. Aggregate failure line (from same log, 2026-04-29T22:30:15.932Z):

"Embedded agent failed before reply: All models failed (3): openai/gpt-5.5: unexpected status 401 Unauthorized:
Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f41beceeb90f0bd-DFW (auth) | openai/gpt-5.4-mini: ... (auth) | openai/gpt-5.2: ... (auth)"

  1. openclaw doctor output captured 2026-04-28 (on 2026.4.25, prior to the .26 upgrade), excerpt:

"Last gateway error: 2026-04-28T19:26:46.393-05:00 Embedded agent failed before reply: All models failed (8):
openai/gpt-5.4: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f3a2490df9eaefe-DFW (auth) |
anthropic/claude-opus-4-7: failed to load configuration: Model provider anthropic not found (unknown) | anthropic/claude-sonnet-4-6: ... anthropic not found (unknown) |
anthropic/claude-opus-4-5: ... anthropic not found (unknown) |
anthropic/claude-sonnet-4-5: ... anthropic not found (unknown) |
anthropic/claude-haiku-4-5: ... anthropic not found (unknown) |
openai/gpt-5.1-codex: unexpected status 401 Unauthorized: Missing bearer ... (auth) | openai-codex/gpt-5.5: unexpected status 401 Unauthorized: Missing bearer ... (auth)"

This excerpt is the strongest single piece of evidence: it shows the same Missing-bearer 401 affecting both the
api_key path (openai/gpt-5.4, openai/gpt-5.1-codex) and the OAuth path (openai-codex/gpt-5.5) on the same release, in the same run, against the same endpoint.

Full live gateway log and full doctor log available on request.

Impact and severity

Affected users/systems/channels: 1 confirmed user at time of filing. All channels routing through the codex agent runtime are blocked: Telegram (direct lane and cron lane both observed failing — log lanes
"session:agent:main:telegram:direct:..." and "cron-nested" both emit lane-task-error entries with the same FailoverError), and the TUI (the runtime path is shared). Anthropic-routed agents would in principle be unaffected by the 401 itself, but cannot run on the codex runtime because of the unrelated "Model provider anthropic not found" config-load error captured in the doctor log.

Severity: blocks workflow. The agent cannot complete a single turn on any openai-family model. The cron scheduler
retains the jobs but applies error backoff after each failure (cron module log: "cron: applying error backoff" with consecutiveErrors:1, backoffMs:30000), so jobs continue to fire and continue to fail on a 30s-and-growing backoff.

Frequency: every turn, every send, every cron firing, since the bug surfaced. No intermittent successes observed in
the captured logs. The same 401 shape (Missing bearer, /v1/responses) repeats with fresh request IDs and cf-ray IDs every attempt, indicating the request is reliably leaving the machine without an Authorization header (not a transient network issue).

Consequence: every Telegram message produces a "Something went wrong while processing your request. Please try again, or use /new to start a fresh session." reply (telegram sendMessage ok logged at 22:30:16.236Z). Every cron job is delayed by an accumulating backoff. The gateway error log (lane task error entries) accumulates one entry per attempt per lane. No data loss observed in the captured logs; sessions remain queryable. No extra-cost consequence on the api_key path because the requests 401 before any tokens are billed; on the OAuth path the same applies. There is, however, an indirect cost: the consequence of the bug pushed the user to retry across many models and prefixes during diagnosis, and on a separate Anthropic-routed agent (not on this codex runtime) the user reports having exhausted an Anthropic budget to ~$100 during recovery attempts. That last point is grounded in user report rather than in the OpenClaw logs themselves and is included only for triage context, not as a direct claim about this codex-runtime bug.

Additional information

Regression status: confirmed regression, but the exact first-bad version is not directly captured in the logs available. Last-bad observed in logs: 2026.4.26 (live gateway log /tmp/openclaw/openclaw-2026-04-29.log, captured
2026-04-29T22:30:15.932Z). First-bad observed in logs: 2026.4.25 (doctor log /tmp/openclaw-recover/doctor-26.log, captured 2026-04-28T19:26:46.393-05:00, before the .26 upgrade ran). Last-good is not captured in any log on this
system; user report (not log-grounded) places a working state on 2026.3.8 with openai/gpt-5.4 via api_key, but no log line from that working state is available to cite, so this is provided as user-recollection-only context, not evidence.

2026.4.26 release-note line that is a plausible candidate for the regression (verbatim from release notes):
"Plugins/providers: move pre-runtime model-id normalization, provider endpoint host metadata, and OpenAI-compatible request-family hints into plugin manifests so core no longer carries bundled-provider routing tables." The visible
"[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning and the codex/* -> openai/* rewrite both appeared in 2026.4.26 logs but not in the 2026.4.25 doctor log, so this change is the most recent observable on-the-wire change between the two captured releases.

2026.4.26 schema/path change observed on disk: auth-profiles.json moved from ~/.openclaw/agents/auth-profiles.json
(the .25 location, which does not exist on this install) to ~/.openclaw/agents/main/agent/auth-profiles.json (3111 bytes, mode 0600, present and readable). The file is being read on every gateway boot (boot log confirms successful
credential reads for the anthropic profile from the Claude CLI keychain). Whether the openai/openai-codex profiles in this file are being read but not threaded through to the openai-responses provider's HTTP request builder is the suspected failure mode, but I do not have direct evidence to confirm or deny that — only the symptom (request leaves the machine without an Authorization header).

Workaround status: community-reported rollback to 2026.4.23 has been raised by multiple independent users on
r/openclaw as a workaround for the broader 2026.4.24/.25/.26 regression cluster. I have not yet attempted the rollback against this codex-runtime 401 specifically, so I cannot confirm whether 2026.4.23 also exhibits the bug.
NOT_ENOUGH_INFO on whether the workaround applies to this specific issue.

Possibly-related prior issue: an earlier issue covering an OAuth-only Missing-bearer 401 on /v1/responses against
ChatGPT/Codex tokens was reportedly filed against an earlier 2026.3.x release and marked closed. I do not have the issue number directly verified from the GitHub repo at filing time; rather than guess, I am leaving the
cross-reference out and flagging this for the maintainer's search. If the maintainer has triaged similar reports recently, this report differs in that the same Missing-bearer 401 is now also observed on the api_key path (openai/gpt-5.4, openai/gpt-5.1-codex) — not just the OAuth path — which suggests the failure is at the auth-attach step in the openai-responses provider rather than an OAuth-scope mismatch with /v1/responses.

Root Cause

anthropic/* models do not exhibit the 401 (Anthropic auth from the Claude CLI keychain attaches correctly) but cannot be used as a workaround on this runtime — they fail at config-load with "Model provider anthropic not found" because the codex agent runtime does not include an anthropic provider.

Fix Action

Fix / Workaround

The same failure occurred on 2026.4.25 prior to upgrading: an openclaw doctor run on 2026-04-28 19:26 captured "All models failed (8)" with identical 401s for openai/gpt-5.4 (api_key path), openai/gpt-5.1-codex (api_key path), and openai-codex/gpt-5.5 (OAuth path) — all hitting the same /v1/responses endpoint with the same Missing bearer error.
The codex/gpt-5.5 prefix introduced in 2026.4.26 reproduces the same way; the runtime rewrites it to openai/gpt-5.5 before dispatch (visible as requestedProvider="openai" in the model_fallback_decision payload) and emits a separate "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning before the 401 chain begins.

anthropic/* models do not exhibit the 401 (Anthropic auth from the Claude CLI keychain attaches correctly) but cannot be used as a workaround on this runtime — they fail at config-load with "Model provider anthropic not found" because the codex agent runtime does not include an anthropic provider.

Every turn fails. The gateway selects the configured primary model, makes the outbound HTTPS request, and receives a
401 response from api.openai.com without ever attaching an Authorization header. The runtime emits a
model_fallback_decision payload with decision="candidate_failed", reason="auth", status=401, and errorPreview="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
https://api.openai.com/v1/responses, cf-ray: 9f41bd929b694612-DFW". It then steps through both configured fallbacks (openai/gpt-5.4-mini, openai/gpt-5.2), each producing an identical 401 with a fresh cf-ray. After the third candidate fails the chain logs fallbackStepFinalOutcome="chain_exhausted" and emits "Embedded agent failed before reply: All models failed (3): openai/gpt-5.5: ... (auth) | openai/gpt-5.4-mini: ... (auth) | openai/gpt-5.2: ... (auth)". The gateway then sends "Something went wrong while processing your request. Please try again, or use /new to start a fresh session." to the user's Telegram chat (telegram sendMessage ok chat=<redacted>). The cron lane logs "lane task error: ... FailoverError: unexpected status 401 ..." and applies a 30000ms error backoff to the affected job (consecutiveErrors:1, backoffMs:30000). On 2026.4.26 a separate warning fires before the 401 chain begins: "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" — the runtime rejects codex/* prefix strings stored on disk and rewrites them to openai/* before dispatch (visible in the model_fallback_decision payload as requestedProvider="openai" even though agents.list[0].model is "codex/gpt-5.5" on disk).

Code Example

Three log excerpts (all sk-* keys, OAuth tokens, and chat IDs redacted before posting):
                                                                                                                        
  1) Live model_fallback_decision payload (subsystem model-fallback/decision) from                                      
  /tmp/openclaw/openclaw-2026-04-29.log, 2026-04-29T22:29:06.962Z:                                                      
                                                                                                                        
  {                                                      
    "event": "model_fallback_decision",
    "decision": "candidate_failed",
    "requestedProvider": "openai",
    "requestedModel": "gpt-5.5",                                                                                        
    "candidateProvider": "openai",
    "candidateModel": "gpt-5.5",                                                                                        
    "attempt": 1,                                                                                                       
    "total": 3,
    "reason": "auth",                                                                                                   
    "status": 401,                                       
    "errorPreview": "unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
  https://api.openai.com/v1/responses, cf-ray: 9f41bd929b694612-DFW",                                                   
    "fallbackStepFromModel": "openai/gpt-5.5",
    "fallbackStepToModel": "openai/gpt-5.4-mini",                                                                       
    "fallbackStepFromFailureReason": "auth",                                                                            
    "fallbackStepFinalOutcome": "next_fallback",                                                                        
    "isPrimary": true,                                                                                                  
    "fallbackConfigured": true                                                                                          
  }                                                      
                                                                                                                        
  The two subsequent attempts (gpt-5.4-mini, then gpt-5.2) emit identical payloads with fresh cf-ray IDs, ending in     
  fallbackStepFinalOutcome="chain_exhausted".
                                                                                                                        
  2) Aggregate failure line (from same log, 2026-04-29T22:30:15.932Z):                                                  
  
  "Embedded agent failed before reply: All models failed (3): openai/gpt-5.5: unexpected status 401 Unauthorized:       
  Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray:
  9f41beceeb90f0bd-DFW (auth) | openai/gpt-5.4-mini: ... (auth) | openai/gpt-5.2: ... (auth)"                           
                                                         
  3) openclaw doctor output captured 2026-04-28 (on 2026.4.25, prior to the .26 upgrade), excerpt:                      
  
  "Last gateway error: 2026-04-28T19:26:46.393-05:00 Embedded agent failed before reply: All models failed (8):         
    openai/gpt-5.4: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
  https://api.openai.com/v1/responses, cf-ray: 9f3a2490df9eaefe-DFW (auth) |                                            
    anthropic/claude-opus-4-7: failed to load configuration: Model provider `anthropic` not found (unknown) |
    anthropic/claude-sonnet-4-6: ... `anthropic` not found (unknown) |                                                  
    anthropic/claude-opus-4-5: ... `anthropic` not found (unknown) |                                                    
    anthropic/claude-sonnet-4-5: ... `anthropic` not found (unknown) |                                                  
    anthropic/claude-haiku-4-5: ... `anthropic` not found (unknown) |                                                   
    openai/gpt-5.1-codex: unexpected status 401 Unauthorized: Missing bearer ... (auth) |
    openai-codex/gpt-5.5: unexpected status 401 Unauthorized: Missing bearer ... (auth)"                                
                                                                                                                        
  This excerpt is the strongest single piece of evidence: it shows the same Missing-bearer 401 affecting both the       
  api_key path (openai/gpt-5.4, openai/gpt-5.1-codex) and the OAuth path (openai-codex/gpt-5.5) on the same release, in 
  the same run, against the same endpoint.                                                                              
                                                         
  Full live gateway log and full doctor log available on request.                                                       
  
  ---                                                                                                                   
  Impact and severity                                    

  Affected users/systems/channels: 1 confirmed user at time of filing. All channels routing through the codex agent
  runtime are blocked: Telegram (direct lane and cron lane both observed failing — log lanes                            
  "session:agent:main:telegram:direct:..." and "cron-nested" both emit lane-task-error entries with the same
  FailoverError), and the TUI (the runtime path is shared). Anthropic-routed agents would in principle be unaffected by 
  the 401 itself, but cannot run on the codex runtime because of the unrelated "Model provider `anthropic` not found"
  config-load error captured in the doctor log.

  Severity: blocks workflow. The agent cannot complete a single turn on any openai-family model. The cron scheduler     
  retains the jobs but applies error backoff after each failure (cron module log: "cron: applying error backoff" with
  consecutiveErrors:1, backoffMs:30000), so jobs continue to fire and continue to fail on a 30s-and-growing backoff.    
                                                         
  Frequency: every turn, every send, every cron firing, since the bug surfaced. No intermittent successes observed in   
  the captured logs. The same 401 shape (Missing bearer, /v1/responses) repeats with fresh request IDs and cf-ray IDs
  every attempt, indicating the request is reliably leaving the machine without an Authorization header (not a transient
   network issue).                                       

  Consequence: every Telegram message produces a "Something went wrong while processing your request. Please try again, 
  or use /new to start a fresh session." reply (telegram sendMessage ok logged at 22:30:16.236Z). Every cron job is
  delayed by an accumulating backoff. The gateway error log (lane task error entries) accumulates one entry per attempt 
  per lane. No data loss observed in the captured logs; sessions remain queryable. No extra-cost consequence on the
  api_key path because the requests 401 before any tokens are billed; on the OAuth path the same applies. There is,
  however, an indirect cost: the consequence of the bug pushed the user to retry across many models and prefixes during
  diagnosis, and on a separate Anthropic-routed agent (not on this codex runtime) the user reports having exhausted an
  Anthropic budget to ~$100 during recovery attempts. That last point is grounded in user report rather than in the
  OpenClaw logs themselves and is included only for triage context, not as a direct claim about this codex-runtime bug.

  ---
  Additional information
                                                                                                                        
  Regression status: confirmed regression, but the exact first-bad version is not directly captured in the logs
  available. Last-bad observed in logs: 2026.4.26 (live gateway log /tmp/openclaw/openclaw-2026-04-29.log, captured     
  2026-04-29T22:30:15.932Z). First-bad observed in logs: 2026.4.25 (doctor log /tmp/openclaw-recover/doctor-26.log,
  captured 2026-04-28T19:26:46.393-05:00, before the .26 upgrade ran). Last-good is not captured in any log on this     
  system; user report (not log-grounded) places a working state on 2026.3.8 with openai/gpt-5.4 via api_key, but no log
  line from that working state is available to cite, so this is provided as user-recollection-only context, not
  evidence.

  2026.4.26 release-note line that is a plausible candidate for the regression (verbatim from release notes):           
  "Plugins/providers: move pre-runtime model-id normalization, provider endpoint host metadata, and OpenAI-compatible
  request-family hints into plugin manifests so core no longer carries bundled-provider routing tables." The visible    
  "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning and the codex/* -> openai/*
   rewrite both appeared in 2026.4.26 logs but not in the 2026.4.25 doctor log, so this change is the most recent
  observable on-the-wire change between the two captured releases.

  2026.4.26 schema/path change observed on disk: auth-profiles.json moved from ~/.openclaw/agents/auth-profiles.json    
  (the .25 location, which does not exist on this install) to ~/.openclaw/agents/main/agent/auth-profiles.json (3111
  bytes, mode 0600, present and readable). The file is being read on every gateway boot (boot log confirms successful   
  credential reads for the anthropic profile from the Claude CLI keychain). Whether the openai/openai-codex profiles in
  this file are being read but not threaded through to the openai-responses provider's HTTP request builder is the
  suspected failure mode, but I do not have direct evidence to confirm or deny that — only the symptom (request leaves
  the machine without an Authorization header).

  Workaround status: community-reported rollback to 2026.4.23 has been raised by multiple independent users on          
  r/openclaw as a workaround for the broader 2026.4.24/.25/.26 regression cluster. I have not yet attempted the rollback
   against this codex-runtime 401 specifically, so I cannot confirm whether 2026.4.23 also exhibits the bug.            
  NOT_ENOUGH_INFO on whether the workaround applies to this specific issue.

  Possibly-related prior issue: an earlier issue covering an OAuth-only Missing-bearer 401 on /v1/responses against     
  ChatGPT/Codex tokens was reportedly filed against an earlier 2026.3.x release and marked closed. I do not have the
  issue number directly verified from the GitHub repo at filing time; rather than guess, I am leaving the               
  cross-reference out and flagging this for the maintainer's search. If the maintainer has triaged similar reports
  recently, this report differs in that the same Missing-bearer 401 is now also observed on the api_key path
  (openai/gpt-5.4, openai/gpt-5.1-codex) — not just the OAuth path — which suggests the failure is at the auth-attach
  step in the openai-responses provider rather than an OAuth-scope mismatch with /v1/responses.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On OpenClaw 2026.4.26 with agentRuntime.id=codex, every outbound OpenAI request to https://api.openai.com/v1/responses returns 401 "Missing bearer or basic authentication in header" across both auth modes (api_key via openai:default and OAuth via openai-codex), causing the configured 3-model fallback chain to exhaust on every turn and the agent to surface "Something went wrong" to Telegram.

Steps to reproduce

Environment: macOS 14 (Darwin 25.3.0), Node 22.22.1, OpenClaw 2026.4.26 installed at /usr/local/lib/node_modules/openclaw, agent with agentRuntime.id=codex.

  1. Register an OpenAI API key via the wizard so that ~/.openclaw/agents/main/agent/auth-profiles.json contains a
    non-empty sk-proj-... entry under profile id openai:default with mode api_key.
  2. In ~/.openclaw/openclaw.json, set agents.list[0].model to "openai/gpt-5.5" and defaults.model.primary to
    "openai/gpt-5.5" with fallbacks ["openai/gpt-5.4-mini","openai/gpt-5.2"].
  3. Start the gateway and confirm the boot log shows: read anthropic credentials from claude cli keychain (succeeds) and [gateway] agent model: openai/gpt-5.5.
  4. Send any message to the agent via Telegram (@L********_bot in our case) or the TUI.

Observed result: in /tmp/openclaw/openclaw-2026-04-29.log the runtime emits one model_fallback_decision per attempt,
all three with reason="auth", status=401, errorPreview="unexpected status 401 Unauthorized: Missing bearer or basic
authentication in header, url: https://api.openai.com/v1/responses". After attempt 3 the chain logs
fallbackStepFinalOutcome="chain_exhausted" and the gateway sends "Something went wrong while processing your request. Please try again, or use /new to start a fresh session." to the Telegram chat.

The same failure occurred on 2026.4.25 prior to upgrading: an openclaw doctor run on 2026-04-28 19:26 captured "All models failed (8)" with identical 401s for openai/gpt-5.4 (api_key path), openai/gpt-5.1-codex (api_key path), and openai-codex/gpt-5.5 (OAuth path) — all hitting the same /v1/responses endpoint with the same Missing bearer error.
The codex/gpt-5.5 prefix introduced in 2026.4.26 reproduces the same way; the runtime rewrites it to openai/gpt-5.5 before dispatch (visible as requestedProvider="openai" in the model_fallback_decision payload) and emits a separate "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning before the 401 chain begins.

anthropic/* models do not exhibit the 401 (Anthropic auth from the Claude CLI keychain attaches correctly) but cannot be used as a workaround on this runtime — they fail at config-load with "Model provider anthropic not found" because the codex agent runtime does not include an anthropic provider.

Expected behavior

The runtime should attach the bearer token from the matched auth profile to the outbound
https://api.openai.com/v1/responses request and the call should return a 2xx response with the model's reply, the same way the parallel anthropic credential read succeeds on every gateway boot ("read anthropic credentials from claude
cli keychain") and the same way the api_key path against this profile reportedly worked on an earlier release.
Concretely: when agents.list[0].model resolves to openai/gpt-5.5 and the openai:default profile contains a non-empty sk-proj-... value, the HTTP request to /v1/responses should include an "Authorization: Bearer sk-proj-..." header derived from that profile, the candidate should not 401 with "Missing bearer", the model_fallback_decision payload should not fire, the fallback chain should not exhaust, and the user should receive the model's reply on Telegram instead of the "Something went wrong" error message

Actual behavior

Every turn fails. The gateway selects the configured primary model, makes the outbound HTTPS request, and receives a
401 response from api.openai.com without ever attaching an Authorization header. The runtime emits a
model_fallback_decision payload with decision="candidate_failed", reason="auth", status=401, and errorPreview="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
https://api.openai.com/v1/responses, cf-ray: 9f41bd929b694612-DFW". It then steps through both configured fallbacks (openai/gpt-5.4-mini, openai/gpt-5.2), each producing an identical 401 with a fresh cf-ray. After the third candidate fails the chain logs fallbackStepFinalOutcome="chain_exhausted" and emits "Embedded agent failed before reply: All models failed (3): openai/gpt-5.5: ... (auth) | openai/gpt-5.4-mini: ... (auth) | openai/gpt-5.2: ... (auth)". The gateway then sends "Something went wrong while processing your request. Please try again, or use /new to start a fresh session." to the user's Telegram chat (telegram sendMessage ok chat=<redacted>). The cron lane logs "lane task error: ... FailoverError: unexpected status 401 ..." and applies a 30000ms error backoff to the affected job (consecutiveErrors:1, backoffMs:30000). On 2026.4.26 a separate warning fires before the 401 chain begins: "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" — the runtime rejects codex/* prefix strings stored on disk and rewrites them to openai/* before dispatch (visible in the model_fallback_decision payload as requestedProvider="openai" even though agents.list[0].model is "codex/gpt-5.5" on disk).

OpenClaw version

2026.4.26 (live failure captured 2026-04-29). Also reproduced on 2026.4.25 (doctor log captured 2026-04-28 19:26:46-05:00 prior to the .26 upgrade).

Operating system

macOS, Darwin kernel 25.3.0, on Apple hardware (hostname).

Install method

Global npm install. Runtime location /usr/local/lib/node_modules/openclaw/dist/. Bundled Node 22.22.1. Gateway is supervised by launchd (gui/501/ai.openclaw.gateway), binds 127.0.0.1:18789, advertises via bonjour as "_openclaw-gw._tcp.local.".

Model

Primary: openai/gpt-5.5. Fallbacks: openai/gpt-5.4-mini, openai/gpt-5.2. The same Missing-bearer 401 was also observed with openai/gpt-5.4, openai/gpt-5.1-codex, openai-codex/gpt-5.5, and codex/gpt-5.5 across the live 2026.4.26 gateway log and the 2026.4.25 doctor log

Provider / routing chain

Telegram (bot name) -> Gateway on 127.0.0.1:18789 (launchd-supervised, subsystem gateway/channels/telegram) -> embedded codex agent runtime (subsystem agent/embedded, agentRuntime.id=codex) -> openai-responses provider plugin -> POST https://api.openai.com/v1/responses (request reaches Cloudflare per cf-ray ids returned in the 401 response bodies, e.g. cf-ray=9f41bd929b694612-DFW, 9f41beceeb90f0bd-DFW, 9f41bf569e83a915-DFW)

Additional provider/model setup details

Auth profiles file: ~/.openclaw/agents/main/agent/auth-profiles.json (3111 bytes, mode 0600, last modified 2026-04-28 19:56). Contains a non-empty api_key entry under profile id "openai:default" (sk-proj-... redacted) and an oauth entry under "openai-codex:<email>". The previous-version path ~/.openclaw/agents/auth-profiles.json does not exist on this install. Anthropic credentials are read from the Claude CLI keychain on every gateway boot (gateway boot log line:
"read anthropic credentials from claude cli keychain") and that read succeeds; however the codex agent runtime cannot use anthropic/* models — they fail config-load with "failed to load configuration: Model provider anthropic not found (unknown)" before any HTTP request is made (captured in the 2026-04-28 doctor log against five anthropic models: claude-opus-4-7, claude-sonnet-4-6, claude-opus-4-5, claude-sonnet-4-5, claude-haiku-4-5). On 2026.4.26 the model-string prefix changed from openai-codex/* to codex/; configs written with codex/ persist correctly on disk (verified by reading ~/.openclaw/openclaw.json with python3 -c "import json; ...") but the runtime emits "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" and rewrites the candidate to openai/gpt-5.5 (visible in model_fallback_decision payload as requestedProvider="openai", requestedModel="gpt-5.5" while the on-disk source is codex/gpt-5.5).

Logs, screenshots, and evidence

Three log excerpts (all sk-* keys, OAuth tokens, and chat IDs redacted before posting):
                                                                                                                        
  1) Live model_fallback_decision payload (subsystem model-fallback/decision) from                                      
  /tmp/openclaw/openclaw-2026-04-29.log, 2026-04-29T22:29:06.962Z:                                                      
                                                                                                                        
  {                                                      
    "event": "model_fallback_decision",
    "decision": "candidate_failed",
    "requestedProvider": "openai",
    "requestedModel": "gpt-5.5",                                                                                        
    "candidateProvider": "openai",
    "candidateModel": "gpt-5.5",                                                                                        
    "attempt": 1,                                                                                                       
    "total": 3,
    "reason": "auth",                                                                                                   
    "status": 401,                                       
    "errorPreview": "unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
  https://api.openai.com/v1/responses, cf-ray: 9f41bd929b694612-DFW",                                                   
    "fallbackStepFromModel": "openai/gpt-5.5",
    "fallbackStepToModel": "openai/gpt-5.4-mini",                                                                       
    "fallbackStepFromFailureReason": "auth",                                                                            
    "fallbackStepFinalOutcome": "next_fallback",                                                                        
    "isPrimary": true,                                                                                                  
    "fallbackConfigured": true                                                                                          
  }                                                      
                                                                                                                        
  The two subsequent attempts (gpt-5.4-mini, then gpt-5.2) emit identical payloads with fresh cf-ray IDs, ending in     
  fallbackStepFinalOutcome="chain_exhausted".
                                                                                                                        
  2) Aggregate failure line (from same log, 2026-04-29T22:30:15.932Z):                                                  
  
  "Embedded agent failed before reply: All models failed (3): openai/gpt-5.5: unexpected status 401 Unauthorized:       
  Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray:
  9f41beceeb90f0bd-DFW (auth) | openai/gpt-5.4-mini: ... (auth) | openai/gpt-5.2: ... (auth)"                           
                                                         
  3) openclaw doctor output captured 2026-04-28 (on 2026.4.25, prior to the .26 upgrade), excerpt:                      
  
  "Last gateway error: 2026-04-28T19:26:46.393-05:00 Embedded agent failed before reply: All models failed (8):         
    openai/gpt-5.4: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url:
  https://api.openai.com/v1/responses, cf-ray: 9f3a2490df9eaefe-DFW (auth) |                                            
    anthropic/claude-opus-4-7: failed to load configuration: Model provider `anthropic` not found (unknown) |
    anthropic/claude-sonnet-4-6: ... `anthropic` not found (unknown) |                                                  
    anthropic/claude-opus-4-5: ... `anthropic` not found (unknown) |                                                    
    anthropic/claude-sonnet-4-5: ... `anthropic` not found (unknown) |                                                  
    anthropic/claude-haiku-4-5: ... `anthropic` not found (unknown) |                                                   
    openai/gpt-5.1-codex: unexpected status 401 Unauthorized: Missing bearer ... (auth) |
    openai-codex/gpt-5.5: unexpected status 401 Unauthorized: Missing bearer ... (auth)"                                
                                                                                                                        
  This excerpt is the strongest single piece of evidence: it shows the same Missing-bearer 401 affecting both the       
  api_key path (openai/gpt-5.4, openai/gpt-5.1-codex) and the OAuth path (openai-codex/gpt-5.5) on the same release, in 
  the same run, against the same endpoint.                                                                              
                                                         
  Full live gateway log and full doctor log available on request.                                                       
  
  ---                                                                                                                   
  Impact and severity                                    

  Affected users/systems/channels: 1 confirmed user at time of filing. All channels routing through the codex agent
  runtime are blocked: Telegram (direct lane and cron lane both observed failing — log lanes                            
  "session:agent:main:telegram:direct:..." and "cron-nested" both emit lane-task-error entries with the same
  FailoverError), and the TUI (the runtime path is shared). Anthropic-routed agents would in principle be unaffected by 
  the 401 itself, but cannot run on the codex runtime because of the unrelated "Model provider `anthropic` not found"
  config-load error captured in the doctor log.

  Severity: blocks workflow. The agent cannot complete a single turn on any openai-family model. The cron scheduler     
  retains the jobs but applies error backoff after each failure (cron module log: "cron: applying error backoff" with
  consecutiveErrors:1, backoffMs:30000), so jobs continue to fire and continue to fail on a 30s-and-growing backoff.    
                                                         
  Frequency: every turn, every send, every cron firing, since the bug surfaced. No intermittent successes observed in   
  the captured logs. The same 401 shape (Missing bearer, /v1/responses) repeats with fresh request IDs and cf-ray IDs
  every attempt, indicating the request is reliably leaving the machine without an Authorization header (not a transient
   network issue).                                       

  Consequence: every Telegram message produces a "Something went wrong while processing your request. Please try again, 
  or use /new to start a fresh session." reply (telegram sendMessage ok logged at 22:30:16.236Z). Every cron job is
  delayed by an accumulating backoff. The gateway error log (lane task error entries) accumulates one entry per attempt 
  per lane. No data loss observed in the captured logs; sessions remain queryable. No extra-cost consequence on the
  api_key path because the requests 401 before any tokens are billed; on the OAuth path the same applies. There is,
  however, an indirect cost: the consequence of the bug pushed the user to retry across many models and prefixes during
  diagnosis, and on a separate Anthropic-routed agent (not on this codex runtime) the user reports having exhausted an
  Anthropic budget to ~$100 during recovery attempts. That last point is grounded in user report rather than in the
  OpenClaw logs themselves and is included only for triage context, not as a direct claim about this codex-runtime bug.

  ---
  Additional information
                                                                                                                        
  Regression status: confirmed regression, but the exact first-bad version is not directly captured in the logs
  available. Last-bad observed in logs: 2026.4.26 (live gateway log /tmp/openclaw/openclaw-2026-04-29.log, captured     
  2026-04-29T22:30:15.932Z). First-bad observed in logs: 2026.4.25 (doctor log /tmp/openclaw-recover/doctor-26.log,
  captured 2026-04-28T19:26:46.393-05:00, before the .26 upgrade ran). Last-good is not captured in any log on this     
  system; user report (not log-grounded) places a working state on 2026.3.8 with openai/gpt-5.4 via api_key, but no log
  line from that working state is available to cite, so this is provided as user-recollection-only context, not
  evidence.

  2026.4.26 release-note line that is a plausible candidate for the regression (verbatim from release notes):           
  "Plugins/providers: move pre-runtime model-id normalization, provider endpoint host metadata, and OpenAI-compatible
  request-family hints into plugin manifests so core no longer carries bundled-provider routing tables." The visible    
  "[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning and the codex/* -> openai/*
   rewrite both appeared in 2026.4.26 logs but not in the 2026.4.25 doctor log, so this change is the most recent
  observable on-the-wire change between the two captured releases.

  2026.4.26 schema/path change observed on disk: auth-profiles.json moved from ~/.openclaw/agents/auth-profiles.json    
  (the .25 location, which does not exist on this install) to ~/.openclaw/agents/main/agent/auth-profiles.json (3111
  bytes, mode 0600, present and readable). The file is being read on every gateway boot (boot log confirms successful   
  credential reads for the anthropic profile from the Claude CLI keychain). Whether the openai/openai-codex profiles in
  this file are being read but not threaded through to the openai-responses provider's HTTP request builder is the
  suspected failure mode, but I do not have direct evidence to confirm or deny that — only the symptom (request leaves
  the machine without an Authorization header).

  Workaround status: community-reported rollback to 2026.4.23 has been raised by multiple independent users on          
  r/openclaw as a workaround for the broader 2026.4.24/.25/.26 regression cluster. I have not yet attempted the rollback
   against this codex-runtime 401 specifically, so I cannot confirm whether 2026.4.23 also exhibits the bug.            
  NOT_ENOUGH_INFO on whether the workaround applies to this specific issue.

  Possibly-related prior issue: an earlier issue covering an OAuth-only Missing-bearer 401 on /v1/responses against     
  ChatGPT/Codex tokens was reportedly filed against an earlier 2026.3.x release and marked closed. I do not have the
  issue number directly verified from the GitHub repo at filing time; rather than guess, I am leaving the               
  cross-reference out and flagging this for the maintainer's search. If the maintainer has triaged similar reports
  recently, this report differs in that the same Missing-bearer 401 is now also observed on the api_key path
  (openai/gpt-5.4, openai/gpt-5.1-codex) — not just the OAuth path — which suggests the failure is at the auth-attach
  step in the openai-responses provider rather than an OAuth-scope mismatch with /v1/responses.

Impact and severity

Affected users/systems/channels: 1 confirmed user at time of filing. All channels routing through the codex agent runtime are blocked: Telegram (direct lane and cron lane both observed failing — log lanes
"session:agent:main:telegram:direct:..." and "cron-nested" both emit lane-task-error entries with the same FailoverError), and the TUI (the runtime path is shared). Anthropic-routed agents would in principle be unaffected by the 401 itself, but cannot run on the codex runtime because of the unrelated "Model provider anthropic not found" config-load error captured in the doctor log.

Severity: blocks workflow. The agent cannot complete a single turn on any openai-family model. The cron scheduler
retains the jobs but applies error backoff after each failure (cron module log: "cron: applying error backoff" with consecutiveErrors:1, backoffMs:30000), so jobs continue to fire and continue to fail on a 30s-and-growing backoff.

Frequency: every turn, every send, every cron firing, since the bug surfaced. No intermittent successes observed in
the captured logs. The same 401 shape (Missing bearer, /v1/responses) repeats with fresh request IDs and cf-ray IDs every attempt, indicating the request is reliably leaving the machine without an Authorization header (not a transient network issue).

Consequence: every Telegram message produces a "Something went wrong while processing your request. Please try again, or use /new to start a fresh session." reply (telegram sendMessage ok logged at 22:30:16.236Z). Every cron job is delayed by an accumulating backoff. The gateway error log (lane task error entries) accumulates one entry per attempt per lane. No data loss observed in the captured logs; sessions remain queryable. No extra-cost consequence on the api_key path because the requests 401 before any tokens are billed; on the OAuth path the same applies. There is, however, an indirect cost: the consequence of the bug pushed the user to retry across many models and prefixes during diagnosis, and on a separate Anthropic-routed agent (not on this codex runtime) the user reports having exhausted an Anthropic budget to ~$100 during recovery attempts. That last point is grounded in user report rather than in the OpenClaw logs themselves and is included only for triage context, not as a direct claim about this codex-runtime bug.

Additional information

Regression status: confirmed regression, but the exact first-bad version is not directly captured in the logs available. Last-bad observed in logs: 2026.4.26 (live gateway log /tmp/openclaw/openclaw-2026-04-29.log, captured
2026-04-29T22:30:15.932Z). First-bad observed in logs: 2026.4.25 (doctor log /tmp/openclaw-recover/doctor-26.log, captured 2026-04-28T19:26:46.393-05:00, before the .26 upgrade ran). Last-good is not captured in any log on this
system; user report (not log-grounded) places a working state on 2026.3.8 with openai/gpt-5.4 via api_key, but no log line from that working state is available to cite, so this is provided as user-recollection-only context, not evidence.

2026.4.26 release-note line that is a plausible candidate for the regression (verbatim from release notes):
"Plugins/providers: move pre-runtime model-id normalization, provider endpoint host metadata, and OpenAI-compatible request-family hints into plugin manifests so core no longer carries bundled-provider routing tables." The visible
"[cron] payload.model 'codex/gpt-5.5' not allowed, falling back to agent defaults" warning and the codex/* -> openai/* rewrite both appeared in 2026.4.26 logs but not in the 2026.4.25 doctor log, so this change is the most recent observable on-the-wire change between the two captured releases.

2026.4.26 schema/path change observed on disk: auth-profiles.json moved from ~/.openclaw/agents/auth-profiles.json
(the .25 location, which does not exist on this install) to ~/.openclaw/agents/main/agent/auth-profiles.json (3111 bytes, mode 0600, present and readable). The file is being read on every gateway boot (boot log confirms successful
credential reads for the anthropic profile from the Claude CLI keychain). Whether the openai/openai-codex profiles in this file are being read but not threaded through to the openai-responses provider's HTTP request builder is the suspected failure mode, but I do not have direct evidence to confirm or deny that — only the symptom (request leaves the machine without an Authorization header).

Workaround status: community-reported rollback to 2026.4.23 has been raised by multiple independent users on
r/openclaw as a workaround for the broader 2026.4.24/.25/.26 regression cluster. I have not yet attempted the rollback against this codex-runtime 401 specifically, so I cannot confirm whether 2026.4.23 also exhibits the bug.
NOT_ENOUGH_INFO on whether the workaround applies to this specific issue.

Possibly-related prior issue: an earlier issue covering an OAuth-only Missing-bearer 401 on /v1/responses against
ChatGPT/Codex tokens was reportedly filed against an earlier 2026.3.x release and marked closed. I do not have the issue number directly verified from the GitHub repo at filing time; rather than guess, I am leaving the
cross-reference out and flagging this for the maintainer's search. If the maintainer has triaged similar reports recently, this report differs in that the same Missing-bearer 401 is now also observed on the api_key path (openai/gpt-5.4, openai/gpt-5.1-codex) — not just the OAuth path — which suggests the failure is at the auth-attach step in the openai-responses provider rather than an OAuth-scope mismatch with /v1/responses.

extent analysis

TL;DR

The most likely fix is to investigate and resolve the issue with attaching the bearer token to the outbound OpenAI request, potentially related to changes in the auth-profiles.json file location or the openai-responses provider plugin.

Guidance

  • Investigate the auth-profiles.json file and its contents to ensure the openai:default profile is correctly configured with a non-empty sk-proj-... entry.
  • Verify that the openai-responses provider plugin is correctly reading and attaching the bearer token from the auth-profiles.json file to the outbound OpenAI request.
  • Check the release notes for 2026.4.26 and review the changes made to the openai-responses provider plugin, specifically the move of pre-runtime model-id normalization and provider endpoint host metadata into plugin manifests.
  • Consider rolling back to 2026.4.23 as a potential workaround, as reported by the community, although its effectiveness for this specific issue is uncertain.

Example

No code snippet is provided as the issue is more related to configuration and plugin behavior rather than a specific code error.

Notes

The issue seems to be related to a regression introduced in 2026.4.25 or 2026.4.26, and the exact cause is still uncertain. The auth-profiles.json file location change and the openai-responses provider plugin changes are potential contributing factors.

Recommendation

Apply the workaround by rolling back to 2026.4.23 if possible, as it has been reported to resolve similar issues in the past, although its effectiveness for this specific problem is not confirmed.

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

The runtime should attach the bearer token from the matched auth profile to the outbound
https://api.openai.com/v1/responses request and the call should return a 2xx response with the model's reply, the same way the parallel anthropic credential read succeeds on every gateway boot ("read anthropic credentials from claude
cli keychain") and the same way the api_key path against this profile reportedly worked on an earlier release.
Concretely: when agents.list[0].model resolves to openai/gpt-5.5 and the openai:default profile contains a non-empty sk-proj-... value, the HTTP request to /v1/responses should include an "Authorization: Bearer sk-proj-..." header derived from that profile, the candidate should not 401 with "Missing bearer", the model_fallback_decision payload should not fire, the fallback chain should not exhaust, and the user should receive the model's reply on Telegram instead of the "Something went wrong" error message

#api#network issue#logging issue#authentication issue#prompt issue

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 - 💡(How to fix) Fix [Bug]: 2026.4.26 — auth resolver fails to attach Authorization header to OpenAI requests; all openai/* and codex/* models 401 with "Missing bearer" [1 comments, 2 participants]