#Failing tool/actions

8 messages · Page 1 of 1 (latest)

native abyss
#

Seeing a regression where the assistant says it will check local state/config, but never actually executes the tool call. Instead it loops with “I can check” / “I haven’t checked yet” style replies, even after explicit confirmation. In one case the user-visible reply also got dropped. Expected behavior is immediate tool execution or a real blocker, not repeated conversational fallback.

heady hedgeBOT
#

Yeah, that’s a bug, not expected behavior.

I checked around, and it matches a few existing reports where the assistant claims it’s about to act, but no actual tool call/artifact ever appears, for example #40069, #40631, and #53959. The dropped user-visible reply sounds like the same execution/finalization path going sideways.

Can you post these 3 things so we can narrow it down fast?

  1. openclaw --version
  2. The affected model/provider path
  3. One bad turn from either:
    • transcript: ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl
    • gateway log: /tmp/openclaw/openclaw-YYYY-MM-DD.log or openclaw logs --follow

Docs:

Short-term sanity check: run the same request on a different provider/model path. If that one executes tools correctly, it strongly points to a model/provider-specific regression instead of local tool config.

native abyss
#

2026.4.15 (041266a)

#

That’s the latest version I’m on

heady hedgeBOT
#

Got it, but I still need the exact string from openclaw --version, not “latest”. npm, beta, and main can all differ, so “latest” is a bit slippery.

If you can, please paste:

  1. exact openclaw --version output
  2. affected model/provider path
  3. one bad transcript or log snippet around the failure

The most useful artifact is a session JSONL chunk where the assistant says “I’ll check” but there’s no following toolCall / toolResult.

If you want the shortest path, reproduce it once, then grab either:

  • openclaw logs --follow
  • or the matching ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl snippet

If you paste that here, I’ll help narrow whether this is tool dispatch, session state, or reply finalization.

native abyss
#

OpenClaw 2026.4.15 (041266a)
Chat gpt 5.4

The agent is not emitting tool calls when it clearly should.

Observed behavior:

• when asked to do a web lookup or even a trivial self-test like a local listing, it replies conversationally about doing the action instead of actually invoking the tool
• there are no visible tool execution errors, which suggests the failure may be happening before dispatch, at tool-call generation/parsing time

Most likely cause:

• session/model/orchestrator issue causing tool-call emission to be suppressed, ignored, or parsed incorrectly

In one line:
The model is behaving like chat-only in this session, even when tool use is explicitly requested.

heady hedgeBOT
#

Yep, that’s useful, and I think your read is pretty reasonable.

A couple of important bits:

  • 2026.4.5 already shipped a mitigation for “model narrates the plan instead of taking action”, so seeing this on 2026.4.15 means it’s either a remaining bug or a different path.
  • “ChatGPT 5.4” still isn’t quite specific enough. I’d want the exact provider slug from openclaw status or the Control UI, for example whether this is the OpenAI API path, Codex OAuth path, or an alias resolving to something else.

Fastest isolation test:

  1. start a fresh session with /new
  2. ask for one trivial tool action
  3. watch openclaw logs --follow while reproducing

Interpretation:

  • fails in fresh session too → likely provider/model tool-call emission or parsing bug
  • only fails in the old session → likely session-state / compaction / transcript corruption