Sandbox | Friends of the Crustacean 🦞🤝 | Page 1

brittle hollow Mar 1, 2026, 10:56 PM

#

why my aganet cant access the vps and make changes?

glacial cargoBOT Mar 1, 2026, 10:56 PM

#

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

next flareBOT Mar 1, 2026, 10:57 PM

#

Your agent can’t “reach into a random VPS” by itself.

In OpenClaw, the Gateway host is where the agent lives (sessions + tools run there). So what it can change depends on where your Gateway is running:

1) If your Gateway is running on your laptop

Then exec/file changes happen on your laptop, not on the VPS.
To run commands on the VPS, you need to either:

run the Gateway on the VPS, or
add the VPS as a node host and set exec host=node (Gateway forwards commands to that node).
Docs: https://docs.openclaw.ai/nodes (see “Remote node host (system.run)”) and https://docs.openclaw.ai/gateway/remote

2) If your Gateway is already running on the VPS

Then the agent can change the VPS — but only if:

the exec tool is allowed for that agent, and
exec approvals/allowlist/security aren’t blocking it.

Quick triage (paste output)

#

On the machine where the Gateway runs:

openclaw --version
openclaw status
openclaw nodes status
openclaw devices list

Also tell me: where is your Gateway running (local or VPS)? and what exactly you mean by “make changes” (run shell commands? edit repo files? restart services?).

brittle hollow Mar 1, 2026, 10:59 PM

#

yes run sell commands

next flareBOT Mar 1, 2026, 10:59 PM

#

To run shell commands on your VPS, OpenClaw needs an actual execution surface there.

By default, the exec tool runs on the machine where the Gateway is running — it does not “SSH into your VPS” automatically.

You’ve got 2 sane options:

Option A (simplest): run the Gateway on the VPS

Then the agent is “living on the VPS” and exec runs there.

VPS install guides are here: https://docs.openclaw.ai/help/faq#where-are-the-cloudvps-install-guides

Option B: keep Gateway where it is, add the VPS as a node host

This is the “run commands on another machine” design.

On the VPS, start a node host that connects back to your Gateway:
Docs + exact flow: https://docs.openclaw.ai/nodes (see Remote node host (system.run))

#

Approve the node pairing on the Gateway host:

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Point exec to that node:

openclaw config set tools.exec.host node
openclaw config set tools.exec.node "<node-id-or-name>"

Then exec calls will run on the VPS node (still subject to approvals/allowlist).

#

Quick questions so I can tell you which path fits:

Where is your Gateway running right now (your laptop/PC or the VPS)?
Are the Gateway + VPS on the same network / Tailscale tailnet, or only reachable via SSH?
What error do you get when you try to run a command? (paste the exact message)

brittle hollow Mar 1, 2026, 11:09 PM

#

on my pc. But i am using vps.
only reachable via ssh.
Errors: connetion refused, timeout connection to port 22. Permission denied (publickey)

next flareBOT Mar 1, 2026, 11:10 PM

#

Those SSH errors mean this is not an OpenClaw problem yet — your PC can’t reliably SSH to the VPS, so the agent can’t “run shell on the VPS” either.

Also: OpenClaw doesn’t SSH into machines by default. If your Gateway is on your PC, exec runs on your PC unless you either (a) run the Gateway on the VPS, or (b) add the VPS as a node host (which still requires network connectivity).

Step 1: fix SSH from your PC → VPS

These 3 errors are different failure points:

A) `timeout connecting to port 22`

Your PC can’t reach port 22 at all.

wrong IP / wrong port (some VPSes use a non-22 port)
VPS is down
firewall / security group doesn’t allow inbound 22
sshd not running, but usually that’s “refused” not “timeout”

B) `connection refused`

Host reachable, but nothing is listening on 22.

sshd not running

#

sshd moved to another port
local firewall rejects

C) `Permission denied (publickey)`

Network is fine, but auth failed.

wrong username (common: root vs ubuntu vs debian)
wrong private key used
public key not in ~/.ssh/authorized_keys on the VPS
file permissions wrong on the VPS (~/.ssh and authorized_keys)

Run this locally and paste the relevant lines:

ssh -v user@your-vps-ip

Step 2: choose the OpenClaw setup that matches what you want

#

Option A (recommended if you “use the VPS”): run the Gateway on the VPS

Then the agent lives on the VPS and shell commands run there naturally.
Remote access doc: https://docs.openclaw.ai/gateway/remote

Option B: keep Gateway on PC, run commands on VPS via a node host

This requires the VPS to be able to reach the Gateway WS (or you use a tunnel / Tailscale).
Nodes doc: https://docs.openclaw.ai/nodes (see “Remote node host (system.run)”)

If you tell me your VPS provider (Hetzner/DigitalOcean/etc) + what SSH user you’re using (root/ubuntu/etc) + the ssh -v snippet around the failure, I can point to the exact fix.

brittle hollow Mar 2, 2026, 12:04 AM

#

I'm trying to set up an OpenClaw Gateway on my local machine (running Ubuntu/Linux).

What I tried:

npm install -g openclaw - Installation seemed to work
Tried openclaw gateway start - Command not found
Tried with full path /home/aivora/.npm-global/bin/openclaw-BwRujSg0 gateway start - File not found error
Reinstalled with npm uninstall -g openclaw and npm install -g openclaw again
Still getting "command not found" when trying to run it

What I'm trying to do:
Set up a Gateway on my local machine so I can run remote commands on my VPS via the OpenClaw agent.

Questions:

• How do I properly install and run openclaw gateway start?
• Do I need to set up the PATH differently?
• Should I use a different installation method?

My setup:

• Machine: Linux (aivora-bot-01)
• Node: v22.22.0
• NPM: latest

next flareBOT Mar 2, 2026, 12:05 AM

#

openclaw gateway start is a valid command — your issue is simpler: your shell can’t find the openclaw executable (PATH / npm prefix / nvm mismatch).

0) First: confirm the install actually produced a binary

Run these on your Ubuntu box and paste the output:

node -v
npm -v
npm config get prefix
ls -la "$(npm config get prefix)/bin" | grep -E "openclaw|clawdbot" || true
echo "$PATH" | tr ':' '\n' | sed -n '1,20p'
which openclaw || true

What we’re looking for:

$(npm config get prefix)/bin/openclaw exists
that .../bin folder is on your $PATH

#

1) Fix: add npm’s global bin to PATH

If your prefix is /home/aivora/.npm-global, then you need this in ~/.bashrc (or ~/.zshrc):

export PATH="$HOME/.npm-global/bin:$PATH"

Then reload:

source ~/.bashrc

After that, openclaw --version should work.

If your npm config get prefix is something else, use that:
export PATH="$(npm config get prefix)/bin:$PATH"

#

2) If you’re using nvm (common on Linux)

Make sure you install OpenClaw under the same Node version you actually run:

nvm use 22
npm install -g openclaw
hash -r
which openclaw
openclaw --version

3) Recommended install method (avoids PATH pain)

The docs recommend the installer + onboarding wizard (it also helps with daemon/service setup):

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

#

openclaw onboard --install-daemon

Docs: https://docs.openclaw.ai/help/faq#whats-the-recommended-way-to-install-and-set-up-openclaw

4) Important: “run commands on my VPS”

Even after you fix the install: a Gateway on your PC runs exec on your PC, not via SSH to your VPS.

To run commands on the VPS, you generally want either:

Gateway on the VPS, or
VPS as a node host (requires connectivity back to the Gateway; SSH-only setups usually need a tunnel or Tailscale)

Nodes overview: https://docs.openclaw.ai/nodes
Remote gateway model: https://docs.openclaw.ai/gateway/remote

#

Send the outputs from step 0 (especially npm config get prefix + the ls .../bin + PATH) and I’ll tell you the exact one-liner fix for your setup.

brittle hollow Mar 2, 2026, 12:47 AM

#

My OpenClaw sandbox is broken and blocking ALL exec commands. Every command fails with this error:

Cannot find module '/home/aivora/.npm-global/lib/node_modules/openclaw/dist/tool-loop-detection-B1_rZFTj.js'
imported from /home/aivora/.npm-global/lib/node_modules/openclaw/dist/reply-Deht_wOB.js

What I tried:

• npm uninstall -g openclaw
• npm cache clean --force
• rm -rf ~/.npm-global/lib/node_modules/openclaw
• Fresh install with curl -fsSL https://openclaw.ai/install.sh | bash

Problem: Even after uninstalling, the sandbox keeps trying to load the corrupted module on EVERY command, blocking all work.

Question: How do I completely reset the sandbox environment or fix the module resolution? I have a Gateway running on my VPS (134.122.72.75:18789) and need the sandbox to connect to it for remote work.

next flareBOT Mar 2, 2026, 12:49 AM

#

That error isn’t “the sandbox” or remote-mode config — it’s your local OpenClaw code install being corrupt/incomplete.

reply-….js is trying to import "./tool-loop-detection-….js" from the same dist/ folder, but that chunk file isn’t there. Until that’s fixed, every command will crash before it can do anything (including connecting to your VPS gateway).

1) First, prove which `openclaw` you’re actually running

On your Ubuntu PC, run and paste output:

which -a openclaw || true
command -v openclaw || true
npm config get prefix
ls -la "$(npm config get prefix)/bin" | grep -E "openclaw" || true
ls -la "$(npm config get prefix)/lib/node_modules" | grep -E "openclaw|\\.openclaw-" || true

This often reveals you have multiple installs (or a leftover .openclaw-* staging dir) and your PATH is picking the broken one.

#

2) Hard reset the code install (not your gateway state)

Use your npm prefix (you already have it: ~/.npm-global), then nuke the binaries + module folders and reinstall:

PREFIX="$(npm config get prefix)"

npm uninstall -g openclaw || true

# remove any leftover installs/staging dirs
rm -rf "$PREFIX/lib/node_modules/openclaw" "$PREFIX/lib/node_modules/.openclaw-"* 2>/dev/null || true

# remove any leftover bin shims
rm -f "$PREFIX/bin/openclaw" "$PREFIX/bin/openclaw-"* 2>/dev/null || true

npm cache verify || npm cache clean --force
npm install -g openclaw@latest --force

#


hash -r
openclaw --version

After reinstall, sanity check that the missing file exists:

ls -la "$PREFIX/lib/node_modules/openclaw/dist" | grep tool-loop-detection || true

If that grep still shows nothing, it’s either:

you’re not executing the install you think you are (PATH mismatch), or
the install is failing mid-way (disk full / permissions / interrupted).

3) If you want the most robust install: “hackable (git) install”

#

This avoids weird global npm packaging/state issues:

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

Docs recommend this when debugging local issues:
https://docs.openclaw.ai/help/faq#im-stuck-whats-the-fastest-way-to-get-unstuck

4) Once local CLI works: connect your PC to the VPS Gateway (SSH-only)

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

If the gateway on the VPS is loopback-bound (recommended), do an SSH tunnel from your PC:

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

#

Then set remote mode on your PC:

openclaw config set gateway.mode remote
openclaw config set gateway.remote.url "ws://127.0.0.1:18789"
openclaw config set gateway.remote.token "<gateway-token>"

(Get the token on the VPS: openclaw config get gateway.auth.token.)

If you paste the output from step (1), I can tell you exactly where the “ghost” install is coming from (wrong prefix / duplicate binary / leftover .openclaw-* folder / PATH picking the wrong one).

brittle hollow Mar 2, 2026, 12:58 AM

#

salesbot@aivora-bot-01:~/sales-coach-phase1$ ssh -N -L 18789:127.0.0.1:18789 salesbot@134.122.72.75
salesbot@134.122.72.75's password:
bind [127.0.0.1]:18789: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 18789
Could not request local forwarding.
openclaw config set gateway.mode remote
openclaw config set gateway.remote.url "ws://127.0.0.1:18789"
openclaw config set gateway.remote.token "<gateway-token>"
^Csalesbot@aivora-bot-01:~/sales-coach-phase1$ openclaw config set gateway.mode remote

openclaw config set gateway.remote.token "<gateway-token>"openclaw: command not found
salesbot@aivora-bot-01:~/sales-coach-phase1$ openclaw config set gateway.remote.url "ws://127.0.0.1:18789"
openclaw: command not found
salesbot@aivora-bot-01:~/sales-coach-phase1$ openclaw config set gateway.remote.token "<gateway-token>"
openclaw: command not found

next flareBOT Mar 2, 2026, 12:58 AM

#

You’ve actually got two separate problems in that paste:

Your SSH tunnel failed because your local port 18789 is already in use.
Your OpenClaw CLI still isn’t installed / not on PATH (openclaw: command not found), so none of the config commands can run anyway.

Let’s fix them in the right order.

A) Fix the SSH tunnel: pick a free local port

bind 127.0.0.1:18789: Address already in use means something on your PC is already listening on 18789 (often a local OpenClaw gateway).

1) See what’s using it:

sudo lsof -iTCP:18789 -sTCP:LISTEN -n -P
# or

#

ss -ltnp | grep 18789

2) Easiest: just tunnel to a different local port (18790)

ssh -N -L 18790:127.0.0.1:18789 salesbot@134.122.72.75

Then your “remote url” should be:

ws://127.0.0.1:18790

(You can leave the VPS side as 18789; only the local port changes.)

B) Fix `openclaw: command not found` (PATH / install)

#

Right now you cannot run OpenClaw locally at all.

Run:

node -v
npm -v
npm config get prefix
ls -la "$(npm config get prefix)/bin" | grep openclaw || true
echo "$PATH" | tr ':' '\n' | grep -E "npm|nvm|pnpm|local" || true

If `$(npm config get prefix)/bin/openclaw` exists, add it to PATH:

If your prefix is ~/.npm-global, do:

echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

#

hash -r
openclaw --version

If it does NOT exist, reinstall:

npm install -g openclaw@latest
hash -r
openclaw --version

C) Once `openclaw` works: point it at the tunneled VPS gateway

Assuming you tunneled local 18790 -> VPS 127.0.0.1:18789:

#

openclaw config set gateway.mode remote
openclaw config set gateway.remote.url "ws://127.0.0.1:18790"
openclaw config set gateway.remote.token "<gateway-token>"
openclaw status

(You can also skip config and just run openclaw status --url ws://127.0.0.1:18790 --token ... once you have the CLI.)

Docs (remote mode): https://docs.openclaw.ai/gateway/remote

Quick question

Do you currently have a local OpenClaw gateway running on your PC? (That would explain why port 18789 is in use.)

If you paste the output of:

#

ss -ltnp | grep 18789
npm config get prefix
ls -la "$(npm config get prefix)/bin" | grep openclaw

…I’ll tell you exactly what to kill / what PATH line you need.

brittle hollow Mar 2, 2026, 1:03 AM

#

the sandbox environment is broken.
when i ask the bot to make change he answer with this.
sandbox environment is broken in a way I can't fix from within it.
till me the exact steps to give him access to sandbox

next flareBOT Mar 2, 2026, 1:05 AM

#

You can’t “give the bot access to the sandbox” from inside chat.

In OpenClaw:

Sandbox = optional Docker isolation for tool execution (it reduces access).
Access to run shell commands is controlled by:
1. tool allow/deny policy, and
2. exec approvals on the machine that will actually execute (gateway host or node host).

That “sandbox environment is broken…” message usually happens when the agent is trying to run exec in host=sandbox but sandboxing isn’t set up (or is disabled), so it fails closed.

Do this on the machine where the Gateway runs (your VPS)

SSH into the VPS manually (normal SSH), then:

1) Point exec at the real host (not sandbox)

If you want commands to run on the VPS itself, set:

#

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.ask on-miss
openclaw gateway restart

(Exec tool docs: https://docs.openclaw.ai/tools/exec)

2) Allow the commands via exec approvals (this is the “permission” part)

On the VPS, add allowlist entries for the binaries you want the agent to use:

openclaw approvals get --gateway
openclaw approvals allowlist add --gateway --agent main "/usr/bin/ls"
openclaw approvals allowlist add --gateway --agent main "/usr/bin/git"

#

openclaw approvals allowlist add --gateway --agent main "/usr/bin/systemctl"

Approvals docs: https://docs.openclaw.ai/tools/exec-approvals
Approvals CLI: https://docs.openclaw.ai/cli/approvals

After this, exec on the VPS will work for allowlisted commands (and will prompt/deny for the rest depending on your approvals settings).

3) (Optional) If you actually want sandboxing

Sandboxing is separate. On the VPS:

cd <your openclaw git checkout>
scripts/sandbox-setup.sh

#

Then set agents.defaults.sandbox.mode in config. Full doc: https://docs.openclaw.ai/gateway/sandboxing
But again: sandboxing does not give more access; it isolates.

Quick question (so I don’t send you down the wrong path)

When you ask “make change”, do you want the command to run:

on the VPS (same host as the Gateway), or
on your PC (Gateway on VPS, but you want a local node to run commands)?

Your earlier setup sounded like (1), so the steps above should fix it. If you want (2), you need a node host on your PC and set tools.exec.host=node.

brittle hollow Mar 2, 2026, 1:06 AM

#

ivora@aivora-bot-01:~$ openclaw config set tools.exec.host gateway
openclaw: command not found
aivora@aivora-bot-01:~$ openclaw config set tools.exec.security allowlist
openclaw: command not found
aivora@aivora-bot-01:~$ openclaw config set tools.exec.ask on-miss
openclaw: command not found
aivora@aivora-bot-01:~$

next flareBOT Mar 2, 2026, 1:07 AM

#

Yeah — you’re blocked one level earlier: OpenClaw isn’t installed / isn’t on PATH on that machine (openclaw: command not found). Until that’s fixed, you can’t change exec settings or approvals.

Here are the exact steps to get openclaw working on aivora-bot-01 (Ubuntu), then give it “sandbox/exec access” (really: host exec access).

1) Install OpenClaw (recommended way)

On aivora-bot-01 run:

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

Then open a new shell (or reload your profile):

#

source ~/.profile 2>/dev/null || true
source ~/.bashrc 2>/dev/null || true
hash -r

Check it:

command -v openclaw
openclaw --version

If command -v openclaw prints a path and --version works, you’re good.

If it STILL says “command not found”

Your npm global bin isn’t on PATH. Find the prefix:

#

npm config get prefix

Then add …/bin to PATH. Example (common case):

echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hash -r
command -v openclaw
openclaw --version

2) Now “give the agent access” to run shell on the VPS host

#

This is not sandbox access — it’s configuring exec to run on the gateway host with approvals.

Run on the machine where the Gateway runs (if your gateway is on the VPS, run these there; if your gateway is on this Ubuntu box, run them here):

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.ask on-miss
openclaw gateway restart

Then allow some safe basics:

openclaw approvals allowlist add --gateway --agent main "/usr/bin/ls"
openclaw approvals allowlist add --gateway --agent main "/usr/bin/uname"

#

openclaw approvals allowlist add --gateway --agent main "/usr/bin/uptime"

Docs:

Exec tool: https://docs.openclaw.ai/tools/exec
Exec approvals: https://docs.openclaw.ai/tools/exec-approvals

3) One important clarification

Are you running these commands on your PC (aivora-bot-01) or on the VPS?

Because:

If your Gateway is on the VPS, you must run the config/approvals commands on the VPS (that’s where the agent “lives”).
If your Gateway is on your PC, run them on your PC.

#

Reply with:

output of hostname and openclaw --version (once installed)
where the Gateway is running (PC or VPS)

brittle hollow Mar 2, 2026, 1:11 AM

#

aivora@aivora-bot-01:~$ curl -fsSL https://openclaw.ai/install.sh | bash

🦞 OpenClaw Installer
I can run local, remote, or purely on vibes—results may vary with DNS.

✓ Detected: linux

Install plan
OS: linux
Install method: npm
Requested version: latest

[1/3] Preparing environment
✓ Node.js v22.22.0 found
· Active Node.js: v22.22.0 (/usr/bin/node)
· Active npm: 10.9.4 (/usr/bin/npm)

[2/3] Installing OpenClaw
✓ Git already installed
· Installing OpenClaw v2026.2.26
main: line 638: 393425 Killed "${cmd[@]}" > "$log" 2>&1
! npm install failed for openclaw@latest
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@latest
Installer log: /tmp/tmp.W9THq09sB8
! npm install failed; showing last log lines
! npm install failed; retrying
main: line 638: 393547 Killed "${cmd[@]}" > "$log" 2>&1
! npm install failed for openclaw@latest
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@latest
Installer log: /tmp/tmp.8O0BrVwX0m
! npm install failed; showing last log lines

next flareBOT Mar 2, 2026, 1:12 AM

#

That Killed during npm install -g openclaw@latest is almost always the Linux OOM killer (the kernel killed the npm/node process because the machine ran out of RAM). That also explains your earlier “missing dist/*.js chunk” errors — a half-installed package leaves broken dist/ output.

1) Confirm it’s OOM (on `aivora-bot-01`)

Run:

free -h
dmesg -T | egrep -i "killed process|oom" | tail -30

If you see Out of memory / Killed process node, that’s it.

2) Add swap (quick fix) and retry install

If you have sudo:

#

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

Now retry:

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

#

3) Clean up any broken partial install (important)

After an OOM-killed install, remove leftovers before retrying:

PREFIX="$(npm config get prefix)"
rm -rf "$PREFIX/lib/node_modules/openclaw" "$PREFIX/lib/node_modules/.openclaw-"* 2>/dev/null || true
rm -f  "$PREFIX/bin/openclaw" "$PREFIX/bin/openclaw-"* 2>/dev/null || true
npm cache clean --force

Then reinstall (either the installer again, or):

npm install -g openclaw@latest

#

4) After it installs, verify:

command -v openclaw
openclaw --version

FYI on “giving the bot sandbox access”

Sandboxing doesn’t “give access” — it restricts access. If your goal is “run shell commands”, you want exec on gateway/node host (with approvals), not “more sandbox”.

But first you need a working openclaw binary, and right now you’re being killed mid-install due to low memory.

If you paste free -h (and whether you have sudo), I can tell you how much swap you’ll need / whether you should just upgrade RAM.

brittle hollow Mar 2, 2026, 1:12 AM

#

aivora@aivora-bot-01:~$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 697Mi 1.1Gi 4.0Mi 158Mi 1.1Gi
Swap: 0B 0B 0B
aivora@aivora-bot-01:~$ dmesg -T | egrep -i "killed process|oom" | tail -30
dmesg: read kernel buffer failed: Operation not permitted

next flareBOT Mar 2, 2026, 1:12 AM

#

Yep — 1.9 GiB RAM and no swap is exactly the kind of box where npm install -g openclaw can get OOM-killed. And the dmesg permission error just means you’re not root, so you can’t read kernel logs.

What to do

Option 1 (best): add swap, then reinstall

If you have sudo, do this:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
free -h

(Optional: make it permanent)

#

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Now clean the partial install + retry:

PREFIX="$(npm config get prefix)"

sudo rm -rf "$PREFIX/lib/node_modules/openclaw" "$PREFIX/lib/node_modules/.openclaw-"* 2>/dev/null || true
sudo rm -f  "$PREFIX/bin/openclaw" "$PREFIX/bin/openclaw-"* 2>/dev/null || true

npm cache clean --force
curl -fsSL https://openclaw.ai/install.sh | bash

Then verify:

#

command -v openclaw
openclaw --version

Option 2: upgrade the machine

If you can bump this host to 4GB RAM, installs and builds get dramatically less painful.

Option 3: if you don’t have sudo

Then you can’t add swap. Your choices are basically:

run OpenClaw on a bigger machine (or your VPS), or
ask your admin to add swap.

After install succeeds (important)

To let the agent run commands on the VPS host, you’ll want exec on the gateway host with approvals (not “more sandbox”). We can do that next, but first we need a working install.

#

Quick question: do you have sudo on aivora-bot-01? If yes, run the swap commands above and retry install. If no, tell me and we’ll switch to “run Gateway on the VPS” as the main path.

brittle hollow Mar 2, 2026, 1:20 AM

#

Onboarding complete. Use the dashboard link above to control OpenClaw.

aivora@aivora-bot-01:~$ command -v openclaw
/home/aivora/.npm-global/bin/openclaw
aivora@aivora-bot-01:~$ openclaw --version
2026.2.26
aivora@aivora-bot-01:~$

now the bot not answering in telegram

next flareBOT Mar 2, 2026, 1:21 AM

#

Nice — OpenClaw is installed and the Gateway onboarded. If Telegram isn’t answering, it’s almost always one of these:

Gateway isn’t actually running / reachable
Telegram channel isn’t enabled / bot token is wrong
Access control is blocking replies (pairing / allowFrom / group mention gating)
It’s erroring in the background (you’ll see it in logs)

Here’s the fastest debug path.

1) Confirm the gateway is up and healthy

On aivora-bot-01:

openclaw status
openclaw gateway status
openclaw models status

#

If any of those show errors, paste the output.

2) Tail logs while you message the bot

Run this in one terminal:

openclaw logs --follow

Then in Telegram send your bot a DM like: ping

What we need to know:

Do you see the incoming Telegram update in logs?
If yes: do you see an error when it tries to reply?

(If nothing shows up in logs when you DM the bot, it’s almost certainly token/config/enabled.)

#

3) Check Telegram config + access policy

Show your Telegram config:

openclaw config get channels.telegram

Pay attention to:

enabled: true
botToken set
dmPolicy

Common gotchas:

dmPolicy = "pairing" (default): you must DM the bot and complete pairing (it should send a pairing code / instructions).
allowFrom: must be your numeric Telegram user id (not username). Docs: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom
Group chats: by default many setups require a mention in groups; test in a DM first.

#

4) If Telegram is configured but still silent

Run:

openclaw status --all

That’s designed to be pasteable/safe (tokens redacted) and usually contains the clue.

Reply with:

Are you testing in DM or a group?
Output of openclaw status and the last ~30 lines from openclaw logs --follow after you send “ping”.

brittle hollow Mar 2, 2026, 1:24 AM

#

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:790fea85 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │

Agents
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │

│ main │ ABSENT │ 2 │ 15m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/aivora/.openclaw/openclaw.json
Bind: loopback
✓ Config: /home/aivora/.openclaw/openclaw.json
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 7 eligible · 0 missing · /home/aivora/.openclaw/workspace
! Channel issues skipped (gateway unreachable)
Gateway health:
connect failed: connect ECONNREFUSED 127.0.0.1:18789
Pasteable debug report. Auth tokens redacted.

next flareBOT Mar 2, 2026, 1:25 AM

#

Your Telegram config is fine — the Gateway itself isn’t running.

Key line:

Gateway health: connect failed: connect ECONNREFUSED 127.0.0.1:18789
Channel issues skipped (gateway unreachable)

So Telegram can’t reply because there’s no gateway process listening on 127.0.0.1:18789.

1) Start / restart the Gateway service

Run:

openclaw gateway status
openclaw gateway start

#

If it says it’s already running but still refused, do:

openclaw gateway restart

2) If `gateway start` fails, check logs

openclaw logs --follow

(You should see why it didn’t bind the port — common causes are: config error, another process on the port, or the service wasn’t installed.)

3) Check if something else is using the port

ss -ltnp | grep 18789 || true

#

If you see another process bound to 18789, paste that line.

4) If you want it to run in the background (recommended)

Install the daemon/service:

openclaw onboard --install-daemon
# or if already installed:
openclaw gateway install --force
openclaw gateway restart

Once openclaw status shows Gateway health OK, your Telegram bot will start answering immediately.

Paste the output of openclaw gateway status if it still won’t start.

brittle hollow Mar 2, 2026, 1:32 AM

#

Onboarding complete. but the bot in telegram send this: HTTP 401: authentication_error: invalid x-api-key (request_id: req_011CYdPbXkfMQKpc32uWGjsk)

next flareBOT Mar 2, 2026, 1:33 AM

#

That HTTP 401 invalid x-api-key is not Telegram auth — it’s your LLM provider auth (almost certainly Anthropic, because Anthropic uses the x-api-key header).

So the Gateway is receiving your Telegram message, but when it tries to call the model, the provider rejects the key/token.

Fix checklist (do these on the Gateway host)

1) See what model/provider you’re actually using + what auth profile is picked

openclaw models status

Paste the anthropic section (it’ll redact secrets).

2) Re-auth Anthropic (pick ONE path)

A) If you have an Anthropic API key

#

openclaw models auth paste-token --provider anthropic
# paste your real Anthropic API key when prompted
openclaw gateway restart

B) If you’re using Claude Pro/Max subscription (setup-token)
Generate a setup-token via Claude Code (on any machine):

claude setup-token

Then on the Gateway host:

openclaw models auth paste-token --provider anthropic
# paste the setup-token
openclaw gateway restart

#

(FAQ section on setup-token auth is in the docs: https://docs.openclaw.ai/help/faq.md → “How does Anthropic setup-token auth work”)

3) Make sure you’re not accidentally overriding it with a bad env var

In the same shell you run OpenClaw from:

env | grep -i anthropic || true

If you see ANTHROPIC_API_KEY set to something stale/wrong, unset it and restart the gateway.

If you paste the output of openclaw models status (just that), I can tell you exactly what it’s trying to use (provider + profile) and what to change.

brittle hollow Mar 2, 2026, 1:35 AM

#

the bot is back now.
how i check now if he can accesee the terminal and run comands?

next flareBOT Mar 2, 2026, 1:36 AM

#

Good — now test exec explicitly.

1) Fast test from chat (Telegram)

Send the bot:

/exec

It should reply with the current exec defaults (host/security/ask).
Then try a harmless command:

run `uname -a`

(or “run pwd”, “run ls -la”).

#

2) If it says it can’t / denies / asks for approval

That means exec approvals / allowlist are blocking it (normal).

On the gateway host, check what exec is configured to do:

openclaw config get tools.exec
openclaw approvals get --gateway

Allow a safe command (example)

openclaw approvals allowlist add --gateway --agent main "/usr/bin/uname"
openclaw approvals allowlist add --gateway --agent main "/bin/ls"
openclaw gateway restart

#

Docs for how exec/approvals work:

3) Confirm where it’s running (important)

Remember:

If your Gateway is on your PC, exec runs on your PC.
If your Gateway is on the VPS, exec runs on the VPS.
OpenClaw doesn’t SSH into other machines unless you set up a node host.

If you tell me where your Gateway is running (PC or VPS), I’ll give the exact “best practice” exec settings for that setup.

brittle hollow Mar 2, 2026, 1:36 AM

#

next flareBOT Mar 2, 2026, 1:36 AM

#

That output means: right now the bot cannot run any commands anywhere.

host=sandbox = try to run inside the sandbox container
security=deny = block all exec (even if sandbox exists)
So exec is effectively disabled.

You have two ways to enable it:

Option A (recommended): run commands on the Gateway host with allowlist + approvals

On the machine where your Gateway runs:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.ask on-miss
openclaw gateway restart

#

Then allow a couple safe binaries (still on the gateway host):

openclaw approvals allowlist add --gateway --agent main "/usr/bin/uname"
openclaw approvals allowlist add --gateway --agent main "/bin/ls"

Now in Telegram you can test:

run uname -a
run ls -la

Docs: https://docs.openclaw.ai/tools/exec and https://docs.openclaw.ai/tools/exec-approvals

Option B (quick “break glass”): full exec (not recommended long-term)

This removes safety rails:

#Sandbox

1) If your Gateway is running on your laptop

2) If your Gateway is already running on the VPS

Quick triage (paste output)

Option A (simplest): run the Gateway on the VPS

Option B: keep Gateway where it is, add the VPS as a node host

Quick questions so I can tell you which path fits:

Step 1: fix SSH from your PC → VPS

A) timeout connecting to port 22

B) connection refused

C) Permission denied (publickey)

Step 2: choose the OpenClaw setup that matches what you want

Option A (recommended if you “use the VPS”): run the Gateway on the VPS

Option B: keep Gateway on PC, run commands on VPS via a node host

0) First: confirm the install actually produced a binary

1) Fix: add npm’s global bin to PATH

2) If you’re using nvm (common on Linux)

3) Recommended install method (avoids PATH pain)

4) Important: “run commands on my VPS”

1) First, prove which openclaw you’re actually running

2) Hard reset the code install (not your gateway state)

3) If you want the most robust install: “hackable (git) install”

4) Once local CLI works: connect your PC to the VPS Gateway (SSH-only)

A) Fix the SSH tunnel: pick a free local port

1) See what’s using it:

2) Easiest: just tunnel to a different local port (18790)

B) Fix openclaw: command not found (PATH / install)

If $(npm config get prefix)/bin/openclaw exists, add it to PATH:

If it does NOT exist, reinstall:

C) Once openclaw works: point it at the tunneled VPS gateway

Quick question

Do this on the machine where the Gateway runs (your VPS)

1) Point exec at the real host (not sandbox)

2) Allow the commands via exec approvals (this is the “permission” part)

3) (Optional) If you actually want sandboxing

Quick question (so I don’t send you down the wrong path)

1) Install OpenClaw (recommended way)

If it STILL says “command not found”

2) Now “give the agent access” to run shell on the VPS host

3) One important clarification

1) Confirm it’s OOM (on aivora-bot-01)

2) Add swap (quick fix) and retry install

3) Clean up any broken partial install (important)

4) After it installs, verify:

FYI on “giving the bot sandbox access”

What to do

Option 1 (best): add swap, then reinstall

Option 2: upgrade the machine

Option 3: if you don’t have sudo

After install succeeds (important)

1) Confirm the gateway is up and healthy

2) Tail logs while you message the bot

3) Check Telegram config + access policy

4) If Telegram is configured but still silent

1) Start / restart the Gateway service

2) If gateway start fails, check logs

3) Check if something else is using the port

4) If you want it to run in the background (recommended)

Fix checklist (do these on the Gateway host)

1) See what model/provider you’re actually using + what auth profile is picked

2) Re-auth Anthropic (pick ONE path)

3) Make sure you’re not accidentally overriding it with a bad env var

1) Fast test from chat (Telegram)

2) If it says it can’t / denies / asks for approval

Allow a safe command (example)

3) Confirm where it’s running (important)

Option A (recommended): run commands on the Gateway host with allowlist + approvals

Option B (quick “break glass”): full exec (not recommended long-term)

A) `timeout connecting to port 22`

B) `connection refused`

C) `Permission denied (publickey)`

1) First, prove which `openclaw` you’re actually running

B) Fix `openclaw: command not found` (PATH / install)

If `$(npm config get prefix)/bin/openclaw` exists, add it to PATH:

C) Once `openclaw` works: point it at the tunneled VPS gateway

1) Confirm it’s OOM (on `aivora-bot-01`)

2) If `gateway start` fails, check logs