#Cannot get Codex to work. Upgraded from 4.15 to 5.7.

1 messages · Page 1 of 1 (latest)

dense hamlet
#

I have configured Codex, have an active subscription and /codex commands are working, but when I try to chat with my agent, I get this error - Tried in both webchat and TUI:

hi

⚠️ Agent failed before reply: No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.5, or set OPENAI_API_KEY for direct OpenAI API access. | No API
key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.5, or set OPENAI_API_KEY for direct OpenAI API access.
Logs: openclaw logs --follow

/codex status

Codex app-server: connected
Models: gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex, gpt-5.2

Account: MASKED@gmail.com
Rate limits: Codex: primary 1%, resets in 5 hours (2026-05-12T22:52:46.000Z), secondary 0%, resets in 7 days (2026-05-19T17:52:46.000Z)
MCP servers: 1
Skills: 1

/codex models

Codex models:

  • gpt-5.5 (default)
  • gpt-5.4
  • gpt-5.4-mini
  • gpt-5.3-codex
  • gpt-5.2
    connected | idle

one thing that is odd is the active model is showing as sonnet which is not even the agents default model

agent coder (Coder) | session main (openclaw-tui) | litellm/claude-sonnet-4-6 | tokens 24k/1.0m (2%)

sonic caveBOT
#

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

hoary kindleBOT
#

That error usually means the chat session is routed to the OpenAI provider path without a usable OpenAI API key / Codex-auth mapping. /codex status being connected only proves the Codex app-server side works; the normal agent chat still has to resolve its model + auth route.

First, please check exact version:

openclaw --version

Then try this recovery path:

openclaw doctor --fix
openclaw config validate
openclaw models status
openclaw models auth list --provider openai-codex
openclaw config get agents.defaults.model --json
openclaw config get auth.order.openai --json
#

For current OpenClaw, the normal Codex-subscription agent setup is generally:

{
  agents: {
    defaults: {
      model: { primary: "openai/gpt-5.5" }
    }
  },
  auth: {
    order: {
      openai: ["openai-codex:YOUR_PROFILE_NAME"]
    }
  }
}

So don’t read openai/gpt-5.5 as “must use OPENAI_API_KEY” — with the openai-codex auth profile in auth.order.openai, it should route through Codex subscription auth.

#

The litellm/claude-sonnet-4-6 shown in the TUI is also suspicious: that likely means this session or the coder agent has a stale model pin/override, even if your global default is different. In the TUI/webchat, try switching that session explicitly to openai/gpt-5.5 with the model picker/command, or start a fresh session after doctor --fix.

Relevant docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/concepts/agent-runtimes

If it still fails, paste the redacted output of openclaw models status and openclaw models auth list --provider openai-codex — that should show whether this is missing auth order vs a stale session route pin.

dense hamlet
#

🦞 OpenClaw 2026.5.7 (eeef486) — Your .env is showing; don't worry, I'll pretend I didn't see it.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : litellm/gemini/gemini-3-flash-preview
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : gemini3flash -> litellm/gemini/gemini-3-flash-preview
Configured models (2): litellm/gemini/gemini-3-flash-preview, openai/gpt-5.5

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

  • litellm effective=env:sk-S...9A | env=sk-S...9A | source=env: LITELLM_API_KEY | models.json=sk-S...9A | source=models.json: ~/.openclaw/agents/main/agent/models.json
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:MASKED=OAuth (MASK)

OAuth/token status
^[[A^[[A^[[A- openai-codex usage: 5h 99% left ⏱4h 59m · Week 100% left ⏱6d 23h

  • openai-codex:MASKED (MASKED) ok expires in 10d
    devuser@warm-9u7i6c9q:~/.openclaw$ openclaw models auth list --provider openai-codex

🦞 OpenClaw 2026.5.7 (eeef486) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Agent: main
Auth state file: ~/.openclaw/agents/main/agent/auth-state.json
Provider: openai-codex
Profiles:

  • openai-codex:MASKED (MASKED) [openai-codex/oauth; expires 2026-05-22T17:48:19.561Z]
    devuser@warm-9u7i6c9q:~/.openclaw$
hoary kindleBOT
#

Good, that narrows it down. Your Codex OAuth profile exists and is healthy, but your active/default model is not Codex:

Default: litellm/gemini/gemini-3-flash-preview
Configured models: ..., openai/gpt-5.5

So the failure is likely from a session/agent selecting openai/gpt-5.5 while OpenClaw has no auth.order.openai entry telling it to use your openai-codex:MASKED OAuth profile for OpenAI-model agent turns.

Please check:

openclaw config get auth.order.openai --json
openclaw config get agents.defaults.model --json
openclaw config get agents.coder.model --json

If auth.order.openai is empty/missing, set it to your exact profile id from the auth list:

#
openclaw config set auth.order.openai '["openai-codex:MASKED"]'
openclaw gateway restart

Replace openai-codex:MASKED with the real profile id shown by openclaw models auth list --provider openai-codex.

Then either start a fresh chat session or switch the current TUI session model to:

openai/gpt-5.5

Also: the litellm/claude-sonnet-4-6 display you saw is almost certainly a stale/session-level override or the coder agent config, not your global default. The agents.coder.model command above should confirm that.

dense hamlet
#

my main agent is not codex, correct, but my coder agent needs to use codex, and it is set as default for that agent.

cat: .env: No such file or directory
devuser@warm-9u7i6c9q:~/.openclaw$ openclaw config get auth.order.openai --json
openclaw config get agents.defaults.model --json
openclaw config get agents.coder.model --json
[
"openai-codex:ayoungblood84@gmail.com"
]
{
"primary": "litellm/gemini/gemini-3-flash-preview"
}
Config path not found: agents.coder.model

#

There it is.

hoary kindleBOT
#

Yep — you’re right, and I gave you the wrong config path for that check. Per-agent config lives under agents.list[], not agents.coder.*. Sorry, claws slipped there 🦞

The next thing I’d check is whether the coder agent’s own isolated auth store has the Codex profile. Multi-agent auth/state is per-agent, so main can have Codex OAuth while coder does not.

Run these:

openclaw agents list --bindings
openclaw models status --agent coder
openclaw models auth list --agent coder --provider openai-codex
openclaw config get agents.list --json

In agents.list, the coder entry should look roughly like:

{
  id: "coder",
#
  model: { primary: "openai/gpt-5.5" }
}

If models auth list --agent coder --provider openai-codex is empty, sign in for that agent specifically:

openclaw models auth login --agent coder --provider openai-codex
openclaw gateway restart

If coder does have the profile, then I’d suspect stale session routing from the upgrade. Run:

openclaw doctor --fix
openclaw gateway restart
#

Then start a fresh coder session instead of continuing the old one. The litellm/claude-sonnet-4-6 line still looks like an old session/model pin, not the current desired coder default.

#

Nice — glad we found it. For anyone else hitting this after an upgrade: multi-agent auth is isolated, so the main agent having openai-codex OAuth doesn’t automatically mean the coder agent has it too.

Fix is the agent-specific login:

openclaw models auth login --agent coder --provider openai-codex
openclaw gateway restart

Then start a fresh coder session.

If that fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person. 🦞

dense hamlet
#

odd, I have the model selected under agents.list.coder.model -- is that not the correct place?

"list": [
{
"id": "main",
"default": true,
"subagents": {
"allowAgents": [
"coder",
"main"
]
}
},
{
"id": "coder",
"name": "Coder",
"workspace": "/home/devuser/.openclaw/workspace-coder",
"agentDir": "/home/devuser/.openclaw/agents/coder/agent",
"model": "openai/gpt-5.5",
"identity": {
"name": "Coder",
"emoji": " ^=^r "
},
"tools": {
"profile": "coding"
}
}
]
},

hoary kindleBOT
#

Yes — that is the correct place for the coder agent’s model.

The missing distinction is: agents.list[].model selects the model, but it does not copy auth into that agent. Because you set:

agentDir: "/home/devuser/.openclaw/agents/coder/agent"

coder has its own auth store separate from main:

~/.openclaw/agents/coder/agent/auth-profiles.json

So this config is valid:

#
{
  id: "coder",
  model: "openai/gpt-5.5"
}

…but coder still needs a usable openai-codex profile in its own auth store, or the OpenAI model route falls through to “No API key found for provider openai”.

Check it with:

openclaw models auth list --agent coder --provider openai-codex
openclaw models status --agent coder

If empty, run:

#
openclaw models auth login --agent coder --provider openai-codex
openclaw gateway restart

Also tiny CLI nuance: agents.list.coder.model isn’t a real config path because list is an array. That’s why openclaw config get agents.coder.model failed earlier. Use openclaw config get agents.list --json to inspect per-agent entries.

dense hamlet
#

devuser@warm-9u7i6c9q:~/.openclaw$ openclaw models auth list --agent coder --provider openai-codex

🦞 OpenClaw 2026.5.7 (eeef486) — Your .zshrc wishes it could do what I do.

Agent: coder
Auth state file: ~/.openclaw/agents/coder/agent/auth-state.json
Provider: openai-codex
Profiles:

  • openai-codex:ayoungblood84@gmail.com (MASKED) [openai-codex/oauth; expires 2026-05-22T17:48:19.561Z]
    devuser@warm-9u7i6c9q:~/.openclaw$ openclaw config get agents.list --json
    [
    {
    "id": "main",
    "default": true,
    "subagents": {
    "allowAgents": [
    "coder",
    "main"
    ]
    }
    },
    {
    "id": "coder",
    "name": "Coder",
    "workspace": "/home/devuser/.openclaw/workspace-coder",
    "agentDir": "/home/devuser/.openclaw/agents/coder/agent",
    "model": "openai/gpt-5.5",
    "identity": {
    "name": "Coder",
    "emoji": "💻"
    },
    "tools": {
    "profile": "coding"
    }
    }
    ]
    devuser@warm-9u7i6c9q:~/.openclaw$
hoary kindleBOT
#

Ah — this is the missing piece. Your model is in the right place, but on 2026.5.7 openai/gpt-5.5 alone does not necessarily select the native Codex runtime for that agent.

For the coder agent, add the runtime override too:

{
  "id": "coder",
  "name": "Coder",
  "workspace": "/home/devuser/.openclaw/workspace-coder",
  "agentDir": "/home/devuser/.openclaw/agents/coder/agent",
  "model": "openai/gpt-5.5",
  "agentRuntime": { "id": "codex" },
  "identity": {
    "name": "Coder",
    "emoji": "💻"
  },
#
  "tools": {
    "profile": "coding"
  }
}

Then:

openclaw config validate
openclaw gateway restart

And start a fresh coder session, or /reset / /new the current one. In 2026.5.7, harness choice is session-pinned after the first run, so an old session can keep showing OpenClaw Pi Default / weird stale model state even after config changes.

Expected check after restart:

#
openclaw models status --agent coder

You want it to show openai/gpt-5.5 with the Codex/OpenAI Codex runtime, not PI trying direct OpenAI API auth.

Docs for this version say the same thing: model: "openai/gpt-5.5" + agentRuntime: { id: "codex" } for native Codex; openai-codex/gpt-5.5 was the older PI Codex-OAuth route.

dense hamlet
#

something is majorly boorked (broken). Now when I try to chat it bricks openclaw. 'openclaw config validate' just freezes with no reponse. chat is frozen, tui swallon /status and /codex status

hoary kindleBOT
#

Oof — yeah, stop trying chat commands for a minute. If openclaw config validate hangs, that’s below normal model/auth troubleshooting; validation is supposed to be local and quick.

First recover to a known-good-ish state:

# cancel any stuck validate/chat process with Ctrl-C first
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-codex-runtime

If you added this line:

"agentRuntime": { "id": "codex" },

remove just that line from the coder entry for now, then try:

#
timeout 20s openclaw config validate --json; echo "exit=$?"
openclaw gateway status
openclaw status --all

If validation still hangs even after removing agentRuntime, please paste the last ~80 lines from:

openclaw logs --follow

You can stop it after it prints the recent tail.

Also run this targeted status if the CLI isn’t wedged:

#
timeout 20s openclaw models status --agent coder; echo "exit=$?"

My suspicion now is either:

  1. a stale/hung Codex app-server/runtime session got pinned and is blocking the gateway/TUI, or
  2. 2026.5.7 has a config/runtime edge case with per-agent agentRuntime after the 4.15 → 5.7 upgrade.

Either way, don’t keep restarting blindly yet — grab status --all/logs first if possible. If this is reproducible from valid config, it’s probably GitHub-issue territory.

dense hamlet
#

Still seem to be on the pi harness

hi
04:09 PM
Hi Adam. I’m here.
04:10 PM
/status
04:10 PM
Model: gpt-5.5 (openai) Tokens: in 19752 / out 150 Context: 26.3K/1049K (3%)
/codex status
04:10 PM
are you running the codex harness or the default runtime?
04:11 PM
You’re on the default OpenClaw runtime, not a separate Codex harness.

Status says: Runtime: OpenClaw Pi Default, Execution: direct, model openai/gpt-5.5.

hoary kindleBOT
#

That Tokens: in 19752 is the giveaway: you’re still in an existing session. On 2026.5.7, the harness/runtime is pinned per session after the first embedded run, so changing agents.list[].model / agentRuntime won’t move an already-created PI session to Codex.

Two checks:

openclaw config get agents.list --json
openclaw sessions --agent coder --json

Make sure the coder entry still has:

"model": "openai/gpt-5.5",
"agentRuntime": { "id": "codex" }

Then do all three in order:

#
openclaw gateway restart

Then in the UI/TUI, do a truly fresh session:

/new

or use the Control UI New Chat button. Don’t just type hi in the same thread/session — TUI especially can resume the last selected session.

After the fresh session, use the real /status output. If it still says Runtime: OpenClaw Pi Default, then the config isn’t being applied to the session/agent routing. At that point paste:

openclaw agents list --bindings
dense hamlet
#

here are the last few sessions:

devuser@warm-9u7i6c9q:~/.openclaw$ openclaw sessions --agent coder --json
{
"path": "/home/devuser/.openclaw/agents/coder/sessions/sessions.json",
"count": 22,
"totalCount": 22,
"limitApplied": 100,
"hasMore": false,
"activeMinutes": null,
"sessions": [
{
"key": "agent:coder:main",
"updatedAt": 1778616944572,
"ageMs": 55313,
"sessionId": "99b0e4e8-9fc1-4854-8590-c27b584e60a1",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 399,
"outputTokens": 49,
"totalTokens": 26895,
"totalTokensFresh": true,
"model": "gpt-5.5",
"modelProvider": "openai",
"contextTokens": 272000,
"agentId": "coder",
"agentRuntime": {
"id": "codex",
"source": "agent"
},
"kind": "direct"
},
{
"key": "agent:coder:subagent:6ce1d25e-b61c-49e2-a4d0-3202df4293c4",
"updatedAt": 1778612958411,
"ageMs": 4041823,
"sessionId": "0f8fdac1-c206-4126-b0b8-d5b954acc7c0",
"abortedLastRun": false,
"inputTokens": 841,
"outputTokens": 111,
"totalTokens": 36041,
"totalTokensFresh": true,
"model": "gpt-5.5",
"modelProvider": "openai",
"providerOverride": "openai",
"modelOverride": "gpt-5.5",
"contextTokens": 272000,
"agentId": "coder",
"agentRuntime": {
"id": "codex",
"source": "agent"
},
"kind": "direct"
},

hoary kindleBOT
#

That session dump actually says the opposite: the coder session is now pinned to Codex correctly:

"agentRuntime": {
  "id": "codex",
  "source": "agent"
}

So for agent:coder:main, OpenClaw believes the runtime is Codex. Good news: your config is being picked up now.

The remaining mismatch is likely one of these:

  1. You’re looking at /status from a different active session/agent than agent:coder:main.
  2. The model’s answer to “are you running codex?” is just a hallucinated/self-report — ignore that.
  3. Web/TUI has an older selected session cached even though the coder store now has a Codex session.
#

Can you run these and compare keys?

openclaw sessions --all-agents --active 30 --json
openclaw agents list --bindings
openclaw models status --agent coder

In the UI/TUI, the important thing is that the active session key should be:

agent:coder:main

and its session row should show:

#
agentRuntime.id = codex

If /status truly still prints Runtime: OpenClaw Pi Default while openclaw sessions --agent coder --json shows agentRuntime.id: codex for the same session key, that’s a bug in status reporting or session selection. At that point I’d file it with the session JSON + /status output: https://github.com/openclaw/openclaw/issues

dense hamlet
#

when I run '/status' on coder, it gets swalled. Is that normal? On both TUI and webchat

hoary kindleBOT
#

No — a bare /status getting swallowed in both TUI and WebChat is not normal.

Expected behavior:

  • /status should be handled locally by OpenClaw and print a status card.
  • It should not be sent to the model.
  • If commands are unavailable/unauthorized, it should still usually log why, not silently disappear.

Since your session store now shows:

"agentRuntime": { "id": "codex", "source": "agent" }

…but the UI command is getting eaten, I’d stop diagnosing from chat and check gateway logs/CLI state directly:

#
openclaw sessions --agent coder --json
openclaw status --all
openclaw logs --follow

Then, while logs are following, send /status once from WebChat/TUI and look for lines like:

Ignoring /status ...
command ...
agent:coder:main

Also try the CLI status equivalent if available in your build:

#
openclaw sessions --agent coder --active 30 --json
openclaw models status --agent coder

One important nuance: /codex status may be swallowed if the native Codex command handler/plugin path is stuck or not enabled for that surface, but plain /status should not be. If plain /status vanishes with no reply, that’s likely a command-dispatch/session-selection bug, not a Codex auth problem anymore.

At this point I’d capture:

openclaw --version
openclaw status --all
openclaw agents list --bindings
openclaw sessions --agent coder --json

plus the log lines around the swallowed /status, and file it: https://github.com/openclaw/openclaw/issues

dense hamlet
#

Hum. Something is buggy, and I had to reboot my LXC but I think it is working now. Very slow, but working. Without "fast" on, how long should the typical response be using 5.5 and the codex harness?

hoary kindleBOT
#

Yeah, an LXC reboot fixing it points to something runtime/process-level getting wedged, not just config. Glad it’s moving again.

For gpt-5.5 + Codex harness without /fast on, I’d expect rough ballparks like:

  • simple chat/status-ish answer: ~5–20s
  • normal coding answer with context/tools: ~20–90s
  • first turn after restart / large workspace / big session: 1–3+ minutes isn’t shocking
  • repeated multi-tool coding turns can be several minutes

If it’s taking 5+ minutes for a plain “hi” or /status is delayed/swallowed, that’s not normal.

Things that make it feel slow:

  • cold Codex app-server start after gateway/LXC reboot
  • huge session/context; your earlier status showed ~26k context, not terrible, but still non-trivial
  • default contextTokens for 5.5 is large (272k cap), which is safer but can add latency
  • Codex subscription quota/service tier; /fast on maps to priority service tier where supported
dense hamlet
#

if I want to see a short summary of what codex is doing, how would I enable that?

hoary kindleBOT
#

For a short “what is it doing?” view, use verbose minimal:

/verbose on

or inline for one message:

/verbose: fix the failing tests

That should show compact progress/tool summaries without dumping full outputs. Avoid /verbose full unless debugging; it can get noisy.

For Discord preview-style progress, config is usually:

#
channels: {
  discord: {
    streaming: {
      mode: "progress",
      progress: {
        toolProgress: true,
        maxLines: 8,
        commandText: "status"
      }
    }
  }
}

commandText: "status" keeps it short; raw shows more command detail.