disconnected (1008): unauthorized: gateway token mismatch (open the dashboard URL and paste the toke | Friends of the Crustacean 🦞🤝 | Page 1

mellow fiber Feb 15, 2026, 8:29 PM

#

Was busy trying to conenct my mobile using GoCLaw and then this happened. Crashed the gateway and now I am getting this error

hasty spruceBOT Feb 15, 2026, 8:29 PM

#

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

old hillBOT Feb 15, 2026, 8:31 PM

#

That disconnected (1008): unauthorized: gateway token mismatch usually means the Gateway is up, but the Control UI / GoClaw is still sending an old/wrong token (often after a crash/restart).

Fix checklist:

On the machine running the Gateway, grab the current dashboard URL + token:

openclaw dashboard

Open the link it prints (don’t reuse an old bookmarked URL).

Verify what token the Gateway expects:

openclaw config get gateway.auth.token

Then in Control UI settings (or in GoClaw if it asks), paste that exact token.

If you don’t have a token yet (or it’s blank), generate one:

#

openclaw doctor --generate-gateway-token
openclaw gateway restart

If the browser UI keeps reconnecting even after pasting the right token: open the dashboard in an incognito/private window (clears the cached token stored in localStorage) and paste it again.

If it’s still broken, paste outputs of:

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

Docs reference: https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting-what-now

mellow fiber Feb 15, 2026, 8:37 PM

#

Still broken.

Took the URL for dashboard and replaced the token as it was different. I now receive another error:

missing scope: operator.read

old hillBOT Feb 15, 2026, 8:40 PM

#

missing scope: operator.read means: you are authenticated, but the token you’re currently connected with is not an operator token with read permissions (so the UI can’t even call basic “status” methods).

Most common cause: your browser/UI is reusing an old device token (or a node-scoped token from GoClaw), not the fresh gateway token.

Try this:

Don’t paste tokens here (they’re secrets).
On the Gateway host, open the dashboard the “clean” way:

openclaw dashboard

In your browser, clear site data for the dashboard origin (or just use an Incognito/Private window), then load the dashboard URL again.

This forces the Control UI to stop reusing the old stored device token and re-pair correctly.

If it now shows pairing required, approve the browser device:

#

openclaw devices list
openclaw devices approve <requestId>

If it still says missing scope, you likely have a paired device entry with wrong scopes. Fix by revoking that device’s operator token and reloading the UI:

openclaw devices list
openclaw devices revoke --device <deviceId> --role operator

Then reload the dashboard and approve again.

If you tell me:

openclaw --version
and whether you’re opening the UI via 127.0.0.1, LAN IP, or Tailscale/Serve URL

…I can point you to the exact best path (HTTP vs HTTPS/secure context affects pairing/device identity a lot).

mellow fiber Feb 15, 2026, 8:49 PM

#

Version 2026.2.14
Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\archo.openclaw\openclaw.json
Bind: auto

✓ Config: C:\Users\archo.openclaw\openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 9800: node.exe (127.0.0.1:18789)
Another process is listening on this port.
✓ Tailscale: off · Running · archon.tail9f1bf4.ts.net
ips: 100.72.168.77, fd7a:115c:a1e0::3a3a:a84d
✓ Skills: 18 eligible · 0 missing · C:\Users\archo.openclaw\workspace
✓ Channel issues (none)

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

#

Overview
┌─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.14 │
│ OS │ windows 10.0.26200 (x64) │
│ Node │ 24.13.1 │
│ Config │ ~.openclaw\openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off · Running · archon.tail9f1bf4.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.14 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 61ms · auth token │
│ Security │ Run: openclaw security audit --deep │

#

│ Gateway self │ Archon (100.72.168.77) app unknown windows 10.0.26200 │
│ Gateway service │ Scheduled Task installed · registered · running │
│ Node service │ Scheduled Task not installed │
│ Agents │ 1 total · 0 bootstrapping · 0 active · 94 sessions │
└─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

old hillBOT Feb 15, 2026, 8:51 PM

#

That status output is the smoking gun: port 18789 is already in use by node.exe (PID 9800). After the crash you almost certainly ended up with a zombie/old gateway process still listening, so the dashboard/GoClaw is talking to that instance (tokens/scopes won’t line up).

1) Fix the “port already in use” first (Windows)

On the gateway machine:

Check if the gateway is actually healthy:

openclaw gateway status

If it says RPC probe: ok, don’t start another gateway.

If RPC probe: failed (or it’s clearly wedged), stop/kill the process that’s holding the port:

Easiest: Task Manager → Details → PID 9800 → End task
Or CLI:

taskkill /PID 9800 /F

#

Start fresh:

openclaw gateway start

(or openclaw gateway if you run it in the foreground, not as a service)

2) Then fix `missing scope: operator.read`

That error means the client connected, but with a token that doesn’t have operator.read (often a stale device token).

Do this after the gateway is cleanly restarted:

Open a fresh dashboard session (clears stored device token):

Incognito/Private window, then run:

openclaw dashboard

#

If it still complains about scope, rotate/revoke the browser’s operator device token:

openclaw devices list

Then either:

openclaw devices rotate --device <deviceId> --role operator --scope operator.read --scope operator.write

or revoke (forces re-pair):

openclaw devices revoke --device <deviceId> --role operator

If you paste openclaw gateway status output, I can tell you which branch you’re on (healthy gateway vs wedged listener).

#

Your Gateway is actually up and reachable (ws://127.0.0.1:18789, service running). The earlier “port already in use” is consistent with the Scheduled Task gateway already listening — so the remaining problem is almost certainly a bad/stale device token cached by the UI/client, and that token was issued without the operator.read scope.

Do this on the gateway machine:

1) Hard-reset the Control UI’s cached credentials

Close all dashboard tabs.
Open an Incognito/Private window and load the dashboard again via:
```
openclaw dashboard
```

This avoids the old localStorage entry the Control UI keeps (openclaw.control.settings.v1).

2) If it still says `missing scope: operator.read`, revoke/rotate the device token

List devices:

openclaw devices list

#

Find the entry that corresponds to your browser (or the GoClaw client), then revoke the operator role (simplest reset):

openclaw devices revoke --device <deviceId> --role operator

Reload the dashboard (incognito) — on localhost it should re-issue a fresh operator token with the right scopes.

If you prefer explicit scopes instead of revoke:

openclaw devices rotate --device <deviceId> --role operator --scope operator.read --scope operator.write

3) One quick sanity check

Run and paste the output (it’s safe / token-redacted):

openclaw gateway status

#

I want to confirm you’re not accidentally talking to a different instance/config (it’ll show “Config (cli)” vs “Config (service)” if they differ).

Docs: https://docs.openclaw.ai/web/control-ui and https://docs.openclaw.ai/cli/devices

mellow fiber Feb 15, 2026, 9:00 PM

#

OpenClaw status

Overview
┌─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Dashboard │ http://127.0.0.1:18789/ │
│ OS │ windows 10.0.26200 (x64) · node 24.13.1 │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.14 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 86ms · auth token · Archon (100.72.168.77) app │
│ │ unknown windows 10.0.26200 │
│ Gateway service │ Scheduled Task installed · registered · running │
│ Node service │ Scheduled Task not installed │

#

│ Agents │ 1 · no bootstraps · sessions 93 · default main active 47m ago │
│ Memory │ enabled (plugin memory-core) · unavailable │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Heartbeat │ 1h (main) │
│ Sessions │ 93 active · default minimax-m2.5:cloud (131k ctx) · ~.openclaw\agents\main\sessions\sessions.json │
└─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Security audit
Summary: 3 critical · 2 warn · 1 info
CRITICAL Control UI allows insecure HTTP auth
gateway.controlUi.allowInsecureAuth=true allows token-only auth over HTTP and skips device identity.
Fix: Disable it or switch to HTTPS (Tailscale Serve) or localhost.
CRITICAL DANGEROUS: Control UI device auth disabled
gateway.controlUi.dangerouslyDisableDeviceAuth=true disables device identity checks for the Control UI.
Fix: Disable it unless you are in a short-lived break-glass scenario.
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - ollama/qwen3:14b (14B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[web_search, web_fetch, browser]) U…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
WARN No auth rate limiting configured
gateway.bind is not loopback but no gateway.auth.rateLimit is configured. Without rate limiting, brute-force auth attacks are not mitigated.
Fix: Set gateway.auth.rateLimit (e.g. { maxAttempts: 10, windowMs: 60000, lockoutMs: 300000 }).
WARN Discord slash commands have no allowlists
Discord slash commands are enabled, but neither an owner allowFrom list nor any per-guild/channel users allowlist is configured; /… commands will be rejected f…
Fix: Add your user id to channels.discord.allowFrom (or approve yourself via pairing), or configure channels.discord.guilds.<id>.users.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

#

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

#

Sessions
┌─────────────────────────────────────────────────────────────────────────┬────────┬─────────┬────────────────────┬────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├─────────────────────────────────────────────────────────────────────────┼────────┼─────────┼────────────────────┼────────────────┤
│ agent:main:main │ direct │ 47m ago │ minimax-m2.5:cloud │ 90k/131k (68%) │
│ agent:main:discord:channel:9794… │ group │ 49m ago │ minimax-m2.5:cloud │ 26k/131k (20%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 58m ago │ kimi-k2.5:cloud │ 21k/131k (16%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 58m ago │ kimi-k2.5:cloud │ 21k/131k (16%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 59m ago │ kimi-k2.5:cloud │ 35k/131k (27%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 59m ago │ kimi-k2.5:cloud │ 35k/131k (27%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 2h ago │ kimi-k2.5:cloud │ 21k/131k (16%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 2h ago │ kimi-k2.5:cloud │ 17k/131k (13%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 3h ago │ minimax-m2.5:cloud │ 6.4k/131k (5%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 3h ago │ minimax-m2.5:cloud │ 0.2k/131k (0%) │
└─────────────────────────────────────────────────────────────────────────┴────────┴─────────┴────────────────────┴────────────────┘

#

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Need to test channels? openclaw status --deep

old hillBOT Feb 15, 2026, 9:01 PM

#

Good — gateway is up and you’re hitting it on localhost (http://127.0.0.1:18789/). So missing scope: operator.read is no longer a “gateway down” problem; it’s the browser/client presenting a device token that was issued with the wrong scopes (or a stale one cached).

Do this next (Windows):

1) Force the dashboard to stop using the cached device token

In Edge/Chrome:

Close the dashboard tab(s)
Open InPrivate / Incognito
Run:
```
openclaw dashboard
```
In that InPrivate window, go to http://127.0.0.1:18789/

(Incognito creates a new browser “device id”, so it won’t reuse the broken stored token.)

2) Fix the device token scopes on the gateway (most reliable)

#

Run:

openclaw devices list --json

You should see one or more devices with role operator. If one is missing scopes, rotate it to explicitly include operator.read:

openclaw devices rotate --device <deviceId> --role operator --scope operator.read --scope operator.write

If you’re not sure which device is the browser (or there are multiple), the blunt reset is:

openclaw devices revoke --device <deviceId> --role operator

#

Then reload the dashboard (Incognito) and it will re-issue a fresh operator token.

3) One command I still want (it shows config/service mismatches)

Please paste:

openclaw gateway status

That output is safe (tokens redacted) and will confirm the Scheduled Task service and your CLI are pointed at the same config/state (this matters for device tokens).

#

That paste is openclaw status, not openclaw gateway status — and the bit we need next is in gateway status (it will show Config (cli) vs Config (service) and the probe target).

1) Please run and paste:

openclaw gateway status

(tokens are redacted; safe to share)

2) Then fix the `missing scope: operator.read` (almost always stale device token)

On the gateway host, do one of these:

Option A (fastest): clear the Control UI cache

Open the dashboard page → press F12 → Console, run:

localStorage.removeItem("openclaw.control.settings.v1");
location.reload();

#

(or just use an Incognito window)

Option B (server-side reset): revoke the browser’s operator device token

openclaw devices list --json

Find the browser deviceId, then:

openclaw devices revoke --device <deviceId> --role operator

Reload http://127.0.0.1:18789/ and it should re-issue a correct operator token (with operator.read).

Once you paste openclaw gateway status, I can tell immediately if you’ve got a service/CLI profile mismatch (and if so, the fix is usually openclaw gateway install --force).

#

Those audit results explain why you’re stuck: you’ve flipped both “break-glass” Control UI switches on:

gateway.controlUi.allowInsecureAuth=true
gateway.controlUi.dangerouslyDisableDeviceAuth=true

That combination bypasses the normal device identity/pairing flow and tends to leave the UI/client in a weird auth state (including “missing scope: operator.read” if it’s holding onto an old/incorrect device token).

Fix (recommended): put Control UI auth back to normal, then re-pair cleanly

Turn the break-glass flags OFF (on the gateway host):

openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth false
openclaw gateway restart

Clear the dashboard’s cached token (important)

#

Open dashboard in an Incognito/Private window, or clear site data for http://127.0.0.1:18789.

If the UI now says pairing required, approve it:

openclaw devices list
openclaw devices approve <requestId>

One diagnostic that will likely reveal the last wrinkle

Please paste this (safe, tokens redacted):

openclaw gateway status

I’m specifically looking for whether it shows Config (cli) vs Config (service) mismatch (common on Windows Scheduled Task). If they differ, the fix is usually:

openclaw gateway install --force

#

openclaw gateway restart

(Also: your audit warns about small model fallbacks without sandboxing/web tools restrictions — worth fixing after you’re connected, but it’s separate from the dashboard auth issue.)

#

Yep — the security audit basically confirms you “fixed” the earlier token mismatch by turning on the two break-glass Control UI options, and now you’re paying the price (weird auth/scope behavior).

Do this in order (takes ~2 minutes)

1) Turn OFF the break‑glass Control UI flags

On the gateway host:

openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth false
openclaw gateway restart

You’re on 127.0.0.1 anyway, so you don’t need insecure HTTP auth.

2) Clear the dashboard’s cached settings/token

Either:

#

open an Incognito/Private window and go to http://127.0.0.1:18789/, or
clear site data for 127.0.0.1:18789.

(That wipes the stale device token / settings blob the UI keeps.)

3) If it asks for pairing, approve it

openclaw devices list
openclaw devices approve <requestId>

4) If it still says `missing scope: operator.read`

Then revoke the browser’s operator token and retry:

openclaw devices list --json
openclaw devices revoke --device <deviceId> --role operator

#

One thing to avoid right now

Don’t keep toggling those two “insecure” flags to make it connect — it can get you connected in the short term, but it breaks the intended operator device-token + scope flow (and it’s genuinely unsafe on anything except localhost).

If you do the 4 steps above and it still fails, paste openclaw gateway status (not status) and I’ll tell you if the Scheduled Task service is using a different config/profile than your CLI (that’s the other common Windows gotcha; fix is openclaw gateway install --force).

mellow fiber Feb 16, 2026, 5:04 AM

#

@old hill

05:03:04 [diagnostic] lane task error: lane=main durationMs=719 error="Error: spawn docker ENOENT"
05:03:04 [diagnostic] lane task error: lane=session:agent:main:main durationMs=730 error="Error: spawn docker ENOENT"

Agent was working correctly last night but now it is doing this across all platforms

#

07:03:04 Embedded agent failed before reply: spawn docker ENOENT

old hillBOT Feb 16, 2026, 5:08 AM

#

That log line is the key:

Error: spawn docker ENOENT = the Gateway tried to run the docker executable, but can’t find it (not installed, or not on PATH for the Gateway service).

This usually happens when Docker sandboxing is enabled (agents.defaults.sandbox.mode is "all" or "non-main"), but Docker isn’t available.

1) Confirm what’s enabled

On the gateway host, run:

openclaw sandbox explain

If it shows sandboxing is on, you have two options:

Option A (fastest): turn sandboxing off

#

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

Option B: keep sandboxing → install/fix Docker

Make sure Docker is installed and works on the gateway host:
```
docker --version
docker ps
```
If Docker works in your terminal but the Gateway service still can’t find it, it’s almost always a service PATH issue (common on macOS/launchd). Reinstalling the service from the same environment can help:
```
openclaw gateway install --force
openclaw gateway restart
```

#

Sandbox docs: https://docs.openclaw.ai/gateway/sandboxing
Sandbox CLI: https://docs.openclaw.ai/cli/sandbox

2) About “unauthorized / token mismatch” (1008)

That’s separate: the Control UI is sending the wrong/old token.

Get a fresh dashboard URL:
```
openclaw dashboard
```
Token is:
```
openclaw config get gateway.auth.token
```

(Only paste the token into the Control UI settings — don’t paste it into Discord.)

#

FAQ section: https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting

If you paste these (safe) outputs, we can pinpoint it quickly:

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

And: are you running the Gateway natively or via Docker Compose?

#

spawn docker ENOENT means OpenClaw is trying to run Docker (usually because sandboxing is enabled) but the docker binary isn’t available (not installed, or not on PATH for the Gateway process). That’s why the embedded agent dies before it can reply.

Fix (pick one)

A) Fastest: disable sandboxing
Run on the gateway host:

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

B) Keep sandboxing: make Docker available
On the gateway host:

docker --version
which docker

#

If Docker works in your shell but OpenClaw still can’t find it, it’s commonly a service PATH issue (macOS/launchd especially). Reinstall the service from the same environment:

openclaw gateway install --force
openclaw gateway restart

Also: the “unauthorized / gateway token mismatch (1008)” part

That’s separate: the Control UI has an old/wrong token saved.

openclaw dashboard
openclaw config get gateway.auth.token

Then paste that token into the Control UI settings.

To pinpoint quickly, paste outputs of:

#

openclaw --version
openclaw sandbox explain
openclaw gateway status

And: are you running the Gateway natively or via Docker Compose?

mellow fiber Feb 16, 2026, 5:17 AM

#

disabling the sandbox seems to have worked thank you

old hillBOT Feb 16, 2026, 5:17 AM

#

Nice — that lines up exactly with spawn docker ENOENT (sandboxing was forcing tool runs through Docker, and Docker wasn’t reachable).

If you want to re-enable sandboxing later, you’ll need Docker installed and visible to the Gateway service’s PATH (or run the gateway via Docker Compose).

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

mellow fiber Feb 16, 2026, 8:06 AM

#

Is there a known bug that the AI collapses the gateway when they try restarting?

Also, since the update today, my system has struggled with a bunch of things, and is now saying the they are not able to perform exec commands at all...?

old hillBOT Feb 16, 2026, 8:08 AM

#

“Gateway collapses on restart” isn’t a single known bug so much as a symptom that the Gateway service can’t come back up with its current environment/config (and after an update those mismatches show up a lot).

The two most common culprits I see:

Service using a different config/profile than your CLI

Check:
```
openclaw gateway status
```
If it shows Config (cli) vs Config (service) different, fix it with:
```
openclaw gateway install --force
openclaw gateway restart
```
(This re-points the background service at the same config/profile you’re editing.)

Sandboxing/Docker (what you just hit)

#

If sandboxing is on and Docker isn’t available to the service, it can “restart → immediately crash” and look like the gateway is collapsing.

Exec commands “not able to perform exec at all”

This depends on the exact error message. After updates, exec usually fails for one of these reasons:

A) Exec is being denied by tool policy

Check:

openclaw config get tools.allow
openclaw config get tools.deny

If exec is denied (or not allowed), the agent simply can’t run commands.

B) Exec got switched to `host=gateway` with allowlist security

If tools.exec.host is gateway, and tools.exec.security is allowlist, then most commands will be blocked unless explicitly allowlisted.

#

Check:

openclaw config get tools.exec.host
openclaw config get tools.exec.security

If you just want “normal local exec” again, set it back to sandbox-hosted execution (no Docker required if sandboxing is off):

openclaw config set tools.exec.host sandbox
openclaw gateway restart

Also in-chat, send /exec (with no args) to see if you have a per-session override accidentally set.

C) Approvals/allowlist are blocking it

If you see approval-pending or “allowlist miss” messages, that’s this path. (Different fix; we’ll target it once we see the exact error.)

#

Fast triage: paste these outputs

These are the quickest to diagnose “restart kills gateway” + exec issues:

openclaw --version
openclaw gateway status
openclaw status --all
openclaw sandbox explain

And when you try an exec, paste the exact error line you get (from chat or openclaw logs --follow). That one line usually tells us which bucket (A/B/C) you’re in.

mellow fiber Feb 16, 2026, 8:09 AM

#

Entire system has been SUPER unstable since the last update.

#

PS C:\Users\archo> openclaw gateway status

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll refactor your busywork like it owes me money.

│
◇
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-02-16.log
Command: C:\Program Files\nodejs\node.exe C:\Users\archo\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service env: OPENCLAW_GATEWAY_PORT=18789

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

Gateway: bind=auto (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/

Runtime: stopped (state Ready, last run time 2026/02/16 10:01:35)
RPC probe: ok

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-02-16.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

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

old hillBOT Feb 16, 2026, 8:10 AM

#

Yeah, when things get “SUPER unstable after an update” it’s almost always one of these patterns:

The Gateway service is now running with a different config/profile than your CLI
(so restarts look like “it collapsed” because it comes back with different auth / different settings)
Doctor/migrations didn’t fully apply (service entrypoint, config drift, etc.)
Exec got effectively disabled by either tool policy (tools.allow/deny) or by exec security defaults (tools.exec.host/security/ask) changing during config modernization.

The fastest way to stop guessing is to grab a small “triage bundle”.

Please paste these outputs (they’re safe; `status --all` redacts secrets)

Run on the gateway host:

openclaw --version

#

openclaw update status
openclaw gateway status
openclaw doctor
openclaw status --all

And if exec is failing: paste the exact exec error text you see (one line is usually enough).

Two quick fixes that often stabilize things immediately

1) Force the service to use the same config/profile you’re editing

If openclaw gateway status shows Config (cli) and Config (service) are different:

openclaw gateway install --force

#

openclaw gateway restart

2) Check whether exec is being blocked by config

These tell us if exec is denied or locked down:

openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.exec.host
openclaw config get tools.exec.security

(After you disabled sandboxing, host=sandbox should work fine and should not require Docker.)

If you just want to get back to “last known good”

#

If we confirm the update itself is the cause, rollback is supported:

Global install rollback:

npm i -g openclaw@<version>
openclaw doctor
openclaw gateway restart

Docs: https://docs.openclaw.ai/install/updating#rollback--pinning-when-something-breaks

Send the outputs above and we can tell you exactly which knob got flipped (and why restart/exec started acting weird).

#

That openclaw gateway status output is really telling:

Runtime: stopped (Scheduled Task is not running)
but RPC probe: ok and Listening: 127.0.0.1:18789

That basically means: something else is already running a Gateway on 18789, but it’s not the Scheduled Task. Then when you “restart”, the Scheduled Task often starts → sees the port is taken → exits immediately → everything feels flaky/unstable.

Fix: make it “one gateway, one supervisor”

Stop whatever is currently listening

openclaw gateway stop

Check if the port is still in use

#

netstat -ano | findstr :18789

If it still shows a PID listening on 18789, paste that line (and we’ll confirm what process it is). If it’s clearly a stray node.exe, you can kill it:

tasklist /fi "PID eq <pid>"
Stop-Process -Id <pid> -Force

Rewrite/reinstall the Scheduled Task + wrapper (very common after updates)

openclaw gateway install --force
openclaw gateway restart

Verify

#

openclaw gateway status

To see why the Scheduled Task exited

Please paste this output:

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

Also: when you paste Windows paths in Discord, wrap them in triple backticks … — otherwise Discord can eat backslashes and the “Command:” line becomes unreadable.

Once the gateway is stable again, we can tackle the exec not working part (that’s usually tool policy / exec host+security settings), but right now this “two gateways / port already bound” situation would explain a ton of instability.

mellow fiber Feb 16, 2026, 8:17 AM

#

PS C:\Users\archo> openclaw config get tools.allow

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Config path not found: tools.allow
PS C:\Users\archo> openclaw config get tools.deny

🦞 OpenClaw 2026.2.15 (3fe22ea) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

Config path not found: tools.deny
PS C:\Users\archo> openclaw config get tools.exec.host

🦞 OpenClaw 2026.2.15 (3fe22ea) — Ah, the fruit tree company! 🍎

Config path not found: tools.exec.host
PS C:\Users\archo> openclaw config get tools.exec.securit

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll refactor your busywork like it owes me money.

Config path not found: tools.exec.securit

old hillBOT Feb 16, 2026, 8:18 AM

#

Those config get … results are actually fine: “Config path not found” just means you haven’t set an override, so OpenClaw is using defaults for tool policy + exec settings. So this is not “exec is disabled in config” (at least not via those keys).

The bigger smoking gun is still your earlier gateway status:

Runtime: stopped (Scheduled Task exited)
but RPC probe: ok and Listening: 127.0.0.1:18789

That almost always means you currently have two gateway processes fighting:

the Scheduled Task is not running (it exited),
but some other process is already listening on 18789, so the “service restart” looks like it “collapses” because it starts, hits EADDRINUSE / port-in-use, then exits immediately.

Do this on Windows (PowerShell)

Find what’s actually listening on 18789:

#

netstat -ano | findstr :18789

Inspect the PID before killing it (so we don’t nuke something unrelated):

$pid = <PID_FROM_NETSTAT>
Get-Process -Id $pid
Get-CimInstance Win32_Process -Filter "ProcessId=$pid" | Select-Object CommandLine

If that command line is clearly OpenClaw/Node running …openclaw\dist\index.js gateway …, kill it:

Stop-Process -Id $pid -Force

Now rewrite + restart the Scheduled Task cleanly:

#

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

If the Scheduled Task still exits immediately

Paste the last ~200 lines of the file log:

Get-Content \tmp\openclaw\openclaw-2026-02-16.log -Tail 200

(or run openclaw logs --follow and copy the first fatal/error block).

Why exec “stops working” when this happens

If your chat/UI sometimes talks to the “wrong” gateway instance (the stray one vs the scheduled-task one), you get random behavior: tools missing, exec failing, auth/token mismatch, restarts doing weird stuff, etc. Fixing the single running gateway usually stabilizes everything.

If you paste the netstat line + the CommandLine for that PID, I can tell you exactly what spawned the extra instance.

mellow fiber Feb 16, 2026, 8:24 AM

#

PS C:\Users\archo> netstat -ano | findstr :18789
TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 9864
TCP 127.0.0.1:18789 127.0.0.1:50503 FIN_WAIT_2 9864
TCP 127.0.0.1:18789 127.0.0.1:52795 ESTABLISHED 9864
TCP 127.0.0.1:18789 127.0.0.1:63807 TIME_WAIT 0
TCP 127.0.0.1:18789 127.0.0.1:63809 TIME_WAIT 0
TCP 127.0.0.1:50503 127.0.0.1:18789 CLOSE_WAIT 10912
TCP 127.0.0.1:52795 127.0.0.1:18789 ESTABLISHED 10912
TCP [::1]:18789 [::]:0 LISTENING 9864

old hillBOT Feb 16, 2026, 8:25 AM

#

Yep — that confirms it.

PID 9864 is the process actually listening on 127.0.0.1:18789 (and ::1:18789).
PID 10912 is just a client connected to it (likely your browser / Control UI / some OpenClaw client).

So your “service” (Scheduled Task) says “stopped”, but a different gateway instance is still running in the background, which is exactly the kind of thing that makes restarts/exec feel chaotic.

Next step: identify what 9864 is

Run:

Get-Process -Id 9864,10912 | Select-Object Id,ProcessName,Path

Get-CimInstance Win32_Process -Filter "ProcessId=9864" | Select-Object CommandLine
Get-CimInstance Win32_Process -Filter "ProcessId=10912" | Select-Object CommandLine

#

Paste the output (especially the CommandLine for 9864).

If 9864 is clearly OpenClaw/Node running the gateway

Then kill it and restart cleanly:

Stop-Process -Id 9864 -Force
openclaw gateway restart
openclaw gateway status

After that, openclaw gateway status should show Runtime: running (not stopped), and the instability usually disappears.

Why this breaks exec / “restart collapses”

Because you end up with:

one gateway instance the UI is talking to (PID 9864),
while the Scheduled Task tries to start another, fails (port already taken), and exits,

#

and depending on which instance your clients connect to, tool defaults / session state can differ → “exec stopped working”, token mismatch, etc.

Send the CommandLine for PID 9864 and we can tell you what spawned it (manual openclaw gateway …, a leftover older task, etc.).

mellow fiber Feb 16, 2026, 8:28 AM

#

PS C:\Users\archo> openclaw gateway status

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your inbox, your infra, your rules.

│
◇
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-02-16.log
Command: C:\Program Files\nodejs\node.exe C:\Users\archo\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service env: OPENCLAW_GATEWAY_PORT=18789

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

Gateway: bind=auto (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/

Runtime: running (last run time 2026/02/16 10:26:46)
RPC probe: ok

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

old hillBOT Feb 16, 2026, 8:28 AM

#

Perfect — that’s the “healthy” state:

Runtime: running
RPC probe: ok
Listening: 127.0.0.1:18789

So the Scheduled Task is now the thing owning the port, and the “two gateways fighting” instability should be gone.

Next: verify exec is back (or capture the exact failure)

Two quick checks on the gateway host:

Sanity check the gateway can respond to basic health:

openclaw status

Try a minimal exec from chat (or wherever you were attempting exec). If it still fails, we need the exact error text.

#

If exec still doesn’t work, the usual causes are:

The agent/tool policy doesn’t include exec (per-agent overrides)
You’re in a channel/session where exec is intentionally blocked
Sandbox/approvals settings are forcing gateway/node exec with allowlist approvals

Since your config lookups returned “path not found”, you’re likely on defaults — so if exec is blocked, it’s probably per-agent tools config or session /exec overrides.

Run these to inspect:

openclaw config get agents.list
openclaw config get tools

(If tools is big, just paste agents.list first.)

And in the chat where exec fails, send:

#

/exec

and paste what it prints.

If everything is working now, please mark the solution (right-click → Apps → ✅ Mark Solution) — the “port already in use / second gateway instance” issue is a super common Windows instability cause.

mellow fiber Feb 16, 2026, 8:30 AM

#

PS C:\Users\archo> openclaw status

🦞 OpenClaw 2026.2.15 (3fe22ea) — Greetings, Professor Falken

│
◇
│
◇
OpenClaw status

Overview
┌─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Dashboard │ http://127.0.0.1:18789/ │
│ OS │ windows 10.0.26200 (x64) · node 24.13.1 │
│ Tailscale │ serve · archon.tail9f1bf4.ts.net · https://archon.tail9f1bf4.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 78ms · auth token · Archon (100.72.168.77) app │
│ │ unknown windows 10.0.26200 │
│ Gateway service │ Scheduled Task installed · registered · running │
│ Node service │ Scheduled Task not installed │
│ Agents │ 1 · no bootstraps · sessions 89 · default main active 1m ago │

#

│ Memory │ enabled (plugin memory-core) · unavailable │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Heartbeat │ 1h (main) │
│ Sessions │ 89 active · default minimax-m2.5:cloud (131k ctx) · ~.openclaw\agents\main\sessions\sessions.json │
└─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Security audit
Summary: 2 critical · 1 warn · 2 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - ollama/qwen3:14b (14B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[web_search, web_fetch, browser]) U…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
CRITICAL Telegram group commands have no sender allowlist
Telegram group access is enabled but no sender allowlist is configured; this allows any group member to invoke /… commands (including skill commands).
Fix: Approve yourself via pairing (recommended), or set channels.telegram.groupAllowFrom (or per-group groups.<id>.allowFrom).
WARN Discord slash commands have no allowlists
Discord slash commands are enabled, but neither an owner allowFrom list nor any per-guild/channel users allowlist is configured; /… commands will be rejected f…
Fix: Add your user id to channels.discord.allowFrom (or approve yourself via pairing), or configure channels.discord.guilds.<id>.users.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

#

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ WARN │ token config (8346…Y5p4 · len 46) · accounts 1/1 · gateway: Config allows unmentioned group │
│ │ │ │ messages (requireMention=false). Telegram Bot API p… │
│ Discord │ ON │ OK │ token config (MTQ3…LrJ8 · len 72) · accounts 1/1 │
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Sessions
┌──────────────────────────────────────────────────────────────────────┬────────┬─────────┬────────────────────┬───────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├──────────────────────────────────────────────────────────────────────┼────────┼─────────┼────────────────────┼───────────────────┤
│ agent:main:main │ direct │ 1m ago │ minimax-m2.5:cloud │ 0.1k/131k (0%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 24m ago │ glm-5:cloud │ 13k/131k (10%) │
│ agent:main:cron:1e52071f-e0fb-4… │ direct │ 24m ago │ glm-5:cloud │ 13k/131k (10%) │
│ agent:main:cron:13a9781a-a797-4… │ direct │ 29m ago │ minimax-m2.5:cloud │ unknown/131k (?%) │
│ agent:main:cron:13a9781a-a797-4… │ direct │ 29m ago │ minimax-m2.5:cloud │ unknown/131k (?%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 29m ago │ glm-5:cloud │ 15k/131k (11%) │
│ agent:main:cron:55e800ec-e3a5-4… │ direct │ 29m ago │ glm-5:cloud │ 15k/131k (11%) │
│ agent:main:cron:e54ced0d-e073-4… │ direct │ 1h ago │ minimax-m2.5:cloud │ unknown/131k (?%) │
│ agent:main:cron:e54ced0d-e073-4… │ direct │ 1h ago │ minimax-m2.5:cloud │ unknown/131k (?%) │
│ agent:main:discord:channel:1467… │ group │ 1h ago │ minimax-m2.5:cloud │ unknown/131k (?%) │

#

└──────────────────────────────────────────────────────────────────────┴────────┴─────────┴────────────────────┴───────────────────┘

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Need to test channels? openclaw status --deep

old hillBOT Feb 16, 2026, 8:31 AM

#

That openclaw status looks healthy now:

Gateway: reachable (ws://127.0.0.1:18789)
Gateway service: Scheduled Task … running
Dashboard: http://127.0.0.1:18789/

So the “super unstable” behavior you were seeing was very likely the two-gateways-fighting-for-port-18789 situation (Scheduled Task stopped, but another PID was actually listening). Now it’s back to a single supervised gateway, which is the stable setup.

About “exec commands not able to run”

The Config path not found: tools.* you saw earlier is not a failure — it just means you haven’t explicitly set tool policy overrides, so defaults apply.

To diagnose the exec issue, I need the exact error text you get when exec fails (one line is enough). Common ones look like:

“tool exec is not allowed / denied by policy”
“approval required / allowlist miss”
“spawn … ENOENT” (missing binary)
“sandbox/docker …” (if sandboxing got re-enabled)

#

Please run these and paste output

openclaw sandbox explain
openclaw logs --follow

Then try one exec (wherever you do it: Discord chat / Control UI / etc.) and paste the error line you see, and/or whatever new error shows up in openclaw logs --follow.

Also: are you trying to exec from Discord (chat command) or from the Control UI? The path is slightly different and affects approvals/policy.

mellow fiber Feb 16, 2026, 8:32 AM

#

PS C:\Users\archo> openclaw config get agents.list

🦞 OpenClaw 2026.2.15 (3fe22ea) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

Config path not found: agents.list

old hillBOT Feb 16, 2026, 8:33 AM

#

That openclaw status looks way healthier now (gateway reachable, Scheduled Task running). So we’ve likely fixed the “randomly collapsing on restart” part (the port fight).

1) Your Memory plugin being “unavailable”

This line stands out:

Memory: enabled (plugin memory-core) · unavailable

That won’t usually break the whole gateway, but it can spam errors and make things feel janky. On the gateway host, run:

openclaw plugins doctor
openclaw logs --follow

…and look for memory-core errors.

2) Exec “not able to perform exec commands”

#

On Discord, group/channel sessions are “non-main” sessions. If your sandbox mode is non-main and Docker isn’t available, exec will fail specifically in those sessions (while DMs might still work).

So first, confirm your effective sandbox mode:

openclaw sandbox explain
openclaw config get agents.defaults.sandbox

If sandbox explain shows sandboxing is on (especially mode: non-main / all), and you don’t want Docker on Windows, disable it (again) and restart:

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

3) If exec still fails after sandbox is off

#

I need the exact error line you get when you try an exec (copy/paste). The fastest way to capture it is:

Run:
```
openclaw logs --follow
```
Try one exec from Discord / Control UI
Paste the first relevant error block.

Also: are you trying to exec from Discord (chat) or from the Control UI?

#

Config path not found: agents.list is normal — it just means you’re on the default single agent (no multi‑agent list configured). So we can ignore that one.

The important part for your “exec doesn’t work” complaint is still: is OpenClaw trying to exec inside a Docker sandbox? (because on Windows, that often turns into spawn docker ENOENT and only affects non‑main sessions like Discord channels/threads).

1) Check the effective sandbox mode (this is the key command)

Run and paste:

openclaw sandbox explain

If it shows mode: non-main or mode: all (or anything that implies Docker), and you don’t have Docker available, disable it:

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

#

Why this matters: Discord channel/thread sessions are “non‑main”, so sandboxing can break exec there while DMs still work.

2) Get the exact exec failure

Please paste the exact error line you see when you try exec.

Fastest way to capture it:

openclaw logs --follow

Then try one “do an exec” action (from Discord or Control UI), and copy the first relevant error block from the logs.

3) Memory plugin says “unavailable”

This is separate, but it can add instability/noise. Run:

#

openclaw plugins doctor
openclaw plugins info memory-core

Paste what it reports (it usually tells you exactly what dependency/config is missing).

One quick question: are you trying to exec from Discord (in a channel/thread) or from the Control UI? That changes which session type you’re in and helps confirm the sandbox/non‑main theory.

mellow fiber Feb 16, 2026, 8:40 AM

#

PS C:\Users\archo> openclaw sandbox explain

🦞 OpenClaw 2026.2.15 (3fe22ea) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

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\archo.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: webchat
allowedByConfig: false
failing gates: allowFrom (tools.elevated.allowFrom.webchat)

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
tools.elevated.allowFrom.webchat

Docs: docs.openclaw.ai/sandbox

#

PS C:\Users\archo> openclaw plugins doctor

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'll refactor your busywork like it owes me money.

No plugin issues detected.
PS C:\Users\archo> openclaw plugins info memory-core

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your inbox, your infra, your rules.

Memory (Core)
id: memory-core
File-backed memory search tools and CLI

Status: loaded
Source: ~\AppData\Roaming\npm\node_modules\openclaw\extensions\memory-core\index.ts
Origin: bundled
Version: 2026.2.15
Tools: memory_search, memory_get
CLI commands: memory

old hillBOT Feb 16, 2026, 8:41 AM

#

Good news: that output rules out the Docker/sandbox issue completely.

runtime: direct
mode: off

So exec is not failing because of Docker anymore.

The #1 remaining cause: your session got stuck with `/exec host=gateway` (or `node`)

If at any point you (or the UI) set /exec host=gateway, then exec starts going through the gateway/node approvals/allowlist path and can feel like “exec is broken”.

In the same Discord chat/thread where exec fails, send:

/exec

and paste what it prints.

#

If it’s anything other than host=sandbox, reset it:

/exec host=sandbox

(That restores “normal local exec” behavior.)

If it still fails: grab the exact error from logs

Run on the gateway host:

openclaw logs --follow

Then try one exec again and paste the first relevant error block.

#

If you want a quick grep without live follow:

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log -Pattern "SYSTEM_RUN_DENIED|allowlist|approval|ENOENT|exec" -Context 2,6 | Select-Object -First 40

Side note: memory plugin “unavailable”

Not your exec issue, but worth fixing to reduce instability/noise:

openclaw plugins doctor
openclaw plugins info memory-core

Paste the /exec output + the log error and we can tell you exactly which gate is blocking exec (session override vs allowlist/approval vs missing binary).

mellow fiber Feb 16, 2026, 8:43 AM

#

old hillBOT Feb 16, 2026, 8:43 AM

#

Nice — that explains the “Memory … unavailable” line: the plugin is loaded and fine, but semantic memory search is disabled because OpenClaw can’t find a usable embeddings provider/key (so it marks memory search as unavailable).

Fix the “memory unavailable” warning

Run this to see the exact reason:

openclaw memory status --deep

Typical fix options:

Provide an embeddings API key (OpenAI/Gemini/Voyage) so memory search can build its vector index.
Or explicitly set it to local embeddings (Windows-native can be a bit rough; WSL2 is usually easier).
Or if you don’t care about semantic search right now, you can ignore it (your Markdown memory files still exist; it’s just the vector search that’s “unavailable”).

Re: exec still “not working”

Your sandbox explain shows for agent:main:main:

#

mode: off
runtime: direct

So exec is not failing due to Docker/sandbox anymore.

The next most common gotcha is: you’re trying exec from a Discord channel/thread session (non‑main), and that session has a different /exec override (e.g. host=gateway or host=node) which can trigger approvals/allowlist behavior.

In the Discord thread where exec fails, send:

/exec

and paste what it prints. If it’s not host=sandbox, reset it:

#

/exec host=sandbox

If it still fails after that, grab the real error:

openclaw logs --follow

Then try one exec and paste the first error block that appears.

If you paste the openclaw memory status --deep output + the /exec output (from Discord), we can get both of these fully cleaned up.

mellow fiber Feb 16, 2026, 8:44 AM

#

PS C:\Users\archo> openclaw memory status --deep

🦞 OpenClaw 2026.2.15 (3fe22ea) — The UNIX philosophy meets your DMs.

No API key found for provider "openai". Auth store: C:\Users\archo.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\archo.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.

No API key found for provider "google". Auth store: C:\Users\archo.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\archo.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.

No API key found for provider "voyage". Auth store: C:\Users\archo.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\archo.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.

old hillBOT Feb 16, 2026, 8:46 AM

#

That /exec output is exactly what we want:

host=sandbox …

So this is not a sandbox/Docker issue, and it’s not a session /exec misconfiguration either.

When people see “the AI can’t exec” in this state, it’s usually one of these:

A) The exec tool is actually not available due to tool profile / per‑provider tool policy

tools.allow being “path not found” just means you didn’t set an override — but you might have a tools.profile or tools.byProvider restriction (sometimes added by wizards/updates).

Please run and paste:

openclaw config get tools.profile
openclaw config get tools.byProvider

#

If tools.profile is minimal or messaging, that would explain “can’t exec”.

B) The model/provider you’re using is not reliably tool-calling

Your status showed the session defaulting to minimax-m2.5:cloud. Some providers/models will “talk” about running commands but never actually emit tool calls.

Fast way to confirm: tail logs and try a single “run dir” request, then see if an exec tool call happens.

openclaw logs --follow

Then in Discord ask the bot something dead simple like: “run dir”.

If logs show tool policy blocked / “tool not allowed” → it’s (A).
If logs show no exec attempt at all → it’s (B) (tool calling isn’t firing).

C) It is running exec but failing to spawn a shell/binary

#

Then the logs will contain the real error (spawn … ENOENT, allowlist/approval, etc.).

If you paste:

tools.profile + tools.byProvider outputs, and
the first relevant error block from openclaw logs --follow right after you request an exec,

…I can tell you which bucket you’re in and the exact fix.

#

openclaw memory status --deep is basically saying: memory-core is fine, but semantic memory search can’t run because there’s no embeddings API key configured (OpenAI / Google(Gemini) / Voyage). So “Memory … unavailable” is expected until you give it some embeddings provider.

Fix the Memory “unavailable” warning (pick ONE provider)

Option A — OpenAI embeddings (most common):

Set an API key in config (so the Scheduled Task definitely sees it), then restart:

openclaw config set agents.defaults.memorySearch.provider openai
openclaw config set agents.defaults.memorySearch.model text-embedding-3-small
openclaw config set agents.defaults.memorySearch.remote.apiKey "<YOUR_OPENAI_API_KEY>"
openclaw gateway restart

Then build the index:

openclaw memory index --verbose

#

Option B — Gemini embeddings:

openclaw config set agents.defaults.memorySearch.provider gemini
openclaw config set agents.defaults.memorySearch.model gemini-embedding-001
openclaw config set agents.defaults.memorySearch.remote.apiKey "<YOUR_GEMINI_API_KEY>"
openclaw gateway restart
openclaw memory index --verbose

(Important: don’t paste API keys into Discord.)

If you don’t care about semantic memory search right now, you can also just ignore that warning — your plain Markdown memory files still work; it’s only the vector search that’s disabled.

Exec: your `/exec` defaults are correct

You pasted:

#

Current exec defaults: host=sandbox, security=full, ask=on-miss

…and openclaw sandbox explain shows mode: off / runtime: direct.

So exec is not blocked by Docker and not misconfigured via /exec.

At this point, if “the AI can’t exec”, it’s almost always one of these two:

The model/provider isn’t actually emitting tool calls (it will say it can’t, or it will describe what it would do, but never calls exec).
There’s a tool policy/profile restriction (less likely, but still possible).

To sort that in 30 seconds:

Run:

openclaw logs --follow

#

Then in Discord ask something dead-simple like: “run dir”.

If the logs show an exec attempt and an error → paste that error block.
If the logs show no exec attempt at all → it’s the model/tool-calling reliability issue, and the quickest workaround is to switch that session/agent to a more tool-reliable model for debugging.

If you paste the first exec-related log lines you see after requesting dir, I can tell you exactly which one you’re hitting.

mellow fiber Feb 16, 2026, 8:47 AM

#

PS C:\Users\archo> openclaw config get tools.profile

🦞 OpenClaw 2026.2.15 (3fe22ea) — Type the command with confidence—nature will provide the stack trace if needed.

Config path not found: tools.profile
PS C:\Users\archo> openclaw config get tools.byProvider

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your AI assistant, now without the $3,499 headset.

Config path not found: tools.byProvider

old hillBOT Feb 16, 2026, 8:50 AM

#

Cool — tools.profile and tools.byProvider both being “path not found” means you haven’t configured any tool allow/deny restrictions, so OpenClaw is using the default (i.e. exec shouldn’t be blocked by config).

And your /exec defaults you pasted are correct:

host=sandbox … (so no gateway/node allowlists/approvals getting in the way)

So if “the AI can’t exec”, we’re down to two realistic causes:

1) The model/provider isn’t actually emitting tool calls (most common)

Some models will talk about running commands but never produce an exec tool call.

How to confirm in 30 seconds:

On the gateway host, run:

openclaw logs --follow

#

Then in Discord, ask something super blunt like:

“Run dir and paste the output.”

If the logs show no exec call at all, it’s a tool-calling reliability/model issue (not your config). In that case the quickest workaround is: switch the session to a more tool-reliable model (ask in #models for the current best pick; tool-calling reliability changes fast).

2) It does call exec, but exec fails at runtime

Then the logs will show the real error (e.g. spawn ... ENOENT, permission issues, etc.). Paste the first error block you see right after requesting dir.

Side note: Memory “unavailable”

Your openclaw memory status --deep output is expected: it’s just telling you there are no embeddings API keys configured (OpenAI/Gemini/Voyage), so semantic memory search can’t run. Not related to exec.

If you paste the relevant chunk from openclaw logs --follow after you ask it to run dir, I can tell you immediately which branch you’re in and the exact fix.

mellow fiber Feb 16, 2026, 10:53 AM

#

Agent is working but still struggling to do anythingexec required. Is this a known bug as the agent says its a dev issue as everythin on the agents side is as it should be.

#

The exec is returing no output

old hillBOT Feb 16, 2026, 10:55 AM

#

Not a single “known bug” where exec is globally broken in 2026.2.15 — with your current state (/exec shows host=sandbox and sandboxing is mode: off), the gateway should be able to exec.

When it still “can’t do anything exec-required”, it’s almost always one of these two:

The model/provider isn’t actually emitting tool calls (it’ll say it can’t / “dev issue”, but no exec tool call ever happens).
It does emit exec, but the gateway is throwing a real runtime error (you’ll see it in logs: ENOENT, permissions, etc.).

Quick way to prove which one it is

On the gateway host, run:

openclaw logs --follow

Then, in Discord, ask the bot something dead simple like:

“Run dir and paste the output.”

#

Now check the log output:

If you never see an exec tool call → it’s a model/tool-calling reliability problem, not your gateway/config.
If you do see an exec attempt, paste the first error block after it — that will point to the exact fix.

Optional: faster log filter (no scrolling)

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log -Pattern "tool=exec|exec\\b|ENOENT|SYSTEM_RUN_DENIED" -Context 2,6 | Select-Object -Last 60

If it turns out to be (1), the pragmatic workaround is to switch that session to a tool-reliable model (the up-to-date recommendations change quickly, so ask in #models).

#

If /exec shows host=sandbox and sandbox explain says mode: off, then exec isn’t being blocked by sandboxing or config.

When “exec returns no output”, it’s usually not a known core bug — it’s one of:

the model never actually calls the exec tool (so you get a “dev issue” style reply but no tool run), or
exec is called but the spawn failed / output got lost, and the real reason is in the gateway logs.

Quick proof (takes 1 minute)

On the gateway host, run:

openclaw logs --follow

Then in Discord ask the agent to run something that must print output, e.g.:

cmd.exe /c echo HELLO

#

or powershell -NoProfile -Command "echo HELLO"

If exec still “returns no output”, copy/paste the log lines that appear right after that message (look for tool=exec, spawn, ENOENT, SYSTEM_RUN_DENIED, etc.).

If you don’t want to live-follow logs

Grab the last exec-related lines from the file log:

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log `
  -Pattern "tool=exec|exec\b|spawn|ENOENT|SYSTEM_RUN_DENIED" -Context 2,6 |
  Select-Object -Last 80

Paste that output here.

Once we see whether the gateway is actually receiving an exec tool call (and whether it errors), we can say definitively if it’s a model/tool-calling issue vs a gateway/runtime issue.

mellow fiber Feb 16, 2026, 10:59 AM

#

10:57:02 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_mt3j8ovgpt7k_1
10:57:02 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_mt3j8ovgpt7k_1
Log tail truncated (increase --max-bytes).
10:57:07 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_8wonldwkiy3g_1

#

10:57:07 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_8wonldwkiy3g_1
10:57:12 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_khas702zc5d0_1
10:57:12 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_khas702zc5d0_1
10:57:16 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_qjto93ob1knb_1
10:57:16 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a77f58e1-1ce4-4870-aa3a-085787448938 tool=browser toolCallId=call_function_qjto93ob1knb_1
10:57:37 debug cron {"module":"cron","storePath":"C:\Users\archo\.openclaw\cron\jobs.json"} {"nextAt":1771239600000,"delayMs":60000,"clamped":true} cron: timer armed
10:58:22 info discord-auto-reply {"module":"discord-auto-reply"} {"channelId":"979424156217147412","reason":"no-mention"} discord: skipping guild message
10:58:25 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 86ms conn=48acaadf…6305 id=66199d01…2c48
10:58:38 debug cron {"module":"cron","storePath":"C:\Users\archo\.openclaw\cron\jobs.json"} {"nextAt":1771239600000,"delayMs":60000,"clamped":true} cron: timer armed
10:58:39 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:discord:channel:979424156217147412 queueSize=1

#

10:58:39 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:discord:channel:979424156217147412 waitMs=4 queueSize=0
10:58:39 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=2
10:58:39 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=5 queueSize=0
10:58:39 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 sessionId=cb016874-7b32-4b43-b42a-dfe637457cba provider=ollama model=minimax-m2.5:cloud thinking=off messageChannel=discord
10:58:39 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=cb016874-7b32-4b43-b42a-dfe637457cba totalActive=2
10:58:39 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 sessionId=cb016874-7b32-4b43-b42a-dfe637457cba
10:58:39 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5
10:58:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 tool=exec toolCallId=call_function_lobzf4qwyazj_1
10:58:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 tool=exec toolCallId=call_function_lobzf4qwyazj_1
10:58:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 tool=exec toolCallId=call_function_tjz0b3il4mbu_1
10:58:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 tool=exec toolCallId=call_function_tjz0b3il4mbu_1
10:58:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 isError=false
1

#

0:58:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 sessionId=cb016874-7b32-4b43-b42a-dfe637457cba durationMs=9697
10:58:49 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=cb016874-7b32-4b43-b42a-dfe637457cba totalActive=1
10:58:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=0c30cf01-bd47-4b70-b33c-c031ed0041d5 sessionId=cb016874-7b32-4b43-b42a-dfe637457cba durationMs=9840 aborted=false
10:58:49 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=9844 active=1 queued=0
10:58:49 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:discord:channel:979424156217147412 durationMs=9857 active=0 queued=0
10:59:38 debug cron {"module":"cron","storePath":"C:\Users\archo\.openclaw\cron\jobs.json"} {"nextAt":1771239600000,"delayMs":21971,"clamped":false} cron: timer armed

old hillBOT Feb 16, 2026, 11:02 AM

#

That log snippet is not exec at all — it shows the agent calling the browser tool:

embedded run tool start … tool=browser …

So right now we don’t yet have evidence that an exec tool call is happening, which is exactly how you can end up with “exec returns no output”: the model is saying it can’t / blaming “dev issues”, but it never actually emits an exec tool call.

Step 1: force a tiny exec that must print output

In Discord, ask the bot exactly:

Use the exec tool (not browser). Run: cmd.exe /c echo HELLO_EXEC and paste stdout+stderr.

That should produce unmistakable output.

Step 2: confirm in logs whether `exec` was actually called

On the gateway host, run one of these and paste the result:

#

A) Live tail

openclaw logs --follow

Then run the Discord message above, then copy the log lines around it.

B) Quick grep in the file log (often easiest on Windows)

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log `
  -Pattern "tool=exec|\"tool\":\"exec\"|exec tool|spawn|ENOENT|SYSTEM_RUN_DENIED" `
  -Context 2,8 | Select-Object -Last 120

How to interpret what you’ll see

No tool=exec lines at all → not a gateway bug; it’s model/tool-calling reliability (it’s choosing browser or just not calling tools). Workaround: switch to a more tool-reliable model/provider (ask in #models for the current best choice).
tool=exec shows up + an error → paste the error block; we’ll fix the actual runtime issue (missing binary, permissions, etc.).
tool=exec shows up + stdout contains HELLO_EXEC, but Discord reply is blank → then it’s a response/rendering/routing issue, and the logs will usually show why.

#

Paste the grep output (or the live tail around the attempt) and we can pin it down immediately.

#

Your logs actually show the opposite of “exec is broken”:

10:58:43 … tool=exec …
10:58:46 … tool=exec …
… isError=false

So the Gateway is receiving and running exec tool calls. The problem is either:

the command really produced empty stdout/stderr, or
the tool result isn’t making it into the Discord reply (mention-gating / reply suppression / formatting).

Also, this line is a huge clue:

#

discord: skipping guild message … reason="no-mention"

If your message didn’t mention the bot, OpenClaw will often not reply at all in guild channels by default (it may still store context).

Quick, definitive test

In the Discord channel/thread, send a message that mentions the bot and asks for a command that must print output:

Run exactly: cmd.exe /c echo HELLO_EXEC

If you don’t mention it, it may get skipped and look like “no output”.

Then extract the actual exec result from the file log

Since openclaw logs is truncating, search the local file log for the exec call IDs you already have:

#

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log `
  -Pattern "0c30cf01-bd47-4b70-b33c-c031ed0041d5|call_function_lobzf4qwyazj_1|call_function_tjz0b3il4mbu_1" `
  -Context 0,20

Paste that output here. That will tell us whether stdout/stderr is empty (true “no output”) vs Discord just not sending it back.

If the echo HELLO_EXEC stdout is empty in the log, that would be a real Windows exec capture bug and worth escalating—but first we need that snippet.

mellow fiber Feb 16, 2026, 11:55 AM

#

Bug Report Summary

Issue: Exec tool returns no output on Windows

Environment:

OS: Windows_NT 10.0.26200 (x64)
Node: v24.13.1
OpenClaw: 2026.2.14
Reproduction:

Send any exec command via webchat (e.g., echo "test" or powershell -Command "dir")
Tool runs and completes successfully (~100-200ms)
Response returns empty: (no output)
Log Evidence:

Gateway logs show exec tool start/end events
No stdout/stderr content captured between start/end
Bug affects ALL exec commands, all shells (PowerShell, cmd, echo)
Root Cause (Suspected):
Windows child_process spawn not capturing stdout/stderr correctly — likely a Node.js Windows-specific issue with how the exec subsystem pipes output.

Impact:

Blocks all shell command execution on Windows
Workaround: Use read/write/gateway tools instead

Log Evidence:

From C:\tmp\openclaw\openclaw-2026-02-16.log (lines ~5610-5620):

{"subsystem":"agent/embedded","1":"embedded run tool start: runId=7234d5ee-908b-4c5e-bb71-352f7f70a6cf tool=exec toolCallId=call_function_4so4mywj51co_1","_meta":{...},"time":"2026-02-16T11:41:56.720Z"}
{"subsystem":"agent/embedded","1":"embedded run tool end: runId=7234d5ee-908b-4c5e-bb71-352f7f70a6cf tool=exec toolCallId=call_function_4so4mywj51co_1","_meta":{...},"time":"2026-02-16T11:41:56.906Z"}
Note: ~186ms execution time, but no stdout/stderr content between start and end entries.

Earlier example (lines ~5036-5048):

{"subsystem":"agent/embedded","1":"embedded run tool start: runId=f701a225-ae81-49d9-969f-4690629c064e tool=exec toolCallId=call_function_7jxq5ara2is3_1","_meta":{...},"time":"2026-02-16T10:51:23.814Z"}
{"subsystem":"agent/embedded","1":"embedded run tool end: runId=f701a225-ae81-49d9-969f-4690629c064e tool=exec toolCallId=call_function_7jxq5ara2is3_1","_meta":{...},"time":"2026-02-16T10:51:23.939Z"}
Same pattern — tool completes in ~125ms with zero output captured.13

old hillBOT Feb 16, 2026, 11:58 AM

#

Those log lines prove the Gateway is executing the exec tool (tool=exec start/end, isError=false). But the start/end debug lines don’t include stdout/stderr, so we still need one more datapoint: did the exec runner actually capture output, and it just wasn’t sent to Discord — or was stdout/stderr genuinely empty?

1) First: make sure you’re actually triggering replies in Discord

Your logs also show:

discord: skipping guild message … reason="no-mention"

So in that channel/thread, mention the bot (or reply to one of its messages) when you ask it to run a command. Otherwise it may “do work” in the background / store context but not reply, which looks like “no output”.

2) Capture the exec result (stdout/stderr) — turn logs up to trace for one repro

On the gateway host:

openclaw config set logging.level trace
openclaw gateway restart

#

Now reproduce with something guaranteed to print:

cmd.exe /c echo HELLO_EXEC

Then pull the surrounding log lines by toolCallId (replace with your call id):

Select-String -Path \tmp\openclaw\openclaw-2026-02-16.log `
  -Pattern "call_function_4so4mywj51co_1|tool=exec|stdout|stderr|exitCode" `
  -Context 0,30

If stdout/stderr are truly empty in the trace logs for echo HELLO_EXEC, that’s a real Windows exec capture bug.

3) If it is a real Windows bug: best workaround right now

Native Windows is the least-tested environment (WSL2 is the recommended path). The most reliable workaround is to run the Gateway inside WSL2 (Ubuntu) so exec is Linux-native. Docs: https://docs.openclaw.ai/platforms/windows

#disconnected (1008): unauthorized: gateway token mismatch (open the dashboard URL and paste the toke

1) Fix the “port already in use” first (Windows)

2) Then fix missing scope: operator.read

1) Hard-reset the Control UI’s cached credentials

2) If it still says missing scope: operator.read, revoke/rotate the device token

3) One quick sanity check

1) Force the dashboard to stop using the cached device token

2) Fix the device token scopes on the gateway (most reliable)

3) One command I still want (it shows config/service mismatches)

1) Please run and paste:

2) Then fix the missing scope: operator.read (almost always stale device token)

Fix (recommended): put Control UI auth back to normal, then re-pair cleanly

One diagnostic that will likely reveal the last wrinkle

Do this in order (takes ~2 minutes)

1) Turn OFF the break‑glass Control UI flags

2) Clear the dashboard’s cached settings/token

3) If it asks for pairing, approve it

4) If it still says missing scope: operator.read

One thing to avoid right now

1) Confirm what’s enabled

Option A (fastest): turn sandboxing off

Option B: keep sandboxing → install/fix Docker

2) About “unauthorized / token mismatch” (1008)

Fix (pick one)

Also: the “unauthorized / gateway token mismatch (1008)” part

To pinpoint quickly, paste outputs of:

Exec commands “not able to perform exec at all”

A) Exec is being denied by tool policy

B) Exec got switched to host=gateway with allowlist security

C) Approvals/allowlist are blocking it

Fast triage: paste these outputs

Please paste these outputs (they’re safe; status --all redacts secrets)

Two quick fixes that often stabilize things immediately

1) Force the service to use the same config/profile you’re editing

2) Check whether exec is being blocked by config

If you just want to get back to “last known good”

Fix: make it “one gateway, one supervisor”

To see why the Scheduled Task exited

Do this on Windows (PowerShell)

If the Scheduled Task still exits immediately

Why exec “stops working” when this happens

Next step: identify what 9864 is

If 9864 is clearly OpenClaw/Node running the gateway

Why this breaks exec / “restart collapses”

Next: verify exec is back (or capture the exact failure)

If exec still doesn’t work, the usual causes are:

About “exec commands not able to run”

Please run these and paste output

1) Your Memory plugin being “unavailable”

2) Exec “not able to perform exec commands”

3) If exec still fails after sandbox is off

1) Check the effective sandbox mode (this is the key command)

2) Get the exact exec failure

3) Memory plugin says “unavailable”

The #1 remaining cause: your session got stuck with /exec host=gateway (or node)

If it still fails: grab the exact error from logs

Side note: memory plugin “unavailable”

Fix the “memory unavailable” warning

Re: exec still “not working”

A) The exec tool is actually not available due to tool profile / per‑provider tool policy

B) The model/provider you’re using is not reliably tool-calling

C) It is running exec but failing to spawn a shell/binary

Fix the Memory “unavailable” warning (pick ONE provider)

Exec: your /exec defaults are correct

1) The model/provider isn’t actually emitting tool calls (most common)

2) It does call exec, but exec fails at runtime

Side note: Memory “unavailable”

Quick way to prove which one it is

Optional: faster log filter (no scrolling)

Quick proof (takes 1 minute)

If you don’t want to live-follow logs

Step 1: force a tiny exec that must print output

Step 2: confirm in logs whether exec was actually called

How to interpret what you’ll see

Quick, definitive test

Then extract the actual exec result from the file log

1) First: make sure you’re actually triggering replies in Discord

2) Capture the exec result (stdout/stderr) — turn logs up to trace for one repro

3) If it is a real Windows bug: best workaround right now

2) Then fix `missing scope: operator.read`

2) If it still says `missing scope: operator.read`, revoke/rotate the device token

2) Then fix the `missing scope: operator.read` (almost always stale device token)

4) If it still says `missing scope: operator.read`

B) Exec got switched to `host=gateway` with allowlist security

Please paste these outputs (they’re safe; `status --all` redacts secrets)

The #1 remaining cause: your session got stuck with `/exec host=gateway` (or `node`)

Exec: your `/exec` defaults are correct

Step 2: confirm in logs whether `exec` was actually called