#Message keep looping without response

1 messages · Page 1 of 1 (latest)

hardy depot
#

The bot keep typing and no answer, go to openrouter to check, confirm the bot keep calling service and waste huge token and call time.

When check the log, i found 1 message

openclaw.service: Failed with result 'exit-code'.

Is it related to this issue? How to prevebt

cursive jayBOT
# hardy depot The bot keep typing and no answer, go to openrouter to check, confirm the bot ke...

Yes, it can be related — but openclaw.service: Failed with result 'exit-code' by itself just means systemd saw the Gateway process crash/exit. If the service is set to auto-restart, you can get a nasty loop like:

  1. Discord message arrives → bot starts typing → calls OpenRouter
  2. Gateway crashes before it can send the final reply
  3. systemd restarts it → it processes again → more OpenRouter calls → more cost

1) Stop the token burn now

  • In Discord: send stop (as a standalone message) to abort the current run.
  • On the server: stop the gateway service:
openclaw gateway stop

(or systemctl --user stop <service-name> if you’re managing it manually)

2) Get the real crash reason (most important)

Please run these on the machine hosting OpenClaw and paste the output:

# 
openclaw --version
openclaw status --all
openclaw gateway status
openclaw logs --limit 200

If the Gateway won’t stay up, also paste the systemd log:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

(Your unit might not be exactly openclaw-gateway.service if you installed an older/legacy service — openclaw gateway status will tell us the correct one.)

3) How to prevent it happening again

Once we find the cause, the usual “guardrails” are:

  • Fix the underlying crash (config error, missing env vars in service, bad model/provider error, etc.) → openclaw doctor often helps:
# 
openclaw doctor
  • Add stricter timeouts so a run can’t sit “typing” forever (docs show reply.timeoutSeconds and agents.defaults.timeoutSeconds as the knobs).
  • On the OpenRouter side: set a hard usage limit/budget for the API key so a runaway loop can’t drain your account.

Docs refs (so you can follow along):

Paste those 4 command outputs and I’ll tell you exactly what’s crashing + the cleanest fix.

hardy depot
#

this is the result after run "openclaw logs --limit 200"

00:51:40 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=cron toolCallId=call-[ID]
00:51:40 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=cron toolCallId=call-[ID]
00:51:53 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=agents_list toolCallId=call-[ID]
00:51:53 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=agents_list toolCallId=call-[ID]
00:52:06 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=cron toolCallId=call-[ID]
00:52:06 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=cron toolCallId=call-[ID]
00:52:21 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=agents_list toolCallId=call-[ID]
00:52:21 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=agents_list toolCallId=call-[ID]
00:52:26 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=cron toolCallId=call-[ID]
00:52:26 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=cron toolCallId=call-[ID]
00:52:44 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=[ID] tool=agents_list toolCallId=call-[ID]
00:52:44 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=[ID] tool=agents_list toolCallId=call-[ID]

cursive jayBOT
# hardy depot this is the result after run "openclaw logs --limit 200" 00:51:40 debug agent/e...

Those lines are a big clue: the agent is stuck in a tool-call loop (cron ↔ agents_list). That’s not normal for a simple Discord reply, and it absolutely can burn OpenRouter tokens while you only see “typing”.

Most common cause I’ve seen for “keeps typing + lots of model calls” is: a cron job is firing repeatedly (or a job prompt is causing the agent to keep re-checking/rewriting cron), so it’s running turns in the background over and over.

A) Check if cron is the thing triggering the loop

Run:

openclaw cron status
openclaw cron list

If you see a job running very frequently (or anything you don’t recognize), disable it:

openclaw cron disable <jobId>
# 
# or remove it completely:
openclaw cron rm <jobId>

To confirm what’s spamming, check run history for that job:

openclaw cron runs --id <jobId> --limit 20

B) Emergency “stop burning tokens” switch (temporary)

If you just want it to stop right now while debugging, disable cron globally and restart:

  • Add this to ~/.openclaw/.env on the gateway host:
# 
OPENCLAW_SKIP_CRON=1
  • Then restart the gateway:
openclaw gateway restart

(You can remove that line later.)

C) If cron list is empty: we need the error around the stuck run

The snippet you pasted has no error lines (only “tool start/end”). Please paste results of:

openclaw gateway status
openclaw status --all
#

And also this filtered log view:

openclaw logs --limit 400 | rg -n "error|warn|fatal|uncaught|discord|send|lifecycle|timeout|exit"

That usually reveals the real reason it never sends the final Discord message (permission issue, crash, timeout, etc.).

If you paste openclaw cron list output + openclaw gateway status, I can tell you quickly whether this is a runaway cron job vs a Discord send failure vs a gateway crash loop.

hardy depot
#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://[IP_ADDRESS]:18789
Source: local loopback
Config: /[USER]/.openclaw/openclaw.json
Bind: loopback

âś“ Config: /[USER]/.openclaw/openclaw.json
âś“ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 700081 root: openclaw-gateway ([IP_ADDRESS]:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    error: Error: spawn tailscale ENOENT
    ✓ Skills: 5 eligible · 0 missing · /[USER]/.openclaw/workspace
    âś“ Channel issues (none)

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

â—‡

cursive jayBOT
# hardy depot Diagnosis (read-only) Gateway connection details: Gateway target: ws://[IP_AD...

That diagnosis output is relevant.

Two key signals:

  1. Port 18789 is already in use by a Gateway process running as root
  2. Earlier logs show the agent stuck repeatedly calling cron and agents_list

Either of these can create “typing forever + lots of provider calls” (and if a service keeps restarting/crashing you can get repeated runs).

1) First fix: make sure you only have ONE Gateway running (and ideally not as root)

Please run and paste:

openclaw gateway status --deep
systemctl status openclaw.service --no-pager || true
systemctl status openclaw-gateway.service --no-pager || true
# 
systemctl --user status openclaw-gateway.service --no-pager || true

Why: if you accidentally have a root/system service and a user service, one of them will fail to start (“exit-code”), and you can end up with confusing behavior (wrong state dir, wrong config, duplicate restarts).

2) Second fix: check for a runaway cron job (very likely from your earlier log)

Run:

openclaw cron status
openclaw cron list --all

If you see anything running frequently / you don’t recognize, disable it:

# 
openclaw cron disable <jobId>
# or remove:
openclaw cron rm <jobId>

Emergency stop (to prevent token burn while debugging):

Put this in ~/.openclaw/.env on the gateway host:

OPENCLAW_SKIP_CRON=1

Then:

openclaw gateway restart
#

If the looping stops after this, we’ve confirmed cron was the trigger.

3) If it still “types but never replies” after cron is stopped

Then we need the actual send/error line. Best way:

openclaw logs --follow

Then send one Discord message that triggers the bot, and paste the first error/warn lines that show up.

Send the outputs for (1) and (2) and I’ll tell you exactly which process/service/job is causing the loop and the clean way to prevent it permanently.

hardy depot
#

so any recommend command i can uninstall all openclaw service / program for ALL user (include before installation),
after uninstall and re-install again, it should be return to nromal, right?

cursive jayBOT
# hardy depot so any recommend command i can uninstall all openclaw service / program for ALL ...

You can do a clean “nuke & pave”, and yes: if your problem is caused by duplicate services, bad state, or a runaway cron job, a full uninstall + reinstall usually brings things back to normal. Not a 100% guarantee (could still be a config/model bug), but it’s a good reset.

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

0) Warning (what you will lose)

This removes:

  • all sessions/history
  • all channel credentials (Discord/Telegram/etc)
  • cron jobs
  • your workspace files under ~/.openclaw/workspace

If you want to keep your “assistant brain” (AGENTS/SOUL/MEMORY), back up ~/.openclaw/workspace first.

1) Easy full uninstall (current user)

Run as the user that installed OpenClaw:

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

That should stop + uninstall the gateway service and remove the state dir for that user.

2) If you have a ROOT/system service running (you do)

Your diagnosis showed: pid … root: openclaw-gateway and you saw openclaw.service: Failed…, so also clean up system-wide services:

Find any OpenClaw/Clawdbot services

sudo systemctl list-unit-files | grep -Ei 'openclaw|clawdbot|molt|gateway'
sudo systemctl list-units --type=service | grep -Ei 'openclaw|clawdbot|molt|gateway'
#

Stop/disable the one(s) you find (examples)

If you see openclaw.service:

sudo systemctl disable --now openclaw.service

If you see openclaw-gateway.service:

sudo systemctl disable --now openclaw-gateway.service

After disabling, check port 18789 is free:

sudo lsof -nP -iTCP:18789 -sTCP:LISTEN
#

3) Delete state dirs (this is the “factory reset”)

For the user you’re reinstalling as:

rm -rf ~/.openclaw

If you used profiles before, you may also have:

ls -d ~/.openclaw-* 2>/dev/null
# then rm -rf those too if you truly want EVERYTHING gone

If you want to check other users on the machine also had OpenClaw state, you can search:

sudo find /home -maxdepth 2 -type d -name ".openclaw*" -print
#

4) Remove the CLI itself

Depending on how you installed:

npm rm -g openclaw
# or:
pnpm remove -g openclaw

(Do the same under sudo ONLY if you installed it globally as root.)

5) Reinstall cleanly

Then reinstall and onboard again (as a normal user, not root):

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

After reinstall, confirm you have only one gateway:

openclaw gateway status --deep

If you paste the output of the systemctl … | grep -Ei 'openclaw|clawdbot|molt|gateway' commands, I can tell you exactly which unit(s) to remove so you don’t end up with the “root gateway + user gateway” double-install again.

hardy depot
#

for uninstall process, is it normal

[HOST]:~# openclaw uninstall --all --yes --non-interactive

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Welcome to the command line: where dreams compile and confidence segfaults.

Stopped systemd service: openclaw-gateway.service
Removed systemd service: /[USER]/.config/systemd/user/openclaw-gateway.service
Removed ~/.openclaw
Removed ~/.openclaw/workspace
CLI still installed. Remove via npm/pnpm if desired.
[HOST]:~# sudo systemctl list-unit-files | grep -Ei 'openclaw|clawdbot|molt|gateway'
openclaw.service enabled enabled
[HOST]:~# sudo systemctl disable --now openclaw.service
Removed "/etc/systemd/system/multi-user.target.wants/openclaw.service".
[HOST]:~# sudo systemctl list-units --type=service | grep -Ei 'openclaw|clawdbot|molt|gateway'
â—Ź openclaw.service loaded failed failed OpenClaw Gateway Service
[HOST]:~# sudo lsof -nP -iTCP:18789 -sTCP:LISTEN
[HOST]:~# openclaw uninstall --all --yes --non-interactive

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Claws out, commit in—let's ship something mildly responsible.

Gateway service disabled.
Removed ~/.openclaw
Removed ~/.openclaw/workspace
CLI still installed. Remove via npm/pnpm if desired.
[HOST]:~# ^C
[HOST]:~# npm rm -g openclaw

removed 672 packages in 3s
[HOST]:~# sudo npm rm -g openclaw

up to date in 311ms

cursive jayBOT
# hardy depot for uninstall process, is it normal [HOST]:~# openclaw uninstall --all --yes ...

Yes — that’s normal.

What happened:

  • openclaw uninstall --all … removed the systemd user service (~/.config/systemd/user/openclaw-gateway.service) and deleted ~/.openclaw + ~/.openclaw/workspace.
  • Separately, you had a system-wide unit openclaw.service (root/system). You disabled it, but systemd can still show it as “loaded failed” until you either reset the failed state and/or remove the unit file.

Clean up the leftover openclaw.service properly

  1. See where the unit file lives:
sudo systemctl cat openclaw.service
  1. Stop + disable (safe even if already stopped):
sudo systemctl stop openclaw.service || true
# 
sudo systemctl disable openclaw.service || true
  1. Remove the unit file (use the path you saw in systemctl cat):
sudo rm -f /etc/systemd/system/openclaw.service
# (or whatever path `systemctl cat` showed)
  1. Reload systemd + clear the “failed” marker:
sudo systemctl daemon-reload
sudo systemctl reset-failed openclaw.service
  1. Verify it’s gone:
# 
sudo systemctl list-unit-files | grep -i openclaw || true
sudo systemctl list-units --type=service | grep -i openclaw || true

You already verified nothing is listening on 18789, so the burn-loop should be stopped.

Reinstall (recommended)

Reinstall as a normal user (not root) so you only get the user service:

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

If you want, paste the output of sudo systemctl cat openclaw.service and I’ll tell you the exact rm path for your box.

cursive jayBOT
#

Awesome — glad it’s sorted.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.