#Excessive sessions

1 messages · Page 1 of 1 (latest)

wet wren
#

How do I clean up old sessions. Openclaw seasons list shows 300+. Some are on older models I don't use. It's making / status command get confused

Openclaw sessions cleanup didn't remove them

open forgeBOT
#

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

topaz hingeBOT
#

First, can you paste openclaw --version? Version matters here.

Likely cause: openclaw sessions cleanup only follows session.maintenance. Defaults are roughly warn mode + maxEntries 500, so 300 sessions may remove nothing.

Try:

openclaw sessions cleanup --all-agents --dry-run

If it shows removals:

openclaw sessions cleanup --all-agents --enforce

If you want fewer than 300, set a lower cap:

#
openclaw config set session.maintenance.mode enforce
openclaw config set session.maintenance.maxEntries 100 --strict-json
openclaw config set session.maintenance.pruneAfter 14d

openclaw sessions cleanup --all-agents --dry-run
openclaw sessions cleanup --all-agents --enforce

If entries point to missing transcript files, add:

openclaw sessions cleanup --all-agents --dry-run --fix-missing
openclaw sessions cleanup --all-agents --enforce --fix-missing

Also: old sessions using old models shouldn’t affect /status unless the current session has a model override. Use /model to switch/select your desired default model, or clear the override in the Sessions UI.

wet wren
#

Also I used /reset

Now I can't use /new. I get this error

One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.

topaz hingeBOT
#

That /new error is not expected. Bare /new / /reset should be handled locally by the Gateway, not sent to the model.

Please paste:

openclaw --version
openclaw status --all

Quick workaround to unblock: send /new hello instead of bare /new. That gives the first turn non-empty input after the reset.

Then try:

openclaw gateway restart
#

If it still happens after restart, this is likely a bug/regression in command handling or reset startup. Please file it with the version + the openclaw status --all output/log tail here: https://github.com/openclaw/openclaw/issues

Also, for the session cleanup part: if you’re under the default maxEntries: 500, 300 sessions won’t be removed unless you lower the cap or age window and run with --enforce.

wet wren
#

also i keep getting async notifications in my TG. why, is this new? my agent says to stop i have to stop heartbeat announce, but i dont want to stop heartbeat announcing things. i just dont want these stupid annoying async notifications. i do a task in discord, agent runs exec and i get a notification in TG. wtf is this

topaz hingeBOT
#

Yeah, that’s frustrating — and your agent is mixing two separate things.

These are exec completion wakes, not normal heartbeat announcements. By default:

tools.exec.notifyOnExit = true

So when an exec command backgrounds and later exits, OpenClaw enqueues an “Exec finished/failed” system event and wakes heartbeat to process it. If your heartbeat target resolves to Telegram, you see it there.

To stop only those async exec notifications while keeping heartbeat alerts:

openclaw config set tools.exec.notifyOnExit false --strict-json
openclaw gateway restart
#

Also make sure this is false if you changed it:

openclaw config set tools.exec.notifyOnExitEmptySuccess false --strict-json

For currently-running tracked background tasks, you can silence one with:

openclaw tasks list
openclaw tasks notify <task-id-or-session-key> silent

Docs: https://docs.openclaw.ai/tools/exec and https://docs.openclaw.ai/gateway/heartbeat

Also still paste openclaw --version when you can — the /new error you hit earlier still sounds like a bug/regression.

wet wren
#

this is what my agent says

there isn’t a clean async-only kill switch right now**.

Newer OpenClaw behavior routes background exec completions through the heartbeat alert path.

I verified the runtime:

  • async completion prompt is built in heartbeat-runner-DAeyU7uX.js
  • relay-to-user is gated by visibility.showAlerts
  • for webchat, visibility comes from channels.defaults.heartbeat

So today, OpenClaw effectively treats:

  • real heartbeat alerts
  • async exec completion summaries

as the same alert surface.


What that means
If you want:

  • heartbeat alerts ON
  • async exec summaries OFF

there is no first-class config toggle for that in this version.

topaz hingeBOT
#

Your agent is half right, but the conclusion is wrong.

It’s right that background exec completions are delivered through a heartbeat wake/system-event path. But there is an exec-specific kill switch before that path:

openclaw config set tools.exec.notifyOnExit false --strict-json
openclaw gateway restart

That stops backgrounded exec exits from enqueueing the “Exec completed/failed” event + heartbeat wake. It does not disable normal heartbeat alerts.

Keep this false too unless you specifically want no-output success pings:

openclaw config set tools.exec.notifyOnExitEmptySuccess false --strict-json
#

Caveat: this only covers exec completion notifications. Subagent/ACP/cron/media-generation completion announcements have separate task/delivery behavior.

Please still share openclaw --version — if this key isn’t working on your version, that’s the part to file as a bug.

wet wren
#

but will this mess up sub agents if they dont announce to main agent or is that seperate