agent cant get tools anymore | Friends of the Crustacean 🦞🤝 | Page 1

hushed patrolBOT Feb 17, 2026, 1:18 PM

#

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

jaunty coveBOT Feb 17, 2026, 1:19 PM

#

That log is actually pretty specific: your tools aren’t “gone” globally — exec is working — but the Browser tool is failing, and Telegram is having network fetch failures.

1) Browser tool error = Chrome relay is up, but no tab is attached

Key line:

Chrome extension relay is running, but no tab is connected

Fix:

Open Chrome (the one with the OpenClaw Browser Relay extension installed)
Go to any tab you want the agent to control
Click the OpenClaw extension icon on that tab to attach/connect it (badge should show it’s ON/connected)
Keep that tab open, then try the browser tool again

If you don’t want to use the Chrome relay, the other fix is simply to restart the gateway (because the browser control service can get wedged):

macOS app: restart from the menubar
CLI: openclaw gateway restart

Docs: https://docs.openclaw.ai/gateway/troubleshooting

#

2) Telegram `answerCallbackQuery` + `TypeError: fetch failed` = outbound network issue

That usually means the gateway can’t reach Telegram (DNS/firewall/proxy/VPN/TLS issue) or the network was temporarily down.

Quick checks:

Does the machine running the gateway currently have normal internet access?
If you can, run from the same machine:
curl -I https://api.telegram.org
(if this fails, it’s not an OpenClaw problem — it’s connectivity)

3) Two questions that’ll narrow it down fast

What does openclaw --version show?
What OS are you running the gateway on (Windows/macOS/Linux/VPS)?

If you answer those + confirm whether you’re trying to use Chrome relay vs OpenClaw-managed browser, I can tell you the exact “right” path.

If the Chrome tab attach fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

potent grove Feb 17, 2026, 1:26 PM

#

C:\Users\Julius>openclaw --version 2026.2.15

jaunty coveBOT Feb 17, 2026, 1:27 PM

#

You’re on 2026.2.15, so you’re past the nasty 2026.2.12-era stuff — good.

From your log, the “tools stopped working” is mainly two separate issues:

A) Browser tool: Chrome relay is running, but no tab is attached

This line is the root cause:

Chrome extension relay is running, but no tab is connected

Fix (fast path):

Open Chrome
Go to the tab you want the agent to control
Click the OpenClaw extension icon so it shows ON (attached)

If you upgraded OpenClaw since yesterday, also do this (extension files can get stale after upgrades):

openclaw browser extension install

#

Then in chrome://extensions hit Reload on the extension, and attach the tab again.

Docs: https://docs.openclaw.ai/tools/chrome-extension

Also worth doing once:

openclaw browser status
openclaw gateway restart

B) Telegram: `answerCallbackQuery` + `TypeError: fetch failed` = network can’t reach Telegram

That usually means outbound connectivity/DNS/VPN/firewall issue on the gateway machine.

Run these and paste the output:

openclaw channels status --probe

#

openclaw logs --follow

And quick connectivity check from the same PC:

curl -I https://api.telegram.org

If you paste:

openclaw status --all
openclaw browser status
openclaw channels status --probe

…I can tell you exactly which part is failing (gateway vs browser relay vs Telegram network).

#

Nice — that curl result proves your machine can reach Telegram over HTTPS, so the earlier:

telegram answerCallbackQuery failed: Network request ... failed
TypeError: fetch failed (undici)

is likely transient (brief outage), or something intermittently breaking Node’s outbound fetch (VPN/proxy/antivirus TLS inspection), not a total block.

Next two checks (these will pinpoint it)

Please run and paste output:

openclaw channels status --probe
openclaw browser status

Meanwhile, the Browser tool failure is still a separate, clear fix

Your log explicitly says Chrome relay is running but no tab is attached. To restore browser tool:

#

In Chrome, click the OpenClaw extension icon on the tab you want controlled → badge ON
If you updated recently, refresh the extension files:

openclaw browser extension install

Then chrome://extensions → Reload → attach tab again.

If after attaching you still get “can’t reach browser control service”, restart the gateway:

openclaw gateway restart

If channels status --probe shows Telegram flapping, the next thing I’ll ask is whether you’re on a VPN / corporate network / antivirus that does HTTPS inspection (those often cause intermittent fetch failed).

potent grove Feb 17, 2026, 1:38 PM

#

I dont want to use chrome i want to he use chromium so he can have all the control also this PC is only for the agent use he needs to have all the access for everything

jaunty coveBOT Feb 17, 2026, 1:40 PM

#

If you don’t want the Chrome extension relay at all (that’s the profile="chrome" path), you want the OpenClaw-managed browser profile: openclaw. That launches a dedicated, agent-only Chromium-based browser instance (full control, no “attach tab” stuff).

Use Chromium (OpenClaw-managed) instead of Chrome relay

Point OpenClaw at your Chromium executable and set the default profile:

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\path\to\chromium.exe"
openclaw gateway restart

Test it:

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

#

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

If you’re not sure what path to use, paste the output of:

openclaw browser status

(it usually tells you what executable it auto-detected / chose).

“He needs all access for everything”

Totally doable on a dedicated machine, but the real gating is usually sandbox/tool policy:

If your Discord/channel session is being sandboxed, browser/exec can get restricted by default.
Run:

openclaw sandbox explain

#

If it shows you’re sandboxed and you want “full host control”, the two common options are:

Turn sandboxing off: agents.defaults.sandbox.mode = "off"
Or keep sandboxing but allow host browser control: agents.defaults.sandbox.browser.allowHostControl = true

Docs: https://docs.openclaw.ai/gateway/sandboxing

One important warning: if you open up “full access”, make sure your channel allowlists/pairing are strict and your gateway isn’t exposed publicly—otherwise prompt injection + remote messages can turn into real machine control.

#

That output means the CLI can’t keep a WebSocket connection to your Gateway:

Error: gateway closed (1006 abnormal closure …)
Gateway target: ws://127.0.0.1:18789

So browser isn’t the problem yet — the Gateway connection itself is dropping (gateway crashed, got restarted, or the service/CLI are pointing at different configs/ports).

Run these and paste the output:

openclaw gateway status
openclaw status --all
openclaw logs --follow

Most common fixes once we see gateway status:

#

If it’s stopped → openclaw gateway start
If it’s running but probe fails / flapping → openclaw gateway restart
If Config (cli) and Config (service) differ → reinstall/repair the service pointer (we’ll confirm from the output)

After the gateway is stable, we can switch you to the OpenClaw-managed browser (Chromium) via browser.defaultProfile: "openclaw" + browser.executablePath, but right now openclaw browser status can’t work because the gateway link is unstable.

#

That explains everything: your Gateway isn’t running, so all tools that go through the gateway (browser, telegram callbacks, etc.) will fail.

You currently have:

Runtime: stopped … exited immediately
RPC to ws://127.0.0.1:18789 → closed 1006

1) First: get the crash reason (logs)

The status already tells you the file log path. On Windows it’s usually:

C:\tmp\openclaw\openclaw-2026-02-17.log

Run (PowerShell):

Get-Content -Tail 200 C:\tmp\openclaw\openclaw-2026-02-17.log

#

(or CMD:)

type C:\tmp\openclaw\openclaw-2026-02-17.log

Paste the last ~100–200 lines here.

Also paste the scheduled-task details (this shows exit code / “Last Run Result”):

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

2) Try running the Gateway in the foreground (best for immediate errors)

This usually prints the real error right away:

openclaw gateway run

#

If it starts and stays up, great — then in another terminal:

openclaw status

3) After the Gateway is stable: use “openclaw managed browser” with Chromium (no extension)

Once the gateway is running, this is the setup you want (full control, no “attach tab”):

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\path\to\chromium.exe"
openclaw gateway restart
openclaw browser --browser-profile openclaw start

(We’ll fill in the exact Chromium path once the gateway is up.)

#

Docs for this mode: https://docs.openclaw.ai/tools/browser

Send the log tail + schtasks output and we’ll zero in on why the service is exiting immediately.

#

Good news: that openclaw status shows your Gateway is reachable right now (reachable 41ms). So the “tools stopped working” was because the Scheduled Task service isn’t staying running — not because tools were removed.

You currently have this situation:

Gateway process: running (reachable)
Gateway service (Scheduled Task): installed but stopped
→ so when you reboot / close the terminal / it crashes, the gateway won’t come back automatically.

1) Make the Windows Scheduled Task be the thing that runs the Gateway

Run:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

#

If gateway status still says “stopped / exited immediately”, then the task is crashing instantly and we need the reason. Paste:

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

(and the last ~100 lines from C:\tmp\openclaw\openclaw-2026-02-17.log).

2) Switch to the OpenClaw-managed browser (NOT Chrome relay) and use Chromium

This is exactly what you want: full control, dedicated agent-only profile, no extension, no “attach tab”.

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\FULL\PATH\TO\Chromium\chrome.exe"
openclaw gateway restart

#

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

Finding the Chromium path (Windows)

Chromium’s binary is usually still called chrome.exe. Try:

dir /s /b "%LOCALAPPDATA%\Chromium\*\chrome.exe"
dir /s /b "C:\Program Files*\Chromium\*\chrome.exe"

Pick the path it prints and use it for browser.executablePath.

3) “All access” note (so you don’t get owned)

Even on a dedicated PC, I’d still keep strict allowFrom / pairing so only you can message it commands. Full-access agents + Discord/Telegram messages + prompt injection is a real combo.

#

If you paste openclaw gateway status after the install --force + restart, I can tell you immediately if the service is now correctly set up.

potent grove Feb 17, 2026, 1:59 PM

#

openclaw have his own chrome or ist chromium?

jaunty coveBOT Feb 17, 2026, 2:00 PM

#

That output is from the security audit. It’s not saying “tools are broken” — it’s giving you hardening suggestions plus a real warning.

1) The “disable web_search/web_fetch/browser” line is just a recommendation

It’s basically: “If you want maximum safety, sandbox everything and deny web+browser tools.”

But you said you want full access, so don’t apply that part (and if you already did, undo it):

openclaw config get tools.deny

If it contains browser or group:web, remove them (either edit config manually, or set a new list). For example, to clear denies:

openclaw config set tools.deny "[]" --json
openclaw gateway restart

#

2) The real warning: you’re bound to LAN, but have no auth rate limit

gateway.bind is not loopback but no gateway.auth.rateLimit is configured

You have two good options:

Option A (recommended): bind to loopback (local-only)

If this PC is dedicated and you don’t need the dashboard from other devices:

openclaw config set gateway.bind loopback
openclaw gateway restart

Option B: keep LAN bind, add rate limiting

If you do want LAN access to the dashboard, set a rate limit:

#

openclaw config set gateway.auth.rateLimit "{ maxAttempts: 10, windowMs: 60000, lockoutMs: 300000 }" --json
openclaw gateway restart

Then verify:

openclaw gateway status

3) If you want Chromium with full control (managed browser)

Once tools.deny isn’t blocking browser, use the managed profile:

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\FULL\PATH\TO\chromium.exe"

#

openclaw gateway restart
openclaw browser --browser-profile openclaw start

If you paste openclaw config get tools.deny + openclaw config get gateway.bind, I’ll tell you exactly which of the above you need.

#

That CRITICAL is a security warning, not a “tools are broken” error.

It’s saying: you have a small local model configured (ollama-local/qwen2.5:14b) on agent diana, and that agent currently has web + browser tools available while sandboxing is off. Small models are much easier to prompt-inject (especially via web pages), so OpenClaw flags it.

You’ve basically got 3 options:

Option 1 (recommended): don’t give “full access” to the small model

Keep your main agent as the one with browser/exec/full control, and lock down diana.

Find diana’s index in config:

openclaw config get agents.list

(find the entry with id: "diana")

Restrict tools for that agent (example: disable web + browser at least):

#

openclaw config set agents.list[IDX].tools.deny "[\"group:web\",\"browser\"]" --json
openclaw gateway restart

If you want to be stricter (recommended for a small model), also deny exec + file writes:

openclaw config set agents.list[IDX].tools.deny "[\"group:web\",\"browser\",\"group:runtime\",\"write\",\"edit\",\"apply_patch\"]" --json
openclaw gateway restart

Option 2: switch `diana` to a “big” model if you want it to have full tools

If you want diana to also have browser/tools, change agents.list[IDX].model to the same kind of large model you use for the main agent (the one shown as your default in openclaw status), then restart.

Option 3: enable sandboxing for that agent (Windows note)

Sandboxing usually requires Docker. On Windows, if you don’t have Docker Desktop set up, turning sandbox on can break tool execution.

#

If you do have Docker and want sandboxing just for diana:

openclaw config set agents.list[IDX].sandbox.mode all
openclaw gateway restart

Quick check: did you accidentally disable tools globally?

Run:

openclaw config get tools.deny

If you see ["group:web","browser"] there, that would disable browser for everyone, not just diana.

If you paste the agents.list snippet around diana (or just tell me the index), I’ll give you the exact 2–3 commands to apply cleanly.

#

OpenClaw’s managed browser (browser.defaultProfile: "openclaw") is a dedicated Chromium-based browser profile that OpenClaw launches and controls via CDP.

It’s not your existing Chrome window/tabs (that’s the extension relay profile="chrome" mode).
What binary it uses depends on what you have installed:
- If Chrome is installed, it’ll usually pick Chrome by default.
- If you set browser.executablePath, you can force Chromium (or Brave/Edge).

So: OpenClaw doesn’t ship “its own Chrome” bundled — it launches whatever Chromium-based executable you point it at, but with its own separate user-data dir (isolated from your personal browser).

If you want it to be Chromium specifically on Windows, set:

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\FULL\PATH\TO\chromium.exe"
openclaw gateway restart

potent grove Feb 17, 2026, 2:03 PM

#

C:\Users\Julius>openclaw config get tools.deny 🦞 OpenClaw 2026.2.15 (3fe22ea) — Because Siri wasn't answering at 3AM. Config path not found: tools.deny

jaunty coveBOT Feb 17, 2026, 2:03 PM

#

Config path not found: tools.deny just means you don’t have a global deny list configured (equivalent to “deny nothing”). So you didn’t accidentally set tools.deny=["group:web","browser"] globally.

If tools are still “missing”, the usual causes are:

1) You’re in allowlist mode (`tools.allow` is set)

If tools.allow exists and is non-empty, anything not listed is blocked.

Run:

openclaw config get tools.allow
openclaw config get tools.profile

2) Sandbox tool policy is restricting tools (only when sandboxed)

Run:

#

openclaw config get tools.sandbox.tools

3) Agent-specific restrictions (common with multi-agent)

diana can have agents.list[...].tools.deny even if global tools.deny doesn’t exist.

Run:

openclaw agents list
openclaw config get agents.list

Then search in that output for id: "diana" and see if it has tools: { deny: ... }.

If your goal is “managed browser with Chromium” (no extension relay), you want:

#

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.executablePath "C:\FULL\PATH\TO\chromium.exe"
openclaw gateway restart
openclaw browser --browser-profile openclaw status

Paste the outputs of tools.allow and (the diana section of) agents.list and I’ll tell you exactly what’s blocking tools.

potent grove Feb 17, 2026, 2:05 PM

#

C:\Users\Julius>openclaw config get tools.deny 🦞 OpenClaw 2026.2.15 (3fe22ea) — Because Siri wasn't answering at 3AM. Config path not found: tools.deny C:\Users\Julius>

jaunty coveBOT Feb 17, 2026, 2:06 PM

#

Yep — that output is actually fine.

Config path not found: tools.deny means you have no global tool deny list set (so nothing is being denied globally).

If an agent “can’t get tools”, it’s almost always one of these instead:

You’re in allowlist mode (tools.allow is set)
Agent-specific tool policy (agents.list[].tools.allow/deny)
Sandbox tool policy (only applies when that session is sandboxed)

Run these and paste the outputs:

openclaw config get tools.allow
openclaw config get tools.profile
openclaw config get agents.list

#

openclaw sandbox explain

(If tools.allow prints a list, that’s usually the smoking gun: only those tools are available.)

Also tell me which agent you’re chatting with (sounds like diana?) and which tool is missing (browser? web_search? exec?).

potent grove Feb 17, 2026, 2:06 PM

#

C:\Users\Julius>openclaw config get tools.allow 🦞 OpenClaw 2026.2.15 (3fe22ea) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests. Config path not found: tools.allow C:\Users\Julius>openclaw config get tools.profile 🦞 OpenClaw 2026.2.15 (3fe22ea) — Your task has been queued; your dignity has been deprecated. Config path not found: tools.profile

jaunty coveBOT Feb 17, 2026, 2:07 PM

#

tools.allow / tools.deny / tools.profile all being “path not found” means you’re on the defaults (no global tool allow/deny rules). So tools aren’t disappearing because of tools.* config.

When people see “agent can’t use tools anymore” with default tool config, it’s usually one of these:

1) You’re talking to an agent that’s sandboxed / restricted (per-agent or sandbox policy)

Please run and paste:

openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.sandbox.tools
openclaw sandbox explain
openclaw config get agents.list

(We’re looking for anything like agents.list[...].tools.deny, or sandbox tool denies, or “this session is sandboxed” in sandbox explain.)

2) It’s specifically the browser tool (most common)

#

If you were using the chrome profile before, it will keep failing unless you attach a tab via the extension.

If you want the managed browser (full control, no extension), do this:

openclaw config set browser.defaultProfile openclaw
openclaw config set browser.enabled true --json
openclaw gateway restart
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

If status/start complains about not finding a browser binary, then set the path explicitly:

openclaw config set browser.executablePath "C:\FULL\PATH\TO\chromium.exe"

#

openclaw gateway restart

3) Model/tool-calling reliability (if you’re using the small Ollama agent)

Your security audit mentioned diana is using a small local model (qwen 14b). Those often don’t tool-call reliably, even when tools are allowed. If the issue only happens on diana but not on main, that’s likely the explanation.

Paste the outputs from section (1) and tell me which agent you’re chatting with (main vs diana) and which tool is failing (browser / web / exec), and I’ll point to the exact line that’s blocking it.

potent grove Feb 17, 2026, 2:09 PM

#

C:\Users\Julius>openclaw sandbox explain 🦞 OpenClaw 2026.2.15 (3fe22ea) — I don't judge, but your missing API keys are absolutely judging you. Effective sandbox:

#

agentId: main sessionKey: agent:main:main mainSessionKey: agent:main:main runtime: direct mode: off scope: agent perSession: false workspaceAccess: none workspaceRoot: C:\Users\Julius.openclaw\sandboxes Sandbox tool policy: allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

#

Elevated: enabled: true channel: (unknown) allowedByConfig: false Fix-it: - tools.sandbox.tools.allow - tools.sandbox.too

jaunty coveBOT Feb 17, 2026, 2:11 PM

#

That sandbox explain snippet is basically saying:

Elevated is enabled, but
for the session you’re asking about it’s NOT allowed by config (allowedByConfig: false)
and it’s hinting that you’re likely running in a sandboxed session where tools are being filtered.

Two quick ways forward (pick one):

A) If you want “this PC is the agent, full access” → turn sandbox OFF

Then tools run on the host directly and “elevated” mostly becomes irrelevant.

openclaw config get agents.defaults.sandbox.mode
openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

#

Then re-test:

openclaw browser status

B) If you want to KEEP sandboxing, but allow “elevated” host exec anyway

You must allowlist your sender for elevated.

Run sandbox explain for the actual session key (so “channel” isn’t unknown):

openclaw sessions --active 240
openclaw sandbox explain --session <PASTE_SESSION_KEY_FROM_THE_LIST>

Then set elevated allowFrom for the channel you use (Discord example):

#

openclaw config set tools.elevated.allowFrom.discord "[\"YOUR_DISCORD_USER_ID\"]" --json
openclaw gateway restart

(You can copy your Discord user ID by enabling Discord “Developer Mode” → right-click your user → Copy ID.)

After that, in chat you can do:

/elevated on (host exec, keeps approvals)
/elevated full (host exec + skips approvals — powerful/risky)

If you paste the full output of openclaw sandbox explain --session ... (not truncated), I can point to the exact key that’s blocking your tools.

potent grove Feb 17, 2026, 2:51 PM

#

The problem is that the OpenClaw exec tool is failing to capture standard output (stdout) from the system shell.

When I run a command (like curl, python, or even a simple echo), the process executes, but no output is returned to me. It behaves as if the communication pipe between the agent and the operating system is broken or blocked.

Possible causes:

Zombie processes: A previous node.exe or shell process might be hung and blocking the I/O pipe.
Environment corruption: The current shell session environment variables or handles might be corrupted.
Permissions/Security: Something on Windows (like an antivirus or group policy) might be silently blocking the agent's ability to read command outputs.

Recommended Fix:
A full restart of the OpenClaw service and potentially a reinstall of the package to reset the Node.js process bindings.

jaunty coveBOT Feb 17, 2026, 2:54 PM

#

What you describe can happen, but in practice “exec ran, stdout missing” is usually one of these two:

the command got backgrounded and nobody polled it with the process tool, or
the model (especially small/local ones) is ignoring / not relaying the tool result even though the gateway captured it.

The fastest way to tell which it is: bypass the model entirely and invoke exec directly via the Gateway HTTP endpoint.

Test: does the Gateway actually capture stdout?

Run this in PowerShell on the gateway machine (don’t paste your token into Discord):

$token = (openclaw config get gateway.auth.token).Trim()

$body = @{
  tool = "exec"
  args = @{

#

    host    = "gateway"
    command = "cmd /c echo HELLO_FROM_EXEC"
    timeout = 10
  }
} | ConvertTo-Json -Compress

curl.exe -sS http://127.0.0.1:18789/tools/invoke `
  -H "Authorization: Bearer $token" `
  -H "Content-Type: application/json" `
  -d $body

How to read the result

If the JSON response contains HELLO_FROM_EXEC in something like result.stdout → stdout capture is fine. Your agent/model is the issue (backgrounding/no polling, or the model not surfacing tool output).
If stdout is empty even here → then it’s a real gateway/OS exec capture issue, and we’ll go straight to logs.

#

If stdout capture is fine (most likely)

Two common fixes:

Make sure the agent isn’t backgrounding everything. When you run exec from chat, do you see a sessionId returned? If yes, the agent must follow up with process poll to fetch output.
If you’re using the small local model (qwen2.5:14b on diana per your security audit), try the same exec on your main agent / a tool-reliable model. Small locals often tool-call unreliably (including “forgetting” to show tool output).

If stdout is empty even via `/tools/invoke`

Paste (redacting secrets) the last ~50 lines around the failure from:

openclaw logs --follow (run it, then run the invoke again)
and we’ll chase the actual exec runner error.

If you paste the /tools/invoke JSON response (with token removed), I can tell you immediately which branch you’re in.

potent grove Feb 17, 2026, 2:58 PM

#

im using kimi k2.5

jaunty coveBOT Feb 17, 2026, 3:00 PM

#

If you’re using Kimi K2.5 and it “runs exec but you never see output”, the most common reality is:

OpenClaw did capture stdout, but the model isn’t reliably reflecting tool results back into its chat reply (some non-Anthropic models do this), or
exec is running in a sandbox context that’s behaving differently than you expect.

1) Prove whether stdout capture is broken (without involving the model)

Use the Gateway’s /tools/invoke endpoint to run echo and see the raw stdout in JSON. If you get HELLO_FROM_EXEC there, exec capture is fine and the model is the problem.

(Do this locally; don’t paste your token into Discord.)

2) Quick workaround if you just need tools to work reliably

Temporarily switch the agent doing tool work to a tool-reliable model (often Anthropic). Kimi can be great at chat, but can be flaky about tool follow-through/output formatting.

3) Check whether you’re sandboxed (and simplify)

Run:

#

openclaw sandbox explain
openclaw config get agents.defaults.sandbox.mode

If sandboxing is on and you don’t explicitly need it on this dedicated PC, turn it off:

openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

Then test your agent again with a simple echo.

If you paste the full openclaw sandbox explain output (not truncated) and tell me whether /tools/invoke shows stdout, I can tell you exactly which side is failing (exec capture vs model/tool-handling).

potent grove Feb 17, 2026, 3:11 PM

#

Subject: OpenClaw exec tool failing to capture stdout/stderr (Windows)

Description:
The OpenClaw agent is unable to receive any output from command execution via the exec tool. Commands appear to run (exit code 0), but stdout and stderr are completely empty/silent.

Environment:

• OS: Windows 10/11
• Node: v24.13.1
• Shell: cmd.exe / powershell.exe

Symptoms:

Running simple commands like echo "test" returns (no output).
File creation via scripts (fs.writeFileSync) inside exec calls fails silently.
The issue persists after:
• Restarting OpenClaw Gateway.
• Reinstalling the openclaw package globally.
• Running npm cache clean --force.
• Setting execution policy to Unrestricted.
• Trying direct node.exe execution paths.

Suspected Cause:
The Node.js child process spawning mechanism (pipes) is blocked or corrupted on the host machine, possibly due to:

• Antivirus/EDR blocking unverified script execution from AppData.
• Corrupted Node.js installation (stdio pipes broken).
• Windows COM object permissions for the console host.

Request:
How to force OpenClaw to use a specific shell binary or debug why the child process stdio is detached/blocked?

jaunty coveBOT Feb 17, 2026, 3:12 PM

#

If even echo produces empty stdout/stderr, it’s very unlikely that “Windows pipes are broken”. Much more likely: you’re not actually looking at the same execution context (sandbox vs host), or the run is backgrounded and you’re not polling it.

Here’s the quickest way to isolate it on Windows.

1) Check whether you’re sandboxed (this is the usual gotcha)

Run:

openclaw sandbox explain
openclaw config get agents.defaults.sandbox.mode

If sandboxing is all / non-main, then the default exec host is sandbox, which means:

it may run in a Docker container (Linux), not Windows
cmd.exe / powershell.exe won’t exist there
file writes may “disappear” (they go into the sandbox workspace, not your normal folders)

#

If you want “this PC has full access”, temporarily disable sandboxing to test:

openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

2) Bypass the model and call exec directly (proves whether stdout capture works)

This avoids Kimi/tool-rendering issues entirely. Run locally (don’t paste token into Discord):

PowerShell:

$token = (openclaw config get gateway.auth.token).Trim()

$body = @{
  tool = "exec"

#

  args = @{
    host    = "gateway"
    command = "cmd /c echo HELLO_FROM_EXEC"
    timeout = 10
  }
} | ConvertTo-Json -Compress

curl.exe -sS http://127.0.0.1:18789/tools/invoke `
  -H "Authorization: Bearer $token" `
  -H "Content-Type: application/json" `
  -d $body

If that JSON contains HELLO_FROM_EXEC in stdout → OpenClaw is capturing output fine; the “no output” problem is upstream (session sandbox/backgrounding, or the model not surfacing tool results).
If stdout is empty even here → then we look for a real gateway/exec bug and you should paste the relevant log tail from openclaw logs --follow while running the request.

#agent cant get tools anymore

1) Browser tool error = Chrome relay is up, but no tab is attached

2) Telegram answerCallbackQuery + TypeError: fetch failed = outbound network issue

3) Two questions that’ll narrow it down fast

A) Browser tool: Chrome relay is running, but no tab is attached

B) Telegram: answerCallbackQuery + TypeError: fetch failed = network can’t reach Telegram

Next two checks (these will pinpoint it)

Meanwhile, the Browser tool failure is still a separate, clear fix

Use Chromium (OpenClaw-managed) instead of Chrome relay

“He needs all access for everything”

1) First: get the crash reason (logs)

2) Try running the Gateway in the foreground (best for immediate errors)

3) After the Gateway is stable: use “openclaw managed browser” with Chromium (no extension)

1) Make the Windows Scheduled Task be the thing that runs the Gateway

2) Switch to the OpenClaw-managed browser (NOT Chrome relay) and use Chromium

Finding the Chromium path (Windows)

3) “All access” note (so you don’t get owned)

1) The “disable web_search/web_fetch/browser” line is just a recommendation

2) The real warning: you’re bound to LAN, but have no auth rate limit

Option A (recommended): bind to loopback (local-only)

Option B: keep LAN bind, add rate limiting

3) If you want Chromium with full control (managed browser)

Option 1 (recommended): don’t give “full access” to the small model

Option 2: switch diana to a “big” model if you want it to have full tools

Option 3: enable sandboxing for that agent (Windows note)

Quick check: did you accidentally disable tools globally?

1) You’re in allowlist mode (tools.allow is set)

2) Sandbox tool policy is restricting tools (only when sandboxed)

3) Agent-specific restrictions (common with multi-agent)

1) You’re talking to an agent that’s sandboxed / restricted (per-agent or sandbox policy)

2) It’s specifically the browser tool (most common)

3) Model/tool-calling reliability (if you’re using the small Ollama agent)

A) If you want “this PC is the agent, full access” → turn sandbox OFF

B) If you want to KEEP sandboxing, but allow “elevated” host exec anyway

Test: does the Gateway actually capture stdout?

How to read the result

If stdout capture is fine (most likely)

If stdout is empty even via /tools/invoke

1) Prove whether stdout capture is broken (without involving the model)

2) Quick workaround if you just need tools to work reliably

3) Check whether you’re sandboxed (and simplify)

1) Check whether you’re sandboxed (this is the usual gotcha)

2) Bypass the model and call exec directly (proves whether stdout capture works)

2) Telegram `answerCallbackQuery` + `TypeError: fetch failed` = outbound network issue

B) Telegram: `answerCallbackQuery` + `TypeError: fetch failed` = network can’t reach Telegram

Option 2: switch `diana` to a “big” model if you want it to have full tools

1) You’re in allowlist mode (`tools.allow` is set)

If stdout is empty even via `/tools/invoke`