Missing/corrupted module: tool-loop-detection-B1_rZFTj.js | Friends of the Crustacean 🦞🤝 | Page 1

unreal wigeonBOT Mar 4, 2026, 6:19 AM

#

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

brittle currentBOT Mar 4, 2026, 6:21 AM

#

That error pretty much always means your OpenClaw install is half-updated / missing files in dist/ (the entrypoint is trying to import a hashed chunk like tool-loop-detection-B1_rZFTj.js, but the file isn’t on disk). When that happens, the OpenClaw process can’t load, so everything (exec/read/edit/tools) looks “dead”.

The fix is: reinstall OpenClaw from outside OpenClaw (shell/SSH), then restart the gateway.

1) Fastest repair (recommended): rerun the installer

This works even if openclaw … itself won’t start:

curl -fsSL https://openclaw.ai/install.sh | bash

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

2) If you did a global install: reinstall the npm package

Pick one:

#

npm i -g openclaw@latest
# or
pnpm add -g openclaw@latest

Then verify:

openclaw --version

3) Restart the gateway service

If openclaw gateway restart works again, do:

#

openclaw gateway restart

If the CLI still won’t run but you installed it as a supervised service, restart via the supervisor (from the docs):

Linux (systemd user service):

systemctl --user restart openclaw-gateway.service

macOS (launchd):

launchctl kickstart -k gui/$UID/ai.openclaw.gateway

(Profiles add a suffix; full notes are in the updating doc above.)

#

If you tell me 2 things, I can narrow it to the exact steps

OS (macOS/Linux/Windows+WSL)
How you installed: global npm/pnpm, git/source, Docker, or npx

And if you can paste the first ~20 lines of the stack trace that mentions that missing module, even better.

pale sandal Mar 4, 2026, 6:27 AM

#

⚠️ Issue: Tool Access Error
Status:
❌ read — Tool not found
❌ exec — Tool not found
❌ write — Tool not found
✅ Discord messaging — Working

This suggests the agent session lost tool access to the gateway.

brittle currentBOT Mar 4, 2026, 6:28 AM

#

That “✅ Discord messaging — Working / ❌ read|exec|write — Tool not found” is a different (and much simpler) failure mode than “missing JS module”.

It usually means your config has OpenClaw running with a restricted tool profile (often tools.profile: "messaging"), so the agent literally isn’t allowed to see/use exec/read/write/edit — it will report them as “tool not found”.

Local onboarding even defaults new configs to tools.profile: "messaging" when unset. (So: messaging works, everything else doesn’t.)

Fix: allow the runtime + filesystem tools

In ~/.openclaw/openclaw.json, set one of these:

Option A (simplest):

{
  tools: { profile: "full" }
}

Option B (safer than full):

#

{
  tools: {
    allow: ["group:runtime", "group:fs", "group:messaging"] // add group:web/group:ui if you want
  }
}

Tool groups are documented here:
https://docs.openclaw.ai/gateway/configuration-reference#tools

Then restart the gateway:

openclaw gateway restart

If `openclaw …` won’t run at all

#

Then you’re back in the “corrupted install” bucket and should do the reinstall path:
https://docs.openclaw.ai/install/updating (rerun installer or npm i -g openclaw@latest)

If you paste:

your tools block from openclaw.json (redact tokens), and
whether this is a global install vs git/source

…I can tell you which of the two buckets you’re actually in.

pale sandal Mar 4, 2026, 6:36 AM

#

brittle current That “✅ Discord messaging — Working / ❌ read|exec|write — Tool not found” is a *...

How to set this?

brittle currentBOT Mar 4, 2026, 6:37 AM

#

You set it in your OpenClaw config (JSON5), then restart the gateway.

Option 1 (easiest): use the CLI config setter

On the machine where the Gateway runs:

openclaw config set tools.profile full
openclaw gateway restart

Then sanity-check:

openclaw status

Option 2: edit the config file directly

#

Find the active config path:

openclaw config file

Open that file in an editor (nano/vim/VS Code), and add (top-level):

{
  tools: { profile: "full" },
}

Validate + restart:

#

openclaw config validate
openclaw gateway restart

If `openclaw config …` itself crashes with the missing-module error

Then you need to repair the install first (outside OpenClaw), e.g. rerun the installer:

curl -fsSL https://openclaw.ai/install.sh | bash

After that, do the openclaw config set … steps above.

If you tell me your OS + install method (global npm/pnpm vs git/source vs Docker), I can give the exact “where is the config file” path for that setup.

pale sandal Mar 4, 2026, 6:45 AM

#

OpenClaw is running normally (v2026.3.2).

The skill tracker may have completed but I didn't capture the output. Let me try running it again to get the full tracking results.

My tools are intermittently failing with "Tool not found".

brittle currentBOT Mar 4, 2026, 6:48 AM

#

If OpenClaw is actually up and you’re on v2026.3.2, then intermittent “Tool not found” is almost always one of these:

Tool policy is sometimes “messaging/minimal” (profile / byProvider override), so the model simply isn’t being given exec/read/write/edit for that request, or
Your Gateway service is running with a different config/install than the CLI you’re checking (so behavior flips after restarts / between foreground vs service), or
Less common: you have sub-agents with a stricter tool policy and the failure is happening inside a spawned run.

Here’s the fastest way to pin it down.

1) Confirm what the running service is using

Run and paste the output (you can redact tokens):

openclaw gateway status --deep

In particular, look for the “Config (service)” vs “Config (cli)” paths. If those differ, you’ll get “it works / it doesn’t” depending on which config is in play.

#

2) Dump your tools policy in one shot

openclaw config get tools --json

You’re looking for anything like:

tools.profile: "messaging" (or "minimal")
tools.byProvider restricting to "minimal" for a provider/model you sometimes use
tools.allow missing group:fs / group:runtime

If you want to brute-force eliminate policy as the cause, set:

openclaw config set tools.profile full
openclaw gateway restart

#

3) If it still happens: capture the gateway logs at the moment it fails

Right when you see “Tool not found”, run:

openclaw logs --limit 200 --local-time

If there’s any trace mentioning tool-loop-detection-*.js, that’s back to “corrupted dist / broken install” and the fix is reinstall/rebuild (rerun installer or rebuild from source).

If you paste (a) gateway status --deep and (b) config get tools --json, I can tell you which bucket you’re in and what to change.

pale sandal Mar 4, 2026, 6:53 AM

#

(b)

{
"profile": "full",
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": true
}
},
"agentToAgent": {
"enabled": true,
"allow": [
"main",
"kjp-home-manager",
"analysis",
"neru-b2c",
"ssk"
]
}
}

brittle currentBOT Mar 4, 2026, 6:54 AM

#

Good — with tools.profile: "full" in (b), this is not a tools allowlist/profile problem anymore.

If you’re still seeing Missing/corrupted module: tool-loop-detection-*.js and intermittent “Tool not found”, the most common root cause is:

Your running Gateway service is pointing at an install path that’s getting deleted/changed (classic example: an npx/cache path, or an old Node/nvm global path). It can look “fine” until a code path tries to lazy-load that chunk.

Next: paste (a)

Run this and paste it:

openclaw gateway status --deep

What I’m specifically looking for in the output:

the service command/entrypoint path
whether it references something like .npm/_npx/.../openclaw/... (bad) or a stable global install path (good)
whether it shows Config (service) vs Config (cli) mismatch

#

Likely fix (if the service path is unstable): force reinstall the Gateway service

Do:

# make sure your global install is sane (pick one)
npm i -g openclaw@2026.3.2
# or: npm i -g openclaw@latest

openclaw gateway install --force
openclaw gateway restart

Docs for the --force bit: https://docs.openclaw.ai/cli/gateway
Updating background/service installs: https://docs.openclaw.ai/install/updating

Once you paste gateway status --deep, I can tell you exactly if that’s what’s happening (and which path it’s currently using).

pale sandal Mar 4, 2026, 6:55 AM

#

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-03-04.log
Command: /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

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

Runtime: running (pid 4519, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):

ai.openclaw.node (user, plist: /Users/lunardi/Library/LaunchAgents/ai.openclaw.node.plist)
Cleanup hint: launchctl bootout gui/$UID/ai.openclaw.gateway
Cleanup hint: rm ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

brittle currentBOT Mar 4, 2026, 6:55 AM

#

Nice — that gateway status --deep output is exactly what we needed.

Key takeaways:

Your service is not running from an npx cache path. It’s a stable global install:
/opt/homebrew/lib/node_modules/openclaw/dist/index.js
Config CLI/service are the same file.
Gateway runtime is healthy (RPC probe: ok).

So the remaining “Missing/corrupted module: tool-loop-detection-…js” is very likely: your global OpenClaw install on disk is missing that chunk file (or it’s unreadable), and it only blows up when that code path gets hit — which would explain the “intermittent” nature.

1) Check whether the chunk file is actually present

Run:

ls -la /opt/homebrew/lib/node_modules/openclaw/dist/chunks | grep tool-loop-detection

#

Also grab the exact error lines from the gateway log:

grep -n "tool-loop-detection" /tmp/openclaw/openclaw-2026-03-04.log | tail -50

2) If the file is missing: reinstall OpenClaw (same version is fine)

This should restore the missing dist/chunks/* file(s):

npm uninstall -g openclaw
npm install -g openclaw@2026.3.2
openclaw gateway restart

(If you’d rather just go “latest”: npm install -g openclaw@latest.)

#

3) If the file exists but it still errors

Paste the grep … tool-loop-detection log snippet — the stack usually tells us whether it’s:

wrong path resolution,
permissions,
or a packaging bug in that specific release.

If it turns out to be a packaging bug reproducible after a clean reinstall, that’s GitHub-issue territory (with the log snippet + version), but the reinstall check above will usually fix it quickly.

pale sandal Mar 4, 2026, 6:57 AM

#

ls: /opt/homebrew/lib/node_modules/openclaw/dist/chunks: No such file or directory

brittle currentBOT Mar 4, 2026, 6:57 AM

#

Yep — that explains everything.

Your running LaunchAgent points at:

/opt/homebrew/lib/node_modules/openclaw/dist/index.js

…but the install doesn’t even have dist/chunks/, which is where tool-loop-detection-*.js lives. So when OpenClaw hits a code path that tries to load that chunk, you get the “missing/corrupted module” error and tools go sideways.

Fix (safe): reinstall the global OpenClaw package, then restart the gateway

This does not touch your config/credentials in ~/.openclaw/.

# (optional) stop first
openclaw gateway stop

#

# reinstall (pick one)
npm uninstall -g openclaw
npm install -g openclaw@2026.3.2
# or: npm install -g openclaw@latest

# make sure the service points at the current install (belt + suspenders)
openclaw gateway install --force

# restart
openclaw gateway restart

After that, sanity check the files exist:

#

ls -la /opt/homebrew/lib/node_modules/openclaw/dist/chunks | head

If `npm uninstall` complains / leaves a broken folder behind

Tell me the exact error. Worst case, we remove /opt/homebrew/lib/node_modules/openclaw manually after confirming npm root -g and permissions — but try the uninstall/reinstall path first.

pale sandal Mar 4, 2026, 7:00 AM

#

~ % bash

The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit https://support.apple.com/kb/HT208050.
bash-3.2$ zsh
/Users/user/.openclaw/completions/openclaw.zsh:3718: command not found: compdef
user@useracStudio ~ % ls -la /opt/homebrew/lib/node_modules/openclaw/dist/chunks | head
ls: /opt/homebrew/lib/node_modules/openclaw/dist/chunks: No such file or directory

brittle currentBOT Mar 4, 2026, 7:01 AM

#

You haven’t reinstalled yet — so the dist/chunks folder is still missing (expected).

Two notes:

The compdef error is just your zsh completion system not being initialized (compinit didn’t run). It’s annoying but not related to the missing module problem. You can ignore it for now.
The real fix is to reinstall the global openclaw package so dist/chunks/* gets put back.

Do this in your terminal (macOS / Homebrew Node)

First, make sure you’re using the Homebrew npm:

which node
which npm
npm root -g

#

Then reinstall:

# stop the service (optional but recommended)
openclaw gateway stop

# reinstall OpenClaw (this should restore dist/chunks)
npm uninstall -g openclaw
npm install -g openclaw@2026.3.2
# (or: npm install -g openclaw@latest)

# refresh service entry + restart
openclaw gateway install --force
openclaw gateway restart

Verify the chunks now exist:

#

ls -la "$(npm root -g)/openclaw/dist/chunks" | head

If any of those commands fail

Paste the output of:

npm root -g
npm uninstall -g openclaw (error text)
ls -la /opt/homebrew/lib/node_modules/openclaw/dist

pale sandal Mar 4, 2026, 7:02 AM

#

/opt/homebrew/bin/node
/opt/homebrew/bin/npm
/opt/homebrew/lib/node_modules

brittle currentBOT Mar 4, 2026, 7:02 AM

#

Perfect — you’re using the Homebrew Node/npm, and your global root is:

/opt/homebrew/lib/node_modules

So now do the reinstall that will restore dist/chunks.

1) Stop the running LaunchAgent (pick one)

Try the OpenClaw way first:

openclaw gateway stop

If that fails for any reason, use launchctl:

#

launchctl bootout gui/$UID/ai.openclaw.gateway

2) Force-reinstall OpenClaw globally (this is the key step)

This is usually enough (no uninstall needed):

npm install -g openclaw@latest --force

(If you want to stay pinned: npm install -g openclaw@2026.3.2 --force)

3) Verify the missing folder is back

ls -la /opt/homebrew/lib/node_modules/openclaw/dist/chunks | head

#

4) Reinstall + restart the service

openclaw gateway install --force
openclaw gateway restart

Once dist/chunks exists, that tool-loop-detection-*.js import error should disappear and your tools should stop flaking.

If npm install -g … errors, paste that error output (it’ll usually be a permissions or “files in use” message).

pale sandal Mar 4, 2026, 7:04 AM

#

step 2:

npm warn using --force Recommended protections disabled.
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated npmlog@5.0.1: This package is no longer supported.
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated are-we-there-yet@2.0.0: This package is no longer supported.
npm warn deprecated glob@7.2.3: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated gauge@3.0.2: This package is no longer supported.
npm warn deprecated tar@6.2.1: Old versions of tar are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated glob@10.5.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me

changed 694 packages in 30s

brittle currentBOT Mar 4, 2026, 7:05 AM

#

Those warnings are fine (they’re just npm/transitive dependency deprecation notices). The important part is:

changed 694 packages → reinstall actually happened.

Now do:

3) Verify the missing chunks folder is back

ls -la /opt/homebrew/lib/node_modules/openclaw/dist/chunks | head

4) Restart the gateway service so it picks up the repaired install

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

#

If dist/chunks exists now, the tool-loop-detection-*.js missing-module error should be gone and exec/read/edit should stop failing.

If it’s fixed, please mark the solution message in the thread so Answer Overflow indexes it.

pale sandal Mar 4, 2026, 7:05 AM

#

ls: /opt/homebrew/lib/node_modules/openclaw/dist/chunks: No such file or directory

brittle currentBOT Mar 4, 2026, 7:06 AM

#

Good catch, but: dist/chunks not existing is normal on current OpenClaw builds — the compiled files live directly in dist/ (flat), not in a dist/chunks/ folder.

What’s not normal is the runtime still looking for tool-loop-detection-B1_rZFTj.js. After your reinstall, that filename/hash will almost certainly have changed — and if the gateway process is still the old one, it’ll keep trying to import the old file name that no longer exists on disk.

1) Verify the loop-detection files exist (in `dist/`, not `dist/chunks/`)

Run:

ls -1 /opt/homebrew/lib/node_modules/openclaw/dist | grep tool-loop-detection | head

2) Restart the gateway (this is the important part after `npm install -g`)

Do:

openclaw gateway restart

#

If that fails, force-kick the LaunchAgent:

launchctl kickstart -k gui/$UID/ai.openclaw.gateway

3) Confirm it’s clean now

openclaw gateway status
openclaw logs --limit 200 --local-time

If you still see references to tool-loop-detection-B1_rZFTj.js after the restart, paste the first ~30 lines around that error from openclaw logs — that would suggest you’ve got a second gateway process somewhere, or the service is still pointing at an older on-disk install.

pale sandal Mar 4, 2026, 7:07 AM

#

step 1:

tool-loop-detection-CU80cSdf.js
tool-loop-detection-Chaut2t-.js
tool-loop-detection-DO_6GzrQ.js
tool-loop-detection-T6kj4nlg.js

brittle currentBOT Mar 4, 2026, 7:07 AM

#

Perfect — that means your on-disk install is now sane again.

Next step is the crucial one:

2) Restart the gateway so it stops referencing the old hashed filename

Run:

openclaw gateway restart

If that doesn’t work for any reason, force-restart the LaunchAgent:

launchctl kickstart -k gui/$UID/ai.openclaw.gateway

#

3) Confirm the error is gone

openclaw gateway status
openclaw logs --limit 100 --local-time

After the restart, you should stop seeing tool-loop-detection-B1_rZFTj.js entirely (because the running process will now match the new files you just installed).

If you still see that exact B1_rZFTj hash after restart, paste the gateway status --deep again — that would mean you’ve got a second gateway/service pointing at a different OpenClaw install path.

pale sandal Mar 4, 2026, 7:07 AM

#

step 2 :

Gateway service not loaded.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist

brittle currentBOT Mar 4, 2026, 7:08 AM

#

That’s fine — it just means the LaunchAgent got unloaded (likely from the earlier stop/bootout), so there’s currently no background gateway running.

Bring it back like this:

1) Re-install (load) the LaunchAgent

openclaw gateway install --force

2) Start it (or restart)

openclaw gateway start
# or just:
openclaw gateway restart

3) Confirm it’s running and the error is gone

#

openclaw gateway status --deep
openclaw logs --limit 100 --local-time

If openclaw gateway install --force fails for some reason, do exactly what the hint says (manual load):

launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl kickstart -k gui/$UID/ai.openclaw.gateway

Once it’s loaded again, the missing tool-loop-detection-B1_rZFTj.js hash should disappear (because the running process will match the freshly installed tool-loop-detection-*.js files you saw in step 1).

pale sandal Mar 4, 2026, 7:10 AM

#

step3:

14:09:05 error Other gateway-like services detected (best effort):
14:09:05 error - ai.openclaw.node (user, plist: /Users/lunardi/Library/LaunchAgents/ai.openclaw.node.plist)
14:09:05 error Cleanup hint: launchctl bootout gui/$UID/ai.openclaw.gateway
14:09:05 error Cleanup hint: rm ~/Library/LaunchAgents/ai.openclaw.gateway.plist
14:09:05 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-03-04T07:09:05.703Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js:258:46","fileName":"subsystem-kl-vrkYi.js","fileNameWithLine":"subsystem-kl-vrkYi.js:258","fileColumn":"46","fileLine":"258","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js:258","method":"console.log"}},"time":"2026-03-04T14:09:05.703+07:00"}
14:09:05 error Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
14:09:05 error If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).
14:09:05 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"openclaw","date":"2026-03-04T07:09:05.703Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js:258:46","fileName":"subsystem-kl-vrkYi.js","fileNameWithLine":"subsystem-kl-vrkYi.js:258","fileColumn":"46","fileLine":"258","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/subsystem-kl-vrkYi.js:258","method":"console.log"}},"time":"2026-03-04T14:09:05.703+07:00"}

brittle currentBOT Mar 4, 2026, 7:11 AM

#

What you pasted in step 3 isn’t the “missing module” error — it’s basically just gateway status --deep being chatty:

“Other gateway-like services detected: ai.openclaw.node” → that’s the node worker LaunchAgent. It’s normal if you installed a node. It’s not the gateway.
The “Cleanup hint … bootout … rm plist” lines are just “here’s how to remove the service if you ever want to”, not something you need to do right now.

Now the real question: is the tool-loop-detection-B1_rZFTj.js error gone?

Quick confirmation checks

Run:

openclaw gateway status
openclaw logs --limit 300 --local-time | grep -i tool-loop-detection | tail -50

What we want to see:

gateway status → Runtime: running + RPC probe: ok

#

the grep → no references to tool-loop-detection-B1_rZFTj.js

Then try the thing that used to fail (a read/exec via the agent). If it works now, you’re done — and please mark the solution in the thread so it’s indexed.

If the log still mentions that exact B1_rZFTj hash after your reinstall + restart, paste the new openclaw gateway status --deep (the “Command:” line) — that would mean some process is still running the old build.

pale sandal Mar 4, 2026, 7:13 AM

#

My tools are failing again. Let me try a different approach - running it step by step: test ttStatus |
|------|--------|
| cd to skill directory | ❌ Tool not found |
| exec with simple command | ❌ Tool not found |

Tools are still intermittent. The session seems to have tool access issues.

brittle currentBOT Mar 4, 2026, 7:16 AM

#

At this point I think you’ve got two separate issues, and the “missing module” part is likely fixed (you now have the tool-loop-detection-*.js files on disk).

What you’re describing now — tools sometimes existing, sometimes “Tool not found” — matches a very specific OpenClaw behavior on macOS:

Likely cause: sandboxing + Docker availability (Discord channels are “non‑main” sessions)

exec/read/write/edit/process are the tools that get sandboxed in Docker when sandboxing is enabled.

And per the sandbox docs: group/channel sessions are not “main”, so if your config has:

agents.defaults.sandbox.mode: "non-main" (common), or
agents.defaults.sandbox.mode: "all"

…then Discord channel/thread sessions will try to run tools in Docker. If Docker Desktop is not running / reachable, OpenClaw can end up behaving like “tools aren’t available” (showing up to the model as “Tool not found”), which looks intermittent if Docker comes and goes or if you test in DM vs channel.

Docs: https://docs.openclaw.ai/gateway/sandboxing (see the note about non-main + group/channel sessions)

Quick checks

#

Run these and paste the output:

openclaw config get agents.defaults.sandbox --json
openclaw doctor

Also: is Docker running right now?

docker ps

Fix options (pick one)

Option A: Keep sandboxing (recommended) → ensure Docker is running

Start Docker Desktop, confirm docker ps works, then:

#

openclaw gateway restart

Option B: Turn sandboxing off (tools run on host)

If you don’t want/need Docker sandboxing:

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

If you paste agents.defaults.sandbox from your config + whether docker ps works, I can tell you exactly which option fits your setup.

pale sandal Mar 4, 2026, 7:35 AM

#

Hwo to sandbox mode on

brittle currentBOT Mar 4, 2026, 7:36 AM

#

To turn sandbox mode ON, you need two things:

Docker running, and
agents.defaults.sandbox.mode set to "non-main" or "all".

0) Prereq: Docker Desktop is installed + running

On macOS, install/start Docker Desktop, then verify:

docker ps

If docker ps fails, sandboxed tools won’t work reliably.

1) Build the default sandbox image (first time only)

OpenClaw expects this image by default: openclaw-sandbox:bookworm-slim.

#

From a git checkout of OpenClaw, run:

scripts/sandbox-setup.sh

Docs: https://docs.openclaw.ai/gateway/sandboxing
(See also: https://docs.openclaw.ai/install/docker#build-the-default-sandbox-image)

2) Enable sandboxing in config

Recommended setting (keeps “main” session unsandboxed, but sandboxes Discord channels/threads since they’re “non-main”):

openclaw config set agents.defaults.sandbox.mode non-main

If you want everything sandboxed:

#

openclaw config set agents.defaults.sandbox.mode all

3) Restart gateway

openclaw gateway restart

4) Confirm effective sandbox policy

This is the best debugging command:

openclaw sandbox explain
openclaw sandbox list

#

If you paste the output of openclaw config get agents.defaults.sandbox --json + whether docker ps works, I can tell you if your current “Tool not found” flakiness is coming from Docker/sandbox being unavailable.

pale sandal Mar 4, 2026, 7:39 AM

#

🔍 Why I Can't Run the Skill

Root Cause: Tool Registry Disconnect

When you see "Tool not found", it means:

What Happens	Why
My exec call fails	Session lost connection to tool registry
read fails	Tool channel disconnected
write fails	Agent can't access filesystem

───

🔧 Technical Explanation
The OpenClaw Architecture:

Discord → Gateway → Agent Session → Tool Registry → Tools(exec, read, write)
↑ ↑ ↑
Working Intermittent Sometimes fail

The Problem: The Agent Session to Tool Registry connection keeps dropping.

Why This Happens:

Reason	Explanation
Session timeout	Long operations (>30s) cause timeout
Gateway hiccup	Brief disconnect breaks tool channel
Model/tool mismatch	Kimi K2.5 session not syncing with tools
Concurrent sessions	Multiple Discord sessions conflicting

───

✅ What DOES Work

Function	Status	Why
Discord messaging	✅	Uses different channel
Basic exec date	⚠️	Sometimes works
Complex commands	❌	Usually fails
File operations	❌	Requires stable tool registry

brittle currentBOT Mar 4, 2026, 7:39 AM

#

That big “tool registry disconnect” writeup is almost certainly your agent guessing. In OpenClaw, “Tool not found” is not a network drop/timeout symptom.

What it actually means in practice is one of:

The tool was not injected/allowed for that request (tool profile/denylist, or sandbox policy clamping tools), or
The model produced an invalid tool call (wrong tool name / wrong tool-call format), and OpenClaw rejects it as “not found”.

It’s not “long ops >30s cause timeout” — if exec times out you’ll see an exec timeout/error, not “tool not found”.

The fastest way to get a real answer: check sandbox + tool policy

On the gateway machine, run these and paste results:

openclaw sandbox explain
openclaw config get agents.defaults.sandbox --json
docker ps

#

Why: Discord channel/thread sessions count as “non-main”, so if you have agents.defaults.sandbox.mode: "non-main" (or "all"), tool execution depends on Docker. If Docker isn’t reachable, tool availability can effectively disappear for those sessions.

If sandbox is OFF / Docker is fine, then it’s likely the model call format

To confirm, grab the gateway logs right when it happens:

openclaw logs --limit 200 --local-time

If the logs show the model calling tools with the wrong name/shape, that’s a model/tool-calling reliability issue (common with some providers). In that case the fix is to switch that agent/session to a tool-reliable model (for current recommendations, ask in the server’s #models channel), not to tweak tool config.

Post sandbox explain + agents.defaults.sandbox + whether docker ps works, and we can nail which branch you’re in.

pale sandal Mar 4, 2026, 8:28 AM

#

i still can't fix it, after i update to last version

my openclaw can not use tools ,exec

brittle currentBOT Mar 4, 2026, 8:28 AM

#

If exec (and read/write/edit) aren’t available from the agent, it’s almost always one of these:

Tools are being hidden by tool policy (e.g. tools.profile not full), or
Sandbox mode is on but Docker isn’t working, so OpenClaw won’t expose tool execution for those sessions (Discord channels/threads are typically “non-main”, so they get sandboxed when mode: non-main).

Let’s get you unstuck fast.

1) Paste these 3 commands’ output

Run on the machine where the Gateway runs:

openclaw --version
openclaw sandbox explain
docker ps

2) Quick fix if you don’t care about Docker sandboxing (enable host tools)

#

If docker ps fails (or you don’t want Docker), disable sandboxing:

openclaw config set tools.profile full
openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart

Then try the agent again (it should be able to exec).

3) If you do want sandboxing

Make sure Docker Desktop is running and docker ps works, then:

openclaw gateway restart
openclaw sandbox list

#

Also: tell me what exact error you see in chat (“Tool not found” vs something else) — that changes the diagnosis.

pale sandal Mar 4, 2026, 8:30 AM

#

No sandbox containers found.
Total: 0 (0 running)

#

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /Users/lunardi/.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.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled

Docs: docs.openclaw.ai/sandbox

brittle currentBOT Mar 4, 2026, 8:32 AM

#

openclaw sandbox list showing “No sandbox containers found” is totally normal — containers are only created after a sandboxed session actually runs a tool.

What we need to know is: is sandboxing enabled, and can OpenClaw reach Docker? That’s what determines whether exec/read/write/edit are available (especially in Discord channels/threads, which count as “non-main” sessions).

Run these (and paste the output):

openclaw sandbox explain
openclaw config get agents.defaults.sandbox --json
docker ps

Common outcomes:

sandbox mode = off → tools should run on host; if you still get “Tool not found”, it’s tool policy/model/tool-call-format (we’ll check logs next).
sandbox mode = non-main/all + docker ps fails → tools for channel sessions can effectively disappear. Fix is: start Docker Desktop (so docker ps works) or set sandbox off:

#

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

After you run sandbox explain, we’ll know which branch you’re in.

#

That sandbox explain output is actually a good sign:

sandbox mode is OFF
and the sandbox tool policy allows exec/read/write/edit

So Docker/sandbox isn’t what’s blocking you.

What we still don’t have is the effective policy + model for the Discord channel session where you’re seeing “Tool not found”. You just showed agent:main:main (the main session), not the Discord thread session.

Next step: identify the Discord session key + model

Run:

openclaw sessions --active 240 --json

Find the entry whose key looks like a discord/channel/thread session (not agent:main:main) and paste just that one line (key + model is enough).

#

Then explain sandbox/tool policy for THAT session

Use the key you found:

openclaw sandbox explain --session "<PASTE_SESSION_KEY_HERE>"

Why this matters: if that Discord session is running on a model/provider that isn’t reliably tool-call compatible, or if the session is being clamped by policy, you’ll get “Tool not found” even though your global config looks fine.

Finally: grab the real gateway-side error

Right after reproducing the failure in Discord, run:

openclaw logs --limit 200 --local-time

Paste the lines around the failure (especially anything mentioning “tool”, “allow/deny”, or the model/provider).

#

Once you paste:

the Discord session key + model, and
the sandbox explain --session … output,
we can pinpoint whether this is (a) a model/tool-call-format problem or (b) a policy clamp.

pale sandal Mar 4, 2026, 8:37 AM

#

it is on different gateway and port i dont see it when openclaw sessions --active 240 --json

brittle currentBOT Mar 4, 2026, 8:38 AM

#

That explains it.

openclaw sessions … is not a gateway/RPC call — it reads the local session store on disk (the machine you run the command on). So if your Discord bot is actually being handled by a different gateway host, you won’t see those sessions locally no matter what port you use.

What to do next

Figure out which machine is the real “Gateway host” for Discord (the one that has the Discord token configured and is receiving the messages).
- On your Mac, run:
```
openclaw channels status --probe
```
  If Discord isn’t connected there, your Discord bot is running elsewhere.
Run the debugging commands on the actual gateway host (SSH into it if needed):
```
openclaw --version
openclaw gateway status --deep
```

#Missing/corrupted module: tool-loop-detection-B1_rZFTj.js

1) Fastest repair (recommended): rerun the installer

2) If you did a global install: reinstall the npm package

3) Restart the gateway service

If you tell me 2 things, I can narrow it to the exact steps

Fix: allow the runtime + filesystem tools

If openclaw … won’t run at all

Option 1 (easiest): use the CLI config setter

Option 2: edit the config file directly

If openclaw config … itself crashes with the missing-module error

1) Confirm what the running service is using

2) Dump your tools policy in one shot

3) If it still happens: capture the gateway logs at the moment it fails

Next: paste (a)

Likely fix (if the service path is unstable): force reinstall the Gateway service

1) Check whether the chunk file is actually present

2) If the file is missing: reinstall OpenClaw (same version is fine)

3) If the file exists but it still errors

Fix (safe): reinstall the global OpenClaw package, then restart the gateway

If npm uninstall complains / leaves a broken folder behind

Do this in your terminal (macOS / Homebrew Node)

If any of those commands fail

1) Stop the running LaunchAgent (pick one)

2) Force-reinstall OpenClaw globally (this is the key step)

3) Verify the missing folder is back

4) Reinstall + restart the service

3) Verify the missing chunks folder is back

4) Restart the gateway service so it picks up the repaired install

1) Verify the loop-detection files exist (in dist/, not dist/chunks/)

2) Restart the gateway (this is the important part after npm install -g)

3) Confirm it’s clean now

2) Restart the gateway so it stops referencing the old hashed filename

3) Confirm the error is gone

1) Re-install (load) the LaunchAgent

2) Start it (or restart)

3) Confirm it’s running and the error is gone

Quick confirmation checks

Likely cause: sandboxing + Docker availability (Discord channels are “non‑main” sessions)

Quick checks

Fix options (pick one)

Option A: Keep sandboxing (recommended) → ensure Docker is running

Option B: Turn sandboxing off (tools run on host)

0) Prereq: Docker Desktop is installed + running

1) Build the default sandbox image (first time only)

2) Enable sandboxing in config

3) Restart gateway

4) Confirm effective sandbox policy

The fastest way to get a real answer: check sandbox + tool policy

If sandbox is OFF / Docker is fine, then it’s likely the model call format

1) Paste these 3 commands’ output

2) Quick fix if you don’t care about Docker sandboxing (enable host tools)

3) If you do want sandboxing

Next step: identify the Discord session key + model

Then explain sandbox/tool policy for THAT session

Finally: grab the real gateway-side error

What to do next

If `openclaw …` won’t run at all

If `openclaw config …` itself crashes with the missing-module error

If `npm uninstall` complains / leaves a broken folder behind

1) Verify the loop-detection files exist (in `dist/`, not `dist/chunks/`)

2) Restart the gateway (this is the important part after `npm install -g`)