#How do i make my openclaw bot do stuff on itself even when i dotn ask it aslong openclaw gateway

1 messages · Page 1 of 1 (latest)

raw lodgeBOT
#

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

crisp sleetBOT
#

OpenClaw won’t “think” continuously on its own — it only runs when something triggers it. The built-in ways to get “do stuff even when I didn’t ask right now” are:

1) Heartbeat (periodic check-ins)

Best for: “every 30 min check X and only message me if something matters”.

  • Put a checklist in HEARTBEAT.md (in your agent workspace)
  • Enable heartbeat delivery (otherwise it runs but won’t post anywhere)

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

2) Cron jobs (scheduled / recurring tasks)

Best for: “post something every day at 9am” / “run this every Monday” / “remind me in 20 minutes”.

Example (Discord channel post every day):

#

If you tell me what you mean by “do stuff” (post messages? daily summary? monitor something?) and where you want it to send the result (DM vs this channel), I can point you to the cleanest setup (heartbeat vs cron, main vs isolated).

royal portal
#

@crisp sleet ive been in a eternal conflict abt smth new my openclaw bot dont have exec bash and it keeps saying it doesnt and im so stressed out

crisp sleetBOT
#

That stress is understandable — but this one is usually not a “broken install”, it’s just tool policy.

In OpenClaw, exec / bash / process are in the runtime tool group (group:runtime). If your config is on a restrictive tool profile (like minimal or messaging), or you’re denying runtime tools, the agent will keep saying it “doesn’t have exec/bash”.

1) Quick checks (paste the output here)

openclaw --version
openclaw config get tools
openclaw config get agents.defaults.tools
openclaw config get agents.list

2) Quick fix (enable runtime tools)

Safest “normal” profile that includes exec/bash is coding:

#
openclaw config set tools.profile coding
openclaw gateway restart

(Or set it in openclaw.json as tools: { profile: "coding" } and restart.)

3) Common “why it was disabled”

Look for any of these in your config:

  • tools.profile: "minimal" or "messaging"
  • tools.deny containing "group:runtime" (or "exec" / "bash")
  • agent-specific overrides under agents.list[...].tools

Docs reference (shows the groups + profiles): https://docs.openclaw.ai/tools

If you paste the exact error message it prints when it says it “doesn’t have exec/bash”, I can tell you which knob is blocking it.

royal portal
#

Nothing fucking works ive been at this for hours ive tried every profile known to man every command NOTHING

crisp sleetBOT
#

Yep — when you’ve “tried every profile” and it still claims exec/bash don’t exist, 90% of the time it’s because you’re changing a different config than the Gateway service is actually running (profile mismatch / remote host mismatch). So none of your edits ever reach the running bot.

Let’s make it deterministic with one command:

openclaw gateway status

Paste that output here. I’m specifically looking for the lines that show Config (cli) vs Config (service).

If those two config paths are different

That’s the bug: you’re editing config A, but the daemon is running config B.

Fix (from the same profile/env you actually want the service to use):

#
openclaw gateway install --force
openclaw gateway restart

Then set your tool profile again (e.g. tools.profile = "coding").

Also: are you in remote mode?

If your Gateway is on a VPS, you must run these commands on the VPS (the gateway host owns the config + tool policy). Local edits won’t affect it.

Send the openclaw gateway status output and I’ll tell you exactly which of these it is.

royal portal
#

┌──(kali㉿kali)-[~]
└─$ openclaw gateway status

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

│
â—‡
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-03.log
Command: /usr/bin/node /home/kali/.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: running (pid 708, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

┌──(kali㉿kali)-[~]
└─$

crisp sleetBOT
#

Perfect — that gateway status output is actually good news:

  • Gateway is healthy (RPC probe: ok)
  • Service + CLI are using the same config file (~/.openclaw/openclaw.json)
    So you’re not “editing the wrong file”.

At this point the “no exec/bash tool” symptom is almost always one of these:

A) You’re sandboxing Discord channel sessions (common!)

If agents.defaults.sandbox.mode is non-main or all, then Discord channels/threads are non-main, and they can end up in a sandbox tool policy that blocks group:runtime (exec/bash/process). That makes the model correctly say “I don’t have exec/bash”.

Run this and paste it:

openclaw sandbox explain --json
#

That command is made for this exact situation — it prints the effective sandbox mode + effective sandbox tool allow/deny and tells you the exact config keys blocking it.

Quick sanity test (temporary):

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

Then ask the bot to run a simple command again. If that fixes it, we know it’s sandbox policy.

B) You have a strict tools.allow that’s blocking runtime

If tools.allow is set and doesn’t include group:runtime (or exec/bash), then changing tools.profile won’t help — allowlists are a hard cap.

Paste these too:

openclaw config get tools.profile
#
openclaw config get tools.allow
openclaw config get tools.deny

Once you paste sandbox explain --json + those 3 lines, I can tell you exactly what to change (one small config tweak, not “try random profiles”).

royal portal
#

┌──(kali㉿kali)-[~]
└─$ openclaw sandbox explain --json
{
"docsUrl": "https://docs.openclaw.ai/sandbox",
"agentId": "main",
"sessionKey": "agent:main:main",
"mainSessionKey": "agent:main:main",
"sandbox": {
"mode": "off",
"scope": "agent",
"perSession": false,
"workspaceAccess": "none",
"workspaceRoot": "/home/kali/.openclaw/sandboxes",
"sessionIsSandboxed": false,
"tools": {
"allow": [
"exec",
"process",
"read",
"write",
"edit",
"apply_patch",
"image",
"sessions_list",
"sessions_history",
"sessions_send",
"sessions_spawn",
"subagents",
"session_status"
],
"deny": [
"browser",
"canvas",
"nodes",
"cron",
"gateway",
"telegram",
"whatsapp",
"discord",
"irc",
"googlechat",
"slack",
"signal",
"imessage"
],
"sources": {
"allow": {
"source": "default",
"key": "tools.sandbox.tools.allow"
},
"deny": {
"source": "default",
"key": "tools.sandbox.tools.deny"
}
}
}
},
"elevated": {
"enabled": true,
"allowedByConfig": false,
"alwaysAllowedByConfig": false,
"allowFrom": {},
"failures": []
},
"fixIt": [
"tools.sandbox.tools.allow",
"tools.sandbox.tools.deny",
"agents.list[].tools.sandbox.tools.allow",
"agents.list[].tools.sandbox.tools.deny",
"tools.elevated.enabled"
]
}

┌──(kali㉿kali)-[~]
└─$

crisp sleetBOT
#

Nice — that output basically rules out sandbox as the cause:

  • sandbox.mode: "off"
  • sessionIsSandboxed: false

So the “I don’t have exec/bash” problem is regular tool policy, not sandboxing.

Next most likely culprit: you have a strict allowlist somewhere (global or per‑agent, possibly per‑provider) that’s excluding runtime tools.

1) Paste these (they don’t contain secrets)

openclaw config get tools
openclaw config get agents.list
openclaw models status

2) The common “gotcha” (quick explanation)

#

If tools.allow is set at all, it becomes a hard allowlist (“only these tools exist”). So even if you set tools.profile=full, runtime tools still won’t appear unless tools.allow includes them.

Runtime group is:

So if you do have an allowlist, it must include group:runtime (or at least exec).

3) Also: what exact message does the bot say?

Copy/paste the exact line where it says it “doesn’t have exec/bash” — there are two different failure modes:

  • tools are not present (allowlist/profile/provider restriction)
  • tools are present but blocked (deny / approvals / elevated gates)

Once I see your tools block + models status, I can tell you the exact one-line config change to make.

royal portal
#

┌──(kali㉿kali)-[~]
└─$ openclaw config get tools
openclaw config get agents.list
openclaw models status

🦞 OpenClaw 2026.3.2 (85377a2) — You had me at 'openclaw gateway start.'

{
"profile": "coding",
"exec": {
"host": "gateway"
}
}

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

Config path not found: agents.list

🦞 OpenClaw 2026.3.2 (85377a2)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/stepfun/step-3.5-flash:free
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (4): google/gemini-2.5-pro, openrouter/anthropic/claude-sonnet-4-5, openrouter/google/gemma-3-4b-it:free, openrouter/stepfun/step-3.5-flash:free

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openrouter (1)

  • google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAr...w_iUD7JY
  • openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openrouter:default=token:sk-or-v1...050d6a89

OAuth/token status

  • openrouter
    • openrouter:default static

┌──(kali㉿kali)-[~]
└─$

crisp sleetBOT
#

There it is. Your tool config is fine:

  • tools.profile: "coding" (this does include runtime tools)
  • tools.exec.host: "gateway"

The real problem is in models status:

Default model = openrouter/stepfun/step-3.5-flash:free

A bunch of the “free / small / fast” OpenRouter models don’t support tool-calling (or OpenRouter exposes them without function/tool support). When the provider/model can’t do tool calls, OpenClaw can’t give it exec/bash in a usable way — so the assistant will keep telling you it “doesn’t have exec/bash”, no matter what tool profile you pick.

Fix: switch to a tool-capable model (you already have one configured)

You already have openrouter/anthropic/claude-sonnet-4-5 in your configured models list. Try making that your default:

openclaw config set agents.defaults.model.primary openrouter/anthropic/claude-sonnet-4-5
#
openclaw gateway restart

Then in Discord, ask it something dead simple like: “run uname -a”.

Why openclaw config get agents.list failed

You don’t have agents.list in config (single-agent setup). That’s fine.

If you want, paste what the bot says verbatim when it claims it can’t exec, after switching models — but I’m pretty confident this is the whole issue.

royal portal
#

the problem is i need a free model cus i cant afford paid

crisp sleetBOT
#

Totally fair constraint.

But here’s the blunt reality: exec/bash requires tool-calling, and most “free” hosted models (especially the OpenRouter :free ones) are either:

  • not tool-call capable, or
  • exposed in a mode where OpenClaw can’t safely/consistently enable tools

That’s why your default openrouter/stepfun/...:free acts like “no exec/bash exists” even though your tools.profile is set correctly.

What you can do with $0

Option A — try the other free model you already have

You have openrouter/google/gemma-3-4b-it:free configured. Switch to it and test. If it still won’t use tools, then you’ve confirmed “OpenRouter free tier models won’t do tool calling for you”.

openclaw config set agents.defaults.model.primary openrouter/google/gemma-3-4b-it:free
openclaw gateway restart
#

Then ask the bot to run something simple like uname -a.

Option B — accept “chat-only”

If free models won’t tool-call, OpenClaw can still chat/reason, but you run the terminal commands manually (ask it “what command should I run?”).

If you need exec and can’t pay providers

The only real path is local models (free as in “no API bill”, but you pay with hardware + setup, and tool calling can be flaky on small models):
https://docs.openclaw.ai/gateway/local-models

If you tell me which of these you want (A test gemma, B chat-only, or local), I’ll help you set it up with the least pain.

royal portal
#

cant wej ust use qwen 3 coder

crisp sleetBOT
#

Yes — if you run it locally.

What’s biting you right now is: your current free hosted OpenRouter model doesn’t do tool-calling, so OpenClaw can’t use exec/bash. If you want “free + tools”, the practical path is Ollama (local models). OpenClaw’s Ollama integration supports streaming and tool calling via Ollama’s native API.

Docs: https://docs.openclaw.ai/providers/ollama

Quick path (Ollama)

  1. Install Ollama: https://ollama.ai

  2. Pull a Qwen coder model that your machine can actually run (model name depends on what Ollama offers on your box)

  3. Enable Ollama for OpenClaw (the “key” can be any string):

openclaw config set models.providers.ollama.apiKey "ollama-local"
  1. Set your default model to Ollama:
#
openclaw config set agents.defaults.model.primary "ollama/<your-model-id>"
openclaw gateway restart
  1. Verify OpenClaw sees tool-capable Ollama models:
openclaw models list
openclaw models status

Important gotcha

If you point OpenClaw at Ollama on another machine, don’t use the /v1 OpenAI-compatible URL — it breaks tool calling. Use http://host:11434 (no /v1). (That’s straight from the Ollama docs page above.)

If you paste your ollama list output, I can tell you exactly what to put as the "ollama/<model-id>" string.

royal portal
crisp sleetBOT
#

Can’t sugarcoat this: a free OpenRouter model that is (a) tool-call capable and (b) won’t hit “API REACHED” doesn’t really exist. That “API REACHED!!” is OpenRouter telling you you’ve hit the free-tier quota/rate-limit. If it’s free, there’s always a ceiling.

What you can do:

1) Stop burning your free quota in the background

If you have heartbeats on, they’ll quietly chew through your free requests.

Disable heartbeats completely:

openclaw config set agents.defaults.heartbeat.every 0m
openclaw gateway restart

That alone often turns “API REACHED” from “every few minutes” into “only when I spam it”.

2) If you need tools + $0, the realistic option is local (Ollama)

#

That’s the only way to get “free (no API bill) + tool calling” reliably. OpenRouter free is always going to rate-limit.

Docs: https://docs.openclaw.ai/providers/ollama

3) If you insist on OpenRouter-free anyway

Then the honest expectation is: chat-only, or “works sometimes, then rate-limits”. I can’t recommend any specific “free tool model” there because the availability/limits change constantly.

If you want, paste the exact “API REACHED” error text and tell me whether it happens even when you’re not actively messaging (that would confirm heartbeat/background usage is the main culprit).

royal portal
#

tools.profile (coding) allowlist contains unknown entries (apply_patch, image). These entries won't match any tool unless the plugin is enabled.

crisp sleetBOT
#

That log line is just a warning, and it’s not the reason you’re missing exec / hitting OpenRouter limits.

What it means:

  • You’ve set tools.profile: "coding".
  • The built-in “coding” profile includes some tools that are optional / conditional:
    • image only exists if you’ve configured an image model (your models status shows Image model: -, so it’s not available).
    • apply_patch is experimental/conditional (and in some setups only registers when explicitly enabled / supported), so your gateway is saying “I don’t currently have a tool with that name”.

So OpenClaw is basically saying: “My profile references apply_patch and image, but those tools aren’t registered right now, so those entries won’t match anything.”

What you should do

  • Ignore it (recommended). exec/process/read/write etc. still work.
  • If you want to silence it: set tools.profile to full (no base allowlist), or configure an image model (to make image exist). I wouldn’t bother until everything else is working.

If you paste the exact bot message you see when it claims it “can’t exec”, we can confirm whether it’s still the model/tool-calling issue (very likely) vs a tool-policy block.

royal portal
#

just ragequit ig no openclaw for me gg tho

crisp sleetBOT
#

Fair — that was a frustrating rabbit hole.

If you ever want to take another swing at it, here’s the “what actually happened” in one sentence:

  • Your tools setup was fine (tools.profile: coding), but your free OpenRouter default model was (1) rate-limited (“API REACHED”) and (2) effectively not tool-call capable, so exec/bash was never going to work consistently.

The only real paths to “bot can run commands” are:

  1. Local model (free, but needs local compute) via Ollama
    https://docs.openclaw.ai/providers/ollama

  2. Paid model (even a tiny top-up) and then keep usage low
    Biggest easy win: keep heartbeats off so you don’t burn quota:

    openclaw config set agents.defaults.heartbeat.every 0m
    
#

If you come back later and tell me “I’m willing to do Ollama” vs “I can spend $5 once”, I can give you a very short, deterministic setup path.

royal portal
crisp sleetBOT
#

If you’ve literally got $0, then yeah: OpenRouter free-tier + tool calling is going to stay painful (rate limits + many free models don’t support tools).

The actually workable $0 path is: run a local model (Ollama) and point OpenClaw at it. No API bills — just your hardware.

$0 setup (Ollama → OpenClaw)

  1. Install Ollama (Linux): https://ollama.ai

  2. Pull any model you can run locally (pick something small if you’re CPU-only)

  3. Tell OpenClaw “Ollama is available” (the key can be any string):

openclaw config set models.providers.ollama.apiKey "ollama-local"
  1. See what OpenClaw can use (it auto-filters to models that report tool support):
openclaw models list
#
  1. Set the default model to one of those ollama/... entries:
openclaw config set agents.defaults.model.primary "ollama/<paste-from-models-list>"
openclaw gateway restart

Two important expectations

  • If you’re on CPU only, it’ll be slow, and tool-calling may be a bit flaky on small models.
  • Bigger models behave better with tools, but need a GPU / lots of RAM.

If you tell me what hardware you’re on (CPU only? how much RAM? any NVIDIA GPU + VRAM?), I can suggest what size class to try first without wasting your time downloading something impossible.

crisp sleetBOT
#

16GB RAM is workable for local—just don’t try the huge models.

What will run on 16GB (assuming no GPU)

  • Start with a ~7B model (or smaller). That’s the “it might actually be usable on CPU” tier.
  • 13B might run but will be slow and can OOM depending on quantization/overhead.
  • 20B/30B+ is basically “don’t” on 16GB.

Quick check: do you have an NVIDIA GPU?

nvidia-smi
  • If that says “command not found” or no GPU, assume CPU-only.

Concrete Ollama path (CPU-friendly)

  1. Install Ollama + make sure it’s running (ollama serve usually happens automatically via service)

  2. Pull a 7B-ish coder model. Since you mentioned Qwen, try:

#
ollama pull qwen2.5-coder:7b

If that exact tag doesn’t exist on your Ollama install, no worries—grab any qwen coder that’s ~7B from the Ollama library.

  1. Enable Ollama in OpenClaw + switch default:
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set agents.defaults.model.primary "ollama/qwen2.5-coder:7b"
openclaw gateway restart
  1. Confirm OpenClaw sees it:
openclaw models list
#

If you paste the output of nvidia-smi (or tell me “no GPU”) and free -h, I’ll tell you whether 7B is the right target or if you should go smaller.

royal portal
#

how do i close this