Main agent not responding | Friends of the Crustacean 🦞🤝 | Page 1

#

Yep — this is two auth failures at once, not your prompt.

openai-codex/gpt-5.4 → Codex OAuth refresh token is broken/expired.
ollama/qwen2.5:14b → fallback model can’t auth from this agent’s auth store.

Given you said Claude Code cleaned .openclaw, this is very likely auth/profile state drift.

Run these in order:

openclaw --version
openclaw status --all
openclaw models status

Then fix Codex OAuth:

#

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

If you don’t need Ollama fallback right now, remove it so one bad fallback doesn’t kill replies:

openclaw models fallbacks list
openclaw models fallbacks remove ollama/qwen2.5:14b

If you do need Ollama, reconfigure it (and make sure Ollama itself is running + model exists).

Also important for your env/secrets setup: if gateway runs as a service, shell env often isn’t inherited. Put required vars in:

%OPENCLAW_STATE_DIR%\.env (or default ~/.openclaw/.env)

#

Then restart:

openclaw gateway restart
openclaw models status --probe

If it still fails, paste outputs of these 4 commands and I’ll pinpoint the exact broken profile/path:

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

Docs:

#

Yep — that’s exactly the right fix path. Re-authing Codex via the model setup flow refreshes the broken OAuth token.

For anyone else hitting this same error, the quick path is:

openclaw configure --section model
# choose OpenAI Codex OAuth and complete browser login
openclaw models status

If you still see the Ollama part after that, either reconfigure Ollama auth or remove that fallback model so it stops failing over to it.

Docs: https://docs.openclaw.ai/cli/models and https://docs.openclaw.ai/concepts/oauth

Glad you got it unstuck 🎉
If this fixed the thread issue, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

#

Perfect, this helps a lot.

From this first half I already see 2 important clues:

You’re on 2026.3.28 (latest shown is 2026.4.2).
Status says Secrets: none — so if you expected file-backed secrets, they are currently not active/resolved.

Please paste the second half (especially openclaw models status output).
Also run this one so we can see profile routing for main exactly:

openclaw models auth order get --provider openai-codex --agent main

After we confirm that output, I’ll give you the exact minimal fix path (no guessing).

#

Nice — this output is super clear. Root cause is confirmed:

Codex OAuth refresh token is invalidated (refresh_token_reused)
Fallback model is broken (ollama/qwen2.5:14b has no auth)

Also:

Port 18789 already in use is normal (your gateway service is running).
Shell env: off is not the main issue for Codex OAuth, since it’s using auth-profiles.json.

Fix (minimal, in order)

openclaw models auth login --provider openai-codex --set-default
openclaw models fallbacks remove ollama/qwen2.5:14b
openclaw gateway restart
openclaw models status --probe-provider openai-codex

#

If you actually want Ollama fallback, re-add/configure it after Codex is healthy.

You’re also on 2026.3.28 with update available, so after this auth fix I’d update too:

openclaw update
openclaw gateway restart

Docs:

If that probe comes back clean, you should be fully unblocked.

#

Great progress — you fixed the Ollama side (Fallbacks (0) ✅).

Now the remaining issue is exactly this:

openai-codex:default → broken (expires in 0m, refresh_token_reused)
openai-codex:dead.anas@gmail.com → healthy (expires in 10d)

So pin auth order to the healthy profile only:

openclaw models auth order set --provider openai-codex --agent main "openai-codex:dead.anas@gmail.com"
openclaw models auth order get --provider openai-codex --agent main
openclaw models status --probe-provider openai-codex

Then send a normal message to the agent to confirm replies are back.

#

That gateway.auth.token SecretRef ... unavailable in this command path warning during restart is not the blocker here — the auth profile order is.

If this works, you can later re-login Codex to refresh openai-codex:default cleanly, but it’s optional once the good profile is pinned.

Docs: https://docs.openclaw.ai/help/faq#auth-profiles-what-they-are-and-how-to-manage-them and https://docs.openclaw.ai/cli/models

#

Beautiful — that looks healthy now ✅

Key signals:

You’re on 2026.4.2 now
Auth order is pinned to the good profile
--probe-provider openai-codex no longer shows refresh failure

At this point, your agent should reply again.
Try one normal message in chat to confirm.

Optional cleanup later (not required now):

openclaw models auth login --provider openai-codex --set-default
openclaw models auth order clear --provider openai-codex --agent main

(only if you want to refresh/fix the openai-codex:default profile too)

#

If replies are back, please right-click the solution message → Apps → ✅ Mark Solution so this gets indexed for others. 🎉

#

Ah yep — this is now a broken package install issue, not auth.

ERR_MODULE_NOT_FOUND ... route-reply.runtime-*.js means the installed dist/ bundle is incomplete/mismatched on disk.

Do a clean reinstall + service repoint:

openclaw gateway stop
pnpm add -g openclaw@latest
openclaw doctor
openclaw gateway install --force
openclaw gateway restart

Then verify:

#

openclaw gateway status
openclaw logs --follow

If it still references C:\Users\ClawBot\AppData\Roaming\npm\node_modules\openclaw\dist\..., paste:

where openclaw

and I’ll help you remove the stale binary path cleanly.

Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/troubleshooting

#

This log looks good now — no more ERR_MODULE_NOT_FOUND.

What you’re seeing is mostly non-fatal noise:

SECRETS_REF_IGNORED_INACTIVE_SURFACE → expected when gateway token is coming from env var (so SecretRef is ignored).
bonjour ... re-advertise → local network discovery retry, harmless.
model-pricing ... timeout → pricing metadata fetch timeout, does not block replies.

So the key check now is simple: send a normal message to your agent and confirm it responds.

If it still doesn’t reply, run:

openclaw channels status
openclaw logs --follow

#

then send one test message and paste only the new error lines.

If replies are back, you’re done 🎉
Please mark the solution in-thread (right-click → Apps → ✅ Mark Solution) so others can find this fix.

#

Got it — we’ve moved from auth to a gateway reachability issue now.

channels status saying gateway timeout after 10000ms means CLI can’t talk to the local gateway RPC, even though config exists.

Please run this exact sequence and paste output:

# stop log follow first if still running (Ctrl+C)

openclaw gateway status
openclaw gateway stop
openclaw gateway start
openclaw gateway status
openclaw status --deep

Two likely causes now:

#

service/runtime mismatch after reinstall
gateway token/auth source drift (env/SecretRef vs CLI path)

openclaw gateway status will show which one it is (Probe target, Listening, Last gateway error, config CLI vs service). Then I can give you the exact final fix.

#

Thanks — this confirms something subtle:

Gateway process is alive (cron logs every minute),
but CLI RPC to ws://127.0.0.1:18789 is timing out.

That usually means the service wiring/auth surface is drifted after reinstall/update.

Let’s do a clean service rebind (safe, no data loss):

openclaw gateway stop
openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start
openclaw gateway status
openclaw channels status

#

If channels status still times out, run gateway in foreground once to isolate service issues:

openclaw gateway stop
openclaw gateway run --verbose

(leave it running, open a second terminal, run openclaw status)

If foreground works but service mode fails, we know it’s service env/config drift and can lock it down next.

Docs: https://docs.openclaw.ai/gateway/troubleshooting and https://docs.openclaw.ai/gateway

#Main agent not responding

Fix (minimal, in order)