Switch to ChatGPT 5.5 issues | Friends of the Crustacean 🦞🤝 | Page 1

unkempt salmon Apr 24, 2026, 5:40 AM

#

I need help getting my OpenClaw agent to run GPT-5.5 right now.

Context:

Host machine: macOS
OpenClaw version: 2026.4.22
My agent currently works on openai-codex/gpt-5.4
I want GPT-5.5
I use OpenAI Codex / ChatGPT subscription auth, not a plain OpenAI API key for this route

Important route distinction:

openai-codex/* = Codex OAuth through the normal OpenClaw PI runner
openai/* = different route, and docs say openai/gpt-5.5 may work through the native Codex harness
This is not a simple API-key issue

What happened:

I re-authenticated Codex OAuth successfully and now have:
- one fresh healthy Codex OAuth profile
- one stale old Codex OAuth profile that had a refresh-token issue
I set auth order to prefer the healthy profile.
I updated OpenClaw:
- openclaw update
- result: already on 2026.4.22
I checked model availability:
- openclaw models list --provider openai-codex
  Output:

openai-codex/gpt-5.5 -> tags: default,configured,missing
openai-codex/gpt-5.4 -> available and working

I ran a real smoke test:
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai-codex/gpt-5.5 --json

Exact failure:

FailoverError: Unknown model: openai-codex/gpt-5.5

I reverted to a working model so the agent stays alive:
- openclaw models set openai-codex/gpt-5.4
- openclaw gateway restart

Why this is confusing:

Current OpenClaw docs appear to say GPT-5.5 should be available
Docs suggest two 5.5 paths:
1. openai-codex/gpt-5.5 through PI/Codex OAuth
2. openai/gpt-5.5 through the native Codex app-server harness
But on my live host, the first path fails as unknown model

What I want help with:

How do I get GPT-5.5 working now?
Is openai-codex/gpt-5.5 broken on 2026.4.22 despite docs saying otherwise?

dull shuttleBOT Apr 24, 2026, 5:40 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

mortal havenBOT Apr 24, 2026, 5:40 AM

#

rocky tulipBOT Apr 24, 2026, 5:45 AM

#

Let me verify this against the actual docs/source instead of guessing.

#

Yep, I think you’ve hit a real gap in 2026.4.22, not an auth-order mistake.

What your output means:

configured,missing = OpenClaw knows you asked for that ref, but the runtime cannot actually resolve it
FailoverError: Unknown model: openai-codex/gpt-5.5 confirms it is not runnable on that path right now

I checked the current docs/source situation, and it looks like the docs got ahead of the shipped runtime. There’s already a matching issue here:
https://github.com/openclaw/openclaw/issues/70854

So, short answer:

openai-codex/gpt-5.5 on the normal PI/Codex OAuth route appears broken or not fully shipped on 2026.4.22
Your stale old profile is probably not the blocker
If you want GPT-5.5 now, the practical path is the native Codex harness route, not openai-codex/*

Use this route instead:

#

{
  plugins: {
    entries: {
      codex: { enabled: true },
    },
  },
  agents: {
    defaults: {
      model: { primary: "openai/gpt-5.5" },
      embeddedHarness: {
        runtime: "codex",
        fallback: "none",
      },
    },
  },

#

If you use plugins.allow, include "codex" there too.

Then:

restart the gateway
start a fresh session with /new or /reset (harness choice is session-pinned)

Important nuance:

openai/gpt-5.5 here is not the normal API-key route
with embeddedHarness.runtime: "codex", it goes through the native Codex app-server harness instead

If you need to stay on the PI runner specifically, I’d keep openai-codex/gpt-5.4 for now and wait for the catalog/runtime fix to land.

I would not try to hack models.providers.openai-codex manually unless you really want unsupported territory, since the docs warn that can shadow the built-in Codex OAuth provider path.

#

Docs:

route split: https://docs.openclaw.ai/providers/openai
Codex harness setup: https://docs.openclaw.ai/plugins/codex-harness
FAQ: https://docs.openclaw.ai/help/faq

If you want, paste your redacted agents.defaults + any plugins.allow section and I can sanity-check the exact gpt-5.5 Codex harness config before you flip it.

unkempt salmon Apr 24, 2026, 6:49 AM

#

OPENCLAW_AGENT_RUNTIME=codex OPENCLAW_AGENT_HARNESS_FALLBACK=none openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json
Error: Model override "openai/gpt-5.5" is not allowed for agent "main".

I got the above error

#

@rocky tulip

OPENCLAW_AGENT_RUNTIME=codex OPENCLAW_AGENT_HARNESS_FALLBACK=none openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json
Error: Model override "openai/gpt-5.5" is not allowed for agent "main".

I got the above error

i'm trying the Codex harness route,

rocky tulipBOT Apr 24, 2026, 6:52 AM

#

Yep, that’s a different blocker.

You’re now hitting the allowlist, not the Codex harness itself.

openclaw infer model run --model openai/gpt-5.5 ... still checks agents.defaults.models first.
If openai/gpt-5.5 is not in that map, OpenClaw rejects it before it even tries the Codex runtime.

Try this:

openclaw config set agents.defaults.models '{"openai/gpt-5.5":{}}' --strict-json --merge
openclaw config set plugins.entries.codex.enabled true

Then rerun:

#

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json

Also check this if relevant:

if you use plugins.allow, make sure it includes codex
keep your default model on openai-codex/gpt-5.4 until the smoke test passes

If the smoke test works, then make it persistent:

openclaw config set agents.defaults.model.primary openai/gpt-5.5
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none

#

openclaw gateway restart

Then start a fresh session with /new or /reset, because harness choice is session-pinned.

So the current state is:

openai-codex/gpt-5.5 on 2026.4.22 still looks genuinely broken / missing on the PI route
openai/gpt-5.5 via Codex harness is the right workaround
your newest error is just saying the model is not yet allowed in config

Docs:

https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/providers/openai
issue tracking the PI-side gap: https://github.com/openclaw/openclaw/issues/70854

#

If you want, paste these three sections and I’ll sanity-check them fast:

agents.defaults.models
plugins.entries.codex
plugins.allow

unkempt salmon Apr 24, 2026, 6:52 AM

#

I have downloaded codex, I have signed in using my OPenAI account.

I've also:

Enable the Codex plugin in OpenClaw

openclaw config set plugins.entries.codex.enabled true

Check whether plugins.allow exists

openclaw config get plugins.allow --json

And it printed null

rocky tulipBOT Apr 24, 2026, 6:54 AM

#

Good, plugins.allow = null means plugin gating is not the problem.

At this point the remaining blocker is almost certainly the model allowlist.

Run this:

openclaw config set agents.defaults.models '{"openai/gpt-5.5":{}}' --strict-json --merge

Then retry the same smoke test:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json

#

Why this matters:

enabling plugins.entries.codex.enabled only makes the harness available
it does not automatically add openai/gpt-5.5 to agents.defaults.models
if agents.defaults.models exists, it becomes the model allowlist, and infer --model ... gets rejected before the harness even runs

If that smoke test passes, make it persistent:

openclaw config set agents.defaults.model.primary openai/gpt-5.5
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

Then use /new or /reset, because harness choice is session-pinned.

If the next error is about Codex app-server/version/handshake, check:

#

codex --version

The Codex harness docs want app-server 0.118.0+.

Docs:

https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/plugins/codex-harness
tracking issue for the broken PI-side openai-codex/gpt-5.5 route: https://github.com/openclaw/openclaw/issues/70854

If you paste the output of:

openclaw config get agents.defaults.models --json

#

and the new smoke-test error/output, I can sanity-check the next step fast.

unkempt salmon Apr 24, 2026, 6:58 AM

#

It looked like the smoke test worked. But my agent can't respond he just says "
Something went wrong while processing your request. Please try again, or use /new to start a fresh session."

Here is the output:

% openclaw config get agents.defaults.models --json
{
"openai-codex/gpt-5.4": {},
"openai-codex/gpt-5.5": {},
"openai/gpt-5.5": {}
}

rocky tulipBOT Apr 24, 2026, 6:59 AM

#

Nice, that’s actually good news, it means the Codex harness itself probably works.

What’s likely happening now is simpler:

your smoke test used temporary env vars
your live gateway/session is still on the old model/harness, or the session is pinned to the old runner

So the next move is to make the harness selection persistent, then start a fresh session.

Run these:

openclaw config set agents.defaults.model.primary openai/gpt-5.5
openclaw config set agents.defaults.embeddedHarness.runtime codex
openclaw config set agents.defaults.embeddedHarness.fallback none
openclaw gateway restart

#

Then in Discord:

run /new or /reset
then run /status

What you want to confirm in /status:

model is openai/gpt-5.5
harness shows Codex, not PI

Also, for this test, do not actively select openai-codex/gpt-5.5, that PI route still looks broken on 2026.4.22.

Your allowlist looks fine now:

{
  "openai-codex/gpt-5.4": {},
  "openai-codex/gpt-5.5": {},

#

  "openai/gpt-5.5": {}
}

So the problem is probably active session/runtime selection, not allowlisting anymore.

If it still throws the generic Discord error after /new, paste these 4 outputs and I’ll narrow it down fast:

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.embeddedHarness --json
codex --version

and the Discord /status output.

#

Docs:

unkempt salmon Apr 24, 2026, 7:00 AM

#

I use slack

rocky tulipBOT Apr 24, 2026, 7:01 AM

#

Ah, got it, Slack changes one important detail.

In Slack, use the commands in the same chat as plain standalone text first, not the native slash-command version.

Why:

text commands run in the normal chat session
native Slack slash commands use an isolated session
Slack also reserves /status, so the native slash version is /agentstatus, but plain text /status still works in messages

So for your case, after the config + gateway restart, do this inside the same Slack DM/channel where the agent is failing:

/new
/status

or

#

/reset
/status

as standalone messages.

That should force a fresh chat session to pick up:

openai/gpt-5.5
embeddedHarness.runtime = codex
embeddedHarness.fallback = none

Important: if you use native Slack slash commands, they may not be inspecting/resetting the same session your normal chat replies use, which can make this look maddeningly inconsistent.

So my recommendation is:

keep the persistent config you already set

#

restart gateway
in the same Slack conversation, send plain text:
- /new
- then /status
send a normal test prompt

If it still fails, send me:

the plain text /status output from Slack
openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.embeddedHarness --json
codex --version

Relevant docs:

#

I’m pretty sure the next issue is Slack session targeting, not the GPT-5.5 allowlist anymore.

unkempt salmon Apr 24, 2026, 7:01 AM

#

I did above. The agent still don't work.

Here is the output:

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.embeddedHarness --json
codex --version
{
"primary": "openai/gpt-5.5"
}
{
"runtime": "codex",
"fallback": "none"
}
codex-cli 0.124.0

rocky tulipBOT Apr 24, 2026, 7:08 AM

#

Your config now looks right for the native Codex path.

I dug into the 2026.4.22 source, and the important bit is this:

openai/gpt-5.5 + embeddedHarness.runtime: "codex" is the intended native path
the bundled Codex harness is present
existing conversations can stay pinned to the old PI runner
switching harnesses is not live for an already-used session

So I think you’re hitting session pinning, not a bad config.

What to do next

In the same failing chat/thread, do this:

send /new or /reset
then immediately send /status
then try a tiny prompt like: reply with exactly: smoke-ok

#

What you want /status to show is Codex, not PI (embedded).

What I’m confident about

openai-codex/gpt-5.5 on 2026.4.22 does look genuinely broken/missing on the PI OAuth path
your native Codex config is the correct workaround path
if the session is fresh, openai/gpt-5.5 should be the route that works

Docs:

If it still fails after /new, paste:

the /status output
the exact first error text from that fresh session

and I’ll narrow it down from there.

unkempt salmon Apr 24, 2026, 7:09 AM

#

Me: /new
Ai agent:
⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Me: /status
Ai agent:
🦞 OpenClaw 2026.4.22 (00bd2cf)
🧠 Model: codex/gpt-5.5 · 🔑 unknown
🗄️ Cache: 100% hit · 25k cached, 0 new
📚 Context: 0/200k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:slack:channel:c0ak8p5550c • updated just now
⚙️ Runtime: direct · Runner: pi (embedded) · Think: off · Text: low
👥 Activation: mention · 🪢 Queue: collect (depth 0)

#

@rocky tulip

Me: /new
Ai agent:
⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Me: /status
Ai agent:
🦞 OpenClaw 2026.4.22 (00bd2cf)
🧠 Model: codex/gpt-5.5 · 🔑 unknown
🗄️ Cache: 100% hit · 25k cached, 0 new
📚 Context: 0/200k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:slack:channel:c0ak8p5550c • updated just now
⚙️ Runtime: direct · Runner: pi (embedded) · Think: off · Text: low
👥 Activation: mention · 🪢 Queue: collect (depth 0)

rocky tulipBOT Apr 24, 2026, 7:14 AM

#

I think we found the actual bug.

Your /status tells the story:

bad signal: Runner: pi (embedded)
important: context is reset to 0/200k, so /new did reset the session
but: it did not switch the session off the old PI harness

I checked the 2026.4.22 source, and it looks like /new / reset is preserving the session’s stored agentHarnessId, so a session pinned to PI stays pinned to PI even after reset. That matches what you’re seeing exactly.

So yes, two separate things now look true:

openai-codex/gpt-5.5 on the PI OAuth route looks genuinely broken/missing on 2026.4.22
the native Codex workaround is being blocked by a stale PI harness pin in this Slack session

Fastest workaround right now

#

Use a truly different session key, not just /new in the same Slack conversation.

Best options:

message the agent from a different Slack DM/channel
or surgically remove this session entry from the session store, then restart

The stuck session key is:

agent:main:slack:channel:c0ak8p5550c

Surgical fix

First find the store path:

#

openclaw sessions --agent main --json

Then, after stopping the gateway, remove that one key from the sessions.json entry for main, start the gateway again, and retry /status.

If you use the default state dir, that file is usually:

~/.openclaw/agents/main/sessions/sessions.json

After that, /status should stop saying:

Runner: pi (embedded)

#

and instead show the Codex harness badge, like Fast · codex.

My recommendation

I’d treat this as a real 2026.4.22 bug/regression and file it here after you confirm the workaround:

https://github.com/openclaw/openclaw/issues

Docs:

If you want, I can give you the exact minimal edit command for sessions.json next.

unkempt salmon Apr 24, 2026, 7:22 AM

#

Is it that ChatGPT 5.5 is not available for my account yet?

rocky tulipBOT Apr 24, 2026, 7:23 AM

#

Short answer: probably not as the primary issue.

What your logs point to more strongly is:

PI route problem in 2026.4.22
openai-codex/gpt-5.5 shows configured,missing, then fails with
FailoverError: Unknown model: openai-codex/gpt-5.5
Native Codex route never actually took over
your /status still says Runner: pi (embedded), so that path is not testing GPT-5.5 account access yet, it is still stuck on the wrong runner.

If this were just “my account doesn’t have GPT-5.5 yet”, I’d expect more of an access/availability style failure, not OpenClaw saying the PI model is literally missing / Unknown model.

So my current read is:

openai-codex/gpt-5.5 looks broken on 2026.4.22
your Slack session is also stuck PI-pinned, which blocks the native workaround

#

account availability is still possible, but it is not the main thing your evidence is showing so far

The cleanest way to test the account question specifically is:

if GPT-5.5 is selectable in ChatGPT/Codex itself, your account likely has access
then the OpenClaw issue is routing/session-state, not entitlement

I’d keep treating the immediate workaround as:

use openai/gpt-5.5 + Codex harness
but from a truly fresh session key (different DM/channel, or remove the stuck session entry)

Docs:

If you want, I can give you the exact safest way to remove just that one stuck Slack session entry next.

unkempt salmon Apr 24, 2026, 7:48 AM

#

My agent is down now. I just want it to come back alive. I can wait a bit with 5.5.

how can you help me get him back alive?

#

07:46:39+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=19085 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses,

07:46:39+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:slack:channel:c0aeguqb3ft durationMs=19087 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses,

07:46:39+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"

these are some errors I can see in the logs

rocky tulipBOT Apr 24, 2026, 7:49 AM

#

Yep, let’s get it breathing again on the last known-good path first.

Do this now

1) Roll back to the working model + force PI

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.4
openclaw config set agents.defaults.embeddedHarness.runtime pi
openclaw gateway restart

2) Check basic health

openclaw gateway status
openclaw status

#

One thing that may still block recovery

Earlier testing may have left a model allowlist behind.

Check it:

openclaw config get agents.defaults.models --json

If that shows only openai/gpt-5.5 or otherwise excludes openai-codex/gpt-5.4, add 5.4 back:

openclaw config set agents.defaults.models '{"openai-codex/gpt-5.4":{}}' --strict-json --merge
openclaw gateway restart

#

Then test from a truly fresh Slack session

Because your current Slack session looks poisoned/stuck, don’t trust that one first.

Try the agent from:

a different Slack DM, or
a different Slack channel

That gives OpenClaw a new session key.

If it is still dead everywhere

Do a session-only reset, while keeping auth:

stop the gateway
move the sessions dir aside
restart

Default path:

#

mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.bak.$(date +%Y%m%d-%H%M%S)
openclaw gateway restart

That resets conversation/session state, but keeps auth.

Docs:

If you paste these 3 outputs, I can tell you the next step fast:

openclaw gateway status
openclaw status
openclaw config get agents.defaults.models --json

unkempt salmon Apr 24, 2026, 7:49 AM

#

Let's get him back alive on 5.4

rocky tulipBOT Apr 24, 2026, 7:50 AM

#

Ah, this log is the missing piece.

401 Unauthorized: Missing bearer ... url: https://api.openai.com/v1/responses

That means your agent is currently trying the plain openai/* API route, with no OPENAI_API_KEY. So right now it is not on the working Codex OAuth path.

Fastest way to get it alive again

1) Put the default model back on the known-good route

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.4
openclaw config set agents.defaults.embeddedHarness.runtime pi

2) If you previously set a model allowlist, add 5.4 back

Check:

#

openclaw config get agents.defaults.models --json

If that prints an object, run:

openclaw config set agents.defaults.models '{"openai-codex/gpt-5.4":{}}' --strict-json --merge

3) Restart

openclaw gateway restart

Then fix the broken Slack conversation

In the same Slack DM/channel, send these as plain text messages:

#

/model openai-codex/gpt-5.4
/new
/status

What you want to see is:

model on openai-codex/gpt-5.4
Runner: pi (embedded) is fine for this recovery path
no more api.openai.com/v1/responses 401s

Important

For now, do not use openai/gpt-5.5 unless either:

/status shows the Codex harness badge (codex), or
you actually set OPENAI_API_KEY

Otherwise OpenClaw falls onto the direct OpenAI API route and hits that 401.

#

If that Slack chat is still cursed

Open a different Slack DM/channel and test there first. The old session may still be poisoned.

If you want, paste these next and I’ll check them fast:

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json
the new /status

Docs: https://docs.openclaw.ai/providers/openai

#

Yep, let’s do the boring recovery path first and get him stable on 5.4.

In terminal

Run these exactly:

openclaw models set openai-codex/gpt-5.4
openclaw config set agents.defaults.embeddedHarness.runtime pi
openclaw gateway restart

Then check whether a model allowlist is blocking 5.4:

openclaw config get agents.defaults.models --json

#

If that returns null, you’re fine.
If it returns an object that does not include openai-codex/gpt-5.4, run:

openclaw config set agents.defaults.models '{"openai-codex/gpt-5.4":{}}' --strict-json --merge
openclaw gateway restart

In Slack

In the same broken chat, send these as plain text messages:

/model openai-codex/gpt-5.4
/new
/status

#

You want /status to show:

model on openai-codex/gpt-5.4
Runner: pi (embedded)

That is the healthy recovery path for now.

If that chat is still cursed

Try the agent from a different Slack DM or channel first. That forces a new session key.

If it still won’t come back

Paste these 3 outputs and I’ll tighten it up fast:

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json
openclaw status

#

Docs: https://docs.openclaw.ai/providers/openai

unkempt salmon Apr 24, 2026, 7:52 AM

#

openclaw config get agents.defaults.models --json
{
"openai-codex/gpt-5.4": {},
"openai-codex/gpt-5.5": {},
"openai/gpt-5.5": {},
"codex/gpt-5.5": {},
"codex/gpt-5.4": {}
}

#

Ok he is back alive now.

I really want to test 5.5

rocky tulipBOT Apr 24, 2026, 7:53 AM

#

Good, that means the allowlist is not the blocker. openai-codex/gpt-5.4 is allowed.

So the recovery target is simpler now: force the default model and runner back to the known-good route, then clear the bad session override.

Run this on the host:

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.4
openclaw config set agents.defaults.embeddedHarness.runtime pi
openclaw gateway restart

Then in the same Slack chat, send these as plain text:

/model openai-codex/gpt-5.4

#

/new
/status

What you want /status to show:

model: openai-codex/gpt-5.4
Runner: pi (embedded)

Also, the bad log should stop:

no more https://api.openai.com/v1/responses
no more 401 Unauthorized: Missing bearer...

If that Slack chat still sticks to openai/gpt-5.5, test from a different Slack DM/channel first, because that gives you a fresh session key.

If it still won’t recover, paste these 2 outputs next:

#

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.embeddedHarness --json

Glad we caught the allowlist part, that narrows it down a lot.

#

Nice, glad he’s back 🦐

Safest way to test 5.5 now: do a one-shot terminal smoke test without touching the working 5.4 default.

Run this exactly:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json

How to read the result

If it replies smoke-ok
then GPT-5.5 works for you on the native Codex harness path.
If you see 401 Unauthorized ... api.openai.com/v1/responses
then it is still hitting the plain OpenAI API path, not Codex.

#

If it says model missing/unavailable
then we’re closer to a real Codex catalog/account availability issue.

Important

Do not change your default model again yet. Keep the live agent on:

openai-codex/gpt-5.4

until the smoke test passes.

If you want, after you paste that output, I can help you set up a safe GPT-5.5 test lane so your main Slack agent stays on 5.4.

Docs:

unkempt salmon Apr 24, 2026, 7:54 AM

#

The agent is live. I wnat to test 5.5.

Is there no easy way to do that? seems like veryone else gets it to work?

rocky tulipBOT Apr 24, 2026, 7:55 AM

#

Yeah, there is an easy way to test it safely, just not by flipping your live agent in place.

For your setup, the easy test is this one-shot terminal smoke test:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json

Why I’m recommending this:

it does not touch your now-working 5.4 agent
it forces the native Codex harness
it avoids the openai-codex/gpt-5.5 PI path that looks broken for you on 2026.4.22

So, bluntly:

#

easy safe test: yes, the command above
easy live-agent swap in chat: not really, not on your current path

And you’re not crazy, the reason “everyone else” seems to get it working is usually one of these:

they’re using the native Codex harness path
they’re on a fresh session / different chat
they are not relying on the exact openai-codex/gpt-5.5 PI route that is failing for you

If that command returns smoke-ok, then GPT-5.5 works for your account and we can set up a safe test lane next without risking the live agent.

Docs:

Paste the output and I’ll tell you the next move fast.

unkempt salmon Apr 24, 2026, 7:57 AM

#

detail=unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f138a.....df9c7-CPH, request id: sha256:5.....6fc42
09:54:56 [agent/embedded] auth profile failure state updated: runId=12f....d9-fa6f-4b71-906.....a6fd34e2 profile=sha256:4.....067eeb provider=openai-codex reason=auth window=cooldown reused=false
09:54:56 [agent/embedded] embedded run failover decision: runId=12fe3fd9-fa6f-4b71-906a-.......4e2 stage=prompt decision=surface_error reason=auth from=openai-codex/gpt-5.4 profile=sha256:......067eeb rawError=unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f13.....e29ae-CPH, request id: sha25......04dd
09:54:56 [diagnostic] lane task error: lane=main durationMs=7967 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f138af...e29ae-CPH, request id: req_4418a55......3e61069a9e0a9b"
09:54:56 [diagnostic] lane task error: lane=session:agent:main:main durationMs=7967 error="unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f13.....ae-CPH, request id: req_4418......1069a9e0a9b"
09:54:56 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai-codex/gpt-5.4 reason=auth next=none detail=unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f138.....ae-CPH, request id: sha256......4dd

#

FallbackSummaryError: All models failed (2): openai/gpt-5.5: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f13.....c7-CPH, request id: req_2c97011......c4972dc4478023 (auth) | openai-codex/gpt-5.4: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9f138af34af.....PH, request id: req_4418a556d.....069a9e0a9b (auth)

rocky tulipBOT Apr 24, 2026, 7:58 AM

#

These logs do not look like “your account doesn’t have 5.5 yet”.

They look like auth broke before the model test even happened.

The key line is:

401 Unauthorized: Missing bearer or basic authentication in header
url: https://api.openai.com/v1/responses

That means OpenClaw made an OpenAI-family request without an auth header at all. So this is much more of an auth resolution / bad profile state problem than a GPT-5.5 entitlement problem.

Also this line matters:

#

requested=openai/gpt-5.5 candidate=openai-codex/gpt-5.4

So your last attempt was not a pure isolated 5.5 Codex-harness test. It fell back into the openai-codex path, and that path is currently sick.

Easiest next move

Keep the live agent on 5.4, then repair the Codex OAuth auth state:

openclaw models auth login --provider openai-codex

That is the right repair command, and the source actually clears stale profile lockouts when you do this.

Then check what OpenClaw thinks is usable:

#

openclaw models status --json
openclaw models auth-order get --provider openai-codex --json

What I want you to look for:

auth.unusableProfiles
whether the stale old openai-codex profile is still first in order

Then do the real isolated 5.5 smoke test

Run this exact command, unchanged:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \

#

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --model openai/gpt-5.5 --json

If that still fails, paste:

openclaw models status --json
openclaw models auth-order get --provider openai-codex --json
the full output of that exact smoke test

At this point, I’m pretty confident the blocker is broken openai-codex auth state, not missing GPT-5.5 access.

Docs:

#

That confirms it, this is not a 5.5-only problem anymore.

Both of these failing with the same error:

openai/gpt-5.5
openai-codex/gpt-5.4

and both saying:

401 Unauthorized: Missing bearer or basic authentication in header
url: https://api.openai.com/v1/responses

means your OpenClaw auth state is currently busted for OpenAI/Codex. The request is going out without auth.

Best next step

#

Re-do Codex OAuth cleanly:

openclaw models auth login --provider openai-codex

If the normal browser flow is flaky, use:

openclaw models auth login --provider openai-codex --device-code

Then verify auth, before touching 5.5 again

openclaw models status --probe --probe-provider openai-codex --json

#

openclaw models auth order get --provider openai-codex --json

What I care about in that output:

whether openai-codex probe comes back ok vs auth
whether the stale old profile is still being preferred
whether a profile is in cooldown / disabled state

Then test 5.5 safely

Keep the live agent on 5.4, and run only this one-shot test:

OPENCLAW_AGENT_RUNTIME=codex \
OPENCLAW_AGENT_HARNESS_FALLBACK=none \

#Switch to ChatGPT 5.5 issues

What to do next

What I’m confident about

Fastest workaround right now

Surgical fix

My recommendation

Do this now

1) Roll back to the working model + force PI

2) Check basic health

One thing that may still block recovery

Then test from a truly fresh Slack session

If it is still dead everywhere

Fastest way to get it alive again

1) Put the default model back on the known-good route

2) If you previously set a model allowlist, add 5.4 back

3) Restart

Then fix the broken Slack conversation

Important

If that Slack chat is still cursed

In terminal

In Slack

If that chat is still cursed

If it still won’t come back

How to read the result

Important

Easiest next move

Then do the real isolated 5.5 smoke test

Best next step

Then verify auth, before touching 5.5 again

Then test 5.5 safely