#Agent Doesn't Follow Up After Tool Calls

1 messages · Page 1 of 1 (latest)

cerulean grotto
#

I'm having weird issue where OpenClaw says it will go to make a tool call (even something as simple as "echo") and provide me the results and then __fails __ to send a subsequent message if the action succeeded/failed/etc. It just sort of fails to respond.

I've been through many iterations of trying to troubleshoot issues like exec approval, auto exec, etc. Right now I'm operating security:full and ask:off (locally only) and still having this issue.

Ultimately the traces that OpenClaw has done of these issues states that it is in fact making the tool calls in teh background, but just failing to follow up, but doesn't give me much more than "I'm sorry, that's frustrating".

I've had it scan memory, tools, agent and soul to see if there is something contradicting a normal response, but that seems unlikely to both OpenClaw and myself.

Would love to get any ideas on further troubleshooting.

proud summitBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

mental irisBOT
#

This symptom usually isn’t exec approvals — it’s “the tool ran, but the second model call (the follow‑up that reads the tool result and writes a normal reply) didn’t happen / got rejected / got short‑circuited.”

The 3 most common causes I’ve seen:

1) exec is getting backgrounded, and the model never polls it

If your traces show the exec tool returning something like status: "running" + a sessionId, then OpenClaw did exactly what it should: it started the command in the background. But then the model must call process poll/log to get the output — many models just… don’t.

Things that make this happen even for echo:

  • tools.exec.backgroundMs is set very low (or PI_BASH_YIELD_MS=0), so everything backgrounds immediately.
  • The model is explicitly setting background:true.

What to check/try:

  • In config, look at tools.exec.backgroundMs (default is 10000ms). Docs: https://docs.openclaw.ai/gateway/background-process
  • Make sure the process tool is allowed (if you’re using a tool allowlist). If process is disallowed, exec should run synchronously and ignore backgrounding (also in that doc).

2) Provider rejects the follow-up because the transcript contains a malformed tool call

There’s a specific FAQ entry for a very common version of this:

#

LLM request rejected: messages.N.content.X.tool_use.input: Field required

That happens when the model emitted a tool_use block without the required input (often after long threads / stale sessions / schema changes). Fix is usually: start a fresh session with /new.

Docs: https://docs.openclaw.ai/help/faq#why-am-i-seeing-llm-request-rejected-messagesncontentxtooluseinput-field-required

Key tell: your openclaw logs --follow will show a provider validation error right after the tool result is written.

3) The current model/provider is weak at multi-step tool chaining

Even when OpenClaw is correct, some models just don’t reliably “tool → read result → respond”. If you switch the session to a known tool-reliable provider and the problem disappears, you’ve isolated it to the model rather than exec/security.

What I’d ask you to paste (so we can pin it down fast)

  1. openclaw --version
  2. openclaw status --all (it’s designed to be shareable/redacted)
  3. Reproduce once while running:
#

openclaw logs --follow
Then paste the log chunk covering:

  • the model requesting the tool
  • the tool result
  • whatever happens next (provider error / timeout / run end)

Also: when it “fails to follow up”, does the exec tool result show status:"running" + sessionId? If yes, I’d focus on #1 immediately (backgrounding + missing process poll/log).

cerulean grotto
#

root@Keno-Desktop:~# openclaw --version
2026.2.19-2

#

root@Keno-Desktop:~# openclaw --version
2026.2.19-2
root@Keno-Desktop:~# openclaw status --all

🦞 OpenClaw 2026.2.19-2 (45d9b20) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

│
gateway connect failed: Error: pairing required
gateway connect failed: Error: pairing required
OpenClaw status --all

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.19-2 │
│ OS │ linux 5.15.167.4-microsoft-standard-WSL2 (x64) │
│ Node │ 25.6.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.19-2

#

Diagnosis (read-only)

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

✓ Config: /root/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 63743 root: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    error: Error: spawn tailscale ENOENT
    ✓ Skills: 7 eligible · 0 missing · /root/.openclaw/workspace
    ! Channel issues skipped (gateway query failed)

Gateway health:
Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

#

04:16:28 info exec {"subsystem":"exec"} elevated command echo "This is a direct echo test to verify immediate follow-up."
04:16:28 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=63330c16-e3c6-4c2a-b3b1-c58051fd584c tool=exec toolCallId=exec_1771560988002_16
04:16:31 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=63330c16-e3c6-4c2a-b3b1-c58051fd584c isError=false
04:16:31 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=63330c16-e3c6-4c2a-b3b1-c58051fd584c sessionId=18a3bb35-95f5-4d37-98c3-8b95e6f958cd durationMs=17452
04:16:31 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=18a3bb35-95f5-4d37-98c3-8b95e6f958cd totalActive=0
04:16:31 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=63330c16-e3c6-4c2a-b3b1-c58051fd584c sessionId=18a3bb35-95f5-4d37-98c3-8b95e6f958cd durationMs=17851 aborted=false
04:16:31 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=17852 active=0 queued=0
04:16:31 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=17855 active=0 queued=0
04:16:44 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord gateway: Attempting resume with backoff: 1000ms
04:16:45 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord gateway: WebSocket connection closed with code 1005
04:16:51 debug diagnostic {"subsystem":"diagnostic"} heartbeat: webhooks=0/0/0 active=0 waiting=0 queued=0
04:16:53 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord gateway: Attempting resume with backoff: 1000ms
04:16:53 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord gateway: WebSocket connection closed with code 1005
04:17:00 debug cron {"module":"cron","storePath":"/root/.openclaw/cron/jobs.json"}

#

Agent Doesn't Follow Up After Tool Calls

mental irisBOT
#

Nice — 2026.2.19-2 is recent enough that we can rule out a bunch of older tool-loop weirdness.

Next I’d try to separate “exec ran” from “follow-up LLM turn failed”. The fastest way is to grab one clean repro + the exact gateway log lines right after the tool result.

1) First sanity checks (these catch 80% of “CLI vs service vs wrong user/state dir” issues)

Run and paste outputs:

openclaw gateway status
openclaw status --all
openclaw models status
openclaw config get tools.exec

gateway status is especially important because it’ll show if Config (cli) and Config (service) differ (different state dirs / different config), which can make debugging feel haunted.

2) One controlled repro (fresh session)

#

In the chat/thread where it fails, do a fresh session (/new), then ask it to run something trivial like echo hi.

While reproducing, tail logs:

openclaw logs --follow

What I’m looking for in the log chunk right after the tool completes:

  • Any provider validation error (common one: ...tool_use.input: Field required)
  • Any “second call” failure after tool result (rate limit, timeout, bad transcript, etc.)
  • Whether exec is being backgrounded (tool result includes status:"running" + a sessionId)

3) If exec is coming back as “running”

Then the agent must call process poll/log to fetch output — many models don’t, and you’ll see exactly your symptom (“tool ran” but no meaningful follow-up).

#

In that case, check in the tools.exec config you pasted:

  • backgroundMs (if it’s 0 or very small, even echo can get backgrounded)
  • and whether you’re restricting tools in a way that accidentally blocks process

Docs for that behavior: https://docs.openclaw.ai/gateway/background-process

If you paste those 4 command outputs + ~30–80 lines of logs around a single failed run, I can usually tell you which bucket you’re in immediately.

#

That status --all output is a big clue:

  • The Gateway is running (pid openclaw-gateway on 127.0.0.1:18789)
  • But every WS/RPC client is getting kicked with: gateway closed (1008): pairing required

That’s device pairing (Control UI / operator clients), not exec approvals. Until it’s fixed, a bunch of the “real” debug commands (models status, channels status, etc.) can’t query the gateway properly.

Fix the “pairing required” WS lockout first

1) Grab your gateway token (local file read; no gateway RPC needed)

openclaw config get gateway.auth.token
openclaw config get gateway.auth.mode

If there’s no token set, generate one:

# 
openclaw doctor --generate-gateway-token

2) List + approve pending device requests (explicit URL + token)

openclaw devices list --url ws://127.0.0.1:18789 --token "<TOKEN>"
openclaw devices approve <requestId> --url ws://127.0.0.1:18789 --token "<TOKEN>"

Then retry:

openclaw status --all
openclaw gateway status

3) If devices list also can’t connect

#

Then we need to see what IP the gateway thinks you’re coming from.

Two quick checks:

cat ~/.openclaw/devices/pending.json 2>/dev/null || echo "no pending.json"
openclaw logs --follow

Leave logs --follow running, and in another terminal run openclaw status once (to trigger the pairing request). Paste the handful of log lines that mention the device/pairing request.

Why this happens a lot on WSL2

If you open the Control UI from Windows (even as http://127.0.0.1:18789), WSL2’s localhost-forwarding can make the gateway see the client as non-loopback, so it demands device pairing. That’s “expected”. But your CLI inside WSL should normally count as local — if it doesn’t, the logs will tell us what address it’s seeing.

Once WS/RPC access is unblocked, we can go back to the original “tool runs but no follow-up” and inspect one clean repro in the gateway logs (that’s usually either backgrounded exec needing process poll, or a provider transcript validation error right after the tool result).

cerulean grotto
#

ok I think the pairing issue is resolved
OpenClaw status --all

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.19-2 │
│ OS │ linux 5.15.167.4-microsoft-standard-WSL2 (x64) │
│ Node │ 25.6.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.19-2

#

│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 20ms · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ Keno-Desktop (172.31.42.132) app 2026.2.19-2 linux 5.15.167.4-microsoft-standard-WSL2 │
│ Gateway service │ systemd installed · enabled · running (pid 63743) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 0 active · 15 sessions │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Discord │ ON │ OK │ token config (sha256:465cb2a4 · len 72) · accounts 1/1 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Discord accounts
┌──────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │
└──────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬───────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ OK │ 15 │ 14m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴───────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Diagnosis (read-only)

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

✓ Config: /root/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 63743 root: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    error: Error: spawn tailscale ENOENT
    ✓ Skills: 7 eligible · 0 missing · /root/.openclaw/workspace
    ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

root@Keno-Desktop:/mnt/c/Users/keena# openclaw gateway status

🦞 OpenClaw 2026.2.19-2 (45d9b20) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /root/.nvm/versions/node/v25.6.1/bin/node /root/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/root/.nvm/versions/node/v25.6.1/bin/node)
Service config issue: System Node 22+ not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 90596, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789

#

root@Keno-Desktop:~# openclaw config get tools.exec

🦞 OpenClaw 2026.2.19-2 (45d9b20) — Works on Android. Crazy concept, we know.

{
"security": "full",
"ask": "off",
"pathPrepend": [
"/root/bin/gogcli/bin"
]
}

mental irisBOT
#

Good — openclaw gateway status showing RPC probe: ok means the gateway is reachable and responding normally right now.

The weird part is that a minute ago status --all couldn’t query the gateway and got:

gateway closed (1008): pairing required

So next step is to see if that’s still happening (because if the gateway can’t complete the WS handshake reliably, you’ll get exactly the kind of “tool ran but no follow-up / vague apology” behavior from anything that depends on a second round-trip).

1) Re-run the failing command now

openclaw status --all

If it still says pairing required, approve the pending device pairing request:

# 
openclaw config get gateway.auth.token
openclaw devices list --url ws://127.0.0.1:18789 --token "<TOKEN>"
openclaw devices approve <requestId> --url ws://127.0.0.1:18789 --token "<TOKEN>"

(That’s the “Control UI / operator client” pairing, not DM pairing. Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection)

2) Once status --all works, capture one clean repro of the tool-followup failure

Run:

openclaw logs --follow --json

Then reproduce the problem once (in Discord, do /new, then something trivial like “run echo hi”).

#

tools.exec looks pretty “vanilla” on your side — you’ve only customized the policy bits:

{
  security: "full",
  ask: "off",
  pathPrepend: [...]
}

Notably: there’s no backgroundMs override in there, so exec should be using the default behavior (10s yield) and something like echo hi should virtually never end up backgrounded unless:

  • the model is explicitly sending yieldMs super low / background:true, or
  • you’ve got an env var override (e.g. PI_BASH_YIELD_MS) affecting the gateway process.

Two quick checks that will narrow this down hard

#

Paste the log chunk covering:

  • the model tool request
  • the exec tool result
  • what happens immediately after (provider error? timeout? lifecycle end?)

Two specific things I want to see in the exec tool result:

  • does it return status:"running" + sessionId (backgrounded)?
  • or does it return the output directly?

If it’s coming back running, and the model doesn’t call process poll/log, you’ll see “tool happened” but no real follow-up.

3) Side note: your service is running under nvm Node

Gateway status warns:

“Gateway service uses Node from a version manager; it can break after upgrades…”

Not necessarily your root cause, but if the service ever restarts mid-run (Node path changes, nvm env weirdness), you can get “half runs” where a tool started but the follow-up never completes. Once we have the logs, we’ll know if that’s happening. If it is, the fix is usually openclaw doctor --repair after installing a system Node 22+.

#

1) Is exec actually being backgrounded when it fails?

In the tool trace / logs for a “failed follow-up” run, look at the exec tool result:

  • If you see status: "running" and a sessionId, it was backgrounded, and the agent must call process poll/log to get the output (many models don’t, so the run derails).
  • If you see the actual stdout right there, then it’s not a backgrounding issue — the second model call is failing.

If you can paste just the exec tool result JSON from one bad run, that alone tells us which branch we’re in.

2) Catch the real error in gateway logs during one repro

Run:

openclaw logs --follow --json

Then in Discord do /new and ask it to run echo hi (or whatever minimal repro).

#

Send the updated status --all output + the log snippet from a single failed run and we can narrow it down quickly.

#

Paste the log chunk that covers:

  • the tool call start/end
  • and whatever happens right after (provider rejection, timeout, “tool_use.input: Field required”, etc.)

That “I’m sorry, that’s frustrating” often ends up being a fallback when the follow-up model request gets rejected or errors — the logs will show the real reason.

Optional: rule out env override causing instant backgrounding

On the gateway host (same shell where you run the gateway service), check:

echo "PI_BASH_YIELD_MS=$PI_BASH_YIELD_MS"
openclaw config get tools.exec.backgroundMs

(If PI_BASH_YIELD_MS is set to something tiny/0 in the service env, it would explain “even echo backgrounds”.)

If you drop the exec tool result + that one log snippet, we can tell you exactly what’s happening and what knob fixes it.

cerulean grotto
#

OK the pairing issue is resolved, which seems to have helped overall snappyness of openclaw.

I ran the echo test while tailing logs, below

16:42:49 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
16:42:49 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
16:42:49 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
16:42:49 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
16:42:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 provider=google-vertex model=gemini-2.5-flash thinking=low messageChannel=discord
16:42:49 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=842668aa-356f-413b-95a7-10fcf08b1881 totalActive=1

mental irisBOT
#

Nice — pairing being fixed + “snappier” lines up perfectly (the gateway was basically refusing WS clients before).

For the tool-followup issue: the log chunk you pasted only shows run start, not the important part (tool call + tool result + run end/error). We need ~20–100 more lines.

Please paste the rest of that run (same runId) up to lifecycle end/error

You’ve got:

runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5

Grab everything for that run from the gateway log file (your gateway status showed it here: /tmp/openclaw/openclaw-2026-02-20.log):

RUN=3f0a7ba8-8e0e-4d3f-b793-164506e646d5
grep -n "$RUN" /tmp/openclaw/openclaw-2026-02-20.log

If that’s too sparse, also paste the nearby lines that include tool, exec, process, lifecycle, or error around that timestamp (16:42:49).

#

What I’m specifically looking for:

  • a line showing the tool call (exec) and the command it actually ran
  • the exec result shape:
    • did it return output directly, or status:"running" + sessionId (backgrounded)?
  • whether the run ended with lifecycle end vs lifecycle error
  • any provider validation error right after the tool result

One quick isolation test (since you’re on Vertex/Gemini)

Your run is:

provider=google-vertex model=gemini-2.5-flash

After you paste the run logs, also try the same echo repro once on an Anthropic-backed model (just temporarily via /model picker). If Anthropic follows up reliably but Vertex doesn’t, we can stop chasing exec/tool config and treat it as model/provider tool-chaining behavior.

Once you paste the grep output for that runId, we’ll know which branch this is.

cerulean grotto
#

I'm trying to paste second part of the logs, but keep getting this error from discord

Your message could not be delivered. This is usually because you don't share a server with the recipient or the recipient is only accepting direct messages from friends. You can see the full list of reasons here: https://support.discord.com/hc/en-us/articles/360060145013

mental irisBOT
#

That Discord error message is a DM-delivery error (it usually shows up when you try to DM a user/bot you don’t share a server with, or DMs are closed) — it’s weird if you’re posting inside this thread.

Two ways around it:

Option A (best): upload the log snippet as a file attachment in the thread

On your box:

RUN=3f0a7ba8-8e0e-4d3f-b793-164506e646d5
LOG=/tmp/openclaw/openclaw-2026-02-20.log
grep -n "$RUN" "$LOG" > /tmp/openclaw-run.log
tail -n 200 "$LOG" >> /tmp/openclaw-run.log

Then attach /tmp/openclaw-run.log in Discord.

(Quick heads-up: skim it first to make sure there’s no token/API key in there.)

#

Option B: paste only the minimal lines (small enough for Discord)

Discord hard-limits message length, so do this and paste the output:

RUN=3f0a7ba8-8e0e-4d3f-b793-164506e646d5
LOG=/tmp/openclaw/openclaw-2026-02-20.log
grep -n "$RUN" "$LOG" | head -n 80

If that still misses the tool bits, also paste anything around exec/tool/lifecycle:

grep -nE "$RUN|exec|process|tool|lifecycle|error|rejected" "$LOG" | head -n 120

Also: confirm where you’re trying to paste

Are you pasting in this #help thread or trying to DM someone (or the bot)? If it’s DM, just post it here as a file or split paste—DMs are often restricted.

#

Once I can see the lines for that runId, we’ll know immediately whether this is:

  • exec got backgrounded (needs process poll/log), or
  • the follow-up model call got rejected/errored (common on some Gemini configs), or
  • the run is ending early due to another gateway/runtime issue.
cerulean grotto
#

16:42:53 info exec {"subsystem":"exec"} elevated command echo "hello world"
16:42:53 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5 tool=exec toolCallId=exec_1771605773821_6
16:42:56 debug diagnostic {"subsystem":"diagnostic"} heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
16:42:58 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5 isError=false
16:42:58 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=8224
16:42:58 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=842668aa-356f-413b-95a7-10fcf08b1881 totalActive=0
16:42:58 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=3f0a7ba8-8e0e-4d3f-b793-164506e646d5 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=8275 aborted=false
16:42:58 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=8276 active=0 queued=0
16:42:58 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=8279 active=0 queued=0

mental irisBOT
#

Those lines are actually good news:

  • exec is not being backgrounded here (no status:"running" / no sessionId)
  • the agent loop did do the “follow-up step” after the tool finished (tool ended at 16:42:53, agent ended at 16:42:58, isError=false)

So if, from the user-facing side, it still feels like “tool ran but it didn’t follow up”, it’s almost certainly one of these:

1) You’re seeing the tool-start bubble but not the tool output (verbose level)

When /verbose on is enabled, OpenClaw will send a separate “tool is starting” message (exec: …). But tool output is only forwarded as a separate bubble when verbose is full.

Try in the same Discord thread/session:

  • /verbose (to see current)
  • /verbose full
  • then re-run echo hello world

Docs: https://docs.openclaw.ai/tools/thinking#verbose-directives-verbose-or-v

#

2) The follow-up reply exists, but Discord delivery is failing/suppressed

In that case you’ll see agent end “ok” in logs, but also a Discord send error nearby.

Quick grep around that timestamp:

LOG=/tmp/openclaw/openclaw-2026-02-20.log
grep -nE "16:42:5[0-9]|discord|send failed|drop|Forbidden|missing_scope" "$LOG" | tail -n 80

3) The model is ending the run with an empty/NO_REPLY final message

This happens occasionally with some providers/models: tool call succeeds, then the model’s “post-tool” message is empty (so nothing meaningful gets delivered).

Since you have the sessionId in logs:

sessionId=842668aa-356f-413b-95a7-10fcf08b1881

#

Check what actually got persisted:

tail -n 80 ~/.openclaw/agents/main/sessions/842668aa-356f-413b-95a7-10fcf08b1881.jsonl

If the last assistant message is empty or contains NO_REPLY, that explains the “no follow up”.

One question that will instantly narrow it down: what did you actually see in Discord for this echo test?

  • Did you get any final assistant message after the tool ran?
  • And do you currently have /verbose on in that thread?
cerulean grotto
#

In this case the tool did follow up, here is it from the discord side, so at least with this simple use case it worked, which it wasn't before. I wonder if the pairing issue was the root cause?

About Three Fiddy

— 8:42 AM
Can you go run an echo hello world command and then report back the results to me. Log following is on.
KenoClaw
APP
— 8:42 AM
Alright, I ran echo "hello world" for you.

The result I received was: hello world

Now, if you've been diligently watching that openclaw logs --follow feed like we discussed, you should have the juicy details around that command execution. Time to spill the beans (or the logs, in this case) so we can figure out why I sometimes get stage fright after a tool call.

cerulean grotto
#

hmm got some more instances, here is a log snippet

20:02:15 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=f42213e4cd6f778a5455ed0dc7994c8ce3a2a4cb910bf44d72472fc02e20dead ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.admin,operator.approvals,operator.pairing,operator.read scopesTo=operator.write client=gateway-client conn=e9402d10-6c0a-4c54-8cb3-14daa4cc97b1
20:02:15 error gateway connect failed: Error: pairing required
20:02:15 error gateway connect failed: Error: pairing required
20:02:15 error Subagent completion direct announce failed for run 42cb65bb-3ed3-4dcd-8b6a-174f2b43aaa4:43ece464-f653-4996-a936-e058f64e692d: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
20:02:15 info cron {"module":"cron","storePath":"/root/.openclaw/cron/jobs.json"} {"jobId":"42cb65bb-3ed3-4dcd-8b6a-174f2b43aaa4","consecutiveErrors":2,"backoffMs":60000,"nextRunAtMs":1771817400000} cron: applying error backoff
20:02:15 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":16,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"0fa14282-8537-446f-8819-717634a179dc","host":"127.0.0.1:18789","deviceId":"f42213e4cd6f778a5455ed0dc7994c8ce3a2a4cb910bf44d72472fc02e20dead","requestId":"d713e23f-07f6-4222-acfc-e723e1d457c8","reason":"scope-upgrade"} closed before connect conn=e9402d10-6c0a-4c54-8cb3-14daa4cc97b1 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=pairing required
20:02:15 debug cron {"module":"cron","storePath":"/root/.openclaw/cron/jobs.json"} {"nextAt":1771689600000,"delayMs":60000,"clamped":true} cron: timer armed
20:02:15 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ cron.run 26414ms conn=8d2f4a68…ddec id=6076587b…257b
20:02:15 info {
"ok": true,
"ran": true
}

cerulean grotto
#

21:19:59 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
21:19:59 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
21:19:59 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
21:19:59 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=0 queueSize=0
21:19:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 provider=google-vertex model=gemini-2.5-flash thinking=low messageChannel=discord
21:19:59 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=842668aa-356f-413b-95a7-10fcf08b1881 totalActive=1
21:19:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881
21:19:59 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048
21:20:05 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 tool=exec toolCallId=exec_1771622405381_4
21:20:05 info exec {"subsystem":"exec"} elevated command openclaw cron runs 42cb65bb-3ed3-4dcd-8b6a-174f2b43aaa4
21:20:08 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 tool=exec toolCallId=exec_1771622405381_4
21:20:10 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 tool=exec toolCallId=exec_1771622410578_5
21:20:10 info exec {"subsystem":"exec"} elevated command openclaw cron runs --id 42cb65bb-3ed3-4dcd-8b6a-174f2b43aaa4
21:20:11 info {
<redacted>

#

21:20:11 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 tool=exec toolCallId=exec_1771622410578_5
21:20:18 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 isError=false
21:20:18 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=18311
21:20:18 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=842668aa-356f-413b-95a7-10fcf08b1881 totalActive=0
21:20:18 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=18367 aborted=false
21:20:18 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=18368 active=0 queued=0
21:20:18 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=18369 active=0 queued=0
21:20:18 debug diagnostic {"subsystem":"diagnostic"} heartbeat: webhooks=0/0/0 active=0 waiting=0 queued=0

#

some more runs, can you tell me if this is getting backgrounded?

mental irisBOT
#

Those lines still show the same pattern as before:

  • tool finished (embedded run tool end … tool=exec)
  • model did some post-tool work (7s gap)
  • run ended cleanly (agent end … isError=false, aborted=false)

So the “doesn’t follow up” is now almost certainly not “exec didn’t run” — it’s either:

  1. the run produced no renderable final assistant message (empty / NO_REPLY), or
  2. the final message was produced but Discord delivery failed / was sent elsewhere.

Here are the two quickest confirmations.

A) Did the model actually produce a final assistant message? (check transcript)

Run this locally (don’t paste the whole file—just tell me what it prints):

# 
SID=842668aa-356f-413b-95a7-10fcf08b1881
FILE=~/.openclaw/agents/main/sessions/$SID.jsonl

python3 - <<'PY'
import json, os
path=os.path.expanduser(os.environ["FILE"])
msgs=[json.loads(l) for l in open(path,"r",encoding="utf-8") if l.strip()]
last_asst=next((m for m in reversed(msgs) if m.get("role")=="assistant"), None)
if not last_asst:
    print("no assistant message found at end")
    raise SystemExit
c=last_asst.get("content")
print("assistant content type:", type(c).__name__)
print("assistant content:", c)
PY
#

If the assistant content is NO_REPLY, empty, or just tool metadata with no text: that explains the “no follow up” immediately (OpenClaw filters NO_REPLY / can end with nothing if the model gives nothing).

B) If there is a real assistant message in the transcript, did Discord send fail?

Search the gateway log around that runId for send errors:

RID=82078ed3-c77d-4acd-a4e1-0de4fcd03048
LOG=/tmp/openclaw/openclaw-2026-02-20.log

grep -nE "$RID|discord|send fail|Missing Access|Forbidden|rate limit|50013|50001" "$LOG" | tail -n 120

If you see Missing Access / Forbidden, it’s permissions (common with threads). If you see nothing about Discord sending at all, it often means there was nothing to deliver (case A).

Also: are you running with /verbose on (not full)? If yes, you’ll see “exec starting” style bubbles, but not necessarily the tool output — try /verbose full once just to make the behavior obvious.

Tell me what you get from A (what the last assistant content is) and B (any discord send errors), and we can point to the exact fix.

cerulean grotto
#

3365:{"0":"{"subsystem":"agent/embedded"}","1":"embedded run prompt end: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=18311","_meta":{"runtime":"node","runtimeVersion":"25.6.1","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-02-20T21:20:18.117Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///root/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js:438:14","fileName":"subsystem-BCQGGxdd.js","fileNameWithLine":"subsystem-BCQGGxdd.js:438","fileColumn":"14","fileLine":"438","filePath":".nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js","filePathWithLine":".nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js:438","method":"logToFile"}},"time":"2026-02-20T21:20:18.117Z"}
3367:{"0":"{"subsystem":"agent/embedded"}","1":"embedded run done: runId=82078ed3-c77d-4acd-a4e1-0de4fcd03048 sessionId=842668aa-356f-413b-95a7-10fcf08b1881 durationMs=18367 aborted=false","_meta":{"runtime":"node","runtimeVersion":"25.6.1","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-02-20T21:20:18.121Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///root/.nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js:438:14","fileName":"subsystem-BCQGGxdd.js","fileNameWithLine":"subsystem-BCQGGxdd.js:438","fileColumn":"14","fileLine":"438","filePath":".nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js","filePathWithLine":".nvm/versions/node/v25.6.1/lib/node_modules/openclaw/dist/subsystem-BCQGGxdd.js:438","method":"logToFile"}},"time":"2026-02-20T21:20:18.121Z"}

#

root@Keno-Desktop:~/.openclaw/workspace/skills/gsuite-helper-skill# SID=842668aa-356f-413b-95a7-10fcf08b1881
root@Keno-Desktop:~/.openclaw/workspace/skills/gsuite-helper-skill# FILE=~/.openclaw/agents/main/sessions/$SID.jsonl
root@Keno-Desktop:~/.openclaw/workspace/skills/gsuite-helper-skill# python3 - <<'PY'
import json, os
path=os.path.expanduser(os.environ["FILE"])
msgs=[json.loads(l) for l in open(path,"r",encoding="utf-8") if l.strip()]
last_asst=next((m for m in reversed(msgs) if m.get("role")=="assistant"), None)
if not last_asst:
print("no assistant message found at end")
raise SystemExit
c=last_asst.get("content")
print("assistant content type:", type(c).name)
print("assistant content:", c)
PY
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "<frozen os>", line 685, in getitem
KeyError: 'FILE'
root@Keno-Desktop:~/.openclaw/workspace/skills/gsuite-helper-skill# echo $FILE
/root/.openclaw/agents/main/sessions/842668aa-356f-413b-95a7-10fcf08b1881.jsonl

mental irisBOT
#

Those log lines mean: the run completed successfully (isError=false, aborted=false) after the tool finished.

So the remaining question is: what did the model produce as the final assistant message, and did Discord actually deliver it? Right now we only see “tool end” + “agent end”, not the final payload.

1) Check if the final assistant message is empty / NO_REPLY (most common in this situation)

This prints only a tiny summary (length + a short preview):

SID=842668aa-356f-413b-95a7-10fcf08b1881
FILE=~/.openclaw/agents/main/sessions/$SID.jsonl

python3 - <<'PY'
import json, os
path=os.path.expanduser(os.environ["FILE"])
msgs=[json.loads(l) for l in open(path,"r",encoding="utf-8") if l.strip()]
last_asst=next((m for m in reversed(msgs) if m.get("role")=="assistant"), None)
# 
c = last_asst.get("content") if last_asst else None

# normalize to a single string preview if possible
text=""
if isinstance(c,str):
  text=c
elif isinstance(c,list):
  for b in c:
    if isinstance(b,dict) and b.get("type")=="text":
      text += b.get("text","")
print("found_assistant:", bool(last_asst))
print("text_len:", len(text.strip()))
print("is_NO_REPLY:", text.strip()=="NO_REPLY")
print("preview:", text.strip().replace("\n","\\n")[:160])
PY
#

If text_len is 0 or is_NO_REPLY: True, that explains the “no follow up”: the model basically “stopped after tool use” and produced nothing renderable.

2) If there is text in the transcript, check for Discord send failures

Run:

RID=82078ed3-c77d-4acd-a4e1-0de4fcd03048
LOG=/tmp/openclaw/openclaw-2026-02-20.log
grep -nE "$RID|subsystem\":\"discord|Missing Access|Forbidden|50013|50001|rate limit|send fail" "$LOG" | tail -n 200

3) Quick “make it obvious” test: /verbose full

If your main complaint is “it runs the command but I never see the output”, Discord often just isn’t showing the tool output bubbles.

In the same thread/session, try:

  • /verbose full
#

Yep — that error is just shell scoping:

You set FILE=... in your shell, but you didn’t export it, so Python can’t see it via os.environ["FILE"].

Run it like this (inline env vars for that one command):

SID=842668aa-356f-413b-95a7-10fcf08b1881
FILE=~/.openclaw/agents/main/sessions/$SID.jsonl

FILE="$FILE" python3 - <<'PY'
import json, os
path=os.path.expanduser(os.environ["FILE"])
msgs=[json.loads(l) for l in open(path,"r",encoding="utf-8") if l.strip()]
last_asst=next((m for m in reversed(msgs) if m.get("role")=="assistant"), None)
c = last_asst.get("content") if last_asst else None
#
  • then echo hello world again

With verbose=full, OpenClaw forwards tool output as a separate bubble after completion (docs: https://docs.openclaw.ai/tools/thinking#verbose-directives-verbose-or-v).

If you paste the 4-line summary from step (1) (found_assistant/text_len/is_NO_REPLY/preview), we can tell immediately whether this is “model ended silent” vs “Discord didn’t deliver.”

# 

text=""
if isinstance(c,str):
  text=c
elif isinstance(c,list):
  for b in c:
    if isinstance(b,dict) and b.get("type")=="text":
      text += b.get("text","")

print("found_assistant:", bool(last_asst))
print("text_len:", len(text.strip()))
print("is_NO_REPLY:", text.strip()=="NO_REPLY")
print("preview:", text.strip().replace("\n","\\n")[:160])
PY
#

Alternative (export once):

export FILE=~/.openclaw/agents/main/sessions/842668aa-356f-413b-95a7-10fcf08b1881.jsonl
python3 - <<'PY'
...
PY

Paste the 4 output lines (found_assistant/text_len/is_NO_REPLY/preview). That will tell us whether the model is ending silently (most likely) or whether Discord delivery is the problem.

cerulean grotto
#

normalize to a single string preview if possible

text=""
if isinstance(c,str):
text=c
elif isinstance(c,list):
for b in c:
if isinstance(b,dict) and b.get("type")=="text":
text += b.get("text","")
print("found_assistant:", bool(last_asst))
print("text_len:", len(text.strip()))
print("is_NO_REPLY:", text.strip()=="NO_REPLY")
print("preview:", text.strip().replace("\n","\n")[:160])
PY
found_assistant: False
text_len: 0
is_NO_REPLY: False
preview:

#

root@Keno-Desktop:~/.openclaw/workspace/skills/gsuite-helper-skill# python3 - <<'PY'
import json, os
path=os.path.expanduser("~/.openclaw/agents/main/sessions/842668aa-356f-413b-95a7-10fcf08b1881.jsonl")
msgs=[json.loads(l) for l in open(path,"r",encoding="utf-8") if l.strip()]
last_asst=next((m for m in reversed(msgs) if m.get("role")=="assistant"), None)
if not last_asst:
print("no assistant message found at end")
raise SystemExit
c=last_asst.get("content")
print("assistant content type:", type(c).name)
print("assistant content:", c)
PY
no assistant message found at end

mental irisBOT
#

That output is super suspicious: found_assistant: False means “in that JSONL file, there are zero messages with role == "assistant" anywhere.”

That can happen for two boring reasons:

  1. you’re looking at the wrong transcript file (sessionId mismatch), or
  2. the JSONL lines don’t store role at top-level (e.g. it’s nested like message.role), so the script never sees it.

Let’s confirm which one, without leaking content.

1) First: is the file non-empty?

FILE=~/.openclaw/agents/main/sessions/842668aa-356f-413b-95a7-10fcf08b1881.jsonl
wc -l "$FILE"

2) Print the keys + where role lives (first 5 lines, no content)

# 
python3 - "$FILE" <<'PY'
import json, sys
path=sys.argv[1]
n=0
for i,line in enumerate(open(path,"r",encoding="utf-8"),1):
  line=line.strip()
  if not line: continue
  o=json.loads(line)
  print(i, "keys=", sorted(o.keys()))
  print("  role=", o.get("role"), " message.role=", (o.get("message") or {}).get("role"))
  n += 1
  if n >= 5: break
PY

3) Role histogram (handles both top-level and nested message.role)