#Openclaw agent is not using tools/running commands

17 messages · Page 1 of 1 (latest)

keen lion
#

I have recently updated my OpenClaw to the 4.14 version, and it has stopped using tools and executing commands for me. Instead, it is instructing me to input commands myself.

Are there any recent known issues similar to this that I can refer to?

manic basaltBOT
#

Yep, there are a few recent reports that sound very close.

Most relevant:

Related older reports in the same symptom family:

Those are basically “agent says it will do it, but never actually emits tool calls”.

A couple of important gotchas I’d check too:

#
  • bad tools.allow entries can silently break tool availability after upgrades
    valid examples are real tool names / groups like exec, web_fetch, group:web

Also, if you’re using an OpenAI-compatible backend, there was a tool-calling bug in openai-completions mode:

Can you paste these so we can tell whether yours is the known 2026.4.14 regression or a config/tool-policy issue?

openclaw --version
openclaw status
openclaw models status
openclaw config get tools
openclaw logs --follow
keen lion
#

openclaw config get tools

🦞 OpenClaw 2026.4.14 (323493f) — Making 'I'll automate that later' happen now.

{
"profile": "full",
"allow": [],
"deny": [],
"byProvider": {},
"web": {
"search": {
"enabled": true,
"provider": "brave"
}
},
"exec": {
"security": "full",
"ask": "off"
}
}

manic basaltBOT
#

Nice, this helps. Your tool config looks sane, so this does not look like the common “tools are denylisted / messaging profile / exec approvals” problem.

With:

"profile": "full",
"allow": [],
"deny": [],
"exec": { "security": "full", "ask": "off" }

the closest match is now the known regression bucket, not config.

Most relevant issue:

#

If yes, that points even more strongly at the 2026.4.14 chat-execution regression in #66679.

keen lion
#

Security audit
Summary: 0 critical · 7 warn · 2 info
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Insecure or dangerous config flags enabled
Detected 1 enabled flag(s): hooks.mappings[0].allowUnsafeExternalContent=true.
Fix: Disable these flags when not actively debugging, or keep deployment scoped to trusted/local-only networks.
WARN Gateway token looks short
gateway auth token is 9 chars; prefer a long random token.
WARN Exec security=full is configured
Full exec trust is enabled for: main.
Fix: Prefer tools.exec.security="allowlist" with ask prompts, and reserve "full" for tightly scoped break-glass agents only.
WARN hooks.defaultSessionKey is not configured
Hook agent runs without explicit sessionKey use generated per-request keys. Set hooks.defaultSessionKey to keep hook ingress scoped to a known session.
Fix: Set hooks.defaultSessionKey (for example, "hook:ingress").
WARN Hook agent routing allows any configured agent
hooks.allowedAgentIds is unset or includes '*', so authenticated hook callers may route to any configured agent id.
Fix: Set hooks.allowedAgentIds to an explicit allowlist (for example, ["hooks", "main"]) or [] to deny explicit agent routing.
… +1 more

manic basaltBOT
#

Yep, that audit still does not point to the cause.

Those warnings are mostly hardening notes:

  • reverse proxy / token length / hooks routing, unrelated
  • exec security=full is actually the opposite of “blocked”, so it would not cause this symptom

So at this point, I’d still treat your case as matching the known regression bucket, especially:

And if you’re on the Codex/OpenAI route, also:

What would help most now is just this:

# 
openclaw models status

If that shows you’re on the same affected model/provider path, then I’d say you have a very solid “same bug” reference.

Also useful: does the same task work from CLI/local agent runs, and fail only in chat? If yes, that’s even closer to #66679.

keen lion
#

openclaw models status

🦞 OpenClaw 2026.4.14 (323493f) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openai-codex/gpt-5.4
Fallbacks (15): openai-codex/gpt-5.4-pro, openai-codex/gpt-5.4-mini, openai-codex/gpt-5.3-codex-spark, openai-codex/gpt-5.3-codex, openai-codex/gpt-5.2-codex, openai/gpt-5.4-pro, openai/gpt-5.4-nano, openai/gpt-5.4-mini, openai/gpt-5.4, openai/gpt-5.3-codex, openai/gpt-5.3-chat-latest, openai/gpt-5.2-pro, openai/gpt-5.2-codex, openai/gpt-5.2, openai-codex/gpt-5.2
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

  • anthropic effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | anthropic:default=token:sk-ant-o...h9MKXQAA
  • google effective=env:AIzaSyCS...oDn0e-NU | env=AIzaSyCS...oDn0e-NU | source=env: GOOGLE_API_KEY
  • openai-codex effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:<my email>=OAuth (<my email>)

Missing auth

  • openai Run openclaw models auth login --provider openai, openclaw configure, or set an API key env var.

OAuth/token status

  • anthropic
    • anthropic:default static
  • openai-codex usage: 5h 87% left ⏱25m · Week 87% left ⏱1d 1h
    • openai-codex:<my email> (<my email>) ok expires in 10d
manic basaltBOT
#

Ah, yep, this makes it much clearer.

You’re on:

  • 2026.4.14
  • default model openai-codex/gpt-5.4
  • openai-codex OAuth
  • tool policy fully open

So this is very likely not your config. It lines up with the current Codex + 2026.4.14 regression cluster.

Best issue references for your case:

#

One extra thing I notice:

  • your fallback list includes several openai/* models
  • but openai auth is missing

So if the openai-codex path is broken, some fallbacks are dead anyway. That’s probably not the root cause here, but it does make recovery/failover worse.

If you want to separate the two main buckets cleanly:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json
#
  • if that fails too, your case is very close to #66633 / #66674
  • if CLI works but chat still refuses tools, #66679 is the closest match

So yes, you definitely have real known issues to point to now.

keen lion
#

Some notes from my agent on where things might need broken:

Because my exec runner in this Discord session is unstable with longer commands, and it intermittently kills processes before completion (SIGKILL / no output), so I can’t trust the result when it happens.

Short commands work (we proved that with counts and single-record ops).
Longer multi-step create scripts are where it breaks.

If you want, I can still try a chunked approach right now (one club at a time in short calls) to maximize success and report each result.

manic basaltBOT
#

That actually sounds like a second, separate issue cluster from the “agent only replies conversationally” one.

I would trust the actual system/tool messages more than the agent’s self-explanation, but if you really are seeing SIGKILL, no output, or Command still running, these are very relevant:

So your report may actually be:

  1. Codex / 2026.4.14 tool-calling regression