Is there a quick way to get on board. I'm using Hertzner VPS and discord. Websearch & gmail

[wind ibex]

I've using Hertzner VPS and managed to get up and running using instructions from ChatGPT. It took so many hours that I'm embarrassed to share on here. Himalaya email worked for a short while then stopped.

I got kicked out of kimi cloud model after a tiny bit of use. Then local lama 3.2 failed because of how openclaw configured it. If you change configuration in multiple places I think it will work. I've spent so much time on this that I don't know if I'll pursue.

I'm an accountant with basic tech skills.
I use Claude and chatgpt to write all my code and have built email automations and other programs. I can find my way around Google Cloud platform. Openclaw is tough

[silent dove]

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

[wind summit]

Yeah — OpenClaw can feel way harder than it should, especially if you got guided by random ChatGPT snippets (they’re often outdated and they tend to “spray config” in 3 places).

If you want the fastest “back to a working baseline” on a Hetzner VPS + Discord, I’d do this:

1) Don’t debug blind — grab the 3 outputs (safe to paste)

Run these on the VPS and paste the output here (they redact secrets):

openclaw --version
openclaw status --all
openclaw models status

(If Discord messages stopped arriving, also:)

openclaw channels status

2) Stabilize with the minimum moving parts

Before adding email + local models + web search, get one path working:

• One channel (Discord)
• One provider/auth path (whatever you actually have working/billed)
• Then add web tools, then Gmail/email

This avoids the common trap where any one flaky integration makes the whole experience feel broken.

3) Important clarifications (this usually explains the “it worked then stopped”)

• Config should live in one place: ~/.openclaw/openclaw.json (JSON5).
  Use openclaw configure / openclaw config set instead of editing multiple files.
• If you run the gateway as a service, your shell env vars often don’t load. Put keys in ~/.openclaw/.env or enable shell env import. This is a top cause of “worked once, then stopped after restart”.
• Local Llama/Ollama can work, but it’s not the easiest first win (especially for tool-using agents). I’d treat it as “phase 2” after the basics.

4) Use the official Hetzner + FAQ docs (they’re current)

• Hetzner guide: https://docs.openclaw.ai/install/hetzner

• FAQ (especially the “first 60 seconds if something’s broken” section): https://docs.openclaw.ai/help/faq

If you paste those command outputs, I can tell you exactly what’s failing (auth not loading, gateway not reachable, discord token/channel config, model failover, etc.) and the smallest fix to get you back to “it replies reliably.”

[wind ibex]

Thanks, I'll uninstall and start from scratch.
Is this workflow sufficient

1. openclaw uninstall --all --yes --non-interactive

2. Remove leftover config folders
   rm -rf ~/.openclaw ~/.clawdbot ~/.moltbot ~/.molthub

Stop and remove the background service

systemctl --user disable --now openclaw-gateway.service
rm -f ~/.config/systemd/user/openclaw-gateway.service
systemctl --user daemon-reload

[wind summit]

Mostly yes — but I’d tighten it up a bit, because your step (2) is very destructive and also a bunch of those folders aren’t standard.

The simplest “wipe & restart” flow (Linux/VPS)

Usually this is enough:

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

That’s the officially supported “nuke it” path:
https://docs.openclaw.ai/install/uninstall

Then verify what’s left (before rm -rf)

Check if any gateway service is still around:

systemctl --user status openclaw-gateway.service

ls -la ~/.openclaw* 2>/dev/null || true

• If you used profiles, you may have ~/.openclaw-<profile> dirs — those should be removed too if you truly want “from scratch”.

Only if the service is still running (manual cleanup)

If openclaw is already gone / the service is orphaned, then your systemd cleanup is the right idea (this matches the uninstall docs):

systemctl --user disable --now openclaw-gateway.service
rm -f ~/.config/systemd/user/openclaw-gateway.service
systemctl --user daemon-reload

About deleting ~/.clawdbot ~/.moltbot ~/.molthub

I would not blanket-delete those unless you confirm they exist and you’re sure they’re OpenClaw-related on your machine. Safer:

ls -la ~/.clawdbot ~/.moltbot ~/.molthub 2>/dev/null || true

If they exist and you want a clean slate, then remove them intentionally.

---

When you’re ready to reinstall on Hetzner, follow the official guide (it’ll save you a lot of “ChatGPT archaeology”):
https://docs.openclaw.ai/install/hetzner

If you paste the outputs of the two “verify” commands above after uninstall, I can tell you whether you’re truly clean before you reinstall.

[fiery gazelle]

Hi, I'm also running on Hetzner and my bot is working properly and I'm chatting with it on Telegram, but the problem is when I try to connect it to the internet it just doesn't. I installed Tavily skill and also gave it a brave API, but still it says I don't have access to the internet. What should I do? The problem might be on my gateway because whenever I try to run a command related to Gateway I see this error:
Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found

[wind summit]

That systemctl … Failed to connect to bus: No medium found error is the giveaway: you’re not running the gateway as a systemd service (very likely you’re following the Hetzner Docker guide, where the gateway runs in a container). In that setup, openclaw gateway status/restart/install (service-management commands) can’t work because there is no systemd user bus in the container.

1) Fix the “gateway commands” confusion (Docker vs systemd)

If you’re on the Hetzner Docker flow, manage it like this instead:

docker compose ps
docker compose logs -f openclaw-gateway
docker compose restart openclaw-gateway

And when you run OpenClaw CLI commands, run them inside the container so you’re inspecting the same environment/config:

docker compose exec openclaw-gateway openclaw status --all
docker compose exec openclaw-gateway openclaw models status

2) Fix “no internet access” (usually tool policy / API key not reaching the container)

For “internet”, OpenClaw typically means web_fetch + web_search tools.

Common causes:

• web_search isn’t enabled in config
• tool allowlist blocks web_search/web_fetch (needs group:web or explicit tools)
• Brave API key was set on the host, but not passed into the container (so the gateway doesn’t see it)

Docs: https://docs.openclaw.ai/help/faq#how-do-i-enable-web-search-and-web-fetch and https://docs.openclaw.ai/tools/web

3) What I need from you (paste output)

Run this and paste the output here (it redacts secrets):

docker compose exec openclaw-gateway openclaw status --all

Also tell me: did you put the Brave key in openclaw.json (tools.web.search.apiKey) or as BRAVE_API_KEY in the Docker .env that docker compose loads?

Once I see status --all, I can point to the exact missing bit (enabled flag vs allowlist vs key not injected) and the one-line fix.

[wind ibex]

I purchased VPS for openclaw so nothing else on it. I set up a user folder so I'll install there rather than root.

Once I've done above do i move to Ollama bit where I pick up model.

I like to know what steps are ahead of me

[fiery gazelle]

I'm not using Docker, should I?

[wind summit]

If the VPS is dedicated to OpenClaw, a “clean reinstall + wizard” is a good call.

What steps are ahead (high level)

After uninstall/cleanup, the typical VPS path is:

1. Create/use a non-root user (good) + SSH in as that user
2. Install Node 22+ (required)
3. Install OpenClaw CLI
4. Run the onboarding wizard (this is where you pick the model + set up Discord, etc.)
5. Access the dashboard via an SSH tunnel
6. Verify with openclaw status / openclaw models status / openclaw channels status
7. Only then add “extras” (web search, Gmail, local models)

The official “beginner VPS quick path” is here (worth following exactly once):
https://docs.openclaw.ai/platforms/linux

Where does “pick a model / Ollama” happen?

During openclaw onboard. You don’t do “the Ollama bit” as a separate phase unless you want to.

My strong recommendation for a first successful run:

• Do NOT start with Ollama on a cheap VPS. It’s usually slow/fragile and can eat RAM/CPU fast.
• Start with one cloud provider you have working billing/auth for, get Discord replying reliably, then experiment with Ollama later.

If you really want “local” models, the saner pattern is:

• Run OpenClaw on the VPS
• Run Ollama on a machine that actually has the horsepower (often your local machine or a GPU box)
• Point OpenClaw at that Ollama endpoint

Concrete sequence (so you know what’s next)

On the VPS, as your non-root user:

1. Install Node 22+
2. Install OpenClaw
3. Run:

   openclaw onboard --install-daemon

4. From your laptop:

   ssh -N -L 18789:127.0.0.1:18789 <user>@<vps>
   

   then open http://127.0.0.1:18789/ and paste the token.

If you tell me your VPS OS (Ubuntu/Debian?) + size (RAM/CPU), I’ll tell you whether Ollama on that box is realistic or a guaranteed pain.

You don’t need Docker — but on Hetzner it’s often the most “boring and reliable” way to run 24/7 if you don’t want to fight Linux service manager quirks.

Right now, the key detail is: your error means systemctl --user isn’t usable in your environment, so OpenClaw’s “gateway service” commands can’t do their normal checks.

Two supported paths (pick one)

Option A) Stay non‑Docker (totally fine)

Do this if you want a normal Linux install + systemd user service.

1. First verify whether your VPS is actually running systemd as PID 1:

ps -p 1 -o comm=
systemctl --version

• If PID 1 is not systemd, systemctl will never work properly → you’ll either run OpenClaw in the foreground (tmux) or switch to Docker.
• If PID 1 is systemd, then the “No medium found” is usually a missing user bus / dbus session situation.

2. If it is systemd, try installing the missing bits and re-login:

sudo apt-get update
sudo apt-get install -y dbus-user-session
# then log out + log back in (important)

3. Then install the daemon via the wizard:

openclaw onboard --install-daemon

Docs: https://docs.openclaw.ai/platforms/linux

Option B) Use Docker (recommended for “set and forget” VPS)

Do this if you just want it to stay up and you’re okay managing it with docker compose ….

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

Important: Docker won’t fix “no internet access” by itself

That issue is usually:

• web tools not enabled (tools.web.search.enabled)
• tool allowlist blocking (tools.allow missing group:web / web_search / web_fetch)
• Brave key not actually available to the running gateway process

But first let’s get you onto a consistent “service model” (systemd or docker), because right now the gateway/service commands are failing.

If you paste the outputs of:

ps -p 1 -o comm=
systemctl --version

…I’ll tell you immediately which path you’re on and the shortest fix.

[fiery gazelle]

systemctl --version
systemd
systemd 255 (255.4-1ubuntu8.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

[wind summit]

Nice — so systemd is there (Ubuntu systemd 255). That means the earlier error is almost certainly about the systemd user bus not being available in the shell you’re running OpenClaw from (very commonly: running the command under sudo, or missing dbus-user-session, or no XDG_RUNTIME_DIR).

Quick question first (this usually resolves it)

Are you running your OpenClaw / gateway commands with sudo?

If yes: don’t. sudo often drops the env that systemctl --user needs, and you get exactly:

Failed to connect to bus: No medium found

Run these and paste the output

(please run them as the same user you want the gateway to run as — no sudo)

whoami
id -u
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
ls -la /run/user/$(id -u) || true

systemctl --user status >/dev/null && echo "systemctl --user OK" || echo "systemctl --user FAIL"

If systemctl --user still fails

On Ubuntu, the usual fix is:

sudo apt-get update
sudo apt-get install -y dbus-user-session
# then log out of SSH and log back in

If your goal is “gateway runs 24/7 even when you’re logged out”

Enable lingering for your user (safe/reversible):

sudo loginctl enable-linger $(whoami)

Then re-run:

openclaw onboard --install-daemon

Once the user-bus/service piece is working, we’ll tackle the “no internet” message (that’s typically just tools.web.search enabled + Brave key available to the gateway process + tool allowlist).

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ whoami
id -u
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
ls -la /run/user/$(id -u) || true
claw
1000
XDG_RUNTIME_DIR=
total 0
drwx------ 6 claw claw 200 Mar 6 13:06 .
drwxr-xr-x 4 root root 80 Mar 5 22:13 ..
srw-rw-rw- 1 claw claw 0 Mar 5 22:13 bus
drwx------ 3 claw claw 60 Mar 5 22:30 dbus-1
drwx------ 2 claw claw 160 Mar 5 22:13 gnupg
srw-rw-rw- 1 claw claw 0 Mar 5 22:13 pk-debconf-socket
-rw-r--r-- 1 claw claw 0 Mar 6 13:06 .portals-unavailable
drwx------ 2 claw claw 40 Mar 6 13:06 snap.chromium
srw-rw-rw- 1 claw claw 0 Mar 5 22:13 snapd-session-agent.socket
drwxr-xr-x 7 claw claw 180 Mar 5 22:55 systemd
claw@ubuntu-4gb-nbg1-1:~$ systemctl --user status >/dev/null && echo "systemctl --user OK" || echo "systemctl --user FAIL"
Failed to connect to bus: No medium found
systemctl --user FAIL
claw@ubuntu-4gb-nbg1-1:~$

[wind summit]

Perfect, this explains it.

• Your user bus socket exists: /run/user/1000/bus
• But your shell has XDG_RUNTIME_DIR empty, so systemctl --user can’t figure out where the user bus is → No medium found.

Quick fix (in your current SSH session)

Run:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
systemctl --user status >/dev/null && echo "systemctl --user OK" || echo "still FAIL"

If it still fails, add the explicit bus address too:

export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
systemctl --user status

Make it permanent (safe option)

Add this to ~/.profile (or ~/.bashrc) for the claw user:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

Then log out and back in.

(This is a pragmatic workaround. “Correct” is usually PAM/systemd-logind setting it automatically, but editing sshd/PAM can be a footgun on a VPS, so I’d start with the safe workaround.)

After that

Once systemctl --user works, your gateway commands should stop erroring, and we can tackle the “no internet access” (usually just: tools.web.search.enabled + Brave key available to the gateway process + tool allowlist includes group:web).

Try the quick fix and tell me whether systemctl --user becomes OK.

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw gateway restart

🦞 OpenClaw 2026.3.2 (85377a2)
Powered by open source, sustained by spite and good documentation.

Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found

Again I got the exact same error

[wind summit]

Yep — because openclaw gateway restart is still calling systemctl --user … with XDG_RUNTIME_DIR unset, so it hits the same failure.

You need to set the env vars in the same shell (or prefix them on the command) so systemctl --user can find /run/user/1000/bus.

Do this (copy/paste)

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

# sanity check
systemctl --user status >/dev/null && echo "systemctl --user OK" || echo "systemctl --user FAIL"

# now retry
openclaw gateway restart

One-liner version (no exports)

XDG_RUNTIME_DIR="/run/user/$(id -u)" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" \
openclaw gateway restart

If you want it permanent

Add these two lines to ~/.profile for the claw user and log out/in:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus"

After you get openclaw gateway restart working, paste openclaw status --all and we’ll fix the “no internet access” part (that’s usually just web tools enablement + Brave key visibility + tool allowlist).

[fiery gazelle]

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/claw/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/claw/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

• pid 195777 claw: openclaw-gateway (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  ! Tailscale: off · unknown
  error: Error: spawn tailscale ENOENT
  ✓ Skills: 6 eligible · 0 missing · /home/claw/.openclaw/workspace
  ✓ Channel issues (none)

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

[wind summit]

That error is still happening because openclaw gateway restart is calling systemctl --user …, and your current shell still has XDG_RUNTIME_DIR empty (we saw XDG_RUNTIME_DIR= in your earlier output). Until you set it (or make it permanent), anything that goes through systemctl --user will keep failing.

Do it as a one-liner (no exporting required)

Copy/paste this exactly:

XDG_RUNTIME_DIR="/run/user/$(id -u)" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" \
openclaw gateway restart

If you want to confirm the root cause first:

echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
XDG_RUNTIME_DIR="/run/user/$(id -u)" DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" systemctl --user status

Make it stop happening forever (recommended)

Add to ~/.profile (user claw), then log out/in:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

Bonus: restart without systemctl at all (works if gateway is already running)

If you’re chatting with the bot on Telegram, you can send:

• /restart (if enabled), or
• kill -USR1 <gateway-pid> (in-process restart)

But the clean fix is getting systemctl --user working via the env vars above.

Run the one-liner and tell me what it prints.

[fiery gazelle]

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/claw/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/claw/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

• pid 199900 claw: openclaw-gateway (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  ! Tailscale: off · unknown
  error: Error: spawn tailscale ENOENT
  ✓ Skills: 6 eligible · 0 missing · /home/claw/.openclaw/workspace
  ✓ Channel issues (none)

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

Now this is the neew status

[wind summit]

That output is basically saying: your Gateway is already running (PID 199900 on 127.0.0.1:18789), and whatever command produced this report was trying to start another Gateway on the same port — so it refuses. That part is normal.

A couple important clarifications:

1) “Status” vs “Run”

• openclaw gateway = tries to start the gateway
• openclaw gateway status = checks the service + probes the gateway
• openclaw status = overall health summary

So for checking, use:

openclaw status
openclaw gateway status

2) Restarting the gateway you already have running

Right now it looks like the gateway is running as a standalone process, not necessarily as a managed systemd service.

Fastest restart without systemd service management:

• From Telegram: send /restart (if enabled), OR
• On the VPS: kill -USR1 199900 (in-process restart)

If you want “proper” openclaw gateway restart support long-term, run once:

openclaw onboard --install-daemon

(or openclaw gateway install)

3) The Tailscale warning

spawn tailscale ENOENT just means “tailscale isn’t installed”. Ignore unless you plan to use Tailscale.

---

Now: are you still getting “I don’t have internet access” in chat?

If yes, paste these (they won’t leak your key):

openclaw config get tools.allow
openclaw config get tools.web.search.enabled
openclaw config get tools.web.search.provider

That’ll tell us immediately whether it’s (a) tool allowlist blocking group:web or (b) web_search not enabled / wrong provider / key not visible to the gateway process.

[fiery gazelle]

Ok, looks like it's done but how should I connect it to the internet?
I do have tavily and also gave it Brave API, but still it says I don't have access to the internet

[wind summit]

Your VPS is already “on the internet” (it can reach out). What’s missing is: your OpenClaw agent doesn’t currently have the web tools enabled/allowed, so the model falls back to the canned “I don’t have internet access” line.

Also: Tavily is not required for internet access in OpenClaw. The built-in tools are:

• web_fetch (no API key needed)
• web_search (needs a provider + API key, e.g. Brave)

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

Do this setup (recommended)

On the VPS, run:

openclaw configure --section web

• Pick Brave as the provider
• Paste your Brave Search API key (make sure it’s the “Data for Search” plan key, not “Data for AI”)

Then restart the gateway (whatever method you’re using — systemd service, /restart in chat, or a manual restart).

If you have a tool allowlist, you must allow web tools

Check:

openclaw config get tools.allow

If tools.allow is set, it must include either:

• group:web (best), or
• web_search and web_fetch explicitly

Example:

{
  tools: {
    allow: ["group:web"]
  }
}

(If you’re using sandboxing, you may need the same under tools.sandbox.tools.allow too.)

Quick test (no API key needed)

Ask your bot to do something that forces web_fetch, e.g.:

“Use web_fetch to fetch https://example.com and tell me the page title.”

If it still says “no internet”, then web_fetch is not available to the agent (tool policy / allowlist issue).

If you paste the output of these three commands, I can tell you exactly what’s misconfigured:

openclaw config get tools.allow
openclaw config get tools.web.search.enabled
openclaw config get tools.web.search.provider

[fiery gazelle]

◆ Config handling
│ ● Use existing values
│ ○ Update values
│ ○ Reset

For restarting can I just enter reset here? or it will delete everything?

[wind summit]

Don’t hit Reset there if your goal is “restart the gateway”.

That prompt is about how the wizard should handle the existing config values for the section you’re configuring:

• Use existing values = keep what’s already in openclaw.json (no changes)
• Update values = edit/enter new values (this is what you want to add/fix the Brave key)
• Reset = clear/reset the values for that section back to defaults (you’ll likely wipe the web-search key/settings you already entered)

It won’t “delete everything” like an uninstall, but it will remove/reset the web settings you’re trying to set.

So: pick Update values, finish the web config, then restart separately (e.g. /restart in chat, or openclaw gateway restart once your systemctl --user env issue is handled).

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.allow
openclaw config get tools.web.search.enabled
openclaw config get tools.web.search.provider

🦞 OpenClaw 2026.3.2 (85377a2) — Built by lobsters, for humans. Don't question the hierarchy.

Config path not found: tools.allow

🦞 OpenClaw 2026.3.2 (85377a2)
The only crab in your contacts you actually want to hear from. 🦞

true

🦞 OpenClaw 2026.3.2 (85377a2)
I can run local, remote, or purely on vibes—results may vary with DNS.

Config path not found: tools.web.search.provider

This was the output

[wind summit]

Good news: this output actually tells us a lot.

• tools.allow not found → you’re not in a restrictive tool-allowlist mode (so web tools aren’t being blocked globally).
• tools.web.search.enabled → true (so web_search should be available).
• tools.web.search.provider not set → that’s OK; it means OpenClaw will auto-detect the provider based on which API key it can find.

So if it still says “no internet”, it’s almost always one of these:

A) Brave key isn’t actually visible to the running gateway process

Common if the gateway runs as a service and the key only exists in your interactive shell env.

Fix (recommended): explicitly configure Brave in config:

openclaw configure --section web

Choose Update values, set provider to Brave, paste the key.

Then restart the gateway (easiest: send /restart in Telegram).

B) The model is not using tools (so it falls back to the canned “no internet” line)

This happens with some models/providers that don’t reliably tool-call.

To confirm whether the tool is being called (and what error it returns), do this:

1. In one SSH window:

openclaw logs --follow

2. In Telegram, ask:

“Use web_search to search for ‘OpenClaw web_search tool’ and show 3 results.”

Then paste the log lines around the web_search attempt (it’ll show “missing key”, “401/403”, etc., if that’s the issue).

One more quick check

Can you run:

openclaw config get tools.web.search

If it prints your API key, don’t paste it—just paste the output with the key value replaced by REDACTED.

That will tell us whether the key is stored under the right config path.

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.web.search

🦞 OpenClaw 2026.3.2 (85377a2) — We ship features faster than Apple ships calculator updates.

{
"enabled": true,
"apiKey": "OPENCLAW_REDACTED"
}

[wind summit]

Awesome — that means OpenClaw does see a web search key in the right place:

tools.web.search = { enabled: true, apiKey: … }

So at this point it’s not a “config path / missing key” problem.

Next step: determine what is failing

There are only two realistic possibilities now:

1) The model is not calling the tool

Some models will still respond with the generic “I don’t have internet access” line unless they actually invoke web_search.

Test (in Telegram): send a very explicit request like:

“Use the web_search tool to search for site:docs.openclaw.ai web_search and show 3 results with URLs.”

If it still says “no internet”, we need to see whether a web_search tool call happened.

2) The tool is being called, but Brave is returning an error (401/403/etc.)

This can happen if the Brave key is wrong, expired, or from the wrong Brave API product/plan.

Do this log check (fastest way to see the truth)

1. On the VPS, run:

openclaw logs --follow

2. While that’s running, send the explicit “Use web_search …” message in Telegram.

3. Copy/paste the log lines around the attempt (they’ll show whether web_search was invoked and any HTTP error code).

If you paste that snippet, I can tell you immediately whether we need to:

• switch to a more tool-reliable model (common), or

• fix the Brave key/plan (also common — Brave docs call out using the Data for Search plan).

[fiery gazelle]

15:55:15 error Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found
15:55:24 error Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found
15:55:25 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=feb85a21-d0a1-4f4f-8e6c-4df260965fe7 remote=127.0.0.1 client=openclaw-control-ui webchat vdev reason=rate_limited
15:55:25 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":441,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"6e325ee8-5fd4-4a95-ab21-

15:55:15 error Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found
15:55:24 error Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found
15:55:25 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized conn=feb85a21-d0a1-4f4f-8e6c-4df260965fe7 remote=127.0.0.1 client=openclaw-control-ui webchat vdev reason=rate_limited
15:55:25 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"unauthorized","handshake":"failed","durationMs":441,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"6e325ee8-5fd4-4a95-ab21-81436522dc10","host":"localhost:18789","origin":"http://localhost:18789","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","authMode":"token","authProvided":"token","authReason":"rate_limited","allowTailscale":false,"client":"openclaw-control-ui","mode":"webchat","version":"dev"} closed before connect conn=feb85a21-d0a1-4f4f-8e6c-4df260965fe7 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 code=4008 reason=connect failed
Log tail truncated (increase --max-bytes).

[wind summit]

Those log lines aren’t showing a web_search attempt yet — they’re showing two other things:

1. CLI service check still failing
   Gateway service check failed … No medium found = you’re still running some openclaw gateway … commands without the XDG_RUNTIME_DIR fix in that shell. (Annoying, but not the web issue.)

2. Control UI auth is failing + getting rate-limited
   unauthorized … client=openclaw-control-ui … reason=rate_limited means the Dashboard/WebChat is trying to connect with the wrong token/password repeatedly, so the gateway rate-limits it. This is separate from “internet access”, but you’ll want to fix it.

For the “internet access” problem: we need the logs at the moment you try web_search

Do this:

1. On the VPS:

openclaw logs --follow --json | grep -E 'web_search|web_fetch|brave|tavily'

2. In Telegram, send something that forces it:

“Use web_search to search for OpenClaw web_search tool and show 3 results with URLs.”

3. Paste what appears in the VPS log window right after that (it should show either a web_search call + HTTP status, or nothing at all).

• If nothing shows up → your model isn’t tool-calling (common), and we’ll fix it by switching to a tool-reliable model (check /model status).
• If it shows 401/403 → Brave key/plan issue (very common).
• If it shows a network error → outbound egress/DNS issue (rare on Hetzner, but possible).

For the Control UI “unauthorized / rate_limited”

Once we’re done with web_search, fix it by making sure the dashboard is using the correct gateway token (Control UI settings → token). Easiest path is usually running openclaw dashboard to get the right URL/connection info.

Send the grep-filtered log output from the web_search test and we’ll finish this quickly.

Those logs you pasted are not showing a web_search failure yet — they show your Control UI/WebChat can’t authenticate and is now being rate-limited:

• client=openclaw-control-ui … unauthorized … reason=rate_limited
• code=4008 reason=connect failed

That usually happens when the browser keeps trying to connect with the wrong gateway token (or an empty one) a bunch of times.

Fix the Control UI auth first (don’t paste the token here)

1. On the VPS, get the gateway token (keep it private):

openclaw config get gateway.auth.token

2. In the Control UI (the page you opened at http://localhost:18789), go to Settings / Gateway Access and paste that token exactly.

3. Wait ~1–2 minutes (rate limit cooldown), then reload the page and try again.

Tip: openclaw dashboard --no-open can also help you confirm you’re pointing at the right gateway:
https://docs.openclaw.ai/cli/dashboard

About “no internet access”

Your config shows web search is enabled and has an API key:

{ "enabled": true, "apiKey": "__OPENCLAW_REDACTED__" }

So the next step is to test it from the chat where you see the “no internet” message:

• Are you seeing that message in Telegram, or only in WebChat?

If it’s in Telegram: run openclaw logs --follow on the VPS, then send a Telegram message like:

“Use web_search to search for ‘OpenClaw web_search tool’ and return 3 links.”

…and paste the new log lines that mention web_search / brave (those will show the real error, if any).

If you tell me whether it’s Telegram vs WebChat, I’ll give you the exact minimal test to run next.

[fiery gazelle]

{"type":"log","time":"2026-03-07T20:02:47.146+00:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 3ms errorCode=INVALID_REQUEST errorMessage=No session found with label: tavily conn=a4649244…762d id=33536f3a…2612","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✗ sessions.resolve 3ms errorCode=INVALID_REQUEST errorMessage=No session found with label: tavily conn=a4649244…762d id=33536f3a…2612","_meta":{"runtime":"node","runtimeVersion":"22.22.1","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-03-07T20:02:47.144Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/claw/.npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-07T20:02:47.146+00:00"}"}

This is the error

[wind summit]

That log line is not a “no internet” / Brave / Tavily API error.

It’s the gateway saying:

sessions.resolve … No session found with label: tavily

Meaning: something (usually the Control UI / WebChat, or a /focus tavily-style command) is trying to switch/focus to a session named tavily, but no such session label exists.

What to do

• Don’t try to “focus” or “connect” to Tavily as a session. Tavily is a skill/tool, not a session.

• To use web, just ask the assistant to use the web tool directly, e.g. in your chat:

  Test message:

  “Use web_search to search for OpenClaw web_search tool and return 3 links.”

Quick question (so I can tell you the exact fix)

Where did you type tavily?

• In the WebChat UI (some “session” / “focus” field)?
• Or did you send a command like /focus tavily (or similar)?

If you paste the exact message you sent to the bot right before this log line (and whether it’s Telegram or WebChat), I can tell you what command/UI action is generating sessions.resolve and how to use Tavily/web_search correctly.

[fiery gazelle]

I didn't search tavily anywhere, I just asked my bot to search for something for me but it just answered back with this error

I have just connected tavily web search tool skill before

[wind summit]

That error means WebChat/Control UI is trying to route your message to a session label named tavily, and the gateway can’t find any session with that label:

sessions.resolve … No session found with label: tavily

So it’s not a “Brave key” / “no internet” problem yet — it’s a session targeting/focus problem. (Usually the UI has some saved “focus target” from earlier and keeps trying to use it.)

Fix (fast)

In the chat where you’re seeing this (very likely WebChat), send these as standalone messages:

1. Unfocus (clear any session binding):

/unfocus

2. Start a fresh session:

/new

Then try your search again, explicitly:

“Use web_search to search for …”

If /unfocus doesn’t work (UI reset)

Open the Control UI/WebChat in an incognito/private window (or clear site data for http://localhost:18789). That wipes the UI’s stored “focus/session target” state.

Quick confirm

Are you seeing this error in WebChat (browser) or in Telegram?
(Seeing a sessions.resolve label error almost always points to WebChat/session focus state.)

Got it — that does explain the weird No session found with label: tavily.

What happened is: when you “connected Tavily” before, you likely ended up with WebChat/Control UI focused/bound to a target named tavily (a session label). Now that session doesn’t exist anymore (expired/reset/restarted), so WebChat keeps trying to route messages to tavily and the gateway refuses.

Fix: stop focusing on the tavily session label

In WebChat send:

/unfocus
/new

That clears the stale binding and gives you a normal session again.

Then: use Tavily (or just use built-in web_search)

Installing/connecting a skill does not require a dedicated session. You just run it from the normal chat.

To see how the skill is exposed on your setup, in WebChat run:

/commands

If Tavily registered a command, you’ll see it there. Otherwise you can use:

/skill <name> <your query>

(Where <name> is whatever the Tavily skill is called in /commands.)

Also: since you already have tools.web.search configured (Brave key present), the simplest path is to just ask:

“Use web_search to search for …”

If you paste the output of /commands, I can tell you exactly what to type to invoke the Tavily skill on your install.

[fiery gazelle]

⚠️ /unfocus is only available on Discord.

How can I uninstall skill

[wind summit]

Yep — that message is correct: /unfocus only exists for Discord thread bindings. (It won’t work in WebChat/Telegram/etc.)

For your case (WebChat / Control UI trying to use tavily as a session label), do this instead:

Fix the “No session found with label: tavily” in WebChat / Control UI

Option A (fastest): clear the Control UI saved state

Open the Control UI in an Incognito/Private window and reconnect.

That resets whatever the UI has saved (including any stale “target session label” like tavily).

Option B: clear site data for localhost

In Chrome:

• Settings → Privacy & security → Site settings → View permissions and data stored across sites
• Search for localhost / 127.0.0.1
• Clear data

Then reload the Control UI and connect again.

Then: run web search normally

You don’t need a “tavily session” to search. Just ask in chat:

“Use web_search to search for … and give me links.”

(Your tools.web.search.apiKey is configured correctly already.)

If you still get blocked after clearing the UI state, paste the exact assistant reply text you see in WebChat after you ask for a web_search—at that point we’ll be past the session-label issue and can debug the actual search call.

You’ve got two ways to “remove” a skill:

Option A (recommended): disable it (no deleting)

Add a disable entry in your config, then start a new session so the skills snapshot refreshes.

1. Disable (replace tavily with the skill name as shown in /commands):

openclaw config set 'skills.entries.tavily.enabled' false

2. In the chat where you use the bot, send:

/new

(Important: skills are snapshotted when a session starts; changes won’t reliably apply mid-session.)

Option B: uninstall (delete the skill folder)

Skills live in one of these locations (highest precedence first):

• <workspace>/skills (usually ~/.openclaw/workspace/skills)
• ~/.openclaw/skills
• bundled (can’t uninstall; only disable)

Check where it is:

ls -la ~/.openclaw/workspace/skills 2>/dev/null || true
ls -la ~/.openclaw/skills 2>/dev/null || true

If you see a folder for the skill (e.g. tavily), remove it (or safer: move it aside first):

mv ~/.openclaw/workspace/skills/tavily ~/.openclaw/workspace/skills/tavily.DISABLED
# or: rm -rf ~/.openclaw/workspace/skills/tavily

Then /new in chat.

If you paste the output of those two ls commands, I can tell you exactly which path your Tavily skill is installed in.

[fiery gazelle]

Ok leave tavily, it's removed now I guess. What should I do to get connected to the internet?

[wind summit]

You don’t “connect OpenClaw to the internet” like a plugin — the gateway already has outbound internet. What you’re doing is enabling and using the web tools:

• web_fetch (no API key)
• web_search (uses your Brave key)

You already have tools.web.search.enabled: true and an apiKey configured, so next is just: verify the tools are actually being used in-chat.

Step 1: start a fresh session (so tool/skills snapshot refreshes)

In the chat you’re using (Telegram or WebChat), send:

/new

Step 2: test “internet” with web_fetch (no API key involved)

Ask:

“Use web_fetch to fetch https://example.com and tell me the page title.”

• If this works → the gateway has internet access.
• If it fails → we’ll check DNS/outbound with a simple curl test.

Step 3: test web_search explicitly

Ask:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If it still answers “I don’t have internet access”, then your current model is not tool-calling (it’s ignoring tools and giving the canned response). In that case, run:

/model status

…and paste what it says you’re using (no secrets). Some models are just much worse at actually invoking tools.

Optional: force Brave as provider (removes auto-detect ambiguity)

On the VPS:

openclaw config set tools.web.search.provider brave

Then restart (fastest is in chat):

/restart

Try the web_search test again.

Tell me which of the two tests fails (web_fetch vs web_search), and what the bot replies with, and we’ll zero in fast.

[fiery gazelle]

Current: minimax/MiniMax-M2.5
Default: minimax/MiniMax-M2.5
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: minimax:default=sk-api-u...atqBseco (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• minimax/MiniMax-M2.5 (Minimax)

Still not showing up on my end! My available tools are still just the same 5 I listed before.

Can you run openclaw status and share what tools it shows? That'll help me figure out what's available vs. what's loading.

These are my bot answers

[wind summit]

That /model status output is the missing clue: your bot is running on MiniMax, and in your current setup the bot only “sees” a small tool set (your “same 5 tools”).

That almost always happens when you have a tool profile enabled (most commonly tools.profile: "messaging"), which intentionally limits the tool catalog to a tiny set.

1) Check what tool profile you’re on

On the VPS:

openclaw config get tools.profile
openclaw config get agents.defaults.tools.profile

If either of those is messaging (or minimal), that explains why web_search / web_fetch never show up.

2) Fix: add web tools (small change), or remove the profile

Option A (recommended): keep your current profile, just add web tools

openclaw config set tools.allow '["group:web"]'

Option B: remove the restriction entirely

openclaw config unset tools.profile

(You can always re-add restrictions later.)

3) Refresh the session

In the chat where you’re testing (Telegram/WebChat/Discord), send:

/new

Then ask explicitly:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If you paste the output of openclaw config get tools.profile, I can tell you which option is the cleanest for your current config.

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.profile

🦞 OpenClaw 2026.3.2 (85377a2) — I read logs so you can keep pretending you don't have to.

messaging

[wind summit]

There we go — tools.profile: messaging is exactly why you only ever saw the small “messaging tools” set.

To add internet tools without opening the floodgates, just extend that profile with the web group:

1) Add web tools

On the VPS:

openclaw config set tools.allow '["group:web"]'

(This adds web_search + web_fetch on top of the existing messaging profile.)

2) Refresh your chat session (important)

In the chat where you’re talking to the bot, send:

/new

3) Test

Ask:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If it still refuses, paste /model status again — but 90% of the time this was the missing piece.

[fiery gazelle]

first I ran this:
claw@ubuntu-4gb-nbg1-1:~$ openclaw config set tools.allow '["group:web"]'

🦞 OpenClaw 2026.3.2 (85377a2)
Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

Config overwrite: /home/claw/.openclaw/openclaw.json (sha256 ffd906c61b36f3e5b143d5a55e33c490c7e5a1958782ee23a0a9d0ffc5090ed3 -> cc86787c48a8dd09c95505bb7a84a38885134c4413e86a630bea3f928ce6cc5f, backup=/home/claw/.openclaw/openclaw.json.bak)
Updated tools.allow. Restart the gateway to apply.

Then I restarted the gateway using :
claw@ubuntu-4gb-nbg1-1:~$ openclaw onboard --install-daemon

But again on the tools I can only see messaging

[wind summit]

openclaw onboard --install-daemon isn’t the “restart the gateway” step here — it’s the onboarding wizard + (optionally) a daemon install. It may not restart the already-running gateway the way you expect, and it can also rewrite config depending on what you choose in the wizard.

Let’s make this deterministic:

1) First confirm your config change stuck

On the VPS run:

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

You should see:

• tools.profile = messaging
• tools.allow contains group:web

If tools.allow is missing again, the wizard likely overwrote it — just re-run the config set after the wizard.

2) Restart the gateway for real

Do one of these:

Option A (best): from chat

In the chat where you talk to the bot, send:

/restart

Option B: from SSH (daemon/service)

openclaw gateway restart

(If you still hit the systemctl --user … No medium found thing, you’ll need the XDG_RUNTIME_DIR export workaround again.)

3) Start a new chat session (tool list is snapshotted)

Even after a gateway restart, the tool list is often cached per-session. In the chat, send:

/new

Then try:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If you paste the outputs of openclaw config get tools.allow + openclaw config get tools.profile, I can tell you immediately whether the config is correct or being overwritten.

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.profile

🦞 OpenClaw 2026.3.2 (85377a2) — Claws out, commit in—let's ship something mildly responsible.

messaging
claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.allow

🦞 OpenClaw 2026.3.2 (85377a2) — Self-hosted, self-updating, self-aware (just kidding... unless?).

[
"group:web"
]

I don't have a dedicated web_search tool built in. Let me try to find that info for you using what's available.

Let me try searching via command line:
<tool_code>
exec
args:
command: "curl -s "https://duckduckgo.com/?q=OpenClaw+web_search+tool&format=json\" | head -c 2000"
</tool_code>

This is my bot response

[wind summit]

Great — your config is exactly what you pasted:

• tools.profile = messaging
• tools.allow = ["group:web"]

One important nuance: tools.allow is an allowlist, not an “add-on”. So if you restart the gateway with it set to only group:web, you can accidentally end up with only web tools allowed (and lose the messaging/session tools), depending on how the profile+allowlist intersect.

To get messaging + sessions + web reliably, set tools.allow to include all three groups explicitly.

Do this (recommended allowlist)

On the VPS:

openclaw config set tools.allow '["group:messaging","group:sessions","group:web"]'

Now you’ll have:

• messaging (message)
• session tools (sessions_list, session_status, etc.)
• web tools (web_search, web_fetch)

Then apply it

1. Restart the gateway (easiest is in chat):

/restart

2. Start a fresh session (so the tool snapshot refreshes):

/new

3. Test:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If after that you still don’t see web_search in the tool list, tell me which surface you’re checking (Control UI Tools panel vs Telegram vs Discord), because the Control UI can cache state and needs a hard refresh/incognito sometimes.

That bot reply is actually a strong signal that your gateway/session hasn’t picked up the new tool policy yet.

web_search is built in (core tool) — but tools only “exist” for the model if the gateway includes them in the tool schema for that session. Right now your model isn’t seeing it, so it’s falling back to exec + curl.

Do this in order

1) Fix the allowlist to include messaging + sessions + web (so nothing gets filtered out)

On the VPS:

openclaw config set tools.allow '["group:messaging","group:sessions","group:web"]'

(Your current tools.allow=["group:web"] can end up hiding other stuff depending on how policy is applied.)

2) Restart the running gateway process (for real)

If openclaw gateway restart previously failed for you, use the env-prefixed version:

XDG_RUNTIME_DIR="/run/user/$(id -u)" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" \
openclaw gateway restart

3) Start a new chat session (tool list is snapshotted)

In the chat where you’re testing, send:

/new

4) Re-test

Ask:

“Use web_search to search for OpenClaw web_search tool and return 3 links.”

If after the restart + /new it still claims web_search doesn’t exist, paste:

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

(That last one will catch provider-specific tool restrictions, if any.)

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw config get tools.allow
openclaw config get tools.profile
openclaw config get tools.byProvider

🦞 OpenClaw 2026.3.2 (85377a2) — iMessage green bubble energy, but for everyone.

[
"group:messaging",
"group:sessions",
"group:web"
]

🦞 OpenClaw 2026.3.2 (85377a2) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

messaging

🦞 OpenClaw 2026.3.2 (85377a2) — I don't judge, but your missing API keys are absolutely judging you.

Config path not found: tools.byProvider

Bot still not connected to the internet

[wind summit]

Your tool policy config is now correct:

• tools.profile: messaging
• tools.allow: ["group:messaging","group:sessions","group:web"]
• no tools.byProvider

So if the bot is still saying “no internet / no web_search tool”, we’re down to one of two things:

1. the running gateway + your current chat session haven’t picked up the change yet, or
2. the current model (MiniMax) isn’t actually tool-calling (it will often “pretend” with <tool_code> instead of invoking real tools).

Let’s prove which one it is.

Step 1: restart + new session (fastest way to refresh tool schema)

In chat send:

/restart

then:

/new

Step 2: run a “no API key needed” test (web_fetch)

Ask the bot:

“Use web_fetch to fetch https://example.com and tell me the page title.”

What to look for

• If it actually fetches the page → tools are working; then web_search should work too.
• If it replies with more <tool_code> / “I don’t have web_fetch/web_search” → your model is not invoking tools.

Step 3 (if it’s not invoking tools): switch models just to test

Right now you’re on minimax/MiniMax-M2.5. For debugging, temporarily switch to a model that’s known to be tool-reliable in OpenClaw:

Run in chat:

/model

pick a different provider/model, then retry the web_fetch test.

If that suddenly works, your config is fine — it’s the MiniMax tool-calling behavior.

If you paste the bot’s reply to the web_fetch https://example.com test (and whether you saw any real tool output vs <tool_code>), I can tell you immediately which branch you’re on.

[fiery gazelle]

<tool_code>
exec
args:
command: "curl -s https://example.com/ | grep -o '<title>.*</title>' | sed 's/<title>//;s/</title>//'"
</tool_code>

[wind summit]

That reply (<tool_code> … exec … curl …) is the model suggesting a command — it’s not actually using the real OpenClaw tools (web_fetch / web_search). When tool-calling is working, you won’t see it “roleplay” like this; you’ll get actual search/fetch results.

So we need to answer one question: does the gateway think web_search / web_fetch are available at runtime?

1) Check the gateway’s actual tool catalog (ground truth)

On the VPS run:

openclaw gateway call tools.catalog --json | grep -E '"name":"web_(search|fetch)"' || true

• If you see web_search / web_fetch there → tools exist, but your current model isn’t invoking them.
• If you don’t see them → something is still filtering them out (despite the config looking right).

2) If the tools exist but the model won’t invoke them

You’re currently on minimax/MiniMax-M2.5. In practice, some models/providers are flaky with tool-calling and will do exactly what you’re seeing (they “write tool code” instead of actually calling tools).

Quick test: temporarily switch to another model via:

/model

pick a different one, then ask:

“Use web_fetch to fetch https://example.com and tell me the title.”

If that works on the other model, your config is fine — it’s a MiniMax tool-calling behavior issue.

If you paste the output of the tools.catalog grep above, we’ll know which branch you’re in immediately.

[fiery gazelle]

Nothing returned

[wind summit]

That specific command should return Example Domain on a normal Ubuntu box. So “nothing returned” strongly suggests the command never actually ran — your model is just printing a <tool_code> block, not invoking real tools.

Two quick checks to separate “internet/DNS problem” from “tool-calling problem”:

1) Does the VPS itself have internet?

Run this directly in SSH (not via the bot):

curl -s https://example.com | grep -oP '(?<=<title>).*?(?=</title>)'

Expected output:

Example Domain

• If this prints Example Domain → your VPS is fine; the issue is the model/tool-calling, not internet.

• If it prints nothing → we troubleshoot outbound/DNS next.

2) Is your model actually invoking tools?

Right now you’re on minimax/MiniMax-M2.5, and what you’re seeing (<tool_code> exec …) is a classic symptom of a model/provider that’s not doing native tool calls (it “roleplays” them as text).

Try switching models just as a test:

/model

Pick a different provider/model (one that’s known to tool-call well in OpenClaw), then retry:

“Use web_fetch to fetch https://example.com and tell me the title.”

If that works after switching models, your config is correct — it’s the MiniMax tool-calling behavior that’s blocking “internet”.

If you paste the output of the direct curl test above, I’ll tell you immediately which branch you’re in.

[fiery gazelle]

I changed the minimax model but still I have problem and this is the answer I get when I talk about web search

<tool_code>
exec
args:
command: "curl -s "https://api.allorigins.win/raw?url=https://www.google.com/search?q=OpenClaw+AI+assistant\" 2>&1 | head -c 500"
</tool_code>

[wind summit]

That <tool_code> … exec … curl … reply is the smoking gun: your model is still not actually invoking OpenClaw tools, it’s “role‑playing” a tool call as text.

Two things to do that will tell us exactly what’s going on:

1) Turn off verbose/debug tool echo (so we don’t just see the “plan”)

In the chat where you’re testing, send:

/verbose off
/reasoning off

Then try:

“Use web_search to find ‘OpenClaw web_search tool’ and show 3 links.”

2) Check what tools the model is actually being offered

In that same chat, run:

/context detail

and paste just the part that lists the tools (it’ll show whether web_search / web_fetch are present in the injected toolset).

How to interpret the result

• If /context detail does not list web_search/web_fetch → the gateway is still not offering web tools to that session (restart + /new, or tool policy still not applied where you think).
• If it does list them, but the model still outputs <tool_code> instead of calling them → that’s a model/provider tool-calling compatibility issue. In that case, the fix is to switch to a tool-reliable model/provider for web/tool work (even if you keep MiniMax for cheap chat).

Also: scraping Google HTML via curl is a dead end (CAPTCHAs/blocks). If web tools are working, the bot should be using web_search (Brave/Perplexity/etc.), not curl.

Paste the /context detail tools section and we’ll land this.

[fiery gazelle]

🧠 Context breakdown (detailed)
Workspace: /home/claw/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 24,522 chars (~6,131 tok) (Project Context 13,582 chars (~3,396 tok))
Injected workspace files:

• AGENTS.md: OK | raw 7,804 chars (~1,951 tok) | injected 7,804 chars (~1,951 tok)
• SOUL.md: OK | raw 1,664 chars (~416 tok) | injected 1,664 chars (~416 tok)
• TOOLS.md: OK | raw 850 chars (~213 tok) | injected 850 chars (~213 tok)
• IDENTITY.md: OK | raw 633 chars (~159 tok) | injected 633 chars (~159 tok)
• USER.md: OK | raw 474 chars (~119 tok) | injected 474 chars (~119 tok)
• HEARTBEAT.md: OK | raw 167 chars (~42 tok) | injected 167 chars (~42 tok)
• BOOTSTRAP.md: OK | raw 1,449 chars (~363 tok) | injected 1,449 chars (~363 tok)
Skills list (system prompt text): 2,482 chars (~621 tok) (5 skills)
Skills: healthcheck, skill-creator, tmux, weather, self-improvement
Top skills (prompt entry size):
• self-improvement: 643 chars (~161 tok)
• healthcheck: 491 chars (~123 tok)
• weather: 416 chars (~104 tok)
• skill-creator: 296 chars (~74 tok)
• tmux: 255 chars (~64 tok)
Tool list (system prompt text): 429 chars (~108 tok)
Tool schemas (JSON): 4,976 chars (~1,244 tok) (counts toward context; not shown as text)
Tools: message, sessions_list, sessions_history, sessions_send, session_status
Top tools (schema size):
• message: 4,241 chars (~1,061 tok)
• sessions_send: 273 chars (~69 tok)
• sessions_list: 212 chars (~53 tok)
• sessions_history: 161 chars (~41 tok)
• session_status: 89 chars (~23 tok)
Top tools (summary text size):
• session_status: 207 chars (~52 tok)

• message: 125 chars (~32 tok)
• sessions_send: 84 chars (~21 tok)
• sessions_list: 54 chars (~14 tok)
• sessions_history: 36 chars (~9 tok)
Tools (param count):
• message: 86 params
• sessions_send: 5 params
• sessions_list: 4 params
• sessions_history: 3 params
• session_status: 2 params
Session tokens (cached): 9,731 total / ctx=200000
Inline shortcut: a command token inside normal text (e.g. “hey /status”) that runs immediately (allowlisted senders only) and is stripped before the model sees the remaining message.

[wind summit]

Perfect — that /context detail output answers the whole thing:

Your bot is not being offered web_search / web_fetch at all.

It’s only getting:

message, sessions_list, sessions_history, sessions_send, session_status

So the model literally cannot do web search right now, regardless of API keys.

Why this happens

Your openclaw.json has the right tools.allow, but the running gateway + current session haven’t picked it up yet. Tool lists are snapshotted into the session/tool schema.

Fix (do these two steps)

1) Restart the running gateway process (the one handling your chats)

Do this from chat (recommended, doesn’t rely on systemd):

/restart

If /restart is disabled on your setup, restart from SSH:

XDG_RUNTIME_DIR="/run/user/$(id -u)" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" \
openclaw gateway restart

2) Start a fresh session so the new tool schema is injected

In your chat:

/new

Confirm

Run /context detail again. You should now see web_search + web_fetch in the Tools list.

If you still don’t see them after restart + /new, then your chat is hitting a different gateway/config than the one you edited — and the next thing to paste is:

openclaw gateway status

(That shows which config the service is actually using.)

That snippet is still showing the same 5 tools (message + sessions*). So the web tools still aren’t being injected — nothing has changed yet from the model’s point of view.

What I need you to do (in this exact order)

1. Restart the running gateway
   In chat, try:

/restart

• If it says /restart is disabled / not allowed, restart from SSH instead:

XDG_RUNTIME_DIR="/run/user/$(id -u)" \
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus" \
openclaw gateway restart

2. Start a fresh session (tool schema is snapshotted per session)
   In chat:

/new

3. Run:

/context detail

…and this time paste the single line that starts with:

Tools: ...

(or the “Tools:” section that lists the tool names). That’s the part that will confirm whether web_search / web_fetch finally show up.

If /restart doesn’t work, tell me what it replies with and we’ll pick the right restart method for how your gateway is running (daemon vs manual).

[fiery gazelle]

claw@ubuntu-4gb-nbg1-1:~$ openclaw gateway status

🦞 OpenClaw 2026.3.2 (85377a2) — The only open-source project where the mascot could eat the competition.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /home/claw/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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

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

Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: No medium found)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

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

This is the gateway status

[wind summit]

This gateway status explains why nothing you change is showing up:

• Service: systemd (disabled) → you’re not running the gateway as a managed service.
• RPC probe: ok → the gateway is running, but
• systemctl --user unavailable: No medium found → the CLI can’t control/restart it via systemd in your current SSH environment.

So your openclaw.json edits are landing on disk, but the running gateway process isn’t being restarted/reloaded in a way that refreshes the tool schema for your sessions.

Fastest way to apply the new tool config (no systemd needed)

Because RPC is OK, do this from chat:

1. In your chat with the bot:

/restart

2. Then:

/new

3. Then rerun:

/context detail

You should see web_search + web_fetch in the Tools list.

If /restart doesn’t work: restart the gateway from SSH (manual)

Run the gateway CLI with --force (this kills the existing listener on 18789 and starts a fresh one reading your updated config):

openclaw gateway --force --port 18789

(Do this inside tmux so it keeps running when you disconnect.)

Fix the root cause (so openclaw gateway restart works)

Your systemctl --user is failing because your SSH session is missing the user-bus env. Add this to ~/.profile for user claw, then log out/in:

export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"

After that, you can enable/manage the daemon normally.

If you try /restart now, what does it reply with?

[fiery gazelle]

You are in a loop and it's not working. You repeated the same thing a few times

[wind summit]

You’re right — we’ve been going in circles. The reason is now clear from your gateway status + /context detail:

• Your config is correct on disk, but…
• The running gateway process isn’t being restarted/reloaded, because it’s not running as a systemd service (service disabled) and your environment makes systemctl --user unusable.
• So the bot keeps seeing the old tool schema (messaging-only), no matter what we change.

Let’s do one clean, deterministic fix that doesn’t depend on systemd:

One-shot fix: hard-restart the gateway in tmux (applies config immediately)

On the VPS over SSH:

tmux new -s openclaw
openclaw gateway --force --port 18789

• --force will kill the existing listener on 18789 and start a fresh gateway that reads ~/.openclaw/openclaw.json.

• Leave it running in tmux. Detach with: Ctrl-b, then d.

Then refresh the chat session (so tools are re-injected)

In your chat with the bot:

/new
/context detail

Now the “Tools:” line should include web_search and web_fetch.

If it still doesn’t, paste just the “Tools:” line again — at that point it’s no longer a restart issue and we’ll look for an override (per-agent tool policy, profile mismatch, etc.).

[fiery gazelle]

Tool list (system prompt text): 429 chars (~108 tok)
Tool schemas (JSON): 4,976 chars (~1,244 tok) (counts toward context; not shown as text)
Tools: message, sessions_list, sessions_history, sessions_send, session_status

[wind summit]

Good — this is finally a clear signal.

Even after the restart, your session still shows:

Tools: message, sessions_list, sessions_history, sessions_send, session_status

That means the effective tool set is still the messaging tool profile.

Here’s the key point (and why we were stuck):

tools.allow cannot “add” tools that aren’t in the active tool profile

Tool policy is applied in this order:

base profile → (optional provider profile) → allow/deny

So if tools.profile = "messaging", you cannot expand beyond those messaging tools. Your group:web entry is being ignored because the base profile already filtered web tools out.

Fix: remove the messaging profile (keep your allowlist)

On the VPS:

openclaw config unset tools.profile

(Or equivalently: openclaw config set tools.profile full)

Keep your allowlist as-is:
["group:messaging","group:sessions","group:web"]

Apply it

Restart the gateway (same way as before), then in chat: