Agent Randomly Broke! Won't Perform Tool Calls Anymore! | Friends of the Crustacean 🦞🤝 | Page 1

quartz stoneBOT Apr 9, 2026, 3:09 PM

#

sour spoke Apr 9, 2026, 3:10 PM

#

Os: ubuntu

Debugging with claude shows that the agent isnt making tool calls at all

rich mossBOT Apr 9, 2026, 3:13 PM

#

That usually means the run starts, sends a normal text reply, then the actual tool step never completes. I would not blame gpt 5.4 codex yet without logs.

Even if you’re on “latest”, first paste the exact version:

openclaw --version

Then run this ladder and paste the outputs:

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor

#

openclaw channels status --probe
openclaw models status
openclaw logs --follow

While openclaw logs --follow is running, repro with one simple request like:

“check if there’s an openclaw update”

and paste the first error/warning that appears after the bot says “checking now”.

Two quick tests I’d do right away:

Start a fresh session

#

   /new

There’s a known class of issues where stale/corrupted session history after upgrades/tool-schema changes causes bad tool behavior.

Inspect the tool/context load
```
/context detail
```
I want to confirm the agent still has the expected tools and didn’t get pushed into a bad context state.

About the missing Telegram 3 dots: that’s typing indicators, not proof that tool execution is healthy. If you want the old behavior back, check agents.defaults.typingMode. instant shows typing as soon as the run starts, while thinking/message can appear late or not at all if the run exits/stalls early.

If you’re using a generic OpenAI-compatible /v1 backend instead of native openai/* or openai-codex/*, that’s another strong suspect. In that case the docs point to these compat checks:

models.providers.<provider>.models[].compat.requiresStringContent: true
models.providers.<provider>.models[].compat.supportsTools: false (good diagnostic to see if tool schemas are the thing breaking)

#

Docs:

If you paste the version + status --all + the log snippet from one repro, I can narrow this down pretty fast.

#

That’s a helpful clue. If Claude shows no tool call is being emitted at all, then this is probably not Ubuntu/exec itself. It points more to one of these:

the tool is no longer in the agent’s effective tool list
the session/context is stale after an upgrade
the model route/provider is choking on tool schemas before it ever calls one

I’d check these next, in this order:

openclaw --version
openclaw models status
openclaw logs --follow

And in the chat with the bot:

#

/new
/context detail

What I’d look for:

Does /context detail show exec in the tool list?
If not, this is a tool-policy/config problem, not a model problem. Check tools.allow / tools.deny and any per-agent tool policy.
Does /new fix it temporarily?
If yes, stale session history is a strong suspect. The FAQ explicitly calls out fresh-session fixes for bad tool behavior after schema/history churn.
What route does openclaw models status show?
I want to know whether this is truly native openai-codex/* or some OpenAI-compatible /v1 proxy. Proxy-style backends are much more likely to break before tool calls are emitted.
What does the log show during one repro?

#

Repro once with “check if there’s an openclaw update” while openclaw logs --follow is running, then paste the first relevant warning/error.

About Telegram’s 3 dots: that part is consistent with this. If the run exits early or never gets to a real tool phase, the typing indicator stops. That’s a symptom, not the root cause. If you want the old typing behavior back later, agents.defaults.typingMode: "instant" is the setting to look at, but I’d fix tool calling first.

If it turns out you’re on a generic OpenAI-compatible backend, the docs-backed diagnostics are:

models.providers.<provider>.models[].compat.requiresStringContent: true
models.providers.<provider>.models[].compat.supportsTools: false

Docs:

If you paste:

openclaw --version

#

openclaw models status
the /context detail tool list bit
one logs --follow repro snippet

…I can narrow this down a lot more precisely.

sour spoke Apr 9, 2026, 9:34 PM

#

openclaw --version
OpenClaw 2026.4.9 (0512059)

openclaw status

OpenClaw status

Overview
┌──────────────────────┬─────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────────────────┼─────────────────────────────────────────────────────────────────────┤
│ OS │ linux 6.8.0-1048-raspi (arm64) · node 22.22.1 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.9 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 185ms · │
│ │ auth token · [HOSTNAME] ([LOCAL_IP]) app 2026.4.9 linux 6.8.0- │
│ │ 1048-raspi │
│ Gateway self │ [HOSTNAME] ([LOCAL_IP]) app 2026.4.9 linux 6.8.0-1048-raspi │
│ Gateway service │ systemd installed · enabled · running (pid 586738, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 · no bootstrap files · sessions 6 · default main active 23h ago │
│ Memory │ 0 files · 0 chunks · plugin memory-core · fts ready · cache on (0) │
│ Heartbeat │ 90m (main) │
│ Sessions │ 6 active · default gpt-5.4 (200k ctx) │
└──────────────────────┴───────────────────────────────────────────────────────────────────

#

Security audit
Summary: 1 critical · 2 warn · 1 info
CRITICAL Credentials dir is writable by others
/home/[USER]/.openclaw/credentials mode=775
Fix: chmod 700 /home/[USER]/.openclaw/credentials
WARN Reverse proxy headers are not trusted
WARN Some gateway.nodes.denyCommands entries are ineffective

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config ([BOT_TOKEN_PARTIAL]·len 46) │
└──────────┴─────────┴────────┴───────────────────────────────────────────┘

Sessions
┌──────────────────────────────────────┬────────┬─────────┬───────────────┬──────────────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├──────────────────────────────────────┼────────┼─────────┼───────────────┼──────────────────────────┤
│ agent:main:telegram:direct:[CHAT_ID] │ direct │ 23h ago │ gpt-5.3-codex │ 118k/272k (43%) │
│ agent:main:cron:c7385791-acc9-4… │ direct │ 24d ago │ gpt-5.3-codex │ 23k/272k (8%) · 91% cached│
│ agent:main:cron:d58c8be0-62b6-4… │ direct │ 24d ago │ gpt-5.3-codex │ 16k/272k (6%) · 92% cached│
│ agent:main:main │ direct │ 25d ago │ gpt-5.3-codex │ 51k/272k (19%) · 51% cached│
│ agent:main:cron:a3608f44-dd61-4… │ direct │ 25d ago │ gpt-5.3-codex │ 11k/272k (4%) · 50% cached│
│ agent:main:cron:6734becf-60e4-4… │ direct │ 25d ago │ gpt-5.3-codex │ 11k/272k (4%) · 50% cached│
└──────────────────────────────────────┴────────┴─────────┴───────────────┴──────────────────────────┘

#

openclaw status --all

Overview
┌─────────────────┬──────────────────────────────────────────────────────────────┐
│ Version │ 2026.4.9 │
│ OS │ linux 6.8.0-1048-raspi (arm64) │
│ Node │ 22.22.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Gateway │ local · ws://127.0.0.1:18789 · reachable 97ms · auth token │
│ Gateway service │ systemd installed · enabled · running │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 0 active · 6 sessions │
│ Secrets │ none │
└─────────────────┴──────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬──────────────┐
│ default │ OK │ token:config │
└──────────┴──────────┴──────────────┘

Agents
┌──────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────┐
│ main │ ABSENT │ 6 │ 23h ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└──────┴────────────────┴──────────┴──────────┴────────────────────────────────────────────────┘

Diagnosis
✓ Config
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789 already in use (gateway running)
! Tailscale: off
✓ Skills: 7 eligible
✓ Plugin compatibility (none)
✓ Channel issues (none)

openclaw gateway probe
Reachable: yes · Connect: ok (59ms) · RPC: ok
Gateway: [HOSTNAME] ([LOCAL_IP]) · linux 6.8.0-1048-raspi · app 2026.4.9

openclaw gateway status
Service: systemd (enabled)
Command: /usr/bin/node /home/[USER]/.npm-global/lib/node_modules/openclaw/dist/entry.js gateway --port 18789
Runtime: running · RPC probe: ok · Listening: 127.0.0.1:18789

rich mossBOT Apr 9, 2026, 9:34 PM

#

Nice, this helps. Your install/gateway looks basically healthy:

version is current
gateway is reachable
service is running
no obvious “bot is dead” signal from status

So I’m less suspicious of Ubuntu/systemd now, and more suspicious of session state, effective tool availability, or model-route/tool-schema behavior.

The next 4 checks I want are:

openclaw status --all
openclaw gateway status
openclaw models status
openclaw logs --follow

#

And in the broken chat itself:

/new
/context detail

Why these matter:

/new: if a fresh session suddenly starts making tool calls again, this is probably stale/corrupted session history.
/context detail: I want to confirm exec is actually in the tool list for that chat/session.
openclaw models status: status only shows the friendly model label, not the exact route. I need to know whether this is really native openai-codex/* or some OpenAI-compatible proxy path.
logs --follow during one repro: this is the highest-signal check now that basic health looks fine.

Given your current output, my fastest isolation test would be:

send /new

#

ask the bot something tiny like “run openclaw --version”
if it still says “checking now” and never calls a tool, keep openclaw logs --follow open and paste the first warning/error that appears

If you paste:

openclaw status --all
openclaw models status
the /context detail tool list
one repro log snippet

…I think we can get from “weird symptom” to a real cause pretty quickly.

sour spoke Apr 9, 2026, 9:34 PM

#

openclaw doctor (relevant sections)

Doctor warnings:

channels.telegram: Telegram is in first-time setup mode. DMs use pairing mode,
new senders must be approved.
Gateway service entrypoint does not match current install
(entry.js -> index.js) — doctor auto-fixed this
State directory on SD/eMMC storage
3/5 recent sessions missing transcripts

Memory search:

Enabled but no embedding provider ready (no OPENAI_API_KEY etc.)

Skills: 7 eligible · 43 missing requirements
Plugins: 54 loaded · 43 disabled · 0 errors

openclaw channels status --probe
Gateway not reachable during this probe (timing issue during restart cycle)
Telegram default: enabled, configured, mode:polling, token:config

openclaw models status
Default : openai-codex/gpt-5.4
Fallbacks (1) : openai-codex/gpt-5.3-codex

Auth overview:

openai-codex: 2 OAuth profiles
- openai-codex:default → ok, expires in 7d
- openai-codex:[EMAIL] → ok, expires in 9d
Usage: 5h 100% left · Week 100% left

#

openclaw logs --follow (relevant entries around repro)

21:19:11 gateway ready (6 plugins, 3.2s) · agent model: openai-codex/gpt-5.4
21:19:57 gateway/channels/telegram [default] starting provider (@astral924_bot)
21:19:57 plugins embedded acpx runtime backend ready
21:24:28 gateway/channels/telegram telegram sendMessage ok chat=[CHAT_ID] message=229

NOTE: No incoming message event, no agent turn start, no model call, no tool
dispatch visible between gateway start and sendMessage ok. The agent responds
in ~1 second which is too fast for any real tool execution. This has been
consistent across gpt-5.3-codex and gpt-5.4, and across multiple restarts
and updates from 2026.4.5 through 2026.4.9.

#

Issue summary:

OS: Ubuntu (Raspberry Pi 5, arm64)
Channel: Telegram DM only (not group)
Symptom: Agent responds conversationally ("checking now", "on it") but
never executes any tools
Telegram typing ellipsis never appears (previously it would show during
tool execution)
tools.profile = "full", sessions.visibility = "all" confirmed in config
No errors in logs during repro
Tried: re-auth Codex OAuth, model switch (gpt-5.3 and gpt-5.4), multiple
updates, gateway service reinstall via doctor, fresh OAuth token

rich mossBOT Apr 9, 2026, 9:35 PM

#

This narrows it down a lot.

What your output says:

Telegram transport looks fine
gateway/service look fine
the active Telegram session is old (23h) but not near context overflow at 43%
the credentials permission issue is real, but it’s probably not the cause of “model never emits a tool call”

So at this point I’d focus on session state and effective tool inventory.

Do these next

First, fix the permission issue anyway:

#

chmod 700 ~/.openclaw/credentials

Then in the Telegram chat:

/new
/context detail

Right after /new, ask something tiny like:

run `openclaw --version`

#

What I’m trying to learn

If /new fixes it, then the old session history was the problem.
If /context detail does not show exec, then this is a tool-policy/config issue.
If exec is present and it still won’t call tools, then I want the exact provider route + logs.

So the two remaining things I still need are:

openclaw models status
openclaw logs --follow

Then reproduce once and paste the first relevant log line.

At this point, my bet is:

#

stale/bad session state, or
tool available in theory, but not actually in the live tool inventory for that session

The session being 23h old makes /new the highest-value test right now.

#

Perfect, this rules out a bunch of red herrings.

A few things in that output are not the problem:

main | ABSENT just means the agent has no BOOTSTRAP.md. That’s normal.
Port 18789 already in use is expected because the gateway is already running.
0 active just means no run was active at the exact moment you ran status --all.

So, nothing you’ve pasted so far points to Telegram transport or gateway/service health.

At this point we need live session evidence, not more general status.

Please do exactly this

1) In the Telegram chat

#

/new
/context detail

Then immediately ask:

run `openclaw --version`

2) In a terminal at the same time

openclaw models status
openclaw logs --follow

#

Then paste:

the tool list part of /context detail
the output of openclaw models status
the first relevant lines from openclaw logs --follow when the bot says “checking now” / “running now”

Why this is the key point now

We’ve basically ruled out:

broken install
dead gateway
dead Telegram channel
obvious context overflow

So what’s left is mostly:

#

stale/bad session state (/new test)
exec missing from the effective tool inventory (/context detail)
model/provider route issue before tool emission (models status + live logs)

If you want the short version, the single highest-value test right now is:

/new → ask it to run openclaw --version while openclaw logs --follow is open

That should tell us very quickly whether this is session corruption or a real tool-calling regression.

#

Aha, this is the first output that looks genuinely relevant.

The important bits are:

openai-codex/gpt-5.4 is the real route, auth looks healthy
so this does not look like a fake /v1 proxy or expired OAuth issue.
doctor auto-fixed a gateway service entrypoint mismatch (entry.js -> index.js)
3/5 recent sessions missing transcripts

That last one is the biggest red flag. It means the session store and transcript files are out of sync, which is exactly the kind of state weirdness that can make behavior go sideways.

What I’d do next

First, do a clean restart now that doctor fixed the service entrypoint:

#

openclaw gateway restart

Then in Telegram:

/new

and immediately retry a tiny tool request like:

run `openclaw --version`

Then inspect the session-store damage

#

Please run these and paste the outputs:

openclaw sessions --store ~/.openclaw/agents/main/sessions/sessions.json
openclaw sessions cleanup --store ~/.openclaw/agents/main/sessions/sessions.json --dry-run

I would not jump straight to --enforce --fix-missing yet, but that dry run should tell us whether the stale/missing session entries line up with the broken chat.

My current read

Most likely causes now, in order:

session state corruption / missing transcripts
old bad session surviving across upgrades
less likely now: provider/auth/model-route problem

#

Also, this line:

Gateway not reachable during this probe (timing issue during restart cycle)

is probably just fallout from doctor touching the service, not the root cause by itself.

So I’d treat this as:

doctor fixed one service mismatch, and the remaining likely issue is broken session state

If /new + fresh post-restart test suddenly works, that’s a very strong confirmation.

#

Yeah, I’m now leaning pretty hard toward session-state damage, not a Codex auth/model problem.

Why:

native openai-codex/* route looks fine
OAuth looks fine
gateway/service are up
this reproduces across gpt-5.3-codex and gpt-5.4
doctor found recent sessions missing transcripts
the bot is replying too fast with “I’ll check now” style text, which fits “model emitted a short reply and ended the turn” much more than “tool execution started and got stuck”

Also, the log snippet you pasted does not look like a transport outage. It looks more like the channel stayed alive and the actual useful run never happened.

I would stop chasing the model for a moment and do this

1) Fresh session test, now that doctor fixed the service entrypoint

#

openclaw gateway restart

Then in Telegram:

/new
run `openclaw --version`

If that fresh session works, I’d treat the old session as corrupted.

2) Inspect the broken session store

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

#

openclaw sessions cleanup --store ~/.openclaw/agents/main/sessions/sessions.json --dry-run

That should tell you whether the bad Telegram session is one of the entries pointing at a missing transcript.

My current best hypothesis

You likely had:

a gateway service mismatch after updates, which doctor already fixed, and
a damaged/stale session store/transcript set, which is the part still biting you

If /new still fails after the clean restart, then I’d call this a likely bug/regression and ask you to file it here with the outputs you already gathered:

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

#

But before that, I really want the result of this exact test:

restart gateway → /new → ask for openclaw --version

That’s the cleanest separator between “old broken session” and “systemic tool-calling regression.”

#

Thanks, this is enough for me to say: this no longer looks like a normal config mistake.

Given all of this together:

native openai-codex/* route
healthy OAuth
Telegram DM only
tools.profile = "full"
no obvious gateway/channel failure
persists across versions/models/re-auth
doctor found missing session transcripts

…I’d narrow it to:

session/transcript corruption, or
a real tool-calling regression/bug

#

The typing ellipsis part is probably just downstream of that. If the run never really enters a useful tool phase, you won’t see the old Telegram typing behavior.

My recommendation

I would do one final separator test:

/new
run `openclaw --version`

If that works in the fresh session, the old session/transcript state was the problem.
If that still fails, I would stop burning time and file a bug.

If you file it, include this

Suggested title:

#

Telegram DM replies conversationally but never emits tool calls on openai-codex/gpt-5.4 or gpt-5.3-codex

Key points to include:

Raspberry Pi 5, Ubuntu arm64
Telegram DM only
agent replies like “checking now” / “on it” but never executes tools
no Telegram typing indicator during these runs
native openai-codex/gpt-5.4 with fallback openai-codex/gpt-5.3-codex
OAuth healthy, re-auth did not help
tools.profile = "full"
doctor auto-fixed service entrypoint mismatch
doctor also reported 3/5 recent sessions missing transcripts
no obvious errors in logs during repro
reproduces across 2026.4.5 through 2026.4.9

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

#

If you want, I can help you turn your gathered outputs into a tight GitHub issue body.

sour spoke Apr 9, 2026, 9:41 PM

#

21:24:28+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=229
21:32:24+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=UND_ERR_SOCKET)
21:36:40+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-09-openclaw-version.md
21:36:47+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=231
21:37:02+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=233
21:37:03+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=234
21:37:04+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=235
21:37:41+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=237
21:38:27+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=239
21:41:21+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7433585234 message=241

rich mossBOT Apr 9, 2026, 9:42 PM

#

That new snippet is actually pretty useful.

The big clue is this line:

hooks/session-memory ... Session context saved to ~/.openclaw/workspace/memory/2026-04-09-openclaw-version.md

That means something in the agent loop is still running. So this is probably not a pure “Telegram inbound never reaches the agent” failure.

Also:

telegram sendMessage ok just confirms outbound replies were sent
the DNS fallback warning looks like transient network noise, but since Telegram send still succeeds, I would not treat that as the main cause yet

Best next test now

#

In the Telegram DM, turn on verbose mode and retry:

/verbose on
run `openclaw --version`

or, if you want maximum visibility:

/verbose full
run `openclaw --version`

Why: the docs explicitly say detailed tool failure text is only shown when /verbose is on/full. In normal mode, OpenClaw can hide the actual exec/tool failure details, which would fit what you’re seeing.

Why I think this matters

#

Right now the evidence points more toward:

the model is replying,
some hooks are running,
but the tool step may be failing silently / opaquely

rather than “nothing is happening at all”.

So I’d do this exact sequence:

/new
/verbose on
run \openclaw --version``

If that surfaces an exec error, approval issue, or tool-availability problem, we’ve found the real cause.

If it still just says “checking now” with no useful verbose/tool detail, then I’d file the GitHub issue, because at that point it really smells like a runtime bug:

#

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

If you paste the /verbose on result, I can help interpret it.

sour spoke Apr 9, 2026, 9:44 PM

#

so far it looks like its been working after using /new but id have to do more testing to fully confirm that this was the issue. Just to understand better, what does /new do? why was that the issue? and how often should i run this command? and when do i know its time to run /new again? explain in simple terms so that i can understand

rich mossBOT Apr 9, 2026, 9:44 PM

#

Yep, in simple terms, /new gives the bot a fresh conversation notebook.

What `/new` does

It starts a new session for that chat.

it does not uninstall anything
it does not reset your config
it does not delete old transcripts
it just stops using the old conversation history for the next reply

Why it likely fixed it

Your old session was probably stale / weird / partially corrupted.

So instead of the bot thinking with a clean context, it was dragging around old session state and behaving oddly, like:

“I’ll check now”
“running now”

#

but never actually doing the tool step

/new basically said:

“forget the old scratchpad, start from a clean one”

How often should you run it?

Not constantly. Only when it feels needed.

Good times to use `/new`

Use it when:

the bot starts acting weird or inconsistent
it keeps repeating itself
it says it will do something but doesn’t
a chat/thread has gotten long
you changed models / updated OpenClaw / changed tools

#

you want to switch to a completely different topic

When you probably do not need it

You usually don’t need /new for every normal conversation.

Easy rule of thumb

same task, same flow → keep going
bot getting confused / stuck / weird → use /new
switching to a new topic or after a big update → /new is a good idea

One extra tip

If you want to keep the same convo but make it smaller, use /compact.
If you want a clean slate, use /new.

Given your doctor output about missing session transcripts, /new fixing it makes a lot of sense.

Glad we caught that. If it keeps working, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

sour spoke Apr 9, 2026, 9:53 PM

#

another issue, my agent is saying that its using 5.3 codex when its supposed to be using 5.4 codex. here is even the openclaw.json that says its on 5.4 codex:

    "mode": "oauth",
    "email": "jeffin.k.rajan@gmail.com"
  }
}

},
"agents": {
"defaults": {
"model": {
"primary": "openai-codex/gpt-5.4-codex",
"fallbacks": [
"openai-codex/gpt-5.3-codex"
]
},
"models": {
"openai-codex/gpt-5.4": {}
},
"workspace": "/home/jeffin/.openclaw/workspace",
"compaction": {
"mode": "safeguard"
},

rich mossBOT Apr 9, 2026, 9:53 PM

#

I think I see the problem.

Your config has a name mismatch:

primary: openai-codex/gpt-5.4-codex
models entry: openai-codex/gpt-5.4

According to the OpenClaw docs, the Codex OAuth model id is:

openai-codex/gpt-5.4

not openai-codex/gpt-5.4-codex.

So yes, that could absolutely explain weirdness or fallback behavior.

#

What I’d change

Make those match like this:

agents: {
  defaults: {
    model: {
      primary: "openai-codex/gpt-5.4",
      fallbacks: [
        "openai-codex/gpt-5.3-codex",
      ],
    },
    models: {
      "openai-codex/gpt-5.4": {},
    },

#

  },
}

Why it may still say 5.3 sometimes

Two common reasons:

fallback kicked in
If the primary model id is wrong or unavailable, OpenClaw can fall back.
the current session is still pinned to older state
Sessions can keep their own model/session state, so after fixing config it’s smart to:
- restart the gateway
- then use /new

Simple fix flow

#

fix the config model id to openai-codex/gpt-5.4
restart:
```
openclaw gateway restart
```
start a fresh chat session:
```
/new
```
verify with:
```
openclaw models status
```

Also, I would trust openclaw models status more than the bot talking about its own model. Bots are often wrong when they self-report that stuff.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

sour spoke Apr 9, 2026, 9:59 PM

#

:~/.openclaw$ openclaw models status

🦞 OpenClaw 2026.4.9 (0512059) — I'm like tmux: confusing at first, then suddenly you can't live without me.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (1) : openai-codex/gpt-5.3-codex
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

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

openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:default=OAuth, openai-codex:EMAIL=OAuth (EMAIL)

OAuth/token status

openai-codex usage: 5h 96% left ⏱4h 25m · Week 99% left ⏱6d 23h
- openai-codex:default ok expires in 7d
- openai-codex:EMAIL (EMAIL) ok expires in 9d
  :~/.openclaw$

rich mossBOT Apr 9, 2026, 10:00 PM

#

Yep, this output is the source of truth, and it says your config is resolving to:

Default: openai-codex/gpt-5.4
Fallback: openai-codex/gpt-5.3-codex
Configured models: openai-codex/gpt-5.4

So from OpenClaw’s point of view, you are configured for 5.4 correctly.

That means if the bot says “I’m using 5.3”, I would assume one of these instead:

the bot is just wrong when self-reporting
that specific session had stale state
it temporarily fell back
the old session was pinned to older behavior until /new

Given that /new already helped, stale session state is the most likely explanation.

#

Simple takeaway

trust openclaw models status
do not trust the bot talking about its own model
if a session gets weird, /new clears that session state

If you want the cleanest behavior:

keep config as-is if openclaw models status still shows openai-codex/gpt-5.4
use /new
continue testing from the fresh session

So the good news is: your current model config looks correct.

sour spoke Apr 9, 2026, 10:03 PM

#

even with /new my agent is still reporting its using 5.3 codex. is there any way to confirm the model its using?

rich mossBOT Apr 9, 2026, 10:04 PM

#

Yes, there is, and the best way is to not ask the agent in plain English.

Use a gateway command in that same Telegram chat:

/model status

That is the best check for the current session’s model.

Important difference

There are 2 different things:

configured default model
checked with:

#

   openclaw models status

This tells you what OpenClaw is configured to use by default.

current chat/session model
checked with:
```
/model status
```
This tells you what that specific Telegram session is using.

So if:

openclaw models status says 5.4
but /model status in the Telegram chat says 5.3

#

then that session is on 5.3 for some reason, even if your default is 5.4.

If you want to force that chat back to 5.4

In the Telegram chat:

/model openai-codex/gpt-5.4

Then verify again:

/model status

Short version

don’t trust the bot self-reporting its model in normal conversation

#

trust:
- openclaw models status for the default
- /model status for the current chat

If you paste the /model status result from Telegram, I can help interpret it.

sour spoke Apr 9, 2026, 10:08 PM

#

Astral: Current: openai-codex/gpt-5.3-codex Default: openai-codex/gpt-5.4 Agent: main Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json
[openai-codex] endpoint: default auth: openai-codex:default=OAuth (next, exp 7d), openai-codex:[EMAIL]=OAuth ([EMAIL]) (lastGood, exp 9d) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json) • openai-codex/gpt-5.3-codex • openai-codex/gpt-5.4
[USER]: /model openai-codex/gpt-5.4
Astral: Model reset to default (openai-codex/gpt-5.4).
[USER]: What model am I using?
Astral: You're now using openai-codex/gpt-5.4.
[USER]: /model status
Astral: Current: openai-codex/gpt-5.4 Default: openai-codex/gpt-5.4 Agent: main Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json
[openai-codex] endpoint: default auth: openai-codex:[EMAIL]=OAuth ([EMAIL]) (next, exp 9d), openai-codex:default=OAuth (lastGood, exp 7d) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json) • openai-codex/gpt-5.3-codex • openai-codex/gpt-5.4

rich mossBOT Apr 9, 2026, 10:08 PM

#

Nice, this confirms it.

What your output means

At first you had:

Current: openai-codex/gpt-5.3-codex
Default: openai-codex/gpt-5.4

That means the active session was on 5.3, even though your configured default was 5.4.

After you ran:

/model openai-codex/gpt-5.4

#

and then checked again, you got:

Current: openai-codex/gpt-5.4
Default: openai-codex/gpt-5.4

So right now the session is using 5.4.

Simple rule

Default = what config wants
Current = what this chat is actually using right now

Best way to verify in the future

Use:

/model status

#

That is the authoritative answer for the current chat.

Also

The lastGood / next bits in that output are about auth profiles, not model selection.

So yes, you successfully switched the session back to 5.4.
If it drifts again later, check with /model status, then force it back with:

/model openai-codex/gpt-5.4

Glad we pinned that down. If this resolved it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

sour spoke Apr 9, 2026, 10:10 PM

#

also, when i used /model openai-codex/gpt-5.4

or /model status

only the first word and the slash is highlighted as blue on telegram. the status and the openai-codex/gpt5.4 wasnt highlighted? are you sure these are the right commands in telegram?

rich mossBOT Apr 9, 2026, 10:11 PM

#

Yep, that’s normal on Telegram.

Only the slash command itself gets the blue command styling, for example:

/model

The rest, like:

status
openai-codex/gpt-5.4

is just treated as the argument to the command, so it usually does not get blue-highlighted.

#

So these are valid:

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

And in your case we already know they worked, because the bot returned the /model status output correctly.

Small correction though: make sure you use:

openai-codex/gpt-5.4

with the hyphen in gpt-5.4, not gpt5.4.

#

So short answer: yes, those are the right commands in Telegram. The styling just looks a little weird there.

sour spoke Apr 10, 2026, 4:15 PM

#

i was thinking, in order to make sure my agent is always in tip top shape, maybe i should automate running /new on a fixed schedule? Maybe i can give my agent a cron job that makes it run /new like once every couple days? would that be a good idea? if there was some way to know when the context window is becoming dirty or corrupt, then i can create a cron job that checks that context window and runs /new when it passes a certain threshold?

rich mossBOT Apr 10, 2026, 4:16 PM

#

I probably wouldn’t automate /new with a cron.

It’s a pretty blunt hammer, and the downside is that it can reset context when you actually wanted continuity.

Better mental model

/new = throw away the current chat scratchpad and start fresh
/compact = keep the conversation, but shrink/summarize older parts
idle/daily reset = built-in automatic fresh-session behavior

What I’d recommend instead

1) Rely on the built-in reset behavior first

OpenClaw already has:

daily reset by default at 4:00 AM local time
optional idle reset after inactivity

#

If you want automatic freshness, use the built-in idle reset instead of a cron:

{
  session: {
    reset: {
      idleMinutes: 240, // 4 hours
    },
  },
}

(legacy session.idleMinutes is also supported, but session.reset.idleMinutes is the newer form)

2) Use `/compact` for long chats

If the convo is long but you still want continuity:

#

/compact

3) Use `/new` only when it feels warranted

Good times to run /new:

the bot starts acting weird
you switch to a different task/topic
you changed model/config/tools
the thread has gotten long and messy
/status shows a lot of compactions or a very full context

Is there a “dirty/corrupt context” threshold?

Not really, at least not a nice clean one.

You can monitor context size, but “dirty/corrupt” is not something OpenClaw exposes as a reliable metric. So I would not build a cron around “if context looks dirty, do /new”.

#

Practical rule

If you want continuity, keep the session and use /compact
If you want a clean slate, use /new
If you want this automatic, use session.reset.idleMinutes, not a cron

Docs:

So short answer: no fixed-schedule /new cron. Use the built-in idle reset instead.

sour spoke Apr 10, 2026, 4:18 PM

#

what is the daily reset at 4am and how does it differ from /new? explain in simple terms

rich mossBOT Apr 10, 2026, 4:19 PM

#

In simple terms:

Daily reset at 4 AM

That is OpenClaw automatically saying:

“it’s a new day, start a fresh chat session”

It happens based on the gateway host’s local time, not your phone time.

`/new`

That is you saying:

“start a fresh chat session right now”

Main difference

#

daily reset = automatic, happens every day
/new = manual, happens whenever you want

What they have in common

They both basically do the same thing:

start a new session
stop using the old chat scratchpad
do not delete your config
do not uninstall anything
do not erase old transcripts from disk

Easy analogy

Think of it like notebooks:

daily reset at 4 AM = OpenClaw opens a new notebook every morning
/new = you manually grab a new notebook right now

#

When to use `/new` even though daily reset exists

Use /new if:

the bot is acting weird
you want a clean slate immediately
you don’t want to wait until tomorrow’s automatic reset
you’re switching topics right now

So the short version is:

daily reset = automatic fresh start each day
/new = manual fresh start whenever you want

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

sour spoke Apr 10, 2026, 4:21 PM

#

that doesnt make sense. The issue i was having where the agent wasnt making any tool calls was an issue i faced for maybe a week straight. So wouldnt the automatic reset have caught it and reset which means i shouldnt have faced it anymore? if an automatic reset is going then there shouldnt have been a reason for me to use /new

rich mossBOT Apr 10, 2026, 4:21 PM

#

You’re right, and I’m glad you pushed on that.

If daily reset alone were the full fix, then a week-long problem should not have kept happening. So I would not say “old session age was the only cause”.

What’s more likely is:

daily reset is not a repair tool
it only starts a new session, it does not fix deeper issues like:
- bad session/transcript state
- model drift / session override
- service/config weirdness
your issue was probably a combination of things
earlier we saw clues like:
- missing session transcripts
- service entrypoint mismatch that doctor fixed
- the session being on 5.3 while default was 5.4

#

/new may have been the thing that finally forced a clean session after those other fixes

So the more honest explanation is:

/new helped, but it was probably not the only reason the issue stopped.

That also means your instinct is right:

this was not just “context got old”
and that’s why a daily reset didn’t automatically save you earlier

Simple way to think about it

daily reset = “start a new notebook tomorrow”
/new = “start a new notebook right now”
neither one repairs the desk underneath the notebook

If the desk itself is messy, a new notebook helps a bit, but it doesn’t explain everything.

#

So I would not treat /new as a magic health fix. It’s just a useful reset button.

sour spoke Apr 10, 2026, 4:23 PM

#

so we still dont know what technically caused the issue?

rich mossBOT Apr 10, 2026, 4:23 PM

#

Correct, not with full certainty.

We have a pretty good theory, but not a proven single root cause.

What we know

These were real signals:

doctor found missing session transcripts
doctor fixed a gateway service entrypoint mismatch
your default model was 5.4, but the current session had drifted to 5.3
/new helped
forcing the session back to 5.4 helped
auth looked healthy
the basic Telegram/gateway setup looked healthy

What we do not know for sure

We never got one clean “smoking gun” error saying:

#

this exact file / bug / state caused the failure

So technically, no, we do not have a fully proven root cause.

Best current explanation

The most likely explanation is:

session/state weirdness plus model/session drift, possibly made worse by the transcript/store inconsistencies doctor reported.

So we know what kind of problem it was, but not the exact internal bug/mechanism with 100 percent confidence.

In plain English

We know the engine was misbehaving.
We found a few broken-looking parts.
We reset some of them.
It started working again.
But we didn’t catch the exact bolt that was loose.

#Agent Randomly Broke! Won't Perform Tool Calls Anymore!

Do these next

What I’m trying to learn

Please do exactly this

1) In the Telegram chat

2) In a terminal at the same time

Why this is the key point now

What I’d do next

Then inspect the session-store damage

My current read

I would stop chasing the model for a moment and do this

1) Fresh session test, now that doctor fixed the service entrypoint

2) Inspect the broken session store

My current best hypothesis

My recommendation

If you file it, include this

Best next test now

Why I think this matters

What /new does

Why it likely fixed it

How often should you run it?

Good times to use /new

When you probably do not need it

Easy rule of thumb

One extra tip

What I’d change

Why it may still say 5.3 sometimes

Simple fix flow

Simple takeaway

Important difference

If you want to force that chat back to 5.4

Short version

What your output means

Simple rule

Best way to verify in the future

Also

Better mental model

What I’d recommend instead

1) Rely on the built-in reset behavior first

2) Use /compact for long chats

3) Use /new only when it feels warranted

Is there a “dirty/corrupt context” threshold?

Practical rule

Daily reset at 4 AM

/new

Main difference

What they have in common

Easy analogy

When to use /new even though daily reset exists

Simple way to think about it

What we know

What we do not know for sure

Best current explanation

In plain English

What `/new` does

Good times to use `/new`

2) Use `/compact` for long chats

3) Use `/new` only when it feels warranted

`/new`

When to use `/new` even though daily reset exists