Lots of tools errors recently | Friends of the Crustacean 🦞🤝 | Page 1

prisma snow Mar 11, 2026, 5:45 PM

#

I recently started running in to reliability issues with my agent and I've tried reinstalling, completely wiping the OS and working with my agent to try to get to the root cause.

The problems started broadly when I started using Codex > Claude, but it's gotten worse since.

little fiberBOT Mar 11, 2026, 5:45 PM

#

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

prisma snow Mar 11, 2026, 5:46 PM

#

doesn't look like I can post screenshotss, but here are a few examples

#

to=exec вақит=default code="bash -lc 'set -e\nprintf "== openclaw status ==\n"\nopenclaw status || true\nprintf "\n== candidate config files ==\n"\nfind ~ -maxdepth 3 ( -name "openclaw" -o -name "config." -o -name ".toml" -o -name ".yaml" -o -name ".yml" -o -name "*.json" ) 2>/dev/null | grep -E "openclaw|.openclaw|clawd|gateway|config" | sed -n "1,220p"'" yieldMs=120000} to=exec code output code

#

to=exec вақит=default code="bash -lc 'grep -RIn "tools.profile|allowlist|commentary|telegram|browser" /home/clawd/.npm-global/lib/node_modules/openclaw/docs 2>/dev/null | sed -n "1,220p"'" yieldMs=120000} to=exec code output code

#

messages like this are leaking into the telegram chat

#

Is there a way to clean the active tool profile or basically reset everything, including config files from scratch?

#

My Openclaw's takeway:

"My strongest opinion here:

• tools.profile is definitely wrong
• but it is not the single smoking gun for every symptom
• the bigger architectural smell is that tool availability is not single-source-of-truth right now"

eager quiverBOT Mar 11, 2026, 5:47 PM

#

If it got noticeably worse right when you switched the session model from Claude → Codex, that’s a strong signal this is model/tool-calling reliability (some models are simply much flakier at emitting valid tool calls / valid tool JSON, especially with bigger tool schemas like browser, nodes, etc.). But before guessing, we need one good “snapshot” from your machine.

1) First: what version are you on?

Please paste:

openclaw --version

2) Grab a safe diagnostics bundle (best starting point)

This is read-only and redacts tokens:

openclaw status --all
openclaw models status
openclaw gateway status

#

3) Then capture one failure with logs right around it

Run this, reproduce the tool error once, and paste the relevant chunk:

openclaw logs --follow

(If RPC is down, the FAQ also suggests tailing the newest file log in /tmp/openclaw/.)

4) What I’m looking for in the errors

Can you paste 1-2 exact errors (verbatim)? Common buckets:

provider rejects tool_use (invalid/missing tool_use.input, invalid JSON, etc.)
tool schema too strict / provider bug (often shows up with browser / complex tools)
auth/rate limits (429s, “No credentials…”, retries/cooldowns)
tool allowlist problems (“tool not allowed” / “tool not found” style messages)

Once we know which bucket you’re in, the fix is usually either:

#

keep Codex for coding but use a tool-reliable model for orchestration, or
disable the problematic tool(s) for that agent/model combo, or
fix an env/auth/service mismatch (shows up clearly in status --all).

Docs refs for the exact commands above:

FAQ “First 60 seconds if something’s broken”: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

Drop those outputs and one representative error and I’ll help you narrow it to a concrete root cause + a minimal fix.

prisma snow Mar 11, 2026, 5:48 PM

#

Maybe relevant, but I keep getting double responses for every question/message that I am asking.

eager quiverBOT Mar 11, 2026, 5:48 PM

#

No worries — screenshots aren’t necessary.

Can you paste the examples as text (copy/paste), ideally wrapped in code blocks so Discord doesn’t mangle them?

What to paste (pick any that you have):

The exact error message you see in chat/UI (including any “tool …” / “model …” / “request rejected …” lines)
The matching gateway log chunk around the time it happened:

openclaw logs --follow

A quick snapshot so we know versions + which config the service is actually using:

openclaw --version

#

openclaw status --all

Redaction guidance: feel free to redact tokens/keys/phone numbers — but please leave provider names, HTTP status codes, and stack traces intact.

Also: for each example, tell me which model you were on at the time (Codex vs Claude) and what tool it was trying to use (browser / web_fetch / system.run / message / nodes / etc.). That usually makes the root cause obvious.

prisma snow Mar 11, 2026, 5:49 PM

#

OpenClaw 2026.3.8 (3caab92)

eager quiverBOT Mar 11, 2026, 5:49 PM

#

That snippet is super useful, but it’s not the error yet — it’s just the tool invocation your agent attempted (OpenClaw printing the exec call). What we need next is either:

the tool result (stdout/stderr), or
the tool failure message (e.g. “exec failed…”, timeout, permission denied, spawn error, etc.)

Right now it looks like the run returned blank output, which is itself a strong symptom.

Can you grab the same info from a real terminal (not via the agent)?

Please run these on the Gateway host and paste the output (in ``` blocks):

openclaw --version
openclaw status --all
openclaw gateway status

status --all is the best because it includes a safe report + log tail with secrets redacted.

#

Then: reproduce one failure while tailing logs

In another terminal:

openclaw logs --follow

Trigger the failing behavior once, then paste ~30-80 lines around the error.

Why I’m asking this way

When “tools are flaky”, there are usually only a few root causes, and the outputs above will instantly tell us which one:

CLI vs service config mismatch (service running with different config/env than your shell)
exec/node/tool permissions (tool denied / allowlist issues / sandbox mode)
gateway process instability (restarts, crashes, WS disconnects)
provider/model emits invalid tool calls (gets worse when switching Claude → Codex)

#

Once you paste openclaw gateway status + the log chunk, we can stop guessing and pinpoint it.

#

Yeah — what you’re pasting there is still just the tool call envelope (to=exec ... yieldMs=...). It doesn’t include the result (stdout/stderr) or the error, which is the part we need to diagnose.

Two possibilities:

The exec tool is actually failing / returning nothing (gateway/tooling issue)
The exec tool is succeeding, but the result isn’t being surfaced in Discord (formatting/verbosity/output handling)

Either way, the fastest path is: run the diagnostic commands in a real shell on the gateway host (not via the agent), then paste the raw output.

Please run these in your terminal and paste output

openclaw --version
openclaw status --all
openclaw gateway status

If you truly can’t access a terminal and must do it via the agent, then after you run an exec, please paste the next message(s) that contain the command’s stdout/stderr or any line like “exec failed …” / timeout / denied / spawn …. Right now we only see the “request”, not the “response”.

#

Also: one concrete example helps a lot

Pick one action that fails (e.g. system.run, browser, web_fetch, etc.) and tell me:

what you asked the agent to do
what model it was on (Codex or Claude)
what exact error text you got (even a single line)

Once we have status --all + one real error line, we can narrow this down quickly (config mismatch vs tool allowlist vs provider/tool-call formatting issues).

#

That “to=exec …” stuff showing up in Telegram is almost always verbose/reasoning debug output being enabled for that chat/session.

Quick fix (do this in the Telegram chat as standalone messages)

Send:

/verbose off
/reasoning off

Then (optional but often helps) start clean:

/new

Docs: https://docs.openclaw.ai/help/faq#how-do-i-stop-internal-system-messages-from-showing-in-chat

#

If it keeps happening after that

Two places to check:

Control UI → session settings for that chat: set Verbose = inherit/off (not forced on).
Your config may have verbose defaulted on. Check agents.defaults.verboseDefault (should be "off"):

Docs reference: https://docs.openclaw.ai/gateway/configuration-reference (search verboseDefault)

If you paste your openclaw status --all output, it usually makes it obvious whether the session is stuck in verbose mode or if there’s something else going on.

#

Yes — there are a couple “levels” of reset, depending on whether you just want to clear the chat/tool weirdness or truly nuke everything.

A) Just reset the chat/session (fast, doesn’t wipe config)

In the Telegram chat (or whatever chat is polluted), send as standalone messages:

/verbose off
/reasoning off
/new

This fixes most “tool traces leaking into chat” + stale session issues without touching your install.

Docs: https://docs.openclaw.ai/help/faq#how-do-i-stop-internal-system-messages-from-showing-in-chat

B) Full reset (wipes config/state/workspace; keeps OpenClaw installed)

On the gateway host, run:

#

openclaw reset --scope full --yes --non-interactive
openclaw onboard --install-daemon

That’s the official “start from scratch” path (it clears config + credentials + sessions + workspace, so you’ll have to re-onboard).

Docs: https://docs.openclaw.ai/help/faq#how-do-i-completely-reset-openclaw-but-keep-it-installed

Notes:

If you used profiles (--profile / OPENCLAW_PROFILE), you need to reset the right one (each profile has its own ~/.openclaw-<profile> state dir).

C) Absolute nuke (also removes the service + CLI)

If you want everything gone (service + state + optionally CLI):

#

openclaw uninstall --all --yes --non-interactive

Docs: https://docs.openclaw.ai/install/uninstall

If you tell me what OS you’re on + whether you used --profile, I can tell you exactly which reset path is safest for your situation.

prisma snow Mar 11, 2026, 5:54 PM

#

Here's a openclaw status log:

17:53:03 info agents/tool-images {"subsystem":"agents/tool-images"} {"label":"prompt:images","sourceMimeType":"image/jpeg","sourceWidth":1280,"sourceHeight":237,"sourceBytes":16620,"maxBytes":5242880,"maxDimensionPx":1200,"triggerOverBytes":false,"triggerOverDimensions":true,"outputMimeType":"image/jpeg","outputBytes":16888,"outputQuality":85,"outputMaxSide":1200,"byteReductionPct":-1.6} Image resized to fit limits: 1280x237px 16.2KB -> 16.5KB (--1.6%)
17:53:06 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=954b019f-5d8b-4795-af9b-b42c726c8914 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8 reason=token_mismatch
17:53:06 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":200,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"c7ee5da8-bb75-45b2-aa44-0536a2d600b2","host":"localhost:18789","origin":"http://localhost:18789","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","authMode":"token","authProvided":"token","authReason":"token_mismatch","allowTailscale":false,"client":"openclaw-control-ui","mode":"webchat","version":"2026.3.8"} closed before connect conn=954b019f-5d8b-4795-af9b-b42c726c8914 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=4008 reason=connect failed
17:53:13 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=aad1c584-1160-4406-aff5-687c6d8bb08e remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8 reason=token_mismatch
17:53:13 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":126,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"3123c34f-6ac9-42ca-bc4b-bcec39c65aa5","host":"localhost:18789","origin":"http://localhost:18789","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","authMode":"token","authProvided":"token","authReason":"token_mismatch","allowTailscale":false,"client":"openclaw-control-ui","mode":"webchat","version":"2026.3.8"} closed before connect conn=aad1c584-1160-4406-aff5-687c6d8bb08e remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=1008 reason=unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)
17:53:24 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=5eeb7087-b489-4285-9276-3bdba10291e7 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8 reason=token_mismatch
17:53:24 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":165,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"7f7baae5-9596-4e0d-80af-aa570601acfc","host":"localhost:18789","origin":"http://localhost:18789","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","authMode":"token","authProvided":"token","authReason":"token_mismatch","allowTailscale":false,"client":"openclaw-control-ui","mode":"webchat","version":"2026.3.8"} closed before connect conn=5eeb7087-b489-4285-9276-3bdba10291e7 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=1008 reason=unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)

#

17:53:40 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=42c5b8ef-79ad-4496-9aca-c049cfe7dae6 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8 reason=token_mismatch
17:53:40 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":129,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"7838aa37-1f6d-4a39-8001-d0fd7996f7f5","host":"localhost:18789","origin":"http://localhost:18789","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","authMode":"token","authProvided":"token","authReason":"token_mismatch","allowTailscale":false,"client":"openclaw-control-ui","mode":"webchat","version":"2026.3.8"} closed before connect conn=42c5b8ef-79ad-4496-9aca-c049cfe7dae6 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=1008 reason=unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings)

#

and the accompanying telegram msg

Lemme verify the gateway state locally before I tell you to poke random settings.to=exec code:
{"cmd":"cd /home/clawd/.openclaw/workspace && printf '== files ==\n' && ls && printf '\n== memory files ==\n' && ls memory 2>/dev/null true && printf '\n== today ==\n' && test -f memory/2026-03-11.md && sed -n '1,220p' memory/2026-03-11.md echo '(missing)' && printf '\n== yesterday ==\n' && test -f memory/2026-03-10.md && sed -n '1,220p' memory/2026-03-10.md || echo '(missing)' && printf '\n== openclaw status ==\n' && openclaw status","yieldMs":120000}I’ll check local status and the recent session context.Running the test suite now.
That screenshot is pretty clear: the UI is talking to the gateway with the wrong token, so the dashboard gets unauthorized: gateway token mismatch and everything downstream looks disconnected. Open the dashboard URL directly, copy the token it shows, paste it into the Control UI settings so both sides use the same token, then refresh; if you want, I can walk you through the exact fix path.

eager quiverBOT Mar 11, 2026, 5:54 PM

#

Your bot’s take is directionally right, but it’s mixing two separate issues:

Tool policy (what tools are even available to the model)
Verbose/reasoning rendering (whether internal tool traces leak into chat) ← this is what caused the Telegram “to=exec …” spam

What `tools.profile` actually does (and why it can feel “not single source of truth”)

Tool availability is layered, but it does have a defined precedence:

base profile → provider/model-specific restriction → allow/deny

tools.profile (or per-agent agents.list[].tools.profile) = base allowlist
tools.byProvider = further restrict for a provider or provider/model
tools.allow / tools.deny = final allow/deny (deny wins)

Docs (this table is worth reading once):
https://docs.openclaw.ai/gateway/configuration-reference#tool-profiles
https://docs.openclaw.ai/tools (overview + examples)

#

Two common “smoking guns” that match what you’re seeing

A) Allowlist entries are wrong/unknown → allowlist gets ignored → tool set balloons
If tools.allow contains unknown names (e.g. typo, or things like discord.message instead of message), OpenClaw logs a warning and may ignore the allowlist so core tools stay available. That can make models much less reliable (big schema, lots of tools).

B) Per-agent overrides accidentally bypass your global intent
If you set tools.profile globally but have agents.list[].tools.profile for one agent, you can end up with different tool sets per agent and forget about it.

How I’d “make it single-source-ish” in practice

Pick one global profile (tools.profile: "coding" is the sane default for local tool use)
Keep tools.allow empty unless you really need it
Use tools.deny to remove the heavy/fragile stuff you don’t want (often browser, canvas, nodes if you’re debugging reliability)
Only use tools.byProvider when a specific model/provider is flaky with big tool lists

Quick ask (so we stop theorizing)

Can you paste just your tool policy block from openclaw.json (redact tokens), i.e. the tools: { ... } section and any agents.list[].tools overrides?

Or run this and paste findings (it’s made to catch exactly this kind of drift/misconfig):

#

openclaw security audit --deep

Also: the Telegram leaking traces is still fixed via /verbose off + /reasoning off in that chat — that’s independent of tools.profile.

#

Double responses are almost always one of these:

Verbose/debug output looks like a second “reply” (common if you previously enabled /verbose on)
You have two OpenClaw instances connected to the same channel account (e.g. the background service is running and you also started openclaw gateway in a terminal; or you have a second machine/profile still running with the same Discord/Telegram token)

A couple quick questions so we don’t chase the wrong thing:

Which surface is doubling — Telegram, Discord, or both?
When it “double replies”, is the 2nd message a normal answer, or does it look like tool/debug junk?

Quick checks (on the gateway host)

Please paste:

openclaw gateway status
openclaw status --all

#

These usually reveal config/service mismatches and restarts.

Quick “stop the bleeding” test

In the chat that’s spamming, send:

/verbose off
/reasoning off

If doubles continue after that, the next most likely fix is to ensure only one gateway is running:

openclaw gateway stop
# then check you don't still have another openclaw process running
ps aux | grep -i openclaw | head

#

openclaw gateway start

If you tell me your OS (macOS/Linux/WSL/VPS) + which channel is doubling, I can give the exact “find the second instance” steps for that platform.

#

Good — 2026.3.8 is recent enough that we can treat this as “configuration / multiple instances / session settings”, not “ancient version weirdness”.

Next two things will usually pinpoint both the double replies and the tool-trace leaks:

1) Paste these (from the gateway host)

openclaw gateway status
openclaw status --all

Key things I’m looking for in gateway status:

Config (cli) vs Config (service) (if they differ, you’re often running/editing one while the daemon uses another)
anything suggesting multiple profiles/installs

2) Confirm where the double replies happen

Is it Telegram, Discord, or both?
Is the “second reply” an actual second answer, or is it the debug/tool envelope (the to=exec … stuff)?

#

If doubles are in Discord, the #1 cause is two gateway processes connected with the same Discord bot token (service + manual run, or two machines).
If it’s Telegram and the “second message” is tool/debug text, that’s usually just verbose/reasoning being enabled for that chat (/verbose off, /reasoning off).

#

Those log lines are pretty clear: your Control UI/WebChat is trying to connect with the wrong gateway token.

You’re seeing:

unauthorized ... reason=token_mismatch
code=1008 reason=unauthorized: gateway token mismatch

So this isn’t a “Codex vs Claude” thing — it’s just the browser UI not being authenticated to the gateway.

Fix (fastest)

On the gateway host, run:

openclaw dashboard

That prints/copies/opens the right dashboard link and helps bootstrap the correct auth.

#

Then in the Control UI, paste the token into the auth field (Control UI settings). Docs:
https://docs.openclaw.ai/web/dashboard#if-you-see-unauthorized--1008

Alternative (manual token copy)

openclaw config get gateway.auth.token

Paste that value into the Control UI “Gateway Access” token field and hit Connect.

Common gotcha

If you recently reinstalled / reset / changed tokens, an old browser tab can keep a stale token in sessionStorage. Easiest fix is: open a fresh tab via openclaw dashboard and reconnect.

If after fixing the token you’re still getting double replies, that’s when we should look for a second gateway instance running somewhere (service + manual, or another machine/profile). The next thing to paste for that is:

#

openclaw gateway status

prisma snow Mar 11, 2026, 5:59 PM

#

🦞 OpenClaw 2026.3.8 (3caab92) — I've seen your commit messages. We'll work on that together.

OpenClaw security audit
Summary: 0 critical · 1 warn · 1 info
Run deeper: openclaw security audit --deep

WARN
gateway.trusted_proxies_missing 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 checks cannot be spoofed.
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.

INFO
summary.attack_surface Attack surface summary
groups: open=0, allowlist=1
tools.elevated: enabled
hooks.webhooks: disabled
hooks.internal: enabled
browser control: enabled
trust model: personal assistant (one trusted operator boundary), not hostile multi-tenant on one shared gateway

eager quiverBOT Mar 11, 2026, 6:00 PM

#

Yep — that’s the same problem: your browser Control UI is repeatedly trying to connect with an old/wrong token, and the gateway is rejecting it.

This is only about the local Control UI / WebChat connection (client=openclaw-control-ui mode=webchat). It won’t be fixed by changing models.

Fix it in 2 minutes

On the gateway host, run:

openclaw dashboard

In the Control UI, go to Control → Overview → Gateway Access.
You’ll see two auth inputs side-by-side (Gateway Token and Password). Paste the Gateway Token there and click Connect.

Docs: https://docs.openclaw.ai/web/dashboard#if-you-see-unauthorized--1008

#

Where to get the correct token

Run (on the gateway host):

openclaw config get gateway.auth.token

Paste that exact value.

If you paste the token and it STILL says mismatch

That usually means you’re in the “service config mismatch” situation (daemon running with a different config/profile than your CLI).

Please paste:

openclaw gateway status

#

(That output includes the important Config (cli) vs Config (service) lines, which tell us if you’re editing/reading the wrong state dir/profile.)

#

That Telegram message is exactly what “verbose/tool tracing leaking into chat” looks like — the bot is emitting the internal tool call envelope (to=exec … {cmd: …}) as part of the assistant response.

Two things to do (in this order):

1) Turn off verbose + reasoning in the Telegram chat

Send these as standalone messages in Telegram:

/verbose off
/reasoning off
/new

This should immediately stop the tool-call spam + often also fixes the “double replies” feeling (because you stop getting a “debuggy” second message).

Docs: https://docs.openclaw.ai/help/faq#how-do-i-stop-internal-system-messages-from-showing-in-chat

#

2) Make sure you’re not defaulting to verbose in config

If it keeps coming back after /new, you likely have verboseDefault forced on.

On the gateway host, can you run:

rg -n "verboseDefault|thinkingDefault" ~/.openclaw/openclaw.json

If you see verboseDefault: "on", flip it to "off" (or remove the line), then restart the gateway.

(You can also check the Control UI session settings for that chat and set Verbose = inherit/off.)

One more important note: the tool-call envelope showing up in the chat can also happen when a model/provider combo is “tool-flaky” and outputs tool syntax as text instead of making real tool calls. If after disabling verbose you still see to=exec in plain assistant messages, tell me which model was active when it happened and we’ll narrow it to a tool-compatibility issue vs just verbose mode.

prisma snow Mar 11, 2026, 6:03 PM

#

Where do I find the Control UI?

eager quiverBOT Mar 11, 2026, 6:04 PM

#

Nice — that security audit is actually pretty clean. The two findings there don’t explain the “tool envelope leaking” or “double replies”:

About the audit findings

WARN gateway.trusted_proxies_missing: only matters if you’re putting the Control UI behind a reverse proxy (Caddy/Nginx/Cloudflare Tunnel/etc). If you’re just using it locally on loopback, you can ignore it safely.
Ref: gateway.trustedProxies in the config reference: https://docs.openclaw.ai/gateway/configuration-reference
INFO “tools.elevated: enabled”: just tells you host-exec elevation is on. Not related to duplicates, but worth keeping in mind.

What we still need (this does match your log spam)

Your earlier log lines are token_mismatch from the Control UI. That’s almost always either:

stale token stored in the browser tab, or
CLI vs daemon are using different config/state (so you keep copying the “wrong” token)

Can you paste:

#

openclaw gateway status

That output will show whether Config (cli) and Config (service) are pointing at the same state/config. If they’re different, that also neatly explains a bunch of the “weird + duplicated” behavior you’re seeing.

Also—after you run openclaw dashboard and paste the token in Control → Overview → Gateway Access, do the token_mismatch warnings stop, or do they keep repeating?

#

The Control UI is just the web dashboard that the Gateway serves on port 18789.

If the Gateway is running on your machine

Run this on the gateway host:

openclaw dashboard

It will print/copy the URL and (if possible) open your browser.

Or open manually:

http://127.0.0.1:18789/ (or http://localhost:18789/)

If the Gateway is on another machine (VPS / Mac mini / etc.)

SSH tunnel from your laptop:

#

ssh -N -L 18789:127.0.0.1:18789 user@GATEWAY_HOST

Then open:

http://127.0.0.1:18789/

Docs:

Dashboard / Control UI: https://docs.openclaw.ai/web/dashboard
Control UI guide: https://docs.openclaw.ai/web/control-ui

prisma snow Mar 11, 2026, 6:10 PM

#

Unable to get this to clean up properly. Will just nuke droplet and start anew.

eager quiverBOT Mar 11, 2026, 6:11 PM

#

If you’re going to nuke the droplet anyway, that’ll definitely eliminate the “maybe I have two gateways running” class of problems — but you can get the same clean slate without rebuilding the VM.

Option 1 (usually enough): full reset on the droplet

On the droplet:

openclaw reset --scope full --yes --non-interactive
openclaw onboard --install-daemon

Docs: https://docs.openclaw.ai/help/faq#how-do-i-completely-reset-openclaw-but-keep-it-installed

Option 2: full uninstall (true clean wipe) on the droplet

openclaw uninstall --all --yes --non-interactive

#

Docs: https://docs.openclaw.ai/install/uninstall

If you still want to delete the droplet

Before you do, consider grabbing your workspace/memory (if you care about it):

state dir: ~/.openclaw/
workspace: ~/.openclaw/workspace/

Then on the new droplet, the “known good” first boot loop is:

openclaw status --all
openclaw doctor
openclaw dashboard

VPS install notes: https://docs.openclaw.ai/help/faq#how-do-i-install-openclaw-on-a-vps

#Lots of tools errors recently

1) First: what version are you on?

2) Grab a safe diagnostics bundle (best starting point)

3) Then capture one failure with logs right around it

4) What I’m looking for in the errors

Can you grab the same info from a real terminal (not via the agent)?

Then: reproduce one failure while tailing logs

Why I’m asking this way

Please run these in your terminal and paste output

Also: one concrete example helps a lot

Quick fix (do this in the Telegram chat as standalone messages)

If it keeps happening after that

A) Just reset the chat/session (fast, doesn’t wipe config)

B) Full reset (wipes config/state/workspace; keeps OpenClaw installed)

C) Absolute nuke (also removes the service + CLI)

What tools.profile actually does (and why it can feel “not single source of truth”)

Two common “smoking guns” that match what you’re seeing

How I’d “make it single-source-ish” in practice

Quick ask (so we stop theorizing)

Quick checks (on the gateway host)

Quick “stop the bleeding” test

1) Paste these (from the gateway host)

2) Confirm where the double replies happen

Fix (fastest)

Alternative (manual token copy)

Common gotcha

Fix it in 2 minutes

Where to get the correct token

If you paste the token and it STILL says mismatch

1) Turn off verbose + reasoning in the Telegram chat

2) Make sure you’re not defaulting to verbose in config

About the audit findings

What we still need (this does match your log spam)

If the Gateway is running on your machine

If the Gateway is on another machine (VPS / Mac mini / etc.)

Option 1 (usually enough): full reset on the droplet

Option 2: full uninstall (true clean wipe) on the droplet

If you still want to delete the droplet

What `tools.profile` actually does (and why it can feel “not single source of truth”)