Codex/OpenAI runtime v2026.5.12

[warm galleon]

Hey @thorny night i'm having a hard time with 2026.5.12, as I investigate, the failures are very likely tied to the new Codex/OpenAI runtime (I used pi as default agent runtime). Tried bunch of fixes using codex, but none worked properly.
Which informations do you need?
What do you suggest?

openclaw --version
OpenClaw 2026.5.12 (f066dd2)
node --version
nv26.0.0
npm --version
11.12.1
which openclaw
/opt/homebrew/bin/openclaw
which node
/opt/homebrew/bin/node
which npm
/opt/homebrew/bin/npm

[thorny night]

RTeo, the first thing I’d check: if you “used pi as default agent runtime” via a whole-agent/default runtime key, current docs say that is ignored now. Runtime selection is provider/model-scoped, not whole-agent-scoped. So a config like agents.defaults.agentRuntime or stale session runtime pins won’t force PI anymore.

For 2026.5.12, split the investigation into two paths:

1. If you want the new Codex runtime:

• enable the bundled codex plugin
• keep the agent model as canonical openai/gpt-*, not openai-codex/gpt-*
• run openclaw doctor --fix
• restart gateway
• start a fresh chat/session with /new or /reset
• in the failing chat run /status, then /codex status and /codex models

2. If you want to force old PI/direct OpenAI behavior for comparison:

• set agentRuntime.id: "pi" on the OpenAI provider or on the specific openai/gpt-* model entry
• restart gateway
• use /new before testing, because old sessions can keep surprising route state

[thorny night]

The useful info to share next is:

openclaw status --all
openclaw models status
openclaw doctor
openclaw gateway status

And from the Discord thread/session where it fails:

/status
/codex status
/codex models

[thorny night]

If a bad Codex turn already happened, run /diagnostics codex runtime failure on 2026.5.12 in that same conversation and approve the export if you’re comfortable. That’s usually much better than raw logs because it redacts secrets and includes the relevant Codex harness state.

One extra note: your Node line says nv26.0.0; if that’s actually Node v26, I’d still include it in the report. Docs only require Node >= 22, but runtime edge cases on very new Node versions are exactly the kind of thing diagnostics can expose.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/agent-runtimes
https://docs.openclaw.ai/plugins/codex-harness

[warm galleon]

right now i'm not able to run commands in discord: "The application did not respond"

[thorny night]

That changes the triage: The application did not respond is Discord’s interaction timeout, so the slash-command handler is not acknowledging the command fast enough. That is usually gateway/channel startup, event-loop stall, or Discord command registration/token state, not the Codex model turn itself.

Since Discord commands are unavailable, use local CLI for now:

openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw channels status --probe
openclaw doctor
openclaw logs --follow

Specific things I’d look for in the output/logs:

• gateway not reachable or service restarted/crashed
• Discord account not connected / token/auth error

[thorny night]

• repeated plugin startup errors, especially around codex
• event loop stall / long-running session stuck in processing
• native command registration errors
• split install/path weirdness: which openclaw vs what the service is actually running

If the gateway is running but Discord slash commands still time out, try a normal text mention to the bot in the thread. If text messages work but slash commands fail, it narrows to native command registration/interaction handling. If text messages also do nothing, it’s channel/gateway connectivity or the gateway is wedged.

Docs for the command ladder and Discord setup:
https://docs.openclaw.ai/help/troubleshooting
https://docs.openclaw.ai/channels/discord

[warm galleon]

I'll send the output of the commands in batches
openclaw status --all
openclaw models status
openclaw doctor
openclaw gateway status

[thorny night]

Sounds good. Please redact anything that looks like a token/key if the CLI doesn’t already redact it.

Best order for batches:

1. openclaw gateway status
2. openclaw status --all
3. openclaw models status
4. openclaw doctor

If any command hangs, say which one and roughly where it stops. That matters a lot for the “Discord application did not respond” symptom.

[warm galleon]

Overview

│ Item│ Value │
│ OS │ macos 26.4.1 (arm64) │
│ Node │ 26.0.0 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard│ http://127.0.0.1:18789/ │
│ Tailscale exposure │ serve · unknown · mac-mini..ts.net · https://mac-mini..ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.5.12 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 19ms · auth token · mac-mini (192.168.0.110) app 2026.5.12 macos 26.4.1 │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 33954, state active) │
│ Node service │ LaunchAgent not installed │
│ Agents│ 5 total · 0 bootstrapping · 1 active · 3 sessions │
│ Secrets │ none │

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:a3359f7d · len 46) · accounts 1/1 │
│ Discord │ ON │ OK │ token config (sha256:96344183 · len 72) · accounts 1/1 │
│ WhatsApp │ ON │ OK │ configured · accounts 1/1 │
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config · credential available in gateway runtime · allow:1***9 │
└──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

Discord accounts
┌──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config · credential available in gateway runtime · allow:7***3 │
└──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

WhatsApp accounts
┌──────────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
│ theo-account │ OK │ dm:allowlist · credential available in gateway runtime · │
│ │ │ allow:5***0 │
└──────────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌───────────────────────────────────┬────────────────┬──────────┬──────────┬───────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├───────────────────────────────────┼────────────────┼──────────┼──────────┼───────────────────────────────────────────────┤
│ main │ ABSENT │ 3 │ 1m ago │ ~/.openclaw/agents/main/sessions/sessions. │
│ │ │ │ │ json │
│ assistant-agent (Assistant Agent) │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/assistant-agent/sessions/ │
│ │ │ │ │ sessions.json │
│ cron-worker │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/cron-worker/sessions/ │
│ │ │ │ │ sessions.json │
│ farm-agent (Farm Agent) │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/farm-agent/sessions/ │
│ │ │ │ │ sessions.json │
│ travel-agent (Travel Agent) │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/travel-agent/sessions/ │
│ │ │ │ │ sessions.json │
└───────────────────────────────────┴────────────────┴──────────┴──────────┴───────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/teodoro/.openclaw/openclaw.json
Bind: loopback

✓ Config: /Users/teodoro/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

Gateway last log line:
2026-05-16T11:19:15.088-03:00 [ws] ⇄ res ✓ health 343ms conn=37377584…27eb id=f7b4821b…d3c1
✓ Port 18789
Detected OpenClaw Gateway listener on the configured port.
! Tailscale exposure: serve · daemon unknown · mac-mini..ts.net
https: https://mac-mini..ts.net
✓ Skills: 57 eligible · 0 missing · /Users/teodoro/.openclaw/workspace
✓ Plugin compatibility (none)

[thorny night]

This first batch is useful: gateway is alive and reachable, so Discord’s timeout is probably not “gateway is down.”

Two things stand out:

• Node is 26.0.0. OpenClaw requires Node >= 22, but for a support repro I’d strongly prefer testing on Node 22 LTS or 24 LTS because 26 is very new runtime surface. Don’t change it yet if you’re collecting evidence, but keep it high on the suspect list.
• Gateway self: unknown plus Discord slash timeouts means I want the channel/probe and log parts next, not more model theory yet.

Next most important chunks from openclaw status --all are the Channels/Discord section, runtime/issues section, and the log tail. Then openclaw gateway status and openclaw channels status --probe if you can run it.

If there’s an “active session” shown as processing/stuck, include that too. A wedged active turn can explain command interactions timing out while the gateway still reports reachable.

[thorny night]

Channel config also looks basically healthy, but that table is config/runtime credential availability, not a live Discord interaction probe.

Please send the Discord accounts section if it appears below this, plus any “Issues”, “Sessions”, “Runtime”, or log-tail part from status --all.

One useful extra check, because Discord slash commands specifically are failing:

openclaw channels status --probe

If that reports Discord OK but slash commands still time out, I’d focus on native-command interaction handling/registration. If the probe fails or hangs, it’s broader Discord transport/runtime health.

[thorny night]

Good, Discord credential resolution is OK too. So far this points away from token/config and toward one of:

• Discord native interaction handler is timing out
• gateway event loop is busy/wedged
• an active session/runtime task is blocking command handling
• command registration state is stale even though the bot token is valid

Please keep sending the remaining status --all sections, especially Sessions/Agents/Issues/log tail. After that, openclaw channels status --probe is the next highest-signal command.

[thorny night]

Agents look clean: no bootstrap trap, and only main has sessions. That’s good.

The main active 1m ago could be normal because you’re testing right now, or it could be the stuck lane. The session/status section should tell us more. Please include any section that lists active sessions, current model/runtime, or “processing” state.

If the next output shows a session stuck processing, don’t delete anything yet. First try a normal gateway restart after grabbing logs, because we want to preserve evidence if this is a 2026.5.12 Codex hang.

[thorny night]

This diagnosis still says the local gateway path is healthy. The one warning there, Tailscale daemon unknown, doesn’t explain local Discord slash interactions by itself.

The most interesting bit is the gateway last log line: it’s only showing a health probe. I need the log tail around the Discord timeout/Codex failure, because that’s where we’ll see whether Discord interactions are arriving and timing out, or not arriving at all.

Please run one of these while triggering a Discord slash command once:

openclaw logs --follow

or, if that doesn’t show anything useful:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Then paste the lines around the slash command attempt. Redacted is fine; the useful parts are timestamps, discord, interaction, command, codex, timeout/error lines.

[warm galleon]

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.5
Fallbacks (1) : xai/grok-4.3
Image model : -
Image fallbacks (0): -
Aliases (13) : grok 4.20 -> xai/grok-4.20-0309-reasoning, grok 4.1 fast -> xai/grok-4-1-fast-reasoning, grok 4.3 -> xai/grok-4.3, gemini 2.5 flash lite -> openrouter/google/gemini-2.5-flash-lite-preview-09-2025, gemma 4:31b-free -> openrouter/google/gemma-4-31b-it:free, minimax m2.5 -> openrouter/minimax/minimax-m2.5, qwen3.5:2b -> ollama/qwen3.5:2b-q4_K_M, glm 5.1 -> ollama/glm-5.1:cloud, minimax m2.7 -> ollama/minimax-m2.7:cloud, kimi k2.5 -> ollama/kimi-k2.5:cloud, gpt-5.5 -> openai/gpt-5.5, gpt-5.4 -> openai/gpt-5.4, gpt-5.4-mini -> openai/gpt-5.4-mini
Configured models (13): xai/grok-4.20-0309-reasoning, xai/grok-4-1-fast-reasoning, xai/grok-4.3, openrouter/google/gemini-2.5-flash-lite-preview-09-2025, openrouter/google/gemma-4-31b-it:free, openrouter/minimax/minimax-m2.5, ollama/qwen3.5:2b-q4_K_M, ollama/glm-5.1:cloud, ollama/minimax-m2.7:cloud, ollama/kimi-k2.5:cloud, openai/gpt-5.5, openai/gpt-5.4, openai/gpt-5.4-mini

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

• ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)
• openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[e-mail]=OAuth ([e-mail])
• openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=ref(file:/provider/openrouter/apiKey)
• voyage effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | voyage:default=ref(file:/provider/voyage/apiKey)
• xai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | xai:default=ref(file:/provider/xai/apiKey)

OAuth/token status

• openai-codex
  • openai-codex:[e-mail] ([e-mail]) ok expires in 9d

[thorny night]

That model config is consistent with the new Codex path: openai/gpt-5.5 as default should route through the Codex harness when the bundled codex plugin is enabled. The xai/grok-4.3 fallback is separate and won’t explain Discord slash command timeouts.

The next useful parts from openclaw models status are the auth/runtime rows for OpenAI/Codex: whether the openai-codex auth profile is present/valid, and whether any provider shows errors. Please paste that section if it follows.

But for the immediate “application did not respond” issue, logs around a slash command attempt are still the key evidence. A healthy model config can coexist with a wedged Discord interaction handler.

[thorny night]

OpenAI/Codex auth looks good: OAuth profile exists and is valid for another 9 days. So we can probably stop suspecting “missing Codex auth.”

Current read:

• gateway reachable
• Discord token/config OK
• Codex OAuth OK
• default model shape OK
• agents not stuck in bootstrap

That leaves runtime hang/Discord interaction path/log evidence as the main branch. Please send either:

openclaw channels status --probe

or the log tail while reproducing one slash command timeout:

openclaw logs --follow

[thorny night]

If logs show nothing at all when you trigger a Discord slash command, that suggests Discord is not delivering interactions to the running bot/session. If logs show the interaction arrives and then stalls, that’s the gateway/runtime side.

[warm galleon]

Gateway logs (tail, summarized): /Users/teodoro/.openclaw/logs
2026-05-16T11:15:40.378-03:00 [gateway] starting...
2026-05-16T11:15:42.297-03:00 [secrets] [SECRETS_GATEWAY_AUTH_SURFACE] gateway.auth.token is active. gateway.auth.mode is "token".
2026-05-16T11:15:42.377-03:00 [gateway] starting HTTP server...
2026-05-16T11:15:42.635-03:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-05-16T11:15:45.706-03:00 [gateway] agent model: openai/gpt-5.5 (thinking=medium, fast=off)
2026-05-16T11:15:45.707-03:00 [gateway] http server listening (7 plugins: acpx, codex, diffs, discord, memory-core, telegram, whatsapp; 5.3s)
… 18 lines omitted …
2026-05-16T11:16:25.740-03:00 [ws] ⇄ res ✓ sessions.list 53ms conn=8e184fea…1825 id=213730ce…5971
2026-05-16T11:16:25.742-03:00 [ws] ⇄ res ✓ channels.status 55ms conn=8e184fea…1825 id=78c6e8b2…2c14
2026-05-16T11:16:26.421-03:00 [ws] ⇄ res ✓ logs.tail 603ms conn=8e184fea…1825 id=8e18479f…9afb
2026-05-16T11:16:26.758-03:00 [ws] ⇄ res ✓ status 1003ms conn=8e184fea…1825 id=1249ed8e…2128
2026-05-16T11:16:27.623-03:00 [ws] ⇄ res ✓ usage.cost 1805ms conn=8e184fea…1825 id=ec8c3d9d…751e
2026-05-16T11:16:27.895-03:00 [ws] ⇄ res ✓ models.authStatus 2077ms conn=8e184fea…1825 id=f521345c…fae6
2026-05-16T11:16:30.737-03:00 [ws] ⇄ res ✓ sessions.usage 4919ms conn=8e184fea…1825 id=5af6f4a4…90dd
2026-05-16T11:16:32.690-03:00 [ws] ⇄ res ✓ sessions.delete 58ms conn=8e184fea…1825 id=8f5ecb9e…a527
2026-05-16T11:16:33.195-03:00 [ws] ⇄ res ✗ sessions.delete 0ms errorCode=INVALID_REQUEST errorMessage=Cannot delete the main session (agent:main:main). conn=8e184fea…1825 id=c5900ade…12cf

[thorny night]

This log tail shows a clean gateway boot and confirms codex + discord plugins loaded. The visible lines are all dashboard/RPC activity though; there’s no Discord interaction attempt in the pasted slice.

The omitted 18 lines may matter. Please paste those if they include discord, ready, native commands, application, or interaction.

For the slash timeout, the best repro is:

openclaw logs --follow

Then trigger one simple Discord slash command, wait until Discord says “The application did not respond”, stop the log with Ctrl-C, and paste only the new lines from that window.

If no new log lines appear during the slash command attempt, that’s a strong sign Discord isn’t delivering the interaction to this running bot process, even though the bot token is configured. If lines appear and then pause/error, we can chase the exact handler/runtime failure.

[warm galleon]

2026-05-16T11:17:23.945-03:00 [telegram] Inbound message telegram:19 -> @TBot (direct, 2 chars)
2026-05-16T11:17:35.560-03:00 [memory] qmd watcher starting for agent "main" paths=6
2026-05-16T11:17:35.561-03:00 [memory] qmd manager initialized for agent "main" mode=full collections=7 durationMs=546
2026-05-16T11:17:35.563-03:00 [memory] qmd watcher ready for agent "main" paths=6 durationMs=3
2026-05-16T11:17:37.081-03:00 [memory] qmd sync completed for agent "main" reason=boot durationMs=1519
2026-05-16T11:19:15.088-03:00 [ws] ⇄ res ✓ health 343ms conn=37377584…27eb id=f7b4821b…d3c1

Gateway restart attempts (tail): /Users/teodoro/.openclaw/logs/gateway-restart.log
[2026-04-28T19:21:50Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-04-29T00:41:36Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=12894
[2026-04-29T00:41:42Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-04-29T01:08:55Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=18670
[2026-04-29T01:09:00Z] openclaw restart done source=launchd-handoff mode=kickstart
… 14 lines omitted …

[2026-05-14T03:28:41Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=3831
[2026-05-14T03:28:46Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-05-14T03:38:09Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=4662
[2026-05-14T03:38:15Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-05-14T09:10:48Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=13991
[2026-05-14T09:10:53Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-05-14T12:53:44Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=21696
[2026-05-14T12:53:50Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-05-14T20:44:30Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/501/ai.openclaw.gateway waitPid=37100
[2026-05-14T20:44:36Z] openclaw restart done source=launchd-handoff mode=kickstart
✓ Channel issues (none)

[thorny night]

This slice is actually pretty telling: Telegram inbound is being logged, memory starts normally, and the gateway keeps answering health/RPC. But there are still no Discord inbound/interaction lines.

That makes the current leading suspect: Discord interactions are not reaching this gateway process, or the Discord client registration is stale/wrong for the application currently installed in the server.

Please do these two checks next:

openclaw channels status --probe

Then, with logs following live:

openclaw logs --follow

trigger one Discord slash command and paste the new lines. If there are no new lines at all, I’d re-check the Discord app/bot invite side: the bot in this server must be the same application as the configured token, and the invite must include applications.commands. In that case, a gateway restart may not be enough; Discord may need command re-registration or a fresh invite with the commands scope.

[thorny night]

Don’t rotate the token yet. The config says the token is valid, so rotating it would add noise before we know whether interactions are delivered.

[thorny night]

Channel issues (none) is reassuring, but it’s still a static/status check. The missing piece is live delivery.

At this point I’d do one focused test:

1. Start:

openclaw logs --follow

2. Trigger one Discord slash command that currently times out.
3. Paste the new lines.

Interpretation:

• New discord / interaction lines appear → OpenClaw receives it, then we debug handler/runtime stall.
• No new lines appear → Discord is not delivering interactions to this running bot. Then check the Developer Portal/app install: same bot application as the configured token, invite includes applications.commands, and native command registration is current.

If openclaw channels status --probe is available, run that too; it’s the cleanest live channel probe before touching config.

[warm galleon]

openclaw channels status --probe

🦞 OpenClaw 2026.5.12 (f066dd2) — No $999 stand required.

│
◇
Gateway reachable.

• Discord default: enabled, configured, running, connected, in:11m ago, bot:@Theo, token:config, intents:content=limited, probe failed, error:Unexpected token '', ""... is not valid JSON
• Telegram default: enabled, configured, running, connected, in:26m ago, mode:polling, bot:@T***Bot, token:config, works
• WhatsApp theo-account: enabled, configured, linked, running, connected, dm:allowlist, allow:+5***0, health:healthy

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

[thorny night]

That probe gives us a concrete failure:

Discord ... running, connected ... probe failed, error: Unexpected token '', ""... is not valid JSON

The Discord gateway connection is up, but the REST probe is getting an empty/non-JSON response where OpenClaw expects Discord JSON. That lines up with slash commands timing out: native commands depend on the Discord application/REST side, not just the websocket being connected.

My next moves, in order:

1. Reproduce with live logs while running one slash command:

openclaw logs --follow

If no Discord interaction lines appear, Discord is not delivering interactions to the bot/app OpenClaw is running.

2. Check the app install/command scope:

• the bot in the server is the same app as this token
• invite includes applications.commands

[thorny night]

• native commands are enabled: commands.native / channels.discord.commands.native not false

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/tools/slash-commands

3. Strongly consider retesting on Node 22 or 24 LTS. You’re on Node 26.0.0; the docs require >=22, but this specific “empty body parsed as JSON” probe failure smells enough like runtime/HTTP edge-case territory that I would remove Node 26 from the equation before chasing Codex further.

After switching Node, reinstall/restart the LaunchAgent from that Node:

openclaw gateway install --force
openclaw gateway restart
openclaw channels status --probe

If the Discord probe still fails on Node 22/24 with the same JSON parse error, that’s likely a 2026.5.12 Discord probe/native-command bug worth filing with the probe output and logs:
https://github.com/openclaw/openclaw/issues

[warm galleon]

i was already on node 26.0.0 in openclaw 2026.5.7 and everything was fine

[thorny night]

That’s a fair data point. If Node 26 + OpenClaw 2026.5.7 was stable, then Node is less likely to be the primary cause. I’d treat Node LTS as an isolation test, not the main theory.

The stronger theory now is a 2026.5.12 regression or behavior change in the Discord probe/native-command path. The hard evidence is:

• Discord gateway connection: connected
• Discord REST/probe: fails with Unexpected token '', ""... is not valid JSON
• Telegram/WhatsApp probes: healthy
• slash commands: Discord says app did not respond

So I would focus next on capturing live logs during one slash command attempt. That tells whether the interaction reaches OpenClaw at all.

If you need to get working quickly, the pragmatic workaround is to roll OpenClaw back to 2026.5.7 or use another working channel while collecting the 2026.5.12 repro. For maintainer-grade bug report, include:

OpenClaw 2026.5.12 (f066dd2)
macOS 26.4.1 arm64
Node 26.0.0

[thorny night]

Discord probe failed: Unexpected token '', ""... is not valid JSON
2026.5.7 worked on same Node/config

Then attach/paste:

openclaw channels status --probe
openclaw status --all
openclaw logs --follow   # during one slash command timeout

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

These lines are a different failure from the Discord probe, but they explain why replies/commands may feel broken once a turn starts.

OpenClaw is ending an embedded agent run with provider failure:

provider=openrouter
model=google/gemini-2.5-flash-lite-preview-09-2025
error=HTTP 500 Internal Server Error
providerRuntimeFailureKind=timeout
failoverReason=timeout

So at least one active run is failing through OpenRouter/Gemini, not Codex. That is surprising because your shown default was openai/gpt-5.5 and fallback was xai/grok-4.3. It means one of these is true:

• the active session has a model override pinned to openrouter/google/gemini-2.5-flash-lite-preview-09-2025
• a command/test selected that alias/model earlier
• fallback/config differs from the summary shown

• stale session state is carrying an older model route

Quick isolation test:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.fallbacks
openclaw config get agents.defaults.models
openclaw status --all

Look for the Sessions section and any current model override. If you can use another channel, send /model openai/gpt-5.5 then /new there. If Discord slash commands are dead, do the equivalent from Telegram/WhatsApp if those channels still work.

For debugging, I’d temporarily remove/avoid the OpenRouter Gemini fallback/selection. OpenRouter 500s are upstream/provider path failures; they will muddy the Codex/Discord investigation. Once the active session is back on openai/gpt-5.5, rerun the Discord slash/log test.

This confirms the failing lane is the Discord channel session:

lane=session:agent:main:discord:channel:1468555831141208179
FailoverError: HTTP 500
model=openrouter/google/gemini-2.5-flash-lite-preview-09-2025

So there are now two separate issues, but this one is actionable:

1. The Discord session is using/pinned to OpenRouter Gemini, and that provider path is returning 500s.
2. The configured default you showed is openai/gpt-5.5, so the Discord session state is probably stale or overridden.

Fastest cleanup path:

openclaw sessions list

Find the session for:

agent:main:discord:channel:1468555831141208179

Then reset/delete that Discord channel session if the CLI exposes it. If it does not, use a working channel to send /new or /reset for that Discord-bound session, or use the dashboard session controls.

After resetting, verify the next turn resolves to openai/gpt-5.5, not OpenRouter Gemini.

Also check why Gemini is in the fallback chain despite the summary showing xai/grok-4.3:

openclaw config get agents.defaults.fallbacks
openclaw config get agents.defaults.models
openclaw config get agents.list

For now, remove/avoid openrouter/google/gemini-2.5-flash-lite-preview-09-2025 from this agent’s fallback/session path. It’s producing upstream 500s and making the Codex/Discord problem harder to isolate.

This makes it cleaner: fallbackConfigured=false and isPrimary=true. So Gemini is not a fallback here; it is the primary requested model for that session.

That means the Discord session has a model override/pin:

sessionId=8ebd4d01-17c0-4893-9e64-98e81b30b6c7
requestedModel=openrouter/google/gemini-2.5-flash-lite-preview-09-2025
lane=session:agent:main:discord:channel:1468555831141208179

Fix the stuck user-facing part first:

• Reset that Discord channel session, or switch its model back to openai/gpt-5.5.
• Since slash commands are unreliable, use Dashboard session controls or another working channel if possible.
• If using CLI, list sessions and look for that session id/key:

openclaw sessions list

If there is a session delete/reset command exposed for non-main sessions, use it only on that Discord channel session, not agent:main:main.

The OpenRouter 500 is upstream/provider-side. The OpenClaw-specific bug to report is still the Discord probe/native command issue, but don’t debug that with this session pinned to Gemini because it will keep failing before Codex is even involved.

Yep, same run id repeating. That session is stuck retrying/failing the pinned OpenRouter Gemini model. I’d stop chasing later lines from that same run; they’ll keep saying the same thing.

Do this next:

openclaw sessions list

Find 8ebd4d01-17c0-4893-9e64-98e81b30b6c7 or discord:channel:1468555831141208179, then reset/delete only that session via the dashboard or CLI if available.

If you can’t reset it cleanly, a gateway restart may release the active lane, but it won’t necessarily remove the model pin. The important thing is: before the next Discord test, that channel session needs to be on openai/gpt-5.5 or freshly reset.

Same failure chain, just the final failover decision. The important bit remains: the active run is still on openrouter/google/gemini-2.5-flash-lite-preview-09-2025, and the lane ends with FailoverError: HTTP 500.

At this point, stop collecting more lines from this run and reset/switch the session:

openclaw sessions list

Look for:

sessionId=8ebd4d01-17c0-4893-9e64-98e81b30b6c7
discord:channel:1468555831141208179

Then reset/delete that Discord channel session from dashboard/CLI, or use a working channel to force a fresh session/model. The goal is to get that Discord channel off Gemini and back to openai/gpt-5.5.

Once that’s done, rerun:

openclaw channels status --probe

If Discord probe still says Unexpected token '', ""... is not valid JSON, that’s the separate Discord/native-command regression to report. But the current run failure is definitely the stale/pinned OpenRouter Gemini session.

Yep, that last line is the summary of the same issue:

Embedded agent failed before reply
sessionId=8ebd4d01-17c0-4893-9e64-98e81b30b6c7
session=agent:main:discord:channel:1468555831141208179
primary model=openrouter/google/gemini-2.5-flash-lite-preview-09-2025
fallbackConfigured=false

So the immediate fix is session cleanup/model reset, not more log collection.

Please run:

openclaw sessions list

Then use dashboard/CLI to reset or delete the Discord channel session with that session id/key. After that, verify the next session starts on openai/gpt-5.5.

If you paste the openclaw sessions list output, I can help identify the exact entry to remove/reset. Don’t touch agent:main:main; that’s the main session and OpenClaw already refused to delete it earlier.

[warm galleon]

i have another idea, how do completely remove all openai models and auths whith cli commands?
then i'll re configure it

[thorny night]

You can, but I’d separate config cleanup from auth-store cleanup. Current CLI has good commands for config/order, but I don’t see a first-class models auth remove command in 2026.5.12, so removing stored OAuth credentials needs a small local JSON edit with backups.

First switch away from OpenAI so you don’t leave the default pointing at a removed model:

openclaw models set xai/grok-4.3
openclaw models fallbacks clear

Remove the OpenAI aliases/model entries you showed:

openclaw models aliases remove "gpt-5.5" || true
openclaw models aliases remove "gpt-5.4" || true
openclaw models aliases remove "gpt-5.4-mini" || true

[thorny night]

openclaw config unset 'agents.defaults.models["openai/gpt-5.5"]' || true
openclaw config unset 'agents.defaults.models["openai/gpt-5.4"]' || true
openclaw config unset 'agents.defaults.models["openai/gpt-5.4-mini"]' || true
openclaw config unset models.providers.openai || true
openclaw config unset models.providers.openai-codex || true
openclaw config unset auth.order.openai || true
openclaw config unset auth.order.openai-codex || true

openclaw models auth order clear --provider openai || true
openclaw models auth order clear --provider openai-codex || true

Then remove only OpenAI/OpenAI-Codex auth profiles from the main agent store, with timestamped backups:

[thorny night]

node <<'NODE'
const fs = require("fs");
const os = require("os");
const path = require("path");

const agentDir = path.join(os.homedir(), ".openclaw/agents/main/agent");
const providers = new Set(["openai", "openai-codex"]);

for (const file of ["auth-profiles.json", "auth-state.json"]) {
  const p = path.join(agentDir, file);
  if (!fs.existsSync(p)) continue;

  const data = JSON.parse(fs.readFileSync(p, "utf8"));
  fs.copyFileSync(p, `${p}.bak-${Date.now()}`);

[thorny night]

  if (data.profiles) {
    for (const [id, cred] of Object.entries(data.profiles)) {
      if (providers.has(String(cred?.provider))) delete data.profiles[id];
    }
  }

  for (const key of ["order", "lastGood"]) {
    if (!data[key]) continue;
    for (const provider of providers) delete data[key][provider];
    if (Object.keys(data[key]).length === 0) delete data[key];
  }

  if (data.usageStats) {
    for (const id of Object.keys(data.usageStats)) {
      if (id.startsWith("openai:") || id.startsWith("openai-codex:")) {

[thorny night]

        delete data.usageStats[id];
      }
    }
    if (Object.keys(data.usageStats).length === 0) delete data.usageStats;
  }

  fs.writeFileSync(p, JSON.stringify(data, null, 2) + "
");
}
NODE

Restart and verify: