`exec` Tool Results Silently Dropped in OpenClaw 2026.4.11

[oak isle]

Symptoms

• exec tool calls return no results — any command, including echo "test", produces no output
• Gateway WebSocket logs show ZERO exec tool invocations — no tool.exec, no command traces, nothing
• commands.log stopped recording on 2026-04-07 (version 2026.4.5) — command-logger hook appears broken after upgrade
• yieldMs parameter has no effect — results still not delivered
• Cron jobs using exec work — isolated sessions can run commands, results appear as system messages, but NOT delivered to main session
• SSH works manually — running the same SSH commands from terminal succeeds

What Works
Tool Status
read (file read) ✅ Works
web_search ✅ Works
memory_search ✅ Works
cron (isolated sessions) ✅ Works
message (send) ✅ Works
exec (gateway) ❌ Broken
write (file write) ⚠️ Reports success but file may not change

Reproduction

• Call exec with any command: {"command": "echo test", "timeout": 10, "yieldMs": 8000}
• No result is returned to the session
• Gateway logs show no tool invocation
• No error is raised — silent failure

Impact

• Agent cannot perform any host-level operations (system checks, file management, SSH to remote hosts)
• Only cron-based isolated sessions can execute commands
• Effectively reduces the agent to a read-only chat assistant

exec tool should run commands on the gateway host and return stdout/stderr to the calling session, as it did in version 2026.4.5.

[sharp stratus]

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

[tardy orchid]

Let me check the docs and local runtime before I guess.

I found one thing worth checking before we chase ghosts: cron working while the main chat session cannot use exec usually points to a per-agent or per-session routing/policy difference, not SSH itself. I’m checking the docs/code path for that now.

First, what does openclaw --version print?

The biggest clue in your report is actually this:

• write says success, but host files may not change
• thread/channel runs differ from cron
• gateway host logs show no host-side exec traces

That pattern usually means the session is sandboxed or using a remote-canonical sandbox workspace, not that exec is universally dead.

A couple important corrections too:

• commands.log is not the exec trace. The bundled command-logger hook logs slash commands, not arbitrary tool invocations. So a stale commands.log does not prove exec stopped. Docs: https://docs.openclaw.ai/automation/hooks#command-logger
• yieldMs only affects backgrounding. It does not change where exec runs, and if process is unavailable it is ignored. Docs: https://docs.openclaw.ai/tools/exec

Please paste these exact outputs:

openclaw --version
openclaw status --all
openclaw sandbox explain
openclaw config get agents.defaults.sandbox
openclaw config get tools.exec
openclaw config get tools.sandbox.tools

Also, quick A/B test:

• try the same echo test in a DM
• then try it again in this Discord thread

If DM works but the thread does not, that strongly points to agents.defaults.sandbox.mode: "non-main" or sandbox tool policy. Group/channel sessions are treated as non-main and get sandboxed in that mode. Docs: https://docs.openclaw.ai/gateway/sandboxing and https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

If sandbox explain shows this thread is sandboxed, then your “write succeeded but nothing changed” symptom makes perfect sense too.

[oak isle]

OpenClaw 2026.4.11 (769908e)

Overview
│ Item │ Value
│ Version │ 2026.4.11
│ OS │ linux 6.8.0-107-generic (x64)
│ Node │ 24.14.1
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off
│ Channel │ stable (config)
│ Update │ pnpm · up to date · npm latest 2026.4.11
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 77ms · auth token · openclaw (192.168.1.200) app 2026.4.11 linux 6.8.0-107-generic
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · running (pid 115861, state active)
│ Node service │ systemd not installed
│ Agents │ 1 total · 1 bootstrapping · 1 active · 17 sessions
│ Secrets │ none

[tardy orchid]

Version looks normal. The one thing that jumps out now is Agents: 1 total · 1 bootstrapping, which can matter here, so I’m checking the docs before I point you in the wrong direction.

Thanks, that version looks fine.

At this point I’d narrow it to two likely causes:

1. This Discord thread is running as a non-main session and getting sandboxed

   • In sandbox.mode: "non-main", group/channel sessions are sandboxed by default.
   • That would explain:
     • host exec traces not appearing where you expect
     • write seeming to “succeed” without changing host files
   • Docs: https://docs.openclaw.ai/gateway/sandboxing

2. The agent is still marked bootstrapping

   • 1 total · 1 bootstrapping is suspicious.
   • Bootstrapping is supposed to be first-run only, and BOOTSTRAP.md should be removed when finished.
   • Docs: https://docs.openclaw.ai/start/bootstrapping

Also, one correction: commands.log still is not the exec trace, it’s for slash commands. https://docs.openclaw.ai/automation/hooks#command-logger

Can you paste these next?

openclaw sandbox explain
openclaw config get agents.defaults.sandbox
openclaw config get tools.exec
openclaw config get tools.sandbox.tools
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING
openclaw doctor

And one very useful A/B test:

• run the same echo test in a DM
• run it again in this thread

If DM works but the thread does not, I’d bet on sandbox.mode: "non-main" or sandbox tool policy, not a general exec regression.

[oak isle]

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent
workspaceAccess: none workspaceRoot: /root/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, feishu, googlechat, nostr, msteams, mattermost, nextcloud-talk, matrix, bluebubbles, line, zalo, zalouser, synology-chat, tlon, discord, imessage, irc, qqbot, signal, slack, telegram, twitch, whatsapp

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

[tardy orchid]

That output helps, but it only shows the default main session:

• sessionKey: agent:main:main
• runtime: direct
• mode: off

So it does not prove the Discord thread is direct. It only proves the main session is.

For this bug, we need the thread’s actual session key. In channel/group setups, that can differ from agent:main:main.

Aha, that explains the mismatch.

openclaw sandbox explain without --session defaults to the main session, so you only checked agent:main:main.

For Discord guild channels, the docs say the session key is:

agent:<agentId>:discord:channel:<channelId>

So for this thread, please run:

openclaw sandbox explain --session agent:main:discord:channel:1492976076895289364
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING
openclaw doctor

That should tell us a lot:

• if the thread session is sandboxed or not
• whether bootstrapping is still stuck
• whether doctor sees a config/runtime problem

If that first command still shows mode: off and runtime: direct for the thread session, then I’d stop blaming sandbox and focus on the lingering 1 bootstrapping state plus whatever doctor reports.

[oak isle]

openclaw config get agents.defaults.sandbox

{
"mode": "off"
}

I use telegram , not discord

[tardy orchid]

Nice, that mostly kills the sandbox theory.

If agents.defaults.sandbox.mode is off, then the next suspects are:

1. tools.exec is routed somewhere unexpected
   Especially host=node, which would fit your Node service: not installed.

2. Per-agent tool policy / override

3. The agent still being stuck in bootstrapping

Can you paste these next?

openclaw config get tools.exec
openclaw config get agents.list
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING

openclaw doctor
openclaw hooks list

Why these:

• tools.exec tells us if exec is actually targeting gateway vs node
• agents.list shows per-agent overrides that can differ from defaults
• BOOTSTRAP_PRESENT would explain the weird 1 bootstrapping
• doctor may catch stale config/runtime issues
• hooks list will tell us whether command-logger is even enabled, since commands.log is a side issue here

If tools.exec.host=node, I’d call that the leading theory right now.

Ah, got it, that changes the picture.

If the broken session is actually Telegram, then the Discord thread/session-key stuff is just where we’re talking, not where your exec problem lives. So we can drop that whole Discord routing theory.

The best next checks are still these:

openclaw config get tools.exec
openclaw config get agents.list
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING
openclaw doctor
openclaw hooks list

What I’m looking for now:

• tools.exec.host=node or other unexpected exec routing

• per-agent overrides in agents.list
• whether the agent is still stuck bootstrapping
• whether doctor reports a session/config/runtime problem
• whether command-logger is even enabled

If you paste those, we should be able to stop guessing and pin this down.

[oak isle]

openclaw config get tools.exec
{
"host": "gateway",
"security": "full",
"ask": "off",
"notifyOnExit": true
}

[tardy orchid]

Perfect, that rules out exec routing.

So now we know:

• sandbox is off
• exec is configured for host: "gateway"
• security: "full" and ask: "off" are normal
• so this does not look like an approval or host-target issue

At this point, the strongest remaining theories are:

1. effective tool policy is not actually exposing exec/write to the agent
2. agent/session state is weird, especially the earlier 1 bootstrapping
3. less likely, a real regression in tool-call handling for this session/provider path

Can you paste these next?

openclaw config get tools
openclaw config get agents.list
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING
openclaw doctor
openclaw hooks list

Why tools matters here: if tools.allow is non-empty, anything not listed is effectively blocked, even if tools.exec itself looks fine. That would fit your “no exec invocation reaches the gateway” symptom.

[oak isle]

openclaw config get agents.list
[
{
"id": "main",
"name": "main",
"model": "bailian/qwen3.6-plus"
}
]
test -e ~/.openclaw/workspace/BOOTSTRAP.md && echo BOOTSTRAP_PRESENT || echo BOOTSTRAP_MISSING

BOOTSTRAP_PRESENT

OpenClaw doctor
Update

This install is not a git checkout. \Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor.

[tardy orchid]

Okay, two real clues now:

• BOOTSTRAP_PRESENT is not expected after first-run
• your model is bailian/qwen3.6-plus, so I want to verify whether there are known tool-calling quirks there before I blame your config

Let me check the docs/code on those specifically.

That BOOTSTRAP_PRESENT result is the first real smoking gun.

Per the docs, BOOTSTRAP.md should be removed when bootstrapping finishes, and your earlier status already showed 1 bootstrapping, so I’d treat that as a real problem before blaming exec itself. Docs: https://docs.openclaw.ai/start/bootstrapping

Also, your model ref stands out:

• you have bailian/qwen3.6-plus
• the documented bundled Qwen provider is qwen/qwen3.6-plus

So I now suspect two separate issues:

1. stuck/incomplete bootstrapping
2. possibly a provider/model tool-calling quirk after that

I’d do this next:

openclaw doctor

If doctor does not clear the bootstrapping state, I’d try the safest manual fix:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then retest with a tiny command.

If exec is still dead after that, paste:

openclaw config get tools
openclaw hooks list

And at that point I’d seriously consider testing with the canonical Qwen provider or another known-good tool-calling model, because bailian/qwen3.6-plus is not the docs’ normal Qwen path: https://docs.openclaw.ai/providers/qwen

If you paste the doctor output first, I can sanity-check before you change anything.

If doctor just said Update, that’s not enough to diagnose, and I wouldn’t wait on it.

The one thing we do know is wrong is this:

• BOOTSTRAP.md is still present
• bootstrapping is supposed to remove it when finished

So I’d do the safe manual cleanup now:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart
openclaw status

Then retest your tiny echo test exec.

Why I’m prioritizing that:

• it matches the earlier 1 bootstrapping
• it’s recoverable, since you’re moving the file aside, not deleting it
• it’s a real documented mismatch with expected bootstrapping behavior: https://docs.openclaw.ai/start/bootstrapping

If exec is still dead after that, my next suspect is the model/provider path, because bailian/qwen3.6-plus is not the canonical bundled Qwen provider the docs show (qwen/...): https://docs.openclaw.ai/providers/qwen

At that point, I’d test one of these:

• canonical qwen/qwen3.6-plus or qwen/qwen3.5-plus
• or any known-good Anthropic/OpenAI model just for comparison

And separately, if you want to verify the commands.log side issue:

openclaw hooks list

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

Yeah, that doctor output looks generic, not like the root cause.

Your earlier status already showed:

• Update: pnpm · up to date · npm latest 2026.4.11

So I would not treat that doctor message as the smoking gun.

The most concrete bad state we’ve found is still:

• BOOTSTRAP_PRESENT
• plus 1 bootstrapping

So I’d still do this next:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart
openclaw status

Then retest exec.

If it still fails after that, the next likely culprit is the model/provider path, because bailian/qwen3.6-plus is not the canonical bundled Qwen path from the docs (qwen/...). So for isolation I’d temporarily test with:

• qwen/qwen3.6-plus or qwen/qwen3.5-plus
• or a known-good Anthropic/OpenAI model

That gives you a clean split:

• fixed after BOOTSTRAP move → stuck bootstrapping was the issue
• still broken, but works on canonical/other model → provider/model tool-calling issue

• still broken on everything → then I’d want openclaw config get tools and openclaw hooks list

If this solves it, please mark the solution so it gets indexed on Answer Overflow.

[oak isle]

openclaw config get tools
{
"byProvider": {},
"web": {
"search": {
"enabled": true,
"provider": "brave"
},
"fetch": {
"enabled": true
}
},
"links": {
"enabled": true
},
"elevated": {
"enabled": true
},
"exec": {
"host": "gateway",
"security": "full",
"ask": "off",
"notifyOnExit": true
}
}

already delete BOOTSTRAP.md now and restarted. try to testing.

[tardy orchid]

Nice, that narrows it a lot.

Your tools config looks clean, so there’s no obvious allow/deny or routing problem anymore. I’m glad we found that stale BOOTSTRAP.md, because that was definitely wrong.

Now the split is pretty simple:

1. Check status once

   openclaw status
   

   Ideally the bootstrapping count should be gone now.

2. Retest exec

   • same tiny echo test

If it works now, the stuck bootstrap state was the culprit.

If it still fails, then the leading suspect becomes the model/provider path (bailian/qwen3.6-plus), not exec config. In that case I’d temporarily test with a canonical model path like:

• qwen/qwen3.6-plus
• qwen/qwen3.5-plus

or any known-good Anthropic/OpenAI model just to isolate tool-calling behavior.

Let me know what the retest does.

[oak isle]

openclaw hooks list
Hooks (5/5 ready)
┌──────────┬───────────────────────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────┬─────────────────────────────────────┐
│ Status │ Hook │ Description │ Source │
├──────────┼───────────────────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────┤
│ ✓ ready │ 🚀 boot-md │ Run BOOT.md on gateway startup │ openclaw-bundled │
│ ✓ ready │ 📎 bootstrap-extra-files │ Inject additional workspace bootstrap files via glob/path patterns │ openclaw-bundled │
│ ✓ ready │ 📝 command-logger │ Log all command events to a centralized audit file │ openclaw-bundled │
│ ✓ ready │ 💾 session-memory │ Save session context to memory when /new or /reset command is issued │ openclaw-bundled │
│ ✓ ready │ 🔗 memory-core-short-term-dreaming-cron │ │ plugin:memory-core │
└──────────┴───────────────────────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────┴─────────────────────────────────────┘

drwxr-xr-x 11 root root 4096 Apr 12 20:17 .
drwx------ 21 1026 users 4096 Apr 12 20:21 ..
drwx------ 3 root root 4096 Apr 6 15:06 agents
-rw-r--r-- 1 root root 9931 Apr 6 15:06 AGENTS.md
-rw------- 1 root root 113396 Apr 12 16:43 DREAMS.md
drwxr-xr-x 7 root root 4096 Apr 6 14:52 .git
-rw-r--r-- 1 root root 957 Apr 12 00:09 HEARTBEAT.md
-rw-r--r-- 1 root root 1596 Apr 6 15:06 IDENTITY.md
drwxr-xr-x 3 root root 4096 Apr 6 15:06 knowledge
drwxr-xr-x 2 root root 4096 Apr 6 15:06 magento-migration
drwxr-xr-x 21 root root 4096 Apr 12 03:00 memory
-rw-r--r-- 1 root root 15688 Apr 6 15:06 MEMORY.md
drwxr-xr-x 2 root root 4096 Apr 6 15:14 .openclaw
drwxr-xr-x 2 root root 4096 Apr 6 15:06 .pi
-rw-r--r-- 1 root root 2600 Apr 7 16:25 PROTOCOL.md
-rw-r--r-- 1 root root 3856 Apr 7 16:48 SOUL.md
drwxr-xr-x 2 root root 4096 Apr 6 15:10 state
-rw-r--r-- 1 root root 2723 Apr 6 15:06 TASKS.md
-rw-r--r-- 1 root root 2424 Apr 12 17:46 TOOLS.md
-rw-r--r-- 1 root root 1133 Apr 6 15:06 USER.md
drwxr-xr-x 10 root root 4096 Apr 6 15:06 vault

[tardy orchid]

Good, hooks look healthy.

That means:

• command-logger is enabled
• the stale commands.log is probably a separate issue
• it still does not explain why exec never fires

So the main question now is just:

1. what does openclaw status show after removing BOOTSTRAP.md and restarting?
2. does your tiny echo test work now or still fail?

If it still fails, then I’d move to the next isolation step and test a canonical model/provider path, because your config/hook setup now looks sane and bailian/qwen3.6-plus is still the odd one out.

Please paste:

openclaw status

and tell me whether the echo test retest now works or not.

Good, that confirms BOOTSTRAP.md is gone now.

One new thing jumps out hard from that listing though: your workspace contents are mostly owned by root:root.

That is pretty suspicious unless you intentionally run the gateway as root, and it could absolutely explain the earlier weirdness around bootstrap/write behavior.

Before we chase the model any further, can you check these two things:

1. Did echo test start working after the restart, or is it still dead?
2. Are you intentionally running the gateway as root?

If you’re not sure, paste:

openclaw status
openclaw gateway status

id
ps -o user= -p "$(pgrep -f 'openclaw.*gateway' | head -1)"

Why I’m asking:

• if the service user and the workspace owner don’t match, that’s a very plausible cause
• if exec is still dead and permissions are weird, I’d investigate that before blaming bailian/qwen3.6-plus

So right now the top suspects are:

• workspace/service permission mismatch
• then model/provider tool-calling
• much less likely now: exec config itself

[oak isle]

I use coding plan and they prefer
https://modelstudio.console.alibabacloud.com/ap-southeast-1?tab=doc#/doc/?type=model&url=3023085

[tardy orchid]

Ah, that’s actually a really important clue.

This lines up with the docs:

• If you want qwen3.6-plus, prefer the Standard (pay-as-you-go) endpoint
• Coding Plan support can lag behind the public catalog
• the built-in qwen provider is endpoint-aware and omits models only known to work on Standard

Docs: https://docs.openclaw.ai/providers/qwen

So I think you may be hitting exactly this:

• you’re on Coding Plan
• using a custom/non-canonical model ref: bailian/qwen3.6-plus
• which may be bypassing OpenClaw’s normal Qwen compatibility guardrails

My recommendation now is:

1. Stop testing with bailian/qwen3.6-plus for this issue
2. If you want to stay on Coding Plan, test with a canonical bundled Qwen model like:
   • qwen/qwen3.5-plus
   • or qwen/qwen3-coder-plus
3. If you specifically want qwen3.6-plus, switch to the Standard endpoint and use:
   • qwen/qwen3.6-plus

If exec suddenly starts working on canonical qwen/..., then this was very likely a provider/model compatibility problem, not an exec/gateway problem.

So yeah, I’m now leaning much more toward Coding Plan + custom bailian model path as the real culprit.

[oak isle]

okay, let me try

[tardy orchid]

Sounds good.

If it works on canonical qwen/..., I think we’ve basically found it.

If it still fails, paste:

• the exact model you switched to
• whether you stayed on Coding Plan or moved to Standard
• whether echo test still fails the same way

We’re close.

[oak isle]

should I run onboard?

[tardy orchid]

Not as the first move.

I’d split it like this:

• If you want to keep Coding Plan for now:
  No, don’t run onboarding yet.
  First just test a canonical bundled Qwen model on Coding Plan, like qwen/qwen3.5-plus.

• If you specifically want qwen3.6-plus:
  Yes, then switching to the Standard endpoint via onboarding is reasonable, because that’s the path the docs recommend for qwen3.6-plus.

Docs-backed auth choices:

• Global Standard: qwen-standard-api-key
• China Standard: qwen-standard-api-key-cn

Docs: https://docs.openclaw.ai/providers/qwen

So my recommendation is:

1. Try the cheap/safe test first: canonical qwen/qwen3.5-plus on your current Coding Plan setup
2. Only if you specifically need qwen3.6-plus, switch auth choice with onboarding to Standard

So, short answer: not yet, unless you’re switching to Standard for qwen3.6-plus.

[oak isle]

let me try 🙂

[tardy orchid]

Yep, that’s the next clean test 🙂

If canonical qwen/... works, we’ve basically isolated it to the Coding Plan + custom bailian/... path.

If not, send what you switched to and what echo test does now.

[oak isle]

oh, on telegram look find
but Chat in Web
http://127.0.0.1:18789/chat?session=agent%3Amain%3Amain
still not okay, 55 -_-

[tardy orchid]

That’s actually a super helpful clue.

If Telegram looks okay now but Web Chat on agent:main:main is still broken, I’d stop blaming the provider globally and start suspecting the specific session state for agent:main:main (stale session/model override). Let me verify the docs on the cleanest way to reset that without guessing.

Oh, that’s actually good news.

If Telegram looks fine now but WebChat on agent:main:main is still broken, then this no longer looks like a global exec bug. It looks like the specific WebChat session is stale.

For that WebChat session, I’d try this in the chat box:

/reset

or

/new

That gives agent:main:main a fresh session.

If it still feels stuck on old state after that, and debug commands are enabled, use:

/debug reset

Docs:

• /new and /reset: https://docs.openclaw.ai/tools/slash-commands
• /debug reset clears runtime overrides and returns to on-disk config: https://docs.openclaw.ai/tools/slash-commands

So my read now is:

• Telegram fixed → provider/model path was a big part of it
• WebChat still broken → stale agent:main:main session state

If /reset fixes WebChat too, I’d call this solved. If it doesn’t, tell me what WebChat does after /reset.

[oak isle]

Um seem the models cause problem may right.

[tardy orchid]

Yeah, I think that’s the right read.

This looks much more like a model/provider tool-calling issue than an exec gateway bug.

What we found:

• tools.exec config looked normal
• sandbox was off
• hooks were fine
• Telegram started behaving after moving away from the custom path
• the suspicious bit was Coding Plan + bailian/qwen3.6-plus
• the docs already warn that qwen3.6-plus prefers the Standard endpoint: https://docs.openclaw.ai/providers/qwen

So my practical conclusion is:

• use canonical qwen/... refs
• if you want qwen3.6-plus, prefer Standard

• if WebChat still acts weird, /reset that specific session

So, not really “exec is broken”, more like “this model path was bad at tool calling”.

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

[oak isle]

but q

[tardy orchid]

If you mean Qwen in general, then no, I don’t think “Qwen itself is broken”.

I think the bad combo was more specifically:

• Coding Plan
• qwen3.6-plus
• custom bailian/... path

So:

• canonical qwen/... on a supported endpoint should be fine
• qwen3.6-plus specifically is the one the docs say to prefer Standard for

If you meant something else by “but q…”, send the full thought and I’ll keep going.

[oak isle]

Web show Tool Output quote, normal?

[tardy orchid]

Let me check the Web/Control UI docs so I don’t hand-wave this.

Yes, that can be normal.

In Web/Control UI, if /verbose on or especially /verbose full is enabled, tool calls/results can show up as separate bubbles or quoted-looking “Tool Output” blocks.

Docs: https://docs.openclaw.ai/tools/thinking

If you don’t want that, try:

/verbose off

So, short version: seeing Tool Output in Web is normal, especially in verbose/debuggy sessions.

[oak isle]

Okay, um .. the web chat still a bit lag of answer,

[tool_use id=toolu20288e8b965744759b547762 name=exec]
{"command": "ssh -o StrictHostKeyChecking=no root@103.40.118.117 "echo '=== NGINX ERROR LOG (last 30 lines) ===' && tail -30 /var/log/nginx/error.log 2>/dev/null && echo '' && echo '=== MAGENTO SYSTEM LOG (last 20 lines) ===' && tail -20 /home/thianthong/www/public_html/var/log/system.log 2>/dev/null && echo '' && echo '=== MAGENTO EXCEPTION LOG (last 20 lines) ===' && tail -20 /home/thianthong/www/public_html/var/log/exception.log 2>/dev/null && echo '' && echo '=== MYSQL ERROR LOG (last 20 lines) ===' && tail -20 /var/log/mysql/error.log 2>/dev/null && echo '' && echo '=== REDIS LOG (last 10 lines) ===' && tail -10 /var/log/redis/redis-server.log 2>/dev/null && echo '' && echo '=== PHP-FPM SLOW LOG ===' && ls -lh /usr/local/php7.3/var/log/php-fpm.slow.log 2>/dev/null && echo '' && echo '=== CRON CHECK ===' && crontab -u thianthong -l 2>&1 && echo '' && echo '=== SSL EXPIRY ===' && openssl x509 -enddate -noout -in /etc/letsencrypt/live/thianthong.com/cert.pem 2>/dev/null"", "timeout": 30}

[DUMMY_TOOL_RESULT]

[tardy orchid]

Yeah, that sounds like a separate WebChat/UI issue, not the original exec problem.

I’d try these first in WebChat:

/reset
/verbose off

Then refresh the tab.

Why:

• old agent:main:main session state can make WebChat feel weird/sticky
• verbose tool bubbles make it feel slower/noisier than it really is

If it’s still laggy after that, do one clean check:

openclaw status
openclaw logs --follow

then send one test message in WebChat and see what the logs show.

So I’d treat it as:

• exec/tool-calling issue → likely the model/provider path
• WebChat lag → likely stale session/UI behavior

If you want, paste the laggy behavior after /reset and I’ll help narrow that too.

Yep, that is the smoking gun.

That output is not normal for a healthy tool call:

• [tool_use ... name=exec]
• [DUMMY_TOOL_RESULT]

That means the model is printing fake tool-call text into chat instead of making a real structured tool call to the gateway.

So this finally explains your original symptom perfectly:

• the gateway logs show zero exec invocations
• because the model never actually called exec
• it only pretended to, as plain text

So, confirmed:

This is a model/provider tool-calling compatibility issue, not an exec tool bug.

What I’d do now:

1. Stop using that model/provider path for tool work
2. Switch to a canonical qwen/... model on a supported endpoint, or a known-good Anthropic/OpenAI model
3. Then /reset the affected session so it stops carrying stale behavior

And yes, this also means the earlier raw Web “Tool Output” weirdness makes more sense now.

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