Discord Integration Connected But Bot Not Responding

[fierce herald]

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

[opal whale]

Since sessions are being created, Discord ingress and session routing are probably working. I’d split this into: “agent run never produces a final reply” vs “final reply produced, Discord send fails.”

Next checks I’d run:

openclaw status --all
openclaw gateway status
openclaw models status
openclaw channels status --probe --json
openclaw channels capabilities --channel discord --target channel:<DISCORD_CHANNEL_ID>
openclaw channels logs --channel discord --lines 300
openclaw logs --limit 500 --local-time

Then tail logs while sending one fresh Discord mention:

openclaw logs --follow --local-time

Search that window for these signatures:

• discord inbound: -> message reached the Discord handler and was dispatched
• discord ... reply failed -> agent produced a reply, but outbound Discord delivery failed
• discord missing permissions in channel ... -> bot can read/create sessions but cannot post in that exact channel/thread; check Send Messages in Threads too
• Slow listener detected / discord/event-queue -> Discord event handler is stuck or very slow
• drop guild message (mention required, pairing request, blocked, allowlist -> policy/gating, even if status says OK
• openai-codex, auth, model, dispatch, agent run errors -> runtime/model side before final delivery

If the logs show discord inbound: but never show either delivered ... replies or discord ... reply failed, I’d focus on the model/runtime path: run openclaw models status, try a tiny direct model check from the same VPS, and inspect the active session with:

openclaw sessions --all-agents --active 120 --verbose
openclaw sessions --all-agents --active 120 --json

If they do show a reply failure, paste the exact redacted error line. The Discord send path now tries to turn Discord REST failures into useful messages, especially missing ViewChannel, SendMessages, SendMessagesInThreads, or AttachFiles.

Docs that match this flow:
https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken
https://docs.openclaw.ai/channels/troubleshooting
https://docs.openclaw.ai/channels/discord
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/gateway/logging

One extra note: file logs only get verbose-only details if logging.level is debug or trace; openclaw gateway --verbose affects console/WS logging, not the file log level.

[waxen sapphire]

I'm having the same issue, ug to 5.22 today and discord is not working and it used to work pretty smooth

[opal whale]

If this started right after upgrading to 2026.5.22, please grab a fresh log window while sending one Discord mention/message. That will tell us whether it is Discord delivery or the agent runtime stalling.

Run:

openclaw --version
openclaw status --all
openclaw channels status --probe --json
openclaw channels logs --channel discord --lines 300
openclaw logs --follow --local-time

While openclaw logs --follow is running, send one test message in Discord, then look for/paste the smallest redacted snippet around:

• discord inbound:
• discord ... reply failed
• discord missing permissions in channel

[opal whale]

• Slow listener detected
• openai-codex, auth, model, or agent run

If ingress creates sessions but logs never show a final reply or send failure, that points more toward runtime/model routing after the upgrade. If there is a discord ... reply failed line, it is usually outbound Discord REST/permission/thread delivery.

[opal whale]

Thanks, that status output is useful. The key line is:

Inbound delivery telemetry: received 1 · dispatch 1/1 · turns 1 · processed 1

So Discord ingress is working and OpenClaw thinks the turn was processed. The missing piece is whether the agent produced a final reply and Discord delivery failed, or whether the run completed without a sendable final message.

Next, please run this while sending one fresh test mention/message:

openclaw logs --follow --local-time

Then paste the smallest redacted chunk around that test message, especially any lines containing:

discord inbound:

[opal whale]

discord: delivered
discord ... reply failed
discord missing permissions
dispatch-from-config
agent run
openai-codex
model
auth

Also run the Discord target permission probe against the exact channel/thread where you expect the bot to answer:

openclaw channels capabilities --channel discord --target channel:1508213426684694708

[opal whale]

If this is a Discord thread/forum thread, missing Send Messages in Threads can look exactly like “connected, sessions created, no reply.” If the capabilities probe is clean and logs show no reply failed, then we should look at the runtime/model side next.

[opal whale]

That log pins it down: this is not Discord delivery.

The failing line is:

Embedded agent failed before reply: auth refresh request timed out after 10s

So Discord receives the message, creates/dispatches the session, then the selected model profile (openai-codex/gpt-5.5) fails while refreshing auth before it can generate a reply. That’s why the bot looks “connected but silent.”

Next steps:

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

If the probe shows timeout/auth/expired for the OpenAI Codex profile, re-auth that provider:

[opal whale]

openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart

Then send one Discord test message and tail:

openclaw logs --follow --local-time

A temporary workaround, if you have a normal OpenAI API key profile available, is to switch the agent default away from Codex OAuth to an API-key-backed model/provider. The core issue is the openai-codex OAuth refresh path timing out, not Discord permissions.

If re-auth does not fix it on 2026.5.22, this is worth filing as a GitHub issue with the redacted log snippet and version info:
https://github.com/openclaw/openclaw/issues

Relevant docs:

[opal whale]

https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/gateway/troubleshooting

[torpid ore]

still not getting anywhere, agent will start typing then get stuck

[opal whale]

Typing means the Discord handler got past ingress and started the agent run. If it then hangs, we need the new log lines from the stuck run, not status output.

Please run this, send one fresh Discord message, wait until it has been “typing” for ~30-60s, then paste the redacted chunk from that window:

openclaw logs --follow --local-time --max-bytes 1000000

Also run these after it gets stuck:

openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw sessions --all-agents --active 120 --verbose
openclaw status --all

Given your previous log, my current read is still: Discord is fine, the agent runtime is hanging/failing around openai-codex auth refresh/model execution. If you re-authed and it still stalls, try switching temporarily to a non-Codex OAuth model/profile you already have working, then restart the gateway. If that makes Discord replies work, it confirms the regression is in the Codex auth/runtime path rather than Discord.

[opal whale]

If the new log again contains auth refresh request timed out after 10s after re-auth, I’d file that as a 2026.5.22 bug with the redacted log and your openclaw status --all output:
https://github.com/openclaw/openclaw/issues

[torpid ore]

can you help me troubleshoot why responses take so long now? They used to be almost instant.

Claw finally responded

[opal whale]

Yep. Since it eventually responded, this has shifted from “Discord cannot send” to “agent run latency.”

From your earlier logs, the big delay was here:

durationMs=73141 error="auth refresh request timed out after 10s"

That means runs were spending ~70s failing/retrying/fallback handling around the openai-codex auth/model path before any reply could be sent. Discord typing is just the visible symptom.

For the next slow response, capture phase timings:

openclaw logs --follow --local-time --max-bytes 1000000

Look for these around one message:

• discord inbound: time = Discord received/routed it

[opal whale]

• agent/embedded, model-fallback/decision, auth_profile_failure_state_updated = model/auth delay
• Embedded agent failed before reply = no model reply produced
• discord: delivered ... replies = Discord send completed

Also run:

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

If openai-codex probe is slow/timeout, the fastest isolation test is to temporarily switch to a different already-working provider/profile, restart the gateway, and test Discord again. If responses become instant, the delay is the Codex OAuth/provider path, not Discord.

For a durable fix, I’d do this order:

[opal whale]

openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
openclaw models status --probe-provider openai-codex --probe-timeout 30000

If it still has long auth-refresh/model timeouts on 2026.5.22 after re-auth, file it with the redacted timing logs:
https://github.com/openclaw/openclaw/issues

[opal whale]

This log is pretty conclusive. The delay is not Discord.

You have two latency sources stacked:

1. provider auth state pre-warmed in 38575ms eventLoopMax=28286.4ms

   • Gateway event loop was blocked for up to 28s during auth prewarm. That will make everything feel stuck.

2. The active Discord run then sat in embedded_run and failed after:

   • durationMs=156873
   • auth refresh request timed out after 10s
   • provider/model: openai-codex/gpt-5.5
   • last progress: codex_app_server:notification:error

So the agent is typing because Discord started the run, but the OpenAI Codex auth/app-server path is timing out and tying up the main lane. The “queued_behind_active_work” line explains why later replies also feel slow.

I’d stop testing Discord for now and isolate the model path:

[opal whale]

openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
openclaw models status --probe-provider openai-codex --probe-timeout 30000

If that probe still times out, switch the agent temporarily to a different working provider/profile so the Discord bot is usable again. If you have an OpenAI API key profile configured, use that instead of openai-codex OAuth for now. Then restart the gateway and test one Discord message.

The CPU/event-loop warning is also worth checking on the VPS:

top
free -h
systemctl --user status openclaw-gateway

[opal whale]

But the repeated root error is still the Codex auth refresh timeout. If re-auth + restart doesn’t fix it, please file this as a 2026.5.22 issue with this redacted log. Include these exact signals: provider auth state pre-warmed in 38575ms, eventLoopMax=28286.4ms, codex_app_server:notification:error, and auth refresh request timed out after 10s.

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

The VPS itself looks healthy there: low load, CPU mostly idle, enough memory. So this is not a general CPU/RAM exhaustion issue.

Two notes from that paste:

1. Your command got mashed together:

top
-h
systemctl --user status openclaw-gateway

Run these separately instead:

free -h
systemctl --user status openclaw-gateway --no-pager

ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

2. The login banner says:

*** System restart required ***

Given the gateway had huge event-loop stalls and the machine has been up 19 days, I’d do a clean reboot as a practical reset after you’ve saved any work:

sudo reboot

After it comes back:

openclaw gateway status
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw logs --follow --local-time --max-bytes 1000000

Then send one Discord test message.

If the OpenAI Codex probe still times out after reboot + re-auth, stop burning time on Discord settings. The remaining issue is the openai-codex auth/runtime path on 2026.5.22. Temporary workaround: switch the agent to a different working provider/profile, restart gateway, and file the Codex timeout logs as a GitHub issue.

This explains the event-loop warnings better: the OpenClaw gateway process itself is burning CPU.

/usr/bin/node ... openclaw/dist/index.js   29.6% CPU

And there are multiple Codex child/app-server processes under it. That matches the repeated codex_app_server:notification:error + auth refresh timeout loop.

I’d do a clean reset of just OpenClaw first, then reboot if it comes back weird:

openclaw gateway restart
sleep 10
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw models status --probe-provider openai-codex --probe-timeout 30000

If the old Codex child processes remain after openclaw gateway restart, use systemd so the whole user service tree is stopped/started:

systemctl --user restart openclaw-gateway
sleep 10
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

If CPU stays high or the probe still times out, reboot the VPS. The machine already says restart required, and this smells like a wedged Codex auth/app-server child path.

After reboot/restart, don’t test Discord first. Run the model probe first. If openai-codex is still slow/timeout, switch away from Codex OAuth temporarily or file the 2026.5.22 issue.

[torpid ore]

[REDACTED_USER]@[REDACTED_HOST]:~$ openclaw gateway restart
│
◇
Config warnings:

• plugins.entries.telegram: plugin disabled (disabled in config) but config is present

OpenClaw 2026.5.22 (a374c3a) — Your AI assistant, now without the $3,499 headset.

│
◇ Config warnings ────────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.telegram: plugin disabled (disabled in config) but config is present │
│ │
├──────────────────────────────────────────────────────────────────────────────────────────╯
Restarted systemd service: openclaw-gateway.service

[REDACTED_USER]@[REDACTED_HOST]:~$ sleep 10

[REDACTED_USER]@[REDACTED_HOST]:~$ ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
PID PPID ELAPSED STAT %CPU %MEM CMD
[REDACTED_PID] [REDACTED_PID] 00:55 Sl 1.1 0.9 node server.mjs
[REDACTED_PID] 1 00:52 Sl 0.3 0.7 node /home/[REDACTED_USER]/.openclaw/workspace/scripts/twitter_stream_bridge.mjs
[REDACTED_PID] [REDACTED_PID] 00:16 Rsl 112 10.2 /usr/bin/node /home/[REDACTED_USER]/.npm-global/lib/node_modules/openclaw/dist/index.js

[REDACTED_USER]@[REDACTED_HOST]:~$ openclaw models status --probe-provider openai-codex --probe-timeout 30000

Config warnings:

• plugins.entries.telegram: plugin disabled (disabled in config) but config is present

OpenClaw 2026.5.22 (a374c3a) — Your AI assistant, now without the $3,499 headset.

Config warnings:

• plugins.entries.telegram: plugin disabled (disabled in config) but config is present

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -

Aliases (2):

• gpt -> openai/gpt-5.4
• opus -> anthropic/claude-opus-4-7

Configured models (4):

• openai/gpt-5.4
• openai/gpt-5.5
• anthropic/claude-opus-4-7
• openai/gpt-5.5-codex

Auth overview

Auth store:
~/.openclaw/agents/main/agent/auth-profiles.json

Shell env:
off

Providers w/ OAuth/tokens (3):

• anthropic (2)

• claude-cli (2)

• openai-codex (3)

• anthropic
  effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json
  profiles=2 (oauth=1, token=1, api_key=0)
  anthropic:default=token:[REDACTED_TOKEN]

  anthropic:claude-cli=OAuth

• claude-cli
  effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json
  profiles=2 (oauth=1, token=1, api_key=0)

  anthropic:default=token:[REDACTED_TOKEN]
  anthropic:claude-cli=OAuth

  synthetic=plugin-owned
  source=Claude CLI native auth

• openai-codex
  effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json
  profiles=3 (oauth=3, token=0, api_key=0)

  openai-codex:default=OAuth ([REDACTED_EMAIL])
  openai-codex:[REDACTED_EMAIL]=OAuth ([REDACTED_EMAIL])
  openai-codex:[REDACTED_EMAIL]=OAuth ([REDACTED_EMAIL])

  synthetic=plugin-owned
  source=codex-app-server

Runtime auth

• openai via codex uses openai-codex
  effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json
  status=usable

OAuth/token status

• anthropic

  • anthropic:default static

• claude-cli

  • anthropic:claude-cli expired expires in 0m

• openai-codex

  • openai-codex:default ([REDACTED_EMAIL]) static
  • openai-codex:[REDACTED_EMAIL] ([REDACTED_EMAIL]) static
  • openai-codex:[REDACTED_EMAIL] ([REDACTED_EMAIL]) static

[REDACTED_USER]@[REDACTED_HOST]:~$

[opal whale]

This output adds two important clues:

1. The gateway is pegging a core right after restart:

openclaw/dist/index.js ... 112% CPU

That is not normal steady state. Wait 60-90s after restart and run the same ps again. If it stays high, the gateway is stuck doing startup/auth/plugin work.

2. Your default is:

Default: openai/gpt-5.5
Runtime auth: openai via codex uses openai-codex

So even though the default says openai/..., it is routing through openai-codex, which matches the auth refresh timeout logs. Also, your models status output says “usable”, but it did not disprove the runtime timeout because the actual Discord run is failing inside the Codex app-server/auth path.

Fastest workaround to confirm this:

[opal whale]

openclaw models set opus
openclaw gateway restart
sleep 30
openclaw models status

Then send one Discord test message. Your output shows opus is already an alias to your configured Anthropic provider, so this should bypass the Codex auth/app-server path. If Discord becomes fast again, we have confirmed the regression is Codex runtime/auth, not Discord.

After that, you can repair Codex separately:

openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
sleep 60
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

[opal whale]

openclaw logs --limit 300 --local-time --max-bytes 1000000

If gateway CPU remains high or logs keep showing auth refresh request timed out after 10s, I’d file the issue. The useful repro summary is: 2026.5.22, default openai/gpt-5.5 routes via openai-codex, gateway pegs CPU after restart, Discord run hangs in embedded_run, then fails with auth refresh request timed out after 10s.

Docs: https://docs.openclaw.ai/cli/models

[torpid ore]

please confirm exactly what i need to run now

[opal whale]

Run this exact sequence. It switches you temporarily to the opus alias so Discord bypasses the slow Codex path, restarts, then verifies CPU/model state.

openclaw models set opus
openclaw gateway restart
sleep 60
openclaw models status
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw logs --limit 300 --local-time --max-bytes 1000000

Then send one test message to your Discord bot.

If it replies quickly, the Discord integration is fine and the problem is confirmed as the openai-codex auth/runtime path. Stay on opus for now, then file the Codex timeout issue.

If it is still slow, paste the output from those commands plus the fresh log lines around the test message.

[torpid ore]

why am i setting model to opus

[opal whale]

Only as a temporary isolation test.

Your logs show the slow/failing path is:

openai/gpt-5.5 -> Runtime auth: openai via codex uses openai-codex
auth refresh request timed out after 10s
codex_app_server:notification:error

So even though your default displays as openai/gpt-5.5, OpenClaw is using the openai-codex auth/runtime underneath. That is the path timing out and making Discord appear stuck.

Your models status output showed this alias already exists:

opus -> anthropic/claude-opus-4-7

[opal whale]

Setting opus bypasses Codex entirely. If Discord becomes fast, we’ve proven Discord is fine and Codex auth/runtime is the culprit. It’s not meant as the final model choice unless you want it to be.

If you don’t want to switch models, skip that step and instead run:

openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
sleep 60
openclaw models status --probe-provider openai-codex --probe-timeout 30000

But given the repeated timeouts, switching to opus is the quickest way to get your bot usable while debugging Codex separately.

[opal whale]

Now the immediate problem is gateway reachability, before Discord/model testing:

Gateway service: running
Gateway RPC: unreachable (timeout)
Sessions: still OpenAI Codex

So the service process exists, but the gateway is not responding to local RPC. That usually means it is stuck during startup or blocked on work.

Run these exactly:

systemctl --user status openclaw-gateway --no-pager
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw gateway status

[opal whale]

openclaw logs --limit 500 --local-time --max-bytes 1000000

If the OpenClaw node ... openclaw/dist/index.js process is still high CPU, restart the user service tree once more:

systemctl --user restart openclaw-gateway
sleep 90
openclaw gateway status
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw logs --limit 500 --local-time --max-bytes 1000000

Also: your status still shows the Discord session using OpenAI Codex / gpt-5.5, so the model switch either was not run, did not persist for that existing session, or the stuck gateway prevented it from applying. Once the gateway is reachable again, run:

[opal whale]

openclaw models set opus
openclaw gateway restart
openclaw status

If the gateway keeps timing out even after reboot/restart, paste the latest openclaw logs --limit 500 output. The important thing now is to find what the gateway is blocked on during startup.

[opal whale]

Good, gateway RPC is reachable again, but the service is still hot:

openclaw/dist/index.js 85.9% CPU
long-running session: agent:main:discord:channel:...

First cancel the stuck Discord run from Discord itself. Send this as a standalone message to your bot/channel:

stop

Wait ~20 seconds, then run:

[opal whale]

ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw status

If CPU drops and status is responsive, then switch off Codex before sending another normal prompt:

openclaw models set opus
openclaw gateway restart
sleep 60
openclaw models status
openclaw status

Then test Discord once.

[opal whale]

If stop does not clear the long-running session and CPU stays high, don’t keep sending normal prompts. Restart the service and immediately switch models before testing:

systemctl --user restart openclaw-gateway
sleep 60
openclaw models set opus
openclaw gateway restart
sleep 60
openclaw status

The goal is to get the bot off the Codex runtime path before the next Discord turn re-enters the same timeout loop.

[opal whale]

Your paste is still showing the current Discord session on OpenAI Codex:

agent:main:discord:channel:... just now · gpt-5.4 · OpenAI Codex · 180k/272k

So do this in order, and don’t send any normal Discord prompts until the final test.

1. In Discord, send this as a standalone message to the bot/thread:

stop

2. On the VPS:

[opal whale]

openclaw models set opus
openclaw gateway restart
sleep 90
openclaw status

3. If the Discord session still shows OpenAI Codex, start a fresh session in Discord before testing:

/new

Then send one simple test message.

Why: the current Discord thread is a big existing Codex session. Changing the default model may not rewrite that active session. /new resets the chat session so it can pick up the new default.

[opal whale]

If openclaw status still says gateway unreachable after the restart, stop there and paste only:

openclaw gateway status
openclaw logs --limit 300 --local-time --max-bytes 1000000
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

[opal whale]

Good, this is progress.

Gateway is reachable now, and the default is switched:

Sessions · default claude-opus-4-7

But the existing Discord thread session is still pinned to:

agent:main:discord:channel:... · gpt-5.4 · OpenAI Codex

So the remaining step is to start a fresh Discord session so it picks up the new default.

In Discord, send this as a standalone message:

[opal whale]

/new

Wait for that to finish, then send one simple test like:

say hi

After that, run:

openclaw status

You want the Discord session row to show claude-opus-4-7 / non-Codex runtime. If it still shows OpenAI Codex after /new, paste the new status and we’ll check whether there’s a per-session or per-channel model override keeping that Discord thread pinned.

[torpid ore]

I want it on CODEX not claude....

this is what ive wanted the whole time

[opal whale]

Totally fair. The Claude switch was only a diagnostic workaround, not me saying you should stay there.

If you want to stay on Codex, switch it back and focus on fixing the Codex auth/runtime timeout:

openclaw models set openai/gpt-5.4
openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw status

Then in Discord start fresh so the session picks up the current model cleanly:

[opal whale]

/new

The reason I suggested opus was only because your logs repeatedly showed Codex failing here:

openai via codex uses openai-codex
auth refresh request timed out after 10s
codex_app_server:notification:error

So Codex is the thing we need to repair. If the probe still times out after re-auth + restart, keep Codex selected if that’s your preference, but please file it as a 2026.5.22 Codex auth/runtime bug with the redacted logs:
https://github.com/openclaw/openclaw/issues

[opal whale]

You’re right. I should have kept the goal tighter: keep Codex, fix why Codex got slow/stuck. Sorry for steering the workaround too hard.

Use this path instead:

openclaw models set openai/gpt-5.4
openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw status

Then send this in Discord as a standalone message so the Discord thread starts cleanly on the repaired Codex config:

[opal whale]

/new

If the probe or the next Discord run still shows auth refresh request timed out after 10s, that’s the bug we chase/file: Codex auth/runtime timeout on 2026.5.22. No more Claude detour.

[torpid ore]

im still getting this error, we need to fix

⚠️ Missing API key for OpenAI on the gateway. Use openai/gpt-5.5 with the Codex OAuth profile, or set OPENAI_API_KEY for direct OpenAI API-key runs.

we need to set to 5,5

[opal whale]

That error is because openai/gpt-5.4 is the direct OpenAI API-key route. Since you do not have OPENAI_API_KEY set, it fails.

For Codex subscription/OAuth, switch back to the Codex OAuth model ref, not direct OpenAI:

openclaw models set openai-codex/gpt-5.5
openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart
sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw status

Then in Discord, start a fresh session so the old openai/gpt-5.4 session does not keep using the bad route:

[opal whale]

/new

Then send one test message.

Short version:

• Want Codex OAuth/subscription auth: use openai-codex/gpt-5.5
• Want direct OpenAI API: use openai/gpt-5.4 and set OPENAI_API_KEY

You want the first one. Docs: https://docs.openclaw.ai/providers/openai

[opal whale]

Yes. For Codex OAuth + GPT-5.5, run exactly:

openclaw models set openai-codex/gpt-5.5
openclaw gateway restart
sleep 90
openclaw status

Then in Discord:

/new

After that, openclaw status should show the new Discord session using gpt-5.5 with the Codex OAuth/OpenAI Codex runtime, not openai/gpt-5.4.

[opal whale]

If it still complains about missing OPENAI_API_KEY, it means something is still selecting openai/gpt-5.4 or openai/gpt-5.5 direct OpenAI instead of openai-codex/gpt-5.5.

[torpid ore]

still not responding to any messages in discord. please help better troubleshoot this

[opal whale]

You’re right — let’s reset the troubleshooting loop and separate the layers cleanly. Don’t change providers now. We’ll prove exactly where it stops.

Run this sequence on the VPS, then send one fresh Discord test message:

date
openclaw --version
openclaw gateway status
openclaw models status
openclaw channels status --probe --json
openclaw channels capabilities --channel discord --target channel:1508213426684694708
openclaw logs --follow --local-time --max-bytes 2000000

While logs --follow is running, send one Discord message like:

[opal whale]

test reply please

Wait 90 seconds, then stop the log tail with Ctrl+C and paste the log chunk from that test window.

What I’m looking for:

• No discord inbound: / no delivery telemetry change → Discord ingress/routing problem.
• discord inbound: but no model/run lines → session dispatch/lane problem.
• auth refresh request timed out, codex_app_server:notification:error, Embedded agent failed before reply → Codex runtime/auth problem.
• discord ... reply failed or discord missing permissions → outbound Discord permission/thread send problem.
• discord: delivered ... replies but nothing appears in Discord → wrong target/thread or Discord API delivery mismatch.

Also run this right after the failed test:

[opal whale]

openclaw status --all
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

Important: your earlier logs already proved Discord can receive messages and create sessions. The remaining question is whether the current failure is still Codex auth/runtime, or whether the latest model reset changed the failure mode. The fresh 90-second log window will tell us.

[torpid ore]

i think its getting hung up on the claude model, how do we remove

[opal whale]

Yes. Don’t delete auth yet; just remove Claude from model selection/fallbacks so OpenClaw can’t route there.

Run this exact “Codex only” reset:

# See current model config first
openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json
openclaw models fallbacks list

# Set primary to Codex OAuth GPT-5.5
openclaw models set openai-codex/gpt-5.5

# Clear fallback routing so it cannot fall back to Claude
openclaw models fallbacks clear

[opal whale]

# Make the visible model allowlist Codex-only
openclaw config set agents.defaults.models '{"openai-codex/gpt-5.5":{"alias":"gpt"}}' --strict-json --replace

# Restart and verify
openclaw gateway restart
sleep 90
openclaw models status
openclaw status

Then in Discord, start a fresh session:

/new

[opal whale]

After that, the Discord session should show gpt-5.5 / OpenAI Codex, and there should be no Claude fallback in openclaw models status.

If you later want Claude back as an option, you can add it back with:

openclaw config set agents.defaults.models '{"anthropic/claude-opus-4-7":{"alias":"opus"}}' --strict-json --merge

But for now, Codex-only is the cleanest test.

[torpid ore]

heres doctor please troubleshoot

[opal whale]

This doctor output is the clearest signal so far, and it corrects part of what I told you earlier.

Your install now expects Codex intent to be represented as openai/* plus runtime policy, not legacy openai-codex/* model refs:

Legacy openai-codex/* model refs should be rewritten to openai/*.
Run openclaw doctor --fix

So yes: run the fixer. It says it will rewrite model refs and stale sessions to the current Codex routing shape.

Run exactly:

openclaw doctor --fix
sleep 30

[opal whale]

openclaw gateway status
openclaw status --all
openclaw models status

If openclaw gateway status still says gateway not running after that:

systemctl --user status openclaw-gateway --no-pager -l
journalctl --user -u openclaw-gateway -n 120 --no-pager
openclaw logs --limit 300 --local-time --max-bytes 1000000

Paste those outputs.

What I expect after doctor --fix:

[opal whale]

• configured model refs become openai/gpt-5.5...
• Codex intent moves to runtime policy/harness config
• stale Discord sessions stop being pinned to old openai-codex/*
• then /new in Discord should start a clean Codex-backed session

Also: don’t remove Claude right now. The doctor is not saying Claude is the blocker. It is saying your Codex model config is in an old shape and should be migrated.

[torpid ore]

is it because we changed something with the gateway target? its 127 should it be 0.0.0.0

[opal whale]

No — don’t change it to 0.0.0.0 for this problem.

127.0.0.1 is correct for a local gateway service. The Discord bot connects outbound to Discord, and local CLI/tools connect to the gateway over loopback. Binding to 0.0.0.0 only exposes the gateway on the network; it does not fix an internal gateway timeout, model auth timeout, or Discord response issue.

The evidence points elsewhere:

• Doctor found legacy Codex model refs and explicitly says run openclaw doctor --fix.
• Health check timed out even on local loopback, meaning the gateway process was running but not responding promptly.
• Earlier logs showed auth refresh request timed out after 10s and codex_app_server:notification:error.

So keep bind/target at 127.0.0.1. Next step remains:

openclaw doctor --fix
sleep 30
openclaw gateway status

[opal whale]

openclaw status --all
openclaw models status

Only consider non-loopback bind if you specifically need remote browsers/clients to connect directly to the gateway, and then you must lock it down with gateway auth/firewall/Tailscale. It’s not needed for Discord.

[torpid ore]

[REDACTED_USER]@[REDACTED_HOST]:~$ openclaw gateway status

Config warnings:

• plugins.entries.telegram: plugin disabled (disabled in config) but config is present

OpenClaw 2026.5.22 (a374c3a) — Your .zshrc wishes it could do what I do.

│
◇

Service:
systemd user (enabled)

File logs:
/tmp/openclaw/openclaw-2026-05-24.log

Command:
/usr/bin/node /home/[REDACTED_USER]/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port [REDACTED_PORT]

Service file:
~/.config/systemd/user/openclaw-gateway.service

Service env:
OPENCLAW_GATEWAY_PORT=[REDACTED_PORT]

Config (cli):
~/.openclaw/openclaw.json

Config (service):
~/.openclaw/openclaw.json

Gateway:
bind=loopback (127.0.0.1), port=[REDACTED_PORT] (service args)

Probe target:
ws://127.0.0.1:[REDACTED_PORT]

Dashboard:
http://127.0.0.1:[REDACTED_PORT]/

Probe note:
Loopback-only gateway; only local clients can connect.

Runtime:
running (pid [REDACTED_PID], state active, sub running, last exit 0, reason 0)

Warm-up:
launch agents can take a few seconds. Try again shortly.

Connectivity probe:
failed

Probe target:
ws://127.0.0.1:[REDACTED_PORT]
timeout

Capability:
unknown

Port [REDACTED_PORT] is already in use.

• pid [REDACTED_PID] [REDACTED_USER]:
  /usr/bin/node /home/[REDACTED_USER]/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port [REDACTED_PORT]
  (127.0.0.1:[REDACTED_PORT])

Listening:
127.0.0.1:[REDACTED_PORT]

Troubles:
run openclaw status

Troubleshooting:
https://docs.openclaw.ai/troubleshooting

[REDACTED_USER]@[REDACTED_HOST]:~$

[opal whale]

This means the gateway process is listening on the port but not answering the WebSocket probe. That is not a bind-address problem; it is a stuck or still-starting gateway process.

Give it one minute. If it still fails, collect the service logs and restart cleanly:

sleep 60
openclaw gateway status

If it still shows Connectivity probe: failed timeout, run:

journalctl --user -u openclaw-gateway -n 160 --no-pager -l
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw logs --limit 300 --local-time --max-bytes 1000000

[opal whale]

Then restart once:

systemctl --user restart openclaw-gateway
sleep 90
openclaw gateway status

If it still times out after that, the next practical reset is a full VPS reboot, especially since your login banner earlier said system restart required:

sudo reboot

After reboot:

[opal whale]

openclaw gateway status
openclaw doctor --fix
openclaw status --all

Do not switch to 0.0.0.0; the port is already listening locally. The gateway just isn’t responding.

[torpid ore]

its spent 5 minutes typing a response back

[opal whale]

Don’t wait on that run. Five minutes of typing means the agent turn is wedged, not “thinking normally.”

Do this now:

1. In Discord, send this as a standalone message:

stop

2. On the VPS, immediately run:

openclaw logs --limit 500 --local-time --max-bytes 2000000
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex
openclaw gateway status

[opal whale]

openclaw status --all

Paste the log chunk around the 5-minute typing window. I’m specifically looking for:

long-running session
queued_behind_active_work
auth refresh request timed out
codex_app_server:notification:error
Embedded agent failed before reply
discord ... reply failed

If stop does not end the typing within ~30 seconds, restart the gateway:

[opal whale]

systemctl --user restart openclaw-gateway
sleep 90
openclaw gateway status

At this point, the problem is not Discord permissions. Discord is showing typing because the turn started; the backend run is stuck before final delivery. The log window will tell us whether it is still Codex auth/runtime or the gateway event loop getting wedged.

[torpid ore]

what are the rammifications of running these

If you want everything to move to 5.5-pro immediately, you need to clear or reset the old sessions.

Likely commands:

openclaw sessions list
openclaw sessions prune

or possibly:

openclaw memory clear

You can also manually archive/remove the old Discord session so it recreates fresh on next message.

The important part: this is not an auth issue anymore. It’s just session persistence.

[opal whale]

I would not run those blindly.

Ramifications:

• openclaw sessions list

  • Read-only if it exists in your version, but the documented command is just openclaw sessions.
  • Safe.

• openclaw sessions prune

  • I don’t think prune is the current documented command. The current maintenance command is openclaw sessions cleanup.
  • Cleanup can remove old session records/transcripts depending on your maintenance config. Use dry-run first.

• openclaw memory clear

  • Do not run this for this issue.
  • Memory is not the same as sessions. Clearing memory can delete durable remembered context/preferences. It won’t specifically fix a stuck Discord session.

Safer sequence:

[opal whale]

openclaw sessions --all-agents --active 120 --verbose
openclaw sessions cleanup --all-agents --dry-run

That shows what would be touched without deleting anything.

For the Discord thread specifically, prefer a chat-level reset first:

stop
/new

That should start a fresh session for this Discord conversation without wiping global memory or broad session history.

If you really need old sessions removed, use cleanup with dry-run first, inspect the output, then only enforce if you’re comfortable losing those old session entries/transcripts:

[opal whale]

openclaw sessions cleanup --all-agents --dry-run --json
# only after reviewing:
openclaw sessions cleanup --all-agents --enforce

Also, I would not accept “this is not auth anymore” yet. Your earlier logs had explicit Codex auth/runtime failures and gateway event-loop stalls. Session persistence may be part of why the old Discord thread stays pinned, but the 5-minute typing still needs logs to confirm where the active run is stuck.

[opal whale]

This status is actually good news for the global config:

Sessions · default gpt-5.5-pro
Gateway reachable
Discord ON / OK

The problem is now specifically the existing Discord session row:

agent:main:discord:channel:... · gpt-5.4 · OpenAI Codex

So the Discord thread is still pinned to the old session/model. Don’t clear memory. Don’t prune sessions yet. Force this Discord session onto 5.5-pro directly.

In Discord, send these as standalone messages, in this order:

[opal whale]

stop

then:

/model openai/gpt-5.5-pro

then:

/reset

After that, send one normal test message.

[opal whale]

Then check:

openclaw status
openclaw logs --limit 300 --local-time --max-bytes 1000000

Expected result: the Discord session row should show gpt-5.5-pro / OpenAI Codex. If it still shows gpt-5.4, there is likely a per-channel/session binding or command authorization issue preventing the Discord model command from applying. In that case paste the logs around the /model and /reset messages.

[torpid ore]

"you are not authorized to run this command"

[opal whale]

That error means the Discord sender is allowed to trigger the bot, but is not authorized for owner/admin chat commands like /model or /reset.

Fix the Discord command authorization first. On the VPS, run:

openclaw config get channels.discord --json

Look for your guild/server entry under guilds. Then add your Discord user ID to that guild’s users list.

Your Discord user ID from this thread appears to be:

315939801301909515

Use your actual Discord server ID in place of SERVER_ID:

[opal whale]

openclaw config set 'channels.discord.guilds.SERVER_ID.users' '["315939801301909515"]' --strict-json
openclaw gateway restart
sleep 60
openclaw status

If there are already users in that list, don’t overwrite them. Instead paste the channels.discord config with secrets redacted and I’ll help build the exact safe command.

After that, in Discord, try:

/model openai/gpt-5.5-pro

If it no longer says unauthorized, then run:

[opal whale]

/reset

Then send a normal test message.

So the current blocker is not Claude. It’s command authorization: your Discord account is not in the guild/channel users allowlist that grants owner command rights.

[torpid ore]

im still not authorized to use this command

[opal whale]

Use the explicit owner allowlist instead of guild/channel users. That avoids the account-scoped/guild-path ambiguity.

Run:

openclaw config get commands.ownerAllowFrom --json

If it prints null / missing / empty, run:

openclaw config set commands.ownerAllowFrom '["discord:315939801301909515"]' --strict-json
openclaw gateway restart
sleep 60
openclaw status

[opal whale]

If it already prints a list, preserve the existing entries and add yours, for example:

openclaw config set commands.ownerAllowFrom '["existing-entry-here","discord:315939801301909515"]' --strict-json
openclaw gateway restart
sleep 60
openclaw status

Ramification: commands.ownerAllowFrom gives that Discord user owner/admin command rights for chat commands like /model, /reset, config-ish operations, etc. Keep it to your own Discord user ID only.

After restart, try in Discord:

/model openai/gpt-5.5-pro

[opal whale]

Then:

/reset

If it still says unauthorized after this, paste:

openclaw config get commands.ownerAllowFrom --json
openclaw logs --limit 200 --local-time --max-bytes 1000000

[torpid ore]

$ openclaw config get commands.ownerAllowFrom --json
[
"discord:315939801301909515"
]

[opal whale]

Good — the config is right. Now make sure the running gateway has loaded it, then test the command.

Run:

openclaw gateway restart
sleep 60
openclaw config get commands.ownerAllowFrom --json
openclaw gateway status

Then in Discord, send:

/model openai/gpt-5.5-pro

[opal whale]

If it still says unauthorized, we need the log line around that command because the gateway may be seeing a different sender id/account context than expected. Run right after the failed command:

openclaw logs --limit 300 --local-time --max-bytes 1000000

Also try this in Discord:

/whoami

If /whoami works, it should show the sender/allowFrom identity OpenClaw is using. Paste that output, but redact anything sensitive.

[torpid ore]

im still not authorized to use any of those commands!

[opal whale]

I found the likely reason: commands.ownerAllowFrom is correct, but if commands.allowFrom is configured, it can separately gate command execution. So owner can still look “not authorized” if commands.allowFrom excludes you.

Run:

openclaw config get commands.allowFrom --json

If it prints anything other than null/missing, add your Discord user there too:

openclaw config set commands.allowFrom.discord '["315939801301909515"]' --strict-json
openclaw gateway restart
sleep 60

Then try:

[opal whale]

/whoami

and:

/model openai/gpt-5.5-pro

If commands.allowFrom is null/missing and you’re still unauthorized, paste these two outputs:

openclaw config get commands --json
openclaw logs --limit 300 --local-time --max-bytes 1000000

[opal whale]

The key is: command authorization has two knobs. commands.ownerAllowFrom says who is owner; commands.allowFrom can still restrict who may run commands at all.

[torpid ore]

$ openclaw config get commands.allowFrom --json
Config path not found: commands.allowFrom. Run openclaw config validate to inspect config shape.

[opal whale]

That confirms commands.allowFrom is not configured. For Discord native slash commands, add it explicitly. Use the user: prefix.

Run:

openclaw config set commands.allowFrom '{"discord":["user:315939801301909515"]}' --strict-json
openclaw gateway restart
sleep 60
openclaw config get commands --json
openclaw gateway status

Then try the Discord command again:

/model openai/gpt-5.5-pro

[opal whale]

If it still says unauthorized, add the guild-level fallback too. Replace SERVER_ID with your Discord server ID:

openclaw config set commands.allowFrom '{"discord":["user:315939801301909515","guild:SERVER_ID"]}' --strict-json
openclaw gateway restart
sleep 60

Why this is different from commands.ownerAllowFrom:

• commands.ownerAllowFrom marks you as an owner for owner-only commands.
• commands.allowFrom controls who can run Discord native commands at all.
• Your error is happening at the “can this Discord sender run commands?” layer, so we need commands.allowFrom too.

[torpid ore]

now i get ⚠️ Command produced no visible reply.

[opal whale]

That is progress: you are past the authorization gate. Now the command is executing, but the command handler didn’t return a visible message.

Run this to verify whether it actually changed the session/model:

openclaw status
openclaw models status
openclaw logs --limit 300 --local-time --max-bytes 1000000

Also try the text command form in Discord instead of the native slash UI:

/model openai/gpt-5.5-pro

If that still produces no visible reply, try a plain reset:

[opal whale]

/reset

Then send a normal test message.

What to check in openclaw status:

• Global default should be gpt-5.5-pro
• The Discord session row should move from gpt-5.4 to gpt-5.5-pro

If the row stays gpt-5.4, paste the latest openclaw logs --limit 300 output around the command time. The no-visible-reply warning means we need the gateway log to see whether the model command was applied, rejected silently, or routed through a native slash-command edge case.

[torpid ore]

still having the same issue, starts typing then won'

wont respond at all.

[opal whale]

Typing means Discord ingress is working. The failure is still inside the agent turn before final reply. At this point, more config changes are just noise — we need the exact current failure line.

Please run this and paste the output after one failed test:

openclaw logs --limit 800 --local-time --max-bytes 3000000 | tail -250
openclaw status --all
ps -o pid,ppid,etime,stat,%cpu,%mem,cmd -C node -C codex

Before sending the test message, send this in Discord as standalone text:

stop

Then send one simple prompt:

[opal whale]

reply with just ok

Wait until it has typed for ~60s, then run the three commands above.

What matters in the log is any line containing:

long-running session
embedded_run
auth refresh request timed out
codex_app_server
model_fallback_decision
Embedded agent failed before reply
discord ... reply failed

[opal whale]

delivered

Also please confirm whether you ran openclaw doctor --fix. Doctor explicitly said your old Codex model refs needed migration; if that did not complete cleanly, the gateway can keep falling into the same broken route.

[torpid ore]

what does this log tell you

[opal whale]

This log says the current failure is not Discord and not Claude.

It is still the Codex auth/runtime path:

requestedModel=gpt-5.5-pro
provider=openai-codex
auth refresh request timed out after 10s
Embedded agent failed before reply
fallbackConfigured=false

Meaning:

• Discord receives the message and starts the run.
• The agent enters embedded_run.
• Codex app-server/runtime tries to refresh auth for the OpenAI Codex profile.
• That refresh times out.

[opal whale]

• There is no fallback configured, so the run dies before producing a reply.
• Discord keeps showing typing because the backend run is stuck/failing before final delivery.

The 82s duration is the important user-visible delay:

durationMs=82990

So we need to fix Codex auth/runtime, not channel permissions.

Run these next:

openclaw models auth login --provider openai-codex --set-default
openclaw gateway restart

[opal whale]

sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw logs --limit 300 --local-time --max-bytes 1000000

If the probe still times out after re-auth, this is a 2026.5.22 Codex OAuth/app-server bug or environment issue. File it with exactly this summary:

OpenClaw 2026.5.22, Discord ingress works, Codex run starts, but openai-codex/gpt-5.5-pro fails before reply:
auth refresh request timed out after 10s
provider=openai-codex
stage=prompt
durationMs≈82990
fallbackConfigured=false
codex_app_server notifications appear before failure

[opal whale]

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

Short-term mitigation if you need Discord working now: configure a fallback or use an API-key/direct provider until Codex OAuth refresh stops timing out. But the log itself is clear: Codex auth refresh is the blocker.

[torpid ore]

is it trying to use one of the other emails that i have attached? I had to recently change my openai email account

[opal whale]

Yes, that is very plausible.

Earlier your status showed three openai-codex OAuth profiles. If one of those belongs to the old OpenAI email, OpenClaw may still be trying that profile first or rotating into it. The log only shows a redacted profileId, not the email, so we need to force the auth order to the right profile.

Run these exactly:

openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw models auth order get --provider openai-codex

In the status output, find the openai-codex:... profile that matches the new/correct email. Then pin only that one:

openclaw models auth order set --provider openai-codex 'openai-codex:PASTE_THE_CORRECT_PROFILE_ID_HERE'
openclaw gateway restart

[opal whale]

sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000

Example shape only:

openclaw models auth order set --provider openai-codex 'openai-codex:[e-mail]'

Don’t clear memory for this. Don’t change 127.0.0.1. Don’t switch to Claude. This is specifically about making Codex OAuth use the correct OpenAI account/profile.

[torpid ore]

I did this, confirmed it, and still same issue 🙁

[opal whale]

That’s frustrating, but it narrows the failure a lot.

If you pinned the correct openai-codex:... profile and the log still says auth refresh request timed out after 10s, then this probably is not “wrong email chosen” anymore. It’s either:

1. the saved Codex OAuth token for that account is bad/stale, or
2. the 2026.5.22 Codex app-server auth refresh path is hanging on your VPS.

Next I would do a clean device-code reauth, because that avoids browser/callback weirdness and makes sure you sign into the new OpenAI account:

openclaw models auth login --provider openai-codex --device-code --set-default
openclaw models auth order get --provider openai-codex
openclaw models status --probe-provider openai-codex --probe-timeout 30000
openclaw gateway restart
sleep 90

[opal whale]

Then in Discord send:

/stop
/reset
test

If it still hangs, don’t keep changing Discord or gateway bind settings. Grab the focused evidence:

openclaw logs --limit 500 --local-time --max-bytes 1000000 | grep -Ei 'auth refresh|openai-codex|gpt-5.5|Embedded agent failed|liveness warning|codex_app_server'

If that still shows the same timeout after device-code reauth, I’d treat this as a Codex OAuth/runtime bug in 2026.5.22 and file it. The key phrase for the issue is:

[opal whale]

Discord ingress works, Codex run starts, but openai-codex auth refresh times out after 10s before reply.

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

This log finally changes the diagnosis.

Good news: your profile pin worked. This line proves it is now using the email you selected:

Order override: openai-codex:[e-mail]

The current blocker is this:

The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account.

So don’t use gpt-5.5-pro through Codex OAuth on that account. Set it to regular gpt-5.5 on the Codex OAuth provider:

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw config set agents.defaults.thinkingDefault off
openclaw gateway restart
sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000

Then in Discord run:

/stop
/reset
/model openai-codex/gpt-5.5
test

The older No API key found for provider openai line was from when it was trying openai/gpt-5.5 without the Codex route. The newer log is clearer: auth profile is selected, but 5.5-pro is rejected for ChatGPT/Codex OAuth. Use openai-codex/gpt-5.5 first and get the bot responding again before trying any pro variant.

[opal whale]

Brief summary:

The original Discord integration was working on the Discord side. Messages were received, sessions were created, and the bot started typing. The failure happened after that, inside the model/runtime path.

The logs showed several different stages:

1. Early on, OpenClaw was trying openai/gpt-5.5 / openai/gpt-5.5-pro in a way that required a direct OpenAI API key, causing:

No API key found for provider openai

2. Then it was correctly routed through Codex OAuth, but multiple OpenAI/Codex auth profiles existed after an email/account change. We pinned the intended profile with:

openclaw models auth order set --provider openai-codex 'openai-codex:<correct-email>'

[opal whale]

3. After that, the log confirmed the selected profile, but exposed the current real blocker:

The 'gpt-5.5-pro' model is not supported when using Codex with a ChatGPT account.

So the practical fix is: use Codex OAuth with regular gpt-5.5, not gpt-5.5-pro, for this account.

Recommended final commands:

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw config set agents.defaults.thinkingDefault off
openclaw gateway restart
sleep 90
openclaw models status --probe-provider openai-codex --probe-timeout 30000