#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)
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):
openclaw cron add \
--name "Daily ping" \
--cron "0 9 * * *" \
--tz "UTC" \
--session isolated \
--message "Post a short daily update in this channel." \
--announce \
--channel discord \
--to "channel:<DISCORD_CHANNEL_ID>"
Docs: https://docs.openclaw.ai/automation/cron-jobs
Guide: https://docs.openclaw.ai/automation/cron-vs-heartbeat
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).
@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
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.denycontaining"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.
Nothing fucking works ive been at this for hours ive tried every profile known to man every command NOTHING
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.
┌──(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)-[~]
└─$
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”).
┌──(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)-[~]
└─$
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:
group:runtime→exec,bash,process
(see https://docs.openclaw.ai/tools)
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.
┌──(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)-[~]
└─$
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.
the problem is i need a free model cus i cant afford paid
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.
cant wej ust use qwen 3 coder
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)
-
Install Ollama: https://ollama.ai
-
Pull a Qwen coder model that your machine can actually run (model name depends on what Ollama offers on your box)
-
Enable Ollama for OpenClaw (the “key” can be any string):
openclaw config set models.providers.ollama.apiKey "ollama-local"
- Set your default model to Ollama:
openclaw config set agents.defaults.model.primary "ollama/<your-model-id>"
openclaw gateway restart
- 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.
dude please for the sake of god i want to use openrouter with a model that wont fucking scream API REACHED!! while it can still call tools and is free
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).
tools.profile (coding) allowlist contains unknown entries (apply_patch, image). These entries won't match any tool unless the plugin is enabled.
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:
imageonly exists if you’ve configured an image model (yourmodels statusshowsImage model: -, so it’s not available).apply_patchis 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/writeetc. still work. - If you want to silence it: set
tools.profiletofull(no base allowlist), or configure an image model (to makeimageexist). 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.
just ragequit ig no openclaw for me gg tho
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, soexec/bashwas never going to work consistently.
The only real paths to “bot can run commands” are:
-
Local model (free, but needs local compute) via Ollama
https://docs.openclaw.ai/providers/ollama -
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.
@crisp sleet the thing is i got no cents to my name
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)
-
Install Ollama (Linux): https://ollama.ai
-
Pull any model you can run locally (pick something small if you’re CPU-only)
-
Tell OpenClaw “Ollama is available” (the key can be any string):
openclaw config set models.providers.ollama.apiKey "ollama-local"
- See what OpenClaw can use (it auto-filters to models that report tool support):
openclaw models list
- 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.
i have.. 16.. gb ram..
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)
-
Install Ollama + make sure it’s running (
ollama serveusually happens automatically via service) -
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.
- 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
- 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.
how do i close this