My claw... doesn't do shit

[turbid glade]

So i try a fresh new installation after get some results, because i had problems with configurations and did some shit that wasy easy to just clear everything up.

After a fresh installation i got some issues:
a) I can't allow it to run sudo commands. It seems that he always says: system requires a elevated permission. It seems to be some openclaw config, which i adjusted, but it didn't seems to get any real reflection. Also, it seems to be locked on sandbox and for some reason i can't change it.

b) heartbeats doesn't fire up (or are just ignored). I've checked and the tasks are listed on heartbeat. I tried to adjust it for very 1, 5, 10 min, but it only fires every 30. And still.. nothing. It doesn't do anything at all

c) cronjobs aren't working: aswell, nothing happeans.

I'm using a VPS with gpt 4.1.

Any tips?

[rigid monolith]

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

[sleek notch]

This combo (config changes not taking effect + heartbeats/cron “doing nothing” + “stuck in sandbox”) is very often one root cause: your Gateway service is running with a different config/profile than the one you’re editing.

1) First check: are you editing the config the service actually uses?

Run this on the VPS and paste the output:

openclaw gateway status

If it shows Config (cli) and Config (service) are different, you’re editing one file while systemd is running another (often a --profile / OPENCLAW_STATE_DIR mismatch). Fix per the FAQ:

openclaw gateway install --force
openclaw gateway restart

(FAQ section: “Config (cli) vs Config (service) different” — https://docs.openclaw.ai/help/faq)

That alone usually fixes:

• heartbeat interval “ignoring” your edits
• cron not firing
• tool policy/elevated settings not reflecting

2) (a) “sudo requires elevated permission” + “locked on sandbox”

Two separate concepts:

Why it feels “locked”

If you have agents.defaults.sandbox.mode: "non-main", then Discord guild channels/threads are “non-main” sessions, so they get sandboxed by design. (Sandboxing docs call this out.)

Debug what’s happening for real:

openclaw sandbox explain

Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

How to run host commands anyway (the intended escape hatch)

In sandboxed sessions, sudo inside the container is pointless. What you want is Elevated exec, which forces exec onto the gateway host:

• In chat: /elevated on (or /elevated full to skip exec approvals for that session)

But it’s gated by config:

• tools.elevated.enabled
• tools.elevated.allowFrom.discord (your Discord user id)

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

Also: in guild channels, directives like /elevated ... are only honored when the bot considers the message “mentioned” (depends on your Discord config).

3) (b) Heartbeats “don’t fire” / always 30m / “do nothing”

A few gotchas from the docs:

• Default interval is 30m unless you override agents.defaults.heartbeat.every.
• If the heartbeat reply is just HEARTBEAT_OK, it’s suppressed by default, so it can look like “nothing happened”.
• If HEARTBEAT.md exists but is effectively empty (only headers/blank), OpenClaw may skip the heartbeat run to save calls.

Useful checks:

openclaw system heartbeat last
openclaw logs --follow

Docs: https://docs.openclaw.ai/gateway/heartbeat
FAQ: https://docs.openclaw.ai/help/faq#why-am-i-getting-heartbeat-messages-every-30-minutes

4) (c) Cron jobs not working

Cron runs inside the Gateway process, so if the gateway isn’t continuously up, nothing runs.

Checklist from FAQ:

• cron.enabled is true
• OPENCLAW_SKIP_CRON is not set
• Gateway is running 24/7

Debug commands:

openclaw cron status
openclaw cron list
openclaw cron run <jobId> --force
openclaw cron runs --id <jobId> --limit 50

FAQ: https://docs.openclaw.ai/help/faq#cron-or-reminders-do-not-fire-what-should-i-check
Docs: https://docs.openclaw.ai/automation/cron-jobs

If you paste these outputs, I can tell you exactly where it’s going wrong

openclaw --version
openclaw status --all
openclaw gateway status
openclaw cron status
openclaw system heartbeat last
openclaw sandbox explain

[turbid glade]

🦞 OpenClaw 2026.2.3-1 (d84eb46) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-07.log
Command: /usr/bin/node /usr/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 862, 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

root@clawdbot:~# openclaw system heartbeat last

🦞 OpenClaw 2026.2.3-1 (d84eb46) — Ship fast, log faster.

│
◇
null

[sleek notch]

Nice — config mismatch is not the issue here (CLI + service both use ~/.openclaw/openclaw.json, probe OK).

Heartbeat: why last is null

openclaw system heartbeat last returning null means the gateway believes no heartbeat has ever run since this gateway started (or heartbeats are disabled).

Two quick tests:

1. Make sure heartbeats aren’t paused

openclaw system heartbeat enable

2. Force one to run now (and create a “last”)

openclaw system event --text "heartbeat test (should run immediately)" --mode now
openclaw system heartbeat last

In another terminal while you do that:

openclaw logs --follow

You should see either the heartbeat run, or an error telling us why it’s being skipped (model auth, queue busy, etc.).

Also: if you just restarted the gateway and you’re relying on the default every: 30m, the first scheduled tick won’t happen until ~30 minutes after startup — but the system event --mode now bypasses that, so it’s the best diagnostic.

If the heartbeat runs but you still see “nothing in Discord”

Heartbeat delivery defaults to target: "last" (deliver to the last external chat used by the main session). If you’ve only been talking to it in guild channels, “last” can be unintuitive.

You can force delivery to a specific Discord channel by setting heartbeat target/to in config, e.g.:

{
agents: {

defaults: {
heartbeat: {
every: "10m",
target: "discord",
to: "channel:1469521361843130461"
}
}
}
}

(then openclaw gateway restart)

Elevated / sudo (your point a)

To allow /elevated on|full from Discord, add your Discord user id to the elevated allowlist:

{
tools: {
elevated: {
enabled: true,
allowFrom: { discord: ["353709510830850098"] }
}
}
}

Then in Discord: send /elevated on (or /elevated full).

Next thing to paste (so we can pinpoint it fast)

After you run the forced heartbeat test above, paste:

openclaw cron status
openclaw status --all

(Those will usually reveal immediately if cron/heartbeat are disabled, skipping, or failing due to model/auth/runtime errors.)

[turbid glade]

When i try the /elevated on telegram i got:

elevated is not available right now (runtime=direct).
Failing gates: allowFrom (tools.elevated.allowFrom.telegram)
Fix-it keys:

• tools.elevated.enabled
• tools.elevated.allowFrom.<provider>
• agents.list[].tools.elevated.enabled
• agents.list[].tools.elevated.allowFrom.<provider>
See: openclaw sandbox explain --session agent:main:main

[sleek notch]

That error is actually a good sign — it’s OpenClaw telling you exactly what’s blocking /elevated:

• runtime=direct = you’re not sandboxed in that session (so “elevated” isn’t needed to “escape the sandbox”).
• But /elevated ... is still gated by allowlists, and your Telegram sender isn’t allowlisted in tools.elevated.allowFrom.telegram, so it refuses.

Fix: allowlist yourself for Telegram elevated

In ~/.openclaw/openclaw.json add (replace with your real Telegram user/chat id or username):

{
tools: {
elevated: {
enabled: true,
allowFrom: {
telegram: ["123456789"] // or "@yourusername"
}

}
}
}

Then restart the gateway:

openclaw gateway restart

How to find your Telegram id

Easiest: run this on the VPS:

openclaw logs --follow

Send a DM to the bot on Telegram, then look in logs for something like from.id.

(FAQ has the same “how to find ids” pattern: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom)

Important note about “sudo”

Even with /elevated full, OpenClaw does not magically become root. It just controls where exec runs (host vs sandbox) + approvals behavior. If the gateway runs as a non-root user, sudo will still fail unless your OS sudoers allows it (ideally NOPASSWD for a small allowlist of commands).

Next: paste this (it’ll explain your sudo + heartbeat situation fast)

openclaw sandbox explain --session agent:main:main
openclaw status --all

[turbid glade]

Diagnosis (read-only)

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

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

• pid 25116 root: openclaw-gateway (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  ✓ Tailscale: funnel · Running · clawdbot.taila9642f.ts.net
  ips: 100.98.179.88, fd7a:115c:a1e0::101:b366
  https: https://clawdbot.taila9642f.ts.net
  ✓ Skills: 8 eligible · 0 missing · /root/.openclaw/workspace
  ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.

About sudo... I did what you suggested but i still get "Approval required (id xxx), approve to run; updates will arrive after completion.

I add telegram with ["*"] so i dont get why is happeaning. the gateway was restarted

[sleek notch]

That “Approval required (id …)” message is not the elevated allowlist anymore — it’s the Exec Approvals guardrail kicking in.

So you’re hitting two different layers:

1. Elevated gates (tools.elevated.allowFrom.<provider>)
   → controls whether /elevated … (or elevated exec) is allowed at all.

2. Exec approvals (~/.openclaw/exec-approvals.json)
   → controls whether the command runs without an interactive approval prompt.

Setting tools.elevated.allowFrom.telegram = ["*"] only solves (1). It does not disable (2).

---

Why you’re still blocked

You’re running on a headless VPS, so when OpenClaw asks for approval, it needs some operator UI to approve it (Control UI / dashboard), otherwise it will sit pending and/or eventually deny (depending on askFallback).

Also note: if your Gateway is running as root (your status shows root paths), you usually don’t need sudo at all — but the approvals system still may prompt depending on how exec is being invoked.

---

Fix options (pick one)

Option A (recommended): approve once, then “Always allow” in the UI

Open the Control UI (Dashboard), then go to Nodes → Exec approvals (Gateway), and when the approval pops up choose:

• Allow once (runs now), or
• Always allow (adds it to the allowlist)

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

Option B: bypass approvals for this session

In the chat, set:

• /elevated full

full is special: it skips exec approvals for that session. (/elevated on does not.)

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

Option C: add an allowlist entry from the CLI

This is persistent and avoids prompts, but be careful: allowlisting sudo basically allows anything via sudo.

Inspect current approvals:

openclaw approvals get --gateway

Add allowlist (example):

openclaw approvals allowlist add --gateway --agent "*" "/usr/bin/sudo"

Docs: https://docs.openclaw.ai/cli/approvals

---

Quick sanity check (so we’re not guessing)

Run and paste (redact any tokens if shown):

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

And tell me: are you approving via the Dashboard, or are you expecting approvals to be approved from Telegram/Discord? (That requires explicitly forwarding approvals to chat + using /approve, which is a separate config block.)

[turbid glade]

Ok, sudo is resolved. How i change heartbeats thru cli? is it possible? id like to have it every minute

[sleek notch]

Yep — heartbeat cadence is just config. There isn’t a dedicated openclaw system heartbeat set-every ... command; you change it via openclaw config set and restart.

Set heartbeat to every minute

openclaw config set agents.defaults.heartbeat.every "1m"
openclaw gateway restart

Verify:

openclaw config get agents.defaults.heartbeat
openclaw system heartbeat last

Two gotchas (common)

1. Per-agent override: if you have agents.list[] entries with a heartbeat block, only those agents run heartbeats. In that case set it on the specific agent instead:

openclaw config get agents.list
# then set the right index, e.g.
openclaw config set agents.list[0].heartbeat.every "1m"
openclaw gateway restart

2. You might still “see nothing”: if the heartbeat replies HEARTBEAT_OK, it’s suppressed by default. If you want visible proof it’s running, either put a real checklist in HEARTBEAT.md, or enable “show ok” for your channel (docs explain the knobs):
   https://docs.openclaw.ai/gateway/heartbeat

[turbid glade]

HOW TO CHANGE MODEL BEING USED?

[sleek notch]

Use the models CLI.

Set the default model (global)

openclaw models set <provider/model-or-alias>

Example:

openclaw models set openai/gpt-4.1

(then start a fresh chat or restart the gateway if you want it to apply everywhere immediately)

See what you’re currently using + what’s configured

openclaw models status --plain
openclaw models list

Change just the current conversation (in chat)

Send:

/model

to see current, or:

/model openai/gpt-4.1

Docs: https://docs.openclaw.ai/cli/models

[turbid glade]

tasks on heartbeat should be executed or it works just as reminder? Even having tasks and heartbeats working nothing is moving forward

[sleek notch]

Heartbeat is not a “task runner queue” by default — it’s a periodic awareness check (one agent turn in the main session) meant to notice things and optionally nudge you.

So:

• If your HEARTBEAT.md items are vague (or you don’t have the right skills/tools configured), the model will often just reply HEARTBEAT_OK → and that gets suppressed, so it looks like “nothing happens”.
• The default heartbeat prompt also tells it not to infer/continue old work from prior chats, so it usually won’t “move a project forward” on its own.

Docs (worth reading): https://docs.openclaw.ai/automation/cron-vs-heartbeat and https://docs.openclaw.ai/gateway/heartbeat

If you want “things to actually execute on a schedule”

Use Cron, especially isolated cron jobs. That’s the feature meant for “do X every N minutes” / “do Y at 9am”.

Example (every minute, isolated, announces to your chat):

openclaw cron add \
--name "my task" \

--every "1m" \
--session isolated \
--message "Do <the specific task>. If you took actions, summarize results. If nothing to do, say so." \
--announce \
--channel discord \
--to "channel:1469521361843130461"

If you still want heartbeat to “do work”

Make the checklist explicit and action-oriented in HEARTBEAT.md, e.g.:

• “Check cron runs for failures; if any failed, paste the last error.”
• “If there are pending approvals, alert me.”
• “If X file exists, run Y command and summarize output.”

And set heartbeat delivery to your Discord channel (otherwise target:"last" can silently go nowhere):

agents: { defaults: { heartbeat: { target: "discord", to: "channel:1469521361843130461" } } }

If you tell me what you expect to “move forward” (e.g., run a shell command, check a website, monitor something), I can suggest the cleanest setup (heartbeat vs cron, and the exact prompt).

[turbid glade]

So if i have a huge delivery, like: build a system, test it, etc. Which would be the right way to get it done by clawd?

[sleek notch]

For a “huge delivery” (build a system, run tests, iterate), don’t use heartbeat. Heartbeat is mainly periodic awareness/check-ins. The right pattern is:

Recommended workflow (interactive + tool-driven)

1. Kickoff in a normal chat session

• Give: requirements, success criteria, constraints (stack, DB, auth, deploy target), deadline.
• Ask it to produce: architecture + milestone plan + a “definition of done”.

2. Work in small milestones (vertical slices)

• Example milestone: “API skeleton + health check + one endpoint + tests + CI”.
• After each milestone: run tests, fix, then move on.

3. Use tools to actually do the work

• The bot needs read/write/edit + exec to create files, run installs, run tests, etc.
• If you’re sandboxed and the repo isn’t visible, you may need to adjust sandbox/workspace access or disable sandbox for that agent.

4. Use sub-agents for parallelism

• Main agent stays as “tech lead”.

• Spawn sub-agents for: research, writing test plans, reviewing code, writing docs, etc.
• Commands: /subagents list, etc. (Docs: https://docs.openclaw.ai/tools/subagents)

Where cron fits

Use cron only for things like:

• “Run test suite every hour and report failures”
• “Nightly build + lint + summarize”
• “Reminder in 20 minutes”

Cron is great for scheduled jobs, not for driving a big multi-step build from scratch. (Docs: https://docs.openclaw.ai/automation/cron-vs-heartbeat)

One key question (determines the best setup)

Where is the code going to live and execute?

• On the VPS (OpenClaw has direct access) — simplest.
• On your laptop — best to pair your laptop as a node so OpenClaw can run commands there while the Gateway stays on the VPS.

If you tell me:

1. what you’re building (1–2 sentences),
2. where you want the repo (VPS vs laptop),
3. whether you want sandboxing ON or OFF for this project,
   …I can suggest the exact config + a good first “kickoff prompt” that gets Clawd moving fast.

[turbid glade]

first, a problem. Even being resolved before i asked clawd to install some skills, but it showed again the "Approval required" message. What can it be?

[sleek notch]

That “Approval required (id …)” popping up again is almost always just exec approvals doing their job:

• You previously approved one specific command/binary (or approved “once”).
• Installing skills triggers different binaries (clawhub, git, pnpm/npm, tar, etc.) → those are not in the allowlist yet → approval prompt shows again.

Also: approvals are per agent and match resolved full paths (e.g. /usr/bin/git), not just git.

Quick ways to fix

Option 1 (fastest): set elevated to skip approvals for this session

In chat:

• /elevated full

That skips exec approvals for that session (use carefully).

Option 2 (recommended): allowlist the binaries needed for skill install

On the VPS, find paths:

command -v clawhub git pnpm npm

Then allowlist them (example):

openclaw approvals allowlist add --gateway --agent "*" "/usr/bin/git"
openclaw approvals allowlist add --gateway --agent "*" "/usr/bin/clawhub"
# etc for pnpm/npm path you got

To confirm what exactly triggered the approval

Run:

openclaw logs --follow

then reproduce the “install skills” request. The log lines around the approval will show the resolved executable path it wanted to run.

If you paste:

• the approval id line you saw, and
• the relevant log snippet around that time,
  I can tell you exactly which binary needs allowlisting (and whether you’re accidentally running exec host=gateway in that session via /exec).

[turbid glade]

In telegram when i tried the elevated command i got:

"elevated is not avaliable right now (runtime-direct). Failing gates: provider (ctx.provider) fix-itkeys:..."

I can run the vps option but i honestly want to gave clawd unrestrictd access to my entire vps without boundaries. Is there a way to do it?

[sleek notch]

That error is basically OpenClaw saying: “I can’t enable elevated here because the message context doesn’t map cleanly to a provider allowlist (ctx.provider).” (It’s also worth noting: when runtime=direct, elevated usually isn’t needed anyway — you’re already running on the host, not in a sandbox.)

About “unrestricted access to my entire VPS”

Yes, you can remove most guardrails — but it’s extremely risky. If your bot ever gets prompt-injected (or your chat account/token gets compromised), you’ve effectively handed out remote root.

If you still want it, the “no boundaries” version is basically:

1. Disable sandboxing (so tools run on the VPS, not in Docker)
2. Stop using approval-gated host exec (or set approvals to full)
3. Lock down who can talk to the bot (otherwise you’ve built an RCE endpoint)

Concretely:

A) Make exec run directly on the VPS without approvals

The simplest “unrestricted” setup is:

• agents.defaults.sandbox.mode = "off"
• keep tools.exec.host = "sandbox" (default)

Because per docs: when sandboxing is off, host=sandbox executes directly on the gateway host and does not require exec approvals.
(See: https://docs.openclaw.ai/tools/exec)

So check your config didn’t force host exec:

openclaw config get tools.exec
openclaw config get agents.defaults.sandbox

If you previously used /exec host=gateway ... in-chat, set it back per-session with:

/exec host=sandbox

B) If you do want host=gateway exec, disable approvals (very dangerous)

Exec approvals live in ~/.openclaw/exec-approvals.json (gateway host). Setting defaults to security:"full" + ask:"off" effectively removes the prompt layer. Use the approvals CLI:

• openclaw approvals get --gateway

• then edit/set (docs: https://docs.openclaw.ai/cli/approvals)

One huge warning for your setup

Your earlier status showed Tailscale Funnel running (public HTTPS). Combining public endpoint + unrestricted exec is a very bad idea. If you want “no boundaries”, do it only with:

• gateway bound to loopback/tailnet
• strict allowFrom on your channels (only you)
• no public exposure

If you paste:

openclaw config get tools.exec
openclaw config get agents.defaults.sandbox

…I can tell you exactly why you’re still getting approvals and what to change to get the behavior you want.

[turbid glade]

the problem is... im not using sandbox or even docker. so thats why i dont understanbd why we're having that many problems

[sleek notch]

You can be 100% not using Docker/sandbox and still hit “Approval required” — because that message is from Exec Approvals, which are a separate guardrail from sandboxing.

What triggers “Approval required” (even with no sandbox)

It happens when the agent is running commands in host mode (host=gateway or host=node) with ask=on-miss/always and security=allowlist.

Common ways you accidentally end up in host mode:

• you previously sent /exec host=gateway ... (persists per session)
• you enabled /elevated on (or agents.defaults.elevatedDefault: "on") and the agent requested elevated exec
• your config has tools.exec.host: "gateway"

Quick “make it stop prompting” fix (no sandbox required)

In the chat where it’s prompting, run:

/elevated off
/exec host=sandbox

If agents.defaults.sandbox.mode is off, then host=sandbox means: run directly on the VPS with no approvals (per exec docs).

Verify what’s happening (paste outputs)

On the VPS:

openclaw config get tools.exec
openclaw config get agents.defaults.sandbox
openclaw approvals get --gateway

And in the chat:

/exec
/elevated

Those 4 will pinpoint it immediately (usually you’ll see tools.exec.host=gateway or the session /exec is set to gateway).

If you paste them, I’ll tell you the exact line(s) to change.

[turbid glade]

Current exec defaults: host=sandbox, security=deny, ask=on-miss, node=(unset).
Options: host=sandbox|gateway|node, security=deny|allowlist|full, ask=off|on-miss|always, node=<id>.

[sleek notch]

Those /exec defaults look fine — host=sandbox should not trigger host approvals as long as the exec call is actually staying on host=sandbox.

If you’re still seeing “Approval required (id …)”, almost always one of these is true:

1) Elevated is ON (so exec gets forced onto the gateway host)

/exec output doesn’t show elevated state. If elevated is on/ask/full, the agent may request elevated exec which effectively becomes host execution (and then approvals kick in).

In the same chat, run:

/elevated

If it’s not off, set:

/elevated off

If you want to disable it permanently:

openclaw config set agents.defaults.elevatedDefault "off"
openclaw gateway restart

2) Some command is being executed with host=gateway (or host=node) explicitly

This can happen via a skill/tool that sets host execution explicitly, or if earlier you ran /exec host=gateway in that same session at some point.

To catch the truth, tail logs while reproducing the approval prompt:

openclaw logs --follow

and look for an exec.approval.requested / similar line — it will show the resolved exec host + command path that triggered the approval.

3) You’re not sandboxed, but you did enable approvals as a safety layer

Exec approvals are independent of Docker. They live in:

~/.openclaw/exec-approvals.json

Show me what your gateway thinks the approvals policy is:

openclaw approvals get --gateway

---

Fastest “reset to normal VPS behavior”

If your goal is “just run commands on the VPS without prompts” (and you truly have sandbox off):

1. In chat:

/elevated off
/exec host=sandbox