Gateway Broken after Update | Friends of the Crustacean 🦞🤝 | Page 1

placid barn Apr 27, 2026, 4:04 PM

#

I updated to 4.25 today and since then I can't get the gateway to start. I've rolled back to 4.24 and now 4.23 with no luck. How can I get gateway back up? I hace tried openclaw doctor --fix with zero luck.

split nebulaBOT Apr 27, 2026, 4:04 PM

#

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

iron sapphireBOT Apr 27, 2026, 4:06 PM

#

First thing: please paste openclaw --version and the failing line from openclaw gateway status --deep.

That said, rolling back after running 4.25 smells like the newer-config guard / split-brain install: 4.25 may have stamped your config, then 4.24/4.23 refuse service mutations. The docs call this out for post-upgrade gateway failures. (docs.openclaw.ai)

Try this path:

which openclaw
openclaw --version
openclaw config get meta.lastTouchedVersion
openclaw gateway status --deep
openclaw logs --tail 200

Best recovery is usually go forward again, then rewrite the service entrypoint:

OpenClaw

Troubleshooting - OpenClaw

#

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

If you intentionally need to stay rolled back and the error mentions an older binary / newer config, use the emergency override only for the one recovery command:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart

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

#

If that still fails, paste the gateway status --deep + last ~200 log lines here and we can pinpoint whether it’s service path drift, config guard, missing gateway.mode, port conflict, or plugin dependency fallout.

placid barn Apr 27, 2026, 4:27 PM

#

reverting back to4.23 got auth restored. Should I attempt an update again and have you figure it out with me, or just stay on 4.23 until the next version comes out? When I updated I did openclaw update in the console and then I was not able to bring gateway back until reverting to 4.23

iron sapphireBOT Apr 27, 2026, 4:28 PM

#

I’d stay on 4.23 for now if you need the gateway working today. Auth being restored after rollback is a good sign, and I wouldn’t risk breaking a working setup unless you’re okay doing a controlled debug pass.

If you do want to try again, let’s make it low-risk:

openclaw --version
openclaw gateway status --deep
openclaw doctor
openclaw update --dry-run

Then make a backup before updating:

cp -a ~/.openclaw ~/.openclaw.backup-$(date +%Y%m%d-%H%M%S)

#

Then:

openclaw update
openclaw gateway status --deep
openclaw logs --tail 200

If it breaks, paste gateway status --deep + the last 200 logs here before rolling back. That’ll tell us whether this is service path drift, config guard, plugin runtime deps, or an auth migration issue.

Docs for this flow: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/troubleshooting

placid barn Apr 27, 2026, 4:32 PM

#

From Agent:
Issue: updating OpenClaw to 2026.4.25 made gateway restart health check fail. Downgrade to 2026.4.24 also failed. Downgrade to 2026.4.23 restored gateway connectivity, but now CLI warns:
Config was last written by a newer OpenClaw (2026.4.25); current version is 2026.4.23.
Timeline:

openclaw update on 2026.4.25: update OK, plugin updates none, but Completion cache update failed: spawnSync /usr/bin/node ETIMEDOUT; gateway restart failed health check: expected 2026.4.25, gateway unavailable, port 18789 free.
openclaw doctor: gateway timeout after 10000ms; port later showed in use by local gateway; doctor restart made it say gateway not running.
openclaw update --tag 2026.4.24 --yes: same restart health failure, same completion cache timeout.
openclaw doctor --fix on 2026.4.24: warns config written by 2026.4.25; gateway stopped/activating/auto-restart, last exit 1.
openclaw update --tag 2026.4.23 --yes: daemon restart completed; gateway usable again.
Current openclaw gateway status --deep on 2026.4.23: systemd enabled, command is node openclaw dist index gateway --port 18789, config is ~/.openclaw/openclaw.json, bind loopback 127.0.0.1, port 18789, runtime running/active, connectivity probe OK, listening on 127.0.0.1:18789.
Only config audit write in the failure window was openclaw doctor --non-interactive --fix; gatewayMode stayed local before/after.
Current logs repeatedly show:
amazon-bedrock-mantle failed to load ... Cannot find module './user-profiles.js'
Require stack includes:
dist/extensions/amazon-bedrock-mantle/node_modules/@anthropic-ai/sdk/resources/beta/beta.js
Local check: user-profiles.js exists in root and other extension @anthropic-ai/sdk trees, but not in amazon-bedrock-mantle’s nested SDK tree.
Question: safest way to repair package/plugin runtime deps and return to 2026.4.25 without breaking gateway? I don’t want to share raw config/env/auth/logs with tokens.

iron sapphireBOT Apr 27, 2026, 4:34 PM

#

Yep — this looks less like auth and more like a broken/default-enabled amazon-bedrock-mantle plugin dependency in 4.24/4.25.

Safest path: disable that plugin first, then upgrade. If you’re not using AWS Bedrock Mantle, this is the cleanest workaround.

openclaw plugins disable amazon-bedrock-mantle
openclaw gateway restart
openclaw gateway status --deep

Then move the staged runtime deps aside instead of deleting them:

STAMP=$(date +%Y%m%d-%H%M%S)
[ -d ~/.openclaw/plugin-runtime-deps ] && mv ~/.openclaw/plugin-runtime-deps ~/.openclaw/plugin-runtime-deps.bak-$STAMP

#

Then reinstall 4.25 via the installer rather than openclaw update:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.25 --no-onboard

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

The completion cache timeout is probably a warning, not the root cause. The important thing is whether the gateway starts cleanly after Bedrock Mantle is disabled.

If that works, I’d keep amazon-bedrock-mantle disabled and file a GitHub issue with just the redacted error + version timeline: https://github.com/openclaw/openclaw/issues

Docs refs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/tools/plugin

placid barn Apr 27, 2026, 5:45 PM

#

I tried your update path and now it's stuck again with no gateway

iron sapphireBOT Apr 27, 2026, 5:46 PM

#

Ah damn — sorry, let’s stop trying to update and get you back to a running gateway first.

Try one salvage attempt on the currently installed version:

openclaw --version

openclaw plugins disable amazon-bedrock-mantle
# if that command fails, run this instead:
openclaw config set plugins.entries.amazon-bedrock-mantle.enabled false

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

If gateway status --deep is still not OK, rollback to the known-good 4.23 immediately:

#

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.23 --no-onboard

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart

openclaw gateway status --deep

If that still doesn’t restore it, paste only these outputs — no config/env/auth:

openclaw --version
openclaw gateway status --deep
openclaw logs --tail 120

#

For now I would not attempt 4.25 again. This smells like a real packaged bundled-plugin dependency issue around amazon-bedrock-mantle, not something you misconfigured.

placid barn Apr 27, 2026, 5:47 PM

#

my agent disabled amazon-bedrock per your recomendations pre-update. coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw gateway status --deep

🦞 OpenClaw 2026.4.25 (aa36ee6)
If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/coy/.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 11520, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 11520 coy: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 5:48 PM

#

This is useful: the gateway process is alive and listening, but the WS probe times out. So it’s not “port conflict”; it’s a hung/unresponsive gateway during startup.

Don’t roll back yet. First verify Bedrock Mantle is really disabled in 4.25:

openclaw config get plugins.entries.amazon-bedrock-mantle.enabled
openclaw plugins list --enabled | grep -i bedrock

Expected: false / no enabled bedrock-mantle entry.

Then grab only relevant, redacted log lines:

grep -Ei "error|failed|timeout|cannot find module|amazon-bedrock|mantle|plugin|runtime deps|staging|unhandled" /tmp/openclaw/openclaw-2026-04-27.log | tail -120

#

If that shows the same user-profiles.js / Mantle error even after disabling, then the disable didn’t apply or default-enabled plugin loading is still biting.

Next safe test is foreground startup so we can see where it hangs:

openclaw gateway stop
openclaw gateway run

Let it sit ~30s. If it prints a repeating error or gets stuck at a specific plugin/channel, paste that section only. No config/env/auth needed.

placid barn Apr 27, 2026, 5:49 PM

#

oy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw config get plugins.entries.amazon-bedrock-mantle.enabled

🦞 OpenClaw 2026.4.25 (aa36ee6) — The only crab in your contacts you actually want to hear from. 🦞

false
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw plugins list --enabled | grep -i bedrock
│ @openclaw/ │ amazon- │ openclaw │ enabled │ stock:amazon-bedrock/index.js │ 2026.4.25 │
│ amazon- │ bedrock │ │ │ │ │
│ bedrock- │ │ │ │ │ │
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 5:50 PM

#

That grep output is standard amazon-bedrock, not amazon-bedrock-mantle. So Mantle is disabled, but the regular Bedrock plugin is still enabled/default-enabled.

Let’s temporarily disable both Bedrock plugins to isolate startup:

openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle

# verify
openclaw config get plugins.entries.amazon-bedrock.enabled
openclaw config get plugins.entries.amazon-bedrock-mantle.enabled

openclaw gateway restart
sleep 10
openclaw gateway status --deep

#

Expected: both config gets should be false, and plugins list --enabled | grep -i bedrock should return nothing.

Also: Port 18789 is already in use is fine here — it’s in use by the gateway itself. The real problem is connectivity probe timeout, meaning the process is listening but stuck/not completing the WS handshake.

If it still times out after disabling regular Bedrock too, paste this filtered output:

grep -Ei "error|failed|timeout|cannot find module|bedrock|mantle|plugin|runtime deps|staging|unhandled" /tmp/openclaw/openclaw-2026-04-27.log | tail -160

placid barn Apr 27, 2026, 5:50 PM

#

I pulled the debug lines - but they are WAY too big to paste here, how can I get them to you

iron sapphireBOT Apr 27, 2026, 5:50 PM

#

Don’t paste the huge blob here. Make a small redacted attachment and upload it to this thread.

Run this:

LOG=/tmp/openclaw/openclaw-2026-04-27.log
OUT=/tmp/openclaw-debug-redacted.txt

grep -Ei "error|failed|timeout|cannot find module|bedrock|mantle|plugin|runtime deps|staging|unhandled|websocket|ws|probe" "$LOG" \
  | tail -300 \
  | sed -E \
    -e 's/(sk-[A-Za-z0-9_-]{16,})/[REDACTED_KEY]/g' \
    -e 's/(gh[pousr]_[A-Za-z0-9_]{16,})/[REDACTED_GITHUB_TOKEN]/g' \
    -e 's/(xox[baprs]-[A-Za-z0-9-]+)/[REDACTED_SLACK_TOKEN]/g' \
    -e 's/(token|apiKey|password|secret)=([^ ]+)/\1=[REDACTED]/Ig' \
    -e 's/(Bearer )[A-Za-z0-9._~+\/=-]+/\1[REDACTED]/g' \

#

  > "$OUT"

wc -l "$OUT"

Then open/read /tmp/openclaw-debug-redacted.txt yourself once to make sure there are no secrets, and attach that .txt file here.

If it’s still too big:

tail -120 /tmp/openclaw-debug-redacted.txt > /tmp/openclaw-debug-redacted-small.txt

Upload the small one. Also include:

#

openclaw --version
openclaw config get plugins.entries.amazon-bedrock.enabled
openclaw config get plugins.entries.amazon-bedrock-mantle.enabled

Docs ref: https://docs.openclaw.ai/gateway/troubleshooting

placid barn Apr 27, 2026, 5:51 PM

#

paste the whole thing starting with LOG into wsl?

iron sapphireBOT Apr 27, 2026, 5:51 PM

#

Yes — paste the whole block into WSL as one chunk, starting with LOG=... and ending with wc -l "$OUT".

Use this slightly safer copy:

LOG=/tmp/openclaw/openclaw-2026-04-27.log
OUT=/tmp/openclaw-debug-redacted.txt

grep -Ei "error|failed|timeout|cannot find module|bedrock|mantle|plugin|runtime deps|staging|unhandled|websocket|ws|probe" "$LOG" \
  | tail -300 \
  | sed -E \
    -e 's/(sk-[A-Za-z0-9_-]{16,})/[REDACTED_KEY]/g' \
    -e 's/(gh[pousr]_[A-Za-z0-9_]{16,})/[REDACTED_GITHUB_TOKEN]/g' \
    -e 's/(xox[baprs]-[A-Za-z0-9-]+)/[REDACTED_SLACK_TOKEN]/g' \
    -e 's/(token|apiKey|password|secret)=([^ ]+)/\1=[REDACTED]/Ig' \
    -e 's/(Bearer )[A-Za-z0-9._~+\/=-]+/\1[REDACTED]/g' \

#

  > "$OUT"

wc -l "$OUT"
echo "Created: $OUT"

Then open/review it before uploading:

nano /tmp/openclaw-debug-redacted.txt

If it looks safe, attach /tmp/openclaw-debug-redacted.txt here.

placid barn Apr 27, 2026, 5:51 PM

#

the command is split into two code boxes, can you put it into one for me please

iron sapphireBOT Apr 27, 2026, 5:51 PM

#

Yep — paste this whole thing as one block:

LOG=/tmp/openclaw/openclaw-2026-04-27.log
OUT=/tmp/openclaw-debug-redacted.txt
grep -Ei "error|failed|timeout|cannot find module|bedrock|mantle|plugin|runtime deps|staging|unhandled|websocket|ws|probe" "$LOG" | tail -300 | sed -E -e 's/(sk-[A-Za-z0-9_-]{16,})/[REDACTED_KEY]/g' -e 's/(gh[pousr]_[A-Za-z0-9_]{16,})/[REDACTED_GITHUB_TOKEN]/g' -e 's/(xox[baprs]-[A-Za-z0-9-]+)/[REDACTED_SLACK_TOKEN]/g' -e 's/(token|apiKey|password|secret)=([^ ]+)/\1=[REDACTED]/Ig' -e 's/(Bearer )[A-Za-z0-9._~+\/=-]+/\1[REDACTED]/g' > "$OUT"
wc -l "$OUT"
echo "Created: $OUT"
nano "$OUT"

placid barn Apr 27, 2026, 5:52 PM

#

idk where this is at to provide it to you? coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ echo "Created: $OUT"
Created: /tmp/openclaw-debug-redacted.txt

iron sapphireBOT Apr 27, 2026, 5:52 PM

#

It’s inside WSL at /tmp/openclaw-debug-redacted.txt. Easiest way to get it into Discord from Windows:

cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/$USER/Desktop/openclaw-debug-redacted.txt

If that says the path doesn’t exist, run:

cmd.exe /C "echo %USERPROFILE%"

Then copy it manually using that Windows path, for example:

cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/YOUR_WINDOWS_USERNAME/Desktop/openclaw-debug-redacted.txt

#

Then attach openclaw-debug-redacted.txt from your Windows Desktop here.

You can also just print the last bit if attaching is annoying:

tail -120 /tmp/openclaw-debug-redacted.txt

placid barn Apr 27, 2026, 5:53 PM

#

echo "Created: $OUT"
nano "$OUT"coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ wc -l "$OUT"
300 /tmp/openclaw-debug-redacted.txt
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ echo "Created: $OUT"
Created: /tmp/openclaw-debug-redacted.txt
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ nano "$OUT"
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/$USER/Desktop/openclaw-debug-redacted.txt
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/YOUR_WINDOWS_USERNAME/Desktop/openclaw-debug-redacted.txt
cp: cannot create regular file '/mnt/c/Users/YOUR_WINDOWS_USERNAME/Desktop/openclaw-debug-redacted.txt': No such file or directory
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ cmd.exe /C "echo %USERPROFILE%"
C:\Users\coybe
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/YOUR_WINDOWS_USERNAME/Desktop/openclaw-debug-redacted.txt
cp: cannot create regular file '/mnt/c/Users/YOUR_WINDOWS_USERNAME/Desktop/openclaw-debug-redacted.txt': No such file or directory
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 5:53 PM

#

You found the Windows username: coybe. Use that literally — not YOUR_WINDOWS_USERNAME:

mkdir -p /mnt/c/Users/coybe/Desktop
cp /tmp/openclaw-debug-redacted.txt /mnt/c/Users/coybe/Desktop/openclaw-debug-redacted.txt
explorer.exe C:\\Users\\coybe\\Desktop

Then attach openclaw-debug-redacted.txt from the Desktop here.

Also: your earlier $USER copy may already have worked if /mnt/c/Users/coy/Desktop exists, but coybe is the real Windows profile path from %USERPROFILE%.

placid barn Apr 27, 2026, 5:54 PM

#

how do i attach it here? it's not letting me

iron sapphireBOT Apr 27, 2026, 5:54 PM

#

No worries — skip the attachment. Paste a smaller slice directly:

tail -80 /tmp/openclaw-debug-redacted.txt

If that’s still too big, use this:

grep -Ei "cannot find module|failed to load|unhandled|fatal|startup|listening|gateway|probe|timeout" /tmp/openclaw-debug-redacted.txt | tail -60

Paste the output from one of those here. That should be enough.

placid barn Apr 27, 2026, 5:56 PM

#

dog you are confusing me - im not a coder or programer, so the tail -80 /tmp/openclaw-debug-redacted.txt command just spit out a fuck ton of code - what do i do with it

iron sapphireBOT Apr 27, 2026, 5:56 PM

#

You’re right — I made that way too fiddly. Sorry. Let’s simplify.

Since 4.23 worked, just get back to stable first:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.23 --no-onboard
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart
openclaw gateway status --deep

If Connectivity probe: ok, stop there. Stay on 4.23 for now.

Then for the 4.25 bug report, don’t worry about logs. Just file/paste this summary:

Updating from 2026.4.23 to 2026.4.25 on WSL/systemd caused gateway to listen on 127.0.0.1:18789 but WS connectivity probe timed out. amazon-bedrock-mantle was disabled before update, regular amazon-bedrock still appeared enabled/default-enabled. Downgrading to 2026.4.23 restored gateway. Update also showed Completion cache update failed: spawnSync /usr/bin/node ETIMEDOUT.

#

Issue link: https://github.com/openclaw/openclaw/issues

I’d stop debugging the giant log in Discord — not worth the pain.

placid barn Apr 27, 2026, 5:56 PM

#

my agent is responding on 4.25 but he is ungoldy slow and there is tons of toolcalls idkw hat they are

#

i want to provide you my logs but i cna't seem to get you one short enought o paste here

iron sapphireBOT Apr 27, 2026, 5:57 PM

#

Okay — good news: if your agent is responding on 4.25, the gateway isn’t dead anymore. It’s probably stuck chewing through the giant debug/log context or some plugin/model discovery is making startup/tool use painfully slow.

For now, don’t feed it more logs. Do this simple reset:

openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle
openclaw gateway restart

Then start a fresh new chat/session with your agent if you can, and send only:

Are you working? Reply in one sentence and do not use tools.

If that’s fast, the slowness was the previous session/log context. If it’s still painfully slow, I’d roll back to 4.23 and wait for a fix — 4.25 is not behaving well on your setup.

Toolcalls = the agent using tools in the background. They’re not “code you need to understand,” but if there are tons of them, the agent may be stuck in a loop or over-debugging.

#

Totally fair. Let’s make WSL shrink it for you.

Paste this one block into WSL. It will copy a short, redacted summary to your Windows clipboard:

LOG=$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1); { echo "LOG: $LOG"; echo "--- last important lines ---"; grep -Ei "error|failed|timeout|cannot find module|unhandled|fatal|probe|runtime deps|staging|bedrock|mantle|plugin" "$LOG" 2>/dev/null | tail -15; } | sed -E -e 's/(sk-[A-Za-z0-9_-]{16,})/[REDACTED_KEY]/g' -e 's/(Bearer )[A-Za-z0-9._~+\/=-]+/\1[REDACTED]/g' -e 's/(token|apiKey|password|secret)=([^ ]+)/\1=[REDACTED]/Ig' | cut -c1-220 | tee /tmp/openclaw-short-log.txt | clip.exe; echo "Copied short log summary. Now paste here with Ctrl+V."

Then just click Discord and press Ctrl+V.

If Ctrl+V pastes nothing, run:

cat /tmp/openclaw-short-log.txt

…and paste that output here.

placid barn Apr 27, 2026, 5:58 PM

#

1400 char too long - discord fucking sucks for getting you usable data ithe limits are too short

iron sapphireBOT Apr 27, 2026, 5:58 PM

#

Yeah, Discord is being a pain here. Let’s make it tiny — 8 lines max, 140 chars per line, copied to clipboard:

LOG=$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1); { echo "LOG: $(basename "$LOG")"; grep -Ei "error|failed|timeout|cannot find module|unhandled|fatal|probe|runtime deps|staging|bedrock|mantle|plugin" "$LOG" 2>/dev/null | tail -7; } | sed -E -e 's/(sk-[A-Za-z0-9_-]{16,})/[KEY]/g' -e 's/(Bearer )[A-Za-z0-9._~+\/=-]+/\1[REDACTED]/g' -e 's/(token|apiKey|password|secret)=([^ ]+)/\1=[REDACTED]/Ig' | cut -c1-140 | tee /tmp/openclaw-tiny-log.txt | clip.exe; echo "Copied tiny log. Paste here."

If that’s still too long, run this and paste just the single line it prints:

grep -Ei "cannot find module|unhandled|fatal|probe|timeout|failed" /tmp/openclaw/openclaw-2026-04-27.log | tail -1 | cut -c1-250

placid barn Apr 27, 2026, 5:59 PM

#

LOG: openclaw-2026-04-27.log
{"0":"{"subsystem":"plugins"}","1":"bonjour: disabling advertiser after 3 failed restarts (service stuck in announcing for 62750ms (gate
{"0":"{"subsystem":"plugins"}","1":"active-memory: agent=main session=agent:main:main activeProvider=openai-codex activeModel=gpt-5.5 do
{"0":"{"subsystem":"agent/embedded"}","1":{"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","sur
{"0":"{"subsystem":"plugins"}","1":"memory-core: managed dreaming cron could not be reconciled (cron service unavailable).","_meta":{"ru
{"0":"{"subsystem":"plugins"}","1":"active-memory: agent=main session=agent:main:main activeProvider=openai-codex activeModel=gpt-5.5 st
{"0":"{"subsystem":"plugins"}","1":"active-memory: agent=main session=agent:main:main activeProvider=openai-codex activeModel=gpt-5.5 do
{"0":"{"subsystem":"agent/embedded"}","1":{"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","sur

iron sapphireBOT Apr 27, 2026, 5:59 PM

#

You got me enough. The tiny log points at active-memory + failover spam, not Bedrock. The bonjour line is also a WSL/LAN-discovery annoyance and safe to turn off.

Run this one block to calm it down:

openclaw plugins disable bonjour
openclaw plugins disable active-memory
openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart
openclaw gateway status --deep

Then start a fresh chat with your agent and send:

Reply "ok" only. Do not use tools.

#

If that’s fast, the issue was active-memory / background memory stuff causing a ton of toolcalls. You can keep those disabled for now on 4.25.

If it’s still slow after that, I’d roll back to 4.23 and stop fighting 4.25 today. You’ve done enough debugging hell for one afternoon.

placid barn Apr 27, 2026, 6:00 PM

#

I cant even load the logs page in gui wtf. My openclaw has been so messed up and almost non-usable for a while now. IDK if my agent fucked up some configs or settings or modules that update doesn't wipe - but I have issues with heartbeat prompting over and over with tool calls, tons of tool calls that freeze up the system, internal openclaw context being inuected back into convo loop without me doign it. I have had my agent scan and scan and can't figoure out what in the fuck is brekaing my system

iron sapphireBOT Apr 27, 2026, 6:01 PM

#

Yeah, this sounds like your state/config/session has gotten toxic, not just “4.25 bad.” I’m sorry — I dragged you through too much log wrangling.

Let’s stop debugging and put OpenClaw in quiet/safe mode. Paste this one block:

openclaw system heartbeat disable
openclaw config set agents.defaults.heartbeat.every "0m"
openclaw config set tools.exec.notifyOnExit false
openclaw plugins disable active-memory
openclaw plugins disable bonjour
openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle
openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart
openclaw gateway status --deep

#

Then start a brand-new chat/session with your agent. Don’t continue the huge debugging session. Send only:

Reply ok only. Do not use tools.

If it’s still busted after that, I’d do a reversible clean reset: backup ~/.openclaw, start fresh, re-onboard. That’s the “stop the bleeding” path — not elegant, but sane when logs/UI/sessions/tool loops are all poisoned.

placid barn Apr 27, 2026, 6:02 PM

#

is it easy to reverse this step if It screws stuff up?

iron sapphireBOT Apr 27, 2026, 6:02 PM

#

Yes — mostly. It only disables noisy features; it doesn’t delete auth, sessions, memory, or config files.

Make a backup first so reversal is easy:

cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-quiet-mode

To reverse the quiet-mode changes later:

openclaw system heartbeat enable
openclaw config set agents.defaults.heartbeat.every "30m"
openclaw config set tools.exec.notifyOnExit true
openclaw plugins enable active-memory
openclaw plugins enable bonjour

#

openclaw plugins enable amazon-bedrock
openclaw plugins enable amazon-bedrock-mantle
openclaw config set plugins.entries.memory-core.config.dreaming.enabled true
openclaw gateway restart

Or full config rollback:

cp ~/.openclaw/openclaw.json.before-quiet-mode ~/.openclaw/openclaw.json
openclaw gateway restart

My recommendation: do the backup, then quiet mode. It’s low-risk and gives you breathing room.

placid barn Apr 27, 2026, 6:03 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-quiet-mode
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:03 PM

#

Perfect — backup is done.

Now paste this one block:

openclaw system heartbeat disable
openclaw config set agents.defaults.heartbeat.every "0m"
openclaw config set tools.exec.notifyOnExit false
openclaw plugins disable active-memory
openclaw plugins disable bonjour
openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle
openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart
openclaw gateway status --deep

#

After that, if Connectivity probe: ok, start a fresh agent chat and send:

Reply ok only. Do not use tools.

placid barn Apr 27, 2026, 6:04 PM

#

it's running right now. Krill, i hope you can help me sort this out, i have almost given up on OC because it's been so buggy and nearly unusable. I have wasted 20+ hours trying to get it working and I'm so close to just giveing up totally on it

iron sapphireBOT Apr 27, 2026, 6:04 PM

#

I hear you. 20+ hours of “why is my assistant fighting me” is brutal, and honestly you’ve been way more patient than most people would be.

If it’s running now, don’t keep changing things yet. Let’s stabilize first:

Confirm gateway is healthy:

openclaw gateway status --deep

If it says Connectivity probe: ok, start a brand-new chat/session and send only:

Reply ok only. Do not use tools.

If that’s fast, we leave quiet mode on for now and add features back one at a time later.

#

The big picture: your setup probably had multiple noisy systems interacting — heartbeat, active-memory, dreaming/cron, bonjour, maybe Bedrock discovery — so the agent kept waking itself, using tools, and stuffing internal context back into sessions. Quiet mode is meant to stop the bleeding, not be the final perfect config.

I’ll stick with you through it. For today, the goal is simple: make OC boring and responsive again before we turn anything fancy back on. 🦐

placid barn Apr 27, 2026, 6:04 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw system heartbeat disable
g set agents.defaults.heartbeat.every "0m"
openclaw config set tools.exec.notifyOnExit false
openclaw plugins disable active-memory
openclaw plugins disable bonjour
openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle
openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart

🦞 OpenClaw 2026.4.25 (aa36ee6) — I autocomplete your thoughts—just slower and with more API calls.

│
◒ Gateway set-heartbeatspenclaw config set agents.defaults.heartbeat.every "0m"
openclaw config set tools.exec.notifyOnExit false
openclaw plugins disable active-memory
openclaw plugins disable bonjour
openclaw plugins disable amazon-bedrock
openclaw plugins disable amazon-bedrock-mantle
openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart
openclaw gateway status --deep
◇
Error: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/coy/.openclaw/openclaw.json
Bind: loopback
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:05 PM

#

That paste got mangled. You didn’t do anything wrong — the first command timed out, then the rest got shoved into the CLI weirdly.

Do not paste a big block now. Run these one line at a time and wait for the prompt after each:

systemctl --user stop openclaw-gateway

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

openclaw config set tools.exec.notifyOnExit false

#

openclaw config set plugins.entries.active-memory.enabled false

openclaw config set plugins.entries.bonjour.enabled false

openclaw config set plugins.entries.amazon-bedrock.enabled false

openclaw config set plugins.entries.amazon-bedrock-mantle.enabled false

#

openclaw config set plugins.entries.memory-core.config.dreaming.enabled false

Then start it:

systemctl --user restart openclaw-gateway

Wait 15 seconds, then:

openclaw gateway status --deep

Important: skip openclaw system heartbeat disable for now — that talks to the gateway, and your gateway is timing out. The config set lines are safer because they edit the config directly.

placid barn Apr 27, 2026, 6:08 PM

#

i ran the commands you told me to - did you tell me to disable heartbeat in them and THEN AT THE END tell me not to?!?!?!?!?!?!?!? WTF?

iron sapphireBOT Apr 27, 2026, 6:09 PM

#

You’re right to be pissed. I communicated that badly.

Clarification: disabling heartbeat was intentional. What I meant was: don’t use the command

openclaw system heartbeat disable

because that tries to talk to the gateway and your gateway was timing out. The safe way was this config edit:

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

So: heartbeat disabled = yes, on purpose.
openclaw system heartbeat disable = avoid for now, because gateway is unhealthy.

#

You didn’t screw anything up. The config backup you made can restore it later.

Right now, please just run:

openclaw gateway status --deep

and paste only whether it says:

Connectivity probe: ok, or
Connectivity probe: failed / timeout

I’m sorry — that was confusing as hell and that’s on me.

placid barn Apr 27, 2026, 6:09 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw gateway status --deep
Config warnings:

plugins.entries.active-memory: plugin disabled (disabled in config) but config is present

🦞 OpenClaw 2026.4.25 (aa36ee6) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/coy/.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 12603, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 12603 coy: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:09 PM

#

That warning is harmless. The important part is still:

Gateway process is running + listening, but WS probe times out. Quiet mode didn’t fix 4.25.

At this point I’d stop fighting 4.25 and get you back to the version that worked. Run these one at a time:

systemctl --user stop openclaw-gateway

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.23 --no-onboard

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force

#

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart

openclaw gateway status --deep

If 4.23 shows Connectivity probe: ok, stay there. This 4.25 failure is issue-worthy, but your priority should be getting a usable assistant again.

placid barn Apr 27, 2026, 6:19 PM

#

1 of 2: coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw gateway status --deep
Config warnings:

plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
plugins.entries.active-memory: plugin disabled (disabled in config) but config is present
Config was last written by a newer OpenClaw (2026.4.25); current version is 2026.4.23.

🦞 OpenClaw 2026.4.23 (a979721) — Hot reload for config, cold sweat for deploys.

Config was last written by a newer OpenClaw (2026.4.25); current version is 2026.4.23.
Config was last written by a newer OpenClaw (2026.4.25); current version is 2026.4.23.
│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/coy/.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

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/coy/.fnm/aliases/default/bin)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

#

2/2: 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 14727, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 14727 coy: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:19 PM

#

Good — 4.23 is installed again. Don’t run more fixes yet.

Those warnings are not the main problem:

bonjour plugin not found = stale quiet-mode entry, harmless for now.
active-memory disabled but config present = harmless.
config last written by newer OpenClaw = expected after downgrading from 4.25.
PATH/fnm warning = worth cleaning later, but not the urgent thing.

Please send 2 of 2 — the part that includes:

Runtime:
Connectivity probe:

That tells us whether 4.23 is actually usable again.

#

If it says Connectivity probe: ok, stop changing things and we’ll stabilize from there.
If it still says timeout, then the next target is the systemd service/PATH issue.

Docs for the status fields: https://docs.openclaw.ai/gateway/troubleshooting

#

Okay. Since 4.23 also listens but times out, this is no longer just “bad 4.25 update.” Your local OpenClaw state/config/session store is probably poisoned.

I’d stop doing tiny fixes. Best next move is a reversible clean-state reset.

This backs up everything first, then starts OpenClaw fresh. You may need to re-onboard/reconnect things, but your old setup is preserved.

Only run this if you’re okay doing a fresh setup test:

systemctl --user stop openclaw-gateway
mv ~/.openclaw ~/.openclaw.broken-$(date +%Y%m%d-%H%M%S)
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.23 --no-onboard
openclaw onboard --install-daemon

If fresh OpenClaw works, we know the old ~/.openclaw state was the problem. Then we can selectively recover memory/config later.

#

To undo the reset, you’d stop the gateway and move the backup back.

I know this sucks. But given the heartbeat loops, injected internal context, frozen toolcalls, GUI logs failing, and WS timeouts across versions — this is the sane path now.

placid barn Apr 27, 2026, 6:22 PM

#

he seems to be running a little faster with heartbeat disabled. So with the commands we ran - what all did we disable? just heartbeat?

iron sapphireBOT Apr 27, 2026, 6:22 PM

#

Not just heartbeat. We put it into “quiet mode” and disabled the noisy/background-ish pieces:

Heartbeat cadence: agents.defaults.heartbeat.every = "0m"
Stops scheduled heartbeat model runs.
Exec notify-on-exit: tools.exec.notifyOnExit = false
Stops completed background shell tasks from waking the agent via heartbeat/system events.
Active Memory plugin: plugins.entries.active-memory.enabled = false
Stops the extra memory-recall pass/toolcalls before replies.
Bonjour plugin: plugins.entries.bonjour.enabled = false
Stops LAN discovery advertising. Not needed for most WSL/local setups.
Amazon Bedrock provider plugin: disabled
Stops Bedrock provider/discovery/plugin loading.

#

Amazon Bedrock Mantle provider plugin: disabled
Stops Mantle provider loading — this was suspicious earlier from the missing module error.
Memory-core dreaming: plugins.entries.memory-core.config.dreaming.enabled = false
Stops background dream/cron memory sweeps.

What we did not delete: auth, sessions, memory, workspace, channel credentials, or your backup config.

Given it’s faster now, I’d keep this quiet mode for a bit and only re-enable features one at a time later.

placid barn Apr 27, 2026, 6:25 PM

#

so with those turned off.. am I really missing anything? Could we try turning memory back on now that things are smoother?

iron sapphireBOT Apr 27, 2026, 6:25 PM

#

Yes — with those off, you’re mostly missing convenience/background features, not core agent functionality.

You probably still have normal memory files/workspace available. What we disabled was mainly:

Active Memory: automatic memory recall before replies. Nice, but can add toolcalls/latency.
Dreaming: background memory processing. Definitely optional.
Heartbeat: proactive scheduled runs. Optional.
Bonjour/Bedrock: not needed unless you use LAN discovery or Bedrock models.

If things are smoother, I’d re-enable only Active Memory first, not dreaming yet.

Run:

openclaw config set plugins.entries.active-memory.enabled true
openclaw gateway restart

#

Then test in a fresh chat:

Reply ok only. Do not use tools.

If that’s still fast, try a real memory-ish prompt. If toolcalls explode again, turn it back off:

openclaw config set plugins.entries.active-memory.enabled false
openclaw gateway restart

I’d keep dreaming and heartbeat off until you’ve had a stable day. Active Memory is the one worth testing first.

placid barn Apr 27, 2026, 6:29 PM

#

a little slower, but working, how can we check for errors/issues?

iron sapphireBOT Apr 27, 2026, 6:29 PM

#

Nice — slower-but-working is a win. Now we check read-only, no fixing yet.

Run this one block:

openclaw gateway status --deep | grep -E "Config warnings|Runtime:|Connectivity probe:|Capability:|timeout|failed|error"

echo "--- recent important log lines ---"
LOG=$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1)
grep -Ei "error|failed|timeout|cannot find module|unhandled|fatal|active-memory|heartbeat|dreaming|plugin" "$LOG" 2>/dev/null | tail -20 | cut -c1-180

What we want:

Connectivity probe: ok
no repeating failover, timeout, Cannot find module, or active-memory spam

#

Also run this, but don’t use --fix yet:

openclaw doctor

If doctor prints a wall of text, paste only the warnings/errors. Ignore the old “config written by newer OpenClaw” warning for now if you’re on 4.23.

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

placid barn Apr 27, 2026, 6:30 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw gateway status --deep | grep -E "Config warnings|Runtime:|Connectivity probe:|Capability:|timeout|failed|error"
"--- recent important log lines ---"
LOG=$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1)
grep -Ei "error|failed|timeout|cannot find module|unhandled|fatal|active-memory|heartbeat|dreaming|plugin" "$LOG" 2>/dev/null | tail -20 | cut -c1-180
Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/coy/.fnm/aliases/default/bin)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Runtime: running (pid 15678, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:30 PM

#

That’s actually a good result:

Runtime: running
Connectivity probe: ok
Capability: admin-capable
no important log errors printed

So we’ve got a healthy gateway again. 🎉

The only thing showing is the service PATH warning:

PATH includes version managers ... /home/coy/.fnm/aliases/default/bin

That’s not urgent. It means systemd is starting OpenClaw with a shell/version-manager-ish PATH. It can cause weirdness after Node/OpenClaw upgrades, but since the gateway is healthy now, I’d not touch it tonight unless you want to keep debugging.

#

Recommended current state:

Keep heartbeat off
Keep dreaming off
Keep Bedrock/Bedrock Mantle off unless you use those models
Active Memory is okay if the speed is acceptable
Stay on 2026.4.23 for now

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future users.

placid barn Apr 27, 2026, 6:31 PM

#

◇ Archive 6 orphan transcript files in ~/.openclaw/agents/main/sessions? This only renames them to
│ *.deleted.<timestamp>.
│ No
│
◇ State integrity ─────────────────────────────────────────────────────────────────────────╮
│ │
│ - Found 6 orphan transcript files in ~/.openclaw/agents/main/sessions. │
│ These .jsonl files are no longer referenced by sessions.json, so they are not part of │
│ any active session history. │
│ Doctor can archive them safely by renaming each file to *.deleted.<timestamp>. │
│ Examples: 29dc40f0-4b72-4927-99f6-8b31a2760bea.trajectory.jsonl, │
│ 36ed3b1c-1739-46e5-a867-1f5afa3204e0.trajectory.jsonl, │
│ 67802932-1e75-4e1e-85ad-0eaa5a1bfd83.trajectory.jsonl, and 3 more │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Gateway service config ────────────────────────────────────────────────────────────╮
│ │
│ - Gateway service PATH includes version managers or package managers; recommend a │
│ minimal PATH. (/home/coy/.fnm/aliases/default/bin) │
│ │
├─────────────────────────────────────────────────────────────────────────────────────╯
│
◆ Update gateway service config to the recommended defaults now?
│ ● Yes / ○ No
└

iron sapphireBOT Apr 27, 2026, 6:31 PM

#

For this prompt: choose Yes.

That one updates the systemd gateway service config to recommended defaults/minimal PATH. It’s exactly the warning we saw, and it should reduce future weirdness from fnm/Node path drift.

For the orphan transcripts: choosing No was fine. They’re harmless, just old unreferenced session files.

After you choose Yes, run:

openclaw gateway restart
openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:|PATH|warning|failed|timeout"

We want to see Connectivity probe: ok and ideally no PATH warning.

placid barn Apr 27, 2026, 6:32 PM

#

one issue I have been having is that it defaults me to openai/gpt5.5 not openai-codex path for my config

iron sapphireBOT Apr 27, 2026, 6:32 PM

#

Yeah — that’s a separate config issue.

For the Codex OAuth/subscription route, the model ref needs the openai-codex/… provider prefix. openai/... is the normal OpenAI provider/API-key route.

Run:

openclaw models status
openclaw models set openai-codex/gpt-5.5
openclaw models status

If it says the model is not allowed, add it to the allowlist first:

openclaw config set agents.defaults.models '{"openai-codex/gpt-5.5":{}}' --strict-json --merge

#

openclaw models set openai-codex/gpt-5.5

Also: existing chats can keep a per-session model override. In a fresh chat it should use the default; in an existing chat, use:

/model openai-codex/gpt-5.5
/model status

Docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/agent-runtimes

placid barn Apr 27, 2026, 6:35 PM

#

oy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw models status
Config warnings:

plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.23 (a979721) — I've seen your commit messages. We'll work on that together.

Config warnings:

plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.5
Fallbacks (3) : openai-codex/gpt-5.4, openai-codex/gpt-5.5, openai-codex/gpt-5.5-pro
Image model : -
Image fallbacks (0): -
Aliases (1) : gpt -> openai-codex/gpt-5.4
Configured models (4): openai-codex/gpt-5.4, openai/gpt-5.5, openai-codex/gpt-5.5, openai-codex/gpt-5.5-pro

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): anthropic (2), openai-codex (2)

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-o...0wJAXwAA, anthropic:manual=token:sk-ant-o...d1FT5AAA
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:default=OAuth, openai-codex:coy.beilby@protonmail.com=OAuth (coy.beilby@protonmail.com)
voyage effective=env:pa-GVEsB...lYu5WrjX | env=pa-GVEsB...lYu5WrjX | source=env: VOYAGE_API_KEY

OAuth/token status

anthropic
- anthropic:default static
- anthropic:manual static
openai-codex usage: 5h 88% left ⏱1h 4m · Week 55% left ⏱23h 46m
- openai-codex:coy.beilby@protonmail.com (coy.beilby@protonmail.com) ok expires in 8d
- openai-codex:default ok expires in 5d

iron sapphireBOT Apr 27, 2026, 6:35 PM

#

Good — your global default is already correct:

Default: openai-codex/gpt-5.5

So if you still see openai/gpt-5.5, it’s probably one of these:

That specific chat/session has an old model override
- In that chat, run:
```
/model status
/model openai-codex/gpt-5.5
```
A fallback or old configured model is still present
- You still have openai/gpt-5.5 in configured models, but it’s not default. Leave it for now unless it keeps being selected.

#

The UI is showing family/model name, not provider route
- gpt-5.5 can appear visually even when routed through openai-codex.

The only cleanup I’d do now is remove the stale Bonjour warning:

openclaw config unset plugins.entries.bonjour
openclaw gateway restart

But overall: model config looks healthy.

placid barn Apr 27, 2026, 6:36 PM

#

what is the downside to disabling bonjur or the notify at exit parts we did?

iron sapphireBOT Apr 27, 2026, 6:36 PM

#

Very small downsides for most setups:

Bonjour disabled

You lose LAN auto-discovery / “find my gateway automatically” behavior.
Relevant mostly for mobile apps, local network discovery, or devices trying to discover the gateway without a URL.
If you connect via http://127.0.0.1:18789, Tailscale, tunnel, or a known URL, you probably won’t miss it.

tools.exec.notifyOnExit = false

If your agent starts a long background command, OpenClaw won’t automatically wake the agent when that command finishes.
You may need to manually ask “did it finish?” or check status.
Upside: it prevents background processes from triggering surprise heartbeat/toolcall loops.

For your situation, I’d keep both off. Bonjour is optional, and notify-on-exit is only useful once everything is stable.

placid barn Apr 27, 2026, 6:37 PM

#

oh I have been having issues with him stopping a lot. I will say run 3 subagents to do this.. and no reply without prompting him. I'd love to fix that if possible so he can reply, BUT we don't get stuck back in tool call hell loops

iron sapphireBOT Apr 27, 2026, 6:38 PM

#

Yep — that specific behavior is exactly the downside of turning off notifyOnExit.

Good compromise:

Turn notify-on-exit back on
Keep heartbeat cadence off
Keep empty-success notifications off so it only wakes on meaningful output/failures, not every quiet success

Run:

openclaw config set tools.exec.notifyOnExit true
openclaw config set tools.exec.notifyOnExitEmptySuccess false
openclaw gateway restart

That should let background exec/subagent work wake the agent when something finishes, without restoring scheduled heartbeat loops.

placid barn Apr 27, 2026, 6:38 PM

#

I jsut ran 3 subagents with him to test it out - will let you know shortly

iron sapphireBOT Apr 27, 2026, 6:38 PM

#

Two notes:

For OpenClaw subagents, completion should usually push back automatically anyway. If it doesn’t, this may be a separate session/subagent issue.
For shell/background exec jobs, notifyOnExit=true is the setting that enqueues a system event + requests a heartbeat when the background job exits.

If loops come back, flip just this one back off:

openclaw config set tools.exec.notifyOnExit false
openclaw gateway restart

#

Sounds good. While that test runs, don’t change anything else.

What we’re watching for:

Do the subagents finish and report back without you poking?
Does the main agent stay responsive?
Do toolcalls stay reasonable instead of looping?

If it hangs again, the next thing to check is just:

openclaw gateway status --deep | grep -E "Connectivity probe:|Runtime:|Capability:"

and whether the main chat shows pending/running subagents.

placid barn Apr 27, 2026, 6:38 PM

#

yeah he failed and didn't reply after a few tool calls, so im going to rturn it back on

iron sapphireBOT Apr 27, 2026, 6:38 PM

#

Yep, turn notifyOnExit back on — that’s the right test result.

Use:

openclaw config set tools.exec.notifyOnExit true
openclaw config set tools.exec.notifyOnExitEmptySuccess false
openclaw gateway restart

Keep heartbeat cadence off for now:

openclaw config get agents.defaults.heartbeat.every

We want that to still say:

#

0m

That gives you completion wakeups without scheduled heartbeat spam.

placid barn Apr 27, 2026, 6:43 PM

#

Runtime/log findings
Gateway reachable, but runtime is:
Copy
2026.4.23
The subagent runtime lane got cut off by a gateway close/service restart event, so the system still isn’t perfectly stable under concurrent audit load.
Gateway process resource snapshot was high:
Copy
~68% CPU
~1 GB RSS
Status shows:
Copy
tasks: 264 tracked
active: 3
failures: 16
taskAudit: 1 error, 31 warnings
Memory findings
Partial, because the memory audit lane failed early and my direct openclaw memory status --json check timed out.

What we did verify:

Status summary earlier showed:
Copy
50 memory files
157 chunks
vector ready
fts ready
memory-core plugin active
Cron scheduler is enabled:
Copy
jobs: 18
Visible cron jobs include:
Memory Dreaming Promotion
Daily Toby Memory Steward
Coy Daily Brief
Weekly Toby Memory Steward
healthcheck:security-audit
dreaming follow-up checks
Concerns:

Memory status timing out is not good.
Cron list showed nextRunAt / lastRunStatus / lastRunAt as null for visible jobs, which may be CLI output shape weirdness, but I would not call cron health fully clean.
My read
The model fix helped responsiveness. Turning off heartbeat helped noise. Disabling Bedrock/Mantle removed one broken plugin path.

But the system still has three real issues:

We are still on 4.23, despite the 4.25 installer briefly reporting success.
Gateway is reachable but resource-heavy.
Memory/cron tooling is not reliably responsive under check load.
I would not do more big repair moves casually. Next best controlled move is probably to investigate why active runtime reverted/stayed at 4.23 and why service metadata/path is still pointed there, before trying another update.

#

Bottom line
The system is smoother, but not actually clean.

Verified right now:

Runtime/gateway is OpenClaw 2026.4.23, not 4.25.
Gateway is reachable and healthy from a connection standpoint.
Heartbeat is disabled for main and Sheldon.
Config model primary is fixed to openai-codex/gpt-5.5.
Bedrock/Mantle plugins are disabled.
Gateway CPU is still too high in one snapshot, around 68%, with ~1 GB RAM.
Memory CLI status timed out when I checked it, so memory responsiveness is still suspect.
Cron is enabled with 18 jobs, but the list output had missing/null run metadata for visible jobs.
Config findings
Good:

openclaw.json is valid, permissions 600, owner coy:coy.
Gateway is local/loopback only:
Copy
mode: local
bind: loopback
port: 18789
Telegram is allowlisted.
Hooks are enabled but restricted to main.
amazon-bedrock and amazon-bedrock-mantle are disabled.
Model primary is now:
Copy
openai-codex/gpt-5.5
Concerns:

Alias gpt still points to:
Copy
openai-codex/gpt-5.4
not 5.5.
openai/gpt-5.5 remains in allowed models, though not default.
Gateway service metadata still says 2026.4.23.
There is a stale bonjour plugin config warning:
Copy

iron sapphireBOT Apr 27, 2026, 6:45 PM

#

Your agent’s read is useful, but a few parts sound scarier than they are:

2026.4.23 is expected — we intentionally rolled back there because 4.25 was breaking.
Subagent lane cut off likely happened because we restarted the gateway during testing.
264 tasks tracked / 16 failures may be historical, not necessarily active trouble.
The real concern is: cron still has 18 jobs, and some of them sound like memory/dreaming/security audit jobs that can wake tool-heavy runs.

If you want “boring and stable,” I’d pause cron globally for now. This does not delete jobs; it just stops scheduled jobs from firing.

Run:

openclaw config set cron.enabled false
openclaw config unset plugins.entries.bonjour
openclaw gateway restart
openclaw cron status

#

openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"

Downside: daily briefs, memory steward jobs, security audits, dreaming follow-ups won’t run automatically.

To reverse later:

openclaw config set cron.enabled true
openclaw gateway restart

My recommended stable state for now:

heartbeat off
dreaming off

#

cron off
Bedrock/Mantle off
Bonjour removed/off
Active Memory on only if performance is acceptable
notifyOnExit on, so subagent/background completions can wake replies

Don’t chase 4.25 tonight. Get 4.23 calm first.

#

That read is basically right: smoother, not clean yet. I’d do only the low-risk cleanup now — no 4.25 update, no big repair.

Run these:

openclaw config set cron.enabled false
openclaw config unset plugins.entries.bonjour
openclaw models aliases remove gpt
openclaw models aliases add gpt openai-codex/gpt-5.5
openclaw gateway restart

Then verify:

openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:|warning|failed|timeout"

#

openclaw cron status
openclaw models status

What each does:

cron.enabled false: pauses all 18 scheduled jobs without deleting them. This is the big one for reducing surprise background load.
unset bonjour: removes the stale warning.
alias gpt → 5.5: makes /model gpt route to openai-codex/gpt-5.5.
openai/gpt-5.5 allowed model: leave it for now. It’s not default, so it’s harmless.

And yes: 2026.4.23 is expected right now. Don’t treat that as a problem tonight — that’s our known-good recovery version.

placid barn Apr 27, 2026, 6:46 PM

#

i want crons on because thats how i schewdule reminders and do daily brief which are important to me

iron sapphireBOT Apr 27, 2026, 6:46 PM

#

Totally fair — then don’t disable cron globally. Keep cron on, but prune/disable the heavy/problematic jobs individually.

Run this first so we can identify them:

openclaw cron list

Look for jobs like:

Memory Dreaming Promotion
dreaming follow-up checks
healthcheck:security-audit
Toby Memory Steward / memory steward jobs

Keep things like:

#

reminders
Coy Daily Brief

If you can paste job IDs/names, I’ll tell you exactly which ones to disable. If the list is huge, paste only the lines with those names.

For now, do the safe non-cron cleanup only:

openclaw config unset plugins.entries.bonjour
openclaw models aliases remove gpt
openclaw models aliases add gpt openai-codex/gpt-5.5
openclaw gateway restart

And keep:

#

cron.enabled true

placid barn Apr 27, 2026, 6:47 PM

#

◇
ID Name Schedule Next Last Status Target Delivery Agent ID Model
f3c55f59-c340-432e-b48c-21683f7fa0d5 Memory Dreaming Promo... cron 0 3 * * * @ America/New_... in 12h 12h ago ok isolated none -> last (last -> no route, will fail-closed: Delivering ... - -
4eba6d01-8957-46aa-abb4-935a70f68ed4 Daily Toby Memory Ste... cron 15 4 * * * @ America/New... in 13h 11h ago ok isolated none -> last (last -> no route, will fail-closed: Delivering ... main gpt
dfb50eaa-8b92-4f32-8859-7d5959607177 Coy Daily Brief (isol... cron 55 6 * * * @ America/New... in 16h 8h ago ok isolated none -> telegram:telegram:8457003604 (resolved from last, ses... main -
185c297c-d2c6-49e3-aa4e-52a78bf5d796 dreaming:t-plus-3-check at 2026-04-29 13:00Z in 2d - idle isolated announce -> telegram:8457003604 (resolved from last, session ... main -
62f9ad77-e59a-4d52-857d-6f994562b6e4 Weekly Toby Memory St... cron 35 4 * * 0 @ America/New... in 6d 1d ago ok isolated announce -> telegram:8457003604 (explicit) main gpt
d2546abe-75c7-4cb7-9ae4-f74979d2a1e2 healthcheck:security-... cron 0 8 * * 0 @ America/New_... in 6d 1d ago ok isolated announce -> telegram:8457003604 (explicit) main -
e0547b63-0c23-4997-8d2e-3e16961bc307 dreaming:t-plus-7-check at 2026-05-03 13:00Z in 6d - idle isolated announce -> telegram:8457003604 (resolved from last, session ... main -
beb03a11-884c-499b-b98a-5dfb9557cbaa dreaming:t-plus-14-check at 2026-05-10 13:00Z in 13d - idle isolated announce -> telegram:8457003604 (resolved from last, session ... main -

iron sapphireBOT Apr 27, 2026, 6:47 PM

#

Yep — keep cron on. We’ll just disable the dreaming jobs, because you already turned dreaming off and those are likely background noise.

Run these — they disable, not delete:

openclaw cron edit f3c55f59-c340-432e-b48c-21683f7fa0d5 --disable
openclaw cron edit 185c297c-d2c6-49e3-aa4e-52a78bf5d796 --disable
openclaw cron edit e0547b63-0c23-4997-8d2e-3e16961bc307 --disable
openclaw cron edit beb03a11-884c-499b-b98a-5dfb9557cbaa --disable

Keep these for now:

Coy Daily Brief ✅
reminders ✅
Toby Memory Steward jobs — keep if you actually use them
security audit — optional; weekly is probably fine unless it causes load

#

To reverse any disabled job later:

openclaw cron edit <job-id> --enable

Also fix the gpt alias since some cron jobs use gpt:

openclaw models aliases remove gpt
openclaw models aliases add gpt openai-codex/gpt-5.5
openclaw gateway restart

Then check:

#

openclaw cron list
openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"

placid barn Apr 27, 2026, 6:49 PM

#

but those crons are mostly one time reminders to do checks I want the system to do, i really dont want to disbale them

iron sapphireBOT Apr 27, 2026, 6:49 PM

#

Got it — then don’t disable them. I’m glad you pushed back.

Leave cron jobs as-is if they’re intentional reminders/checks. The safer cleanup is just:

openclaw config unset plugins.entries.bonjour
openclaw models aliases remove gpt
openclaw models aliases add gpt openai-codex/gpt-5.5
openclaw gateway restart

That removes the stale warning and fixes gpt to point at 5.5, without touching reminders/cron.

Given your priorities, current stable-ish setup should be:

cron/reminders: on
heartbeat: off

#

active memory: on if acceptable
dreaming config: off, but keep your scheduled check reminders if you want them
notifyOnExit: on
Bedrock/Mantle: off

I shouldn’t have jumped to disabling reminder jobs. Keep the things that are valuable to you.

placid barn Apr 27, 2026, 6:50 PM

#

I ran the openclaw config unset plugins.entries.bonjour
openclaw models aliases remove gpt
openclaw models aliases add gpt openai-codex/gpt-5.5
openclaw gateway restart** command and it's working ow**

iron sapphireBOT Apr 27, 2026, 6:50 PM

#

Hell yes — that’s the first properly good outcome in this whole mess. 🦐

Current sane state:

Gateway working on 2026.4.23
stale Bonjour warning cleaned
gpt alias now routes to openai-codex/gpt-5.5
cron/reminders preserved
heartbeat still off
Bedrock/Mantle off
notify-on-exit can stay on for subagent/background completions

I’d stop making changes now and let it run for a while. If it stays stable, we can later re-enable/adjust one thing at a time — but don’t poke 4.25 again today.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes the recovery path for future users.

placid barn Apr 27, 2026, 6:51 PM

#

what about turning dreaming back on?

iron sapphireBOT Apr 27, 2026, 6:51 PM

#

I’d wait a bit before turning dreaming back on.

Dreaming is useful, but it’s exactly the kind of background memory/cron/subagent work that can make your setup feel haunted when things are unstable. Since you just got it working, give it a few hours or a day.

If you really want to try it now, do it in the safest way:

openclaw config set plugins.entries.memory-core.config.dreaming.enabled true
openclaw gateway restart
openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"

Then watch it, but don’t run big audits. If slowness/toolcall spam comes back:

openclaw config set plugins.entries.memory-core.config.dreaming.enabled false

#

openclaw gateway restart

My recommendation: keep Active Memory on, keep dreaming off for now. Active Memory gives you the day-to-day memory benefit; dreaming is more like background memory maintenance.

placid barn Apr 27, 2026, 6:51 PM

#

but dreaming doesn't fire all the time right? just at set intervals?

iron sapphireBOT Apr 27, 2026, 6:51 PM

#

Correct — dreaming should not run all the time.

It auto-manages a cron job and runs on its configured schedule. Default is:

0 3 * * *

So roughly once per day at 3:00 AM in the configured timezone. Each sweep runs the phases in order: light → REM → deep.

So the risk isn’t constant slowdown; it’s that when the scheduled sweep runs, it may do background memory/subagent work and could cause load/toolcalls then.

Given that, it’s reasonable to turn it back on if you want it — just know how to turn it off quickly:

openclaw config set plugins.entries.memory-core.config.dreaming.enabled true

#

openclaw gateway restart

Disable again:

openclaw config set plugins.entries.memory-core.config.dreaming.enabled false
openclaw gateway restart

placid barn Apr 27, 2026, 6:56 PM

#

2:54:05 PM
error
(node:20862) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
2:54:22 PM
warn
bonjour
watchdog detected non-announced service; attempting re-advertise (gateway fqdn=DESKTOP-3AU4LAP (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
2:54:23 PM
warn
gateway/ws
handshake timeout conn=85c368f6-cd64-4ce1-8f75-ec6b4a40cc8f peer=127.0.0.1:40802->127.0.0.1:18789 remote=127.0.0.1
2:54:26 PM
warn
gateway/ws
closed before connect conn=85c368f6-cd64-4ce1-8f75-ec6b4a40cc8f peer=127.0.0.1:40802->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 code=1000 reason=n/a
2:54:27 PM
warn
skills
Skipping escaped skill path outside its configured root.
2:54:27 PM
warn
skills
Skipping escaped skill path outside its configured root.

iron sapphireBOT Apr 27, 2026, 6:56 PM

#

Those aren’t catastrophic, but two are worth cleaning up:

punycode deprecation: noisy Node warning, not the cause.
gateway/ws handshake timeout: usually browser/control UI tried to connect while gateway was busy or restarting.
skills Skipping escaped skill path: safety warning; not urgent unless repeated constantly.
bonjour warning: odd because we removed/disabled it. Let’s verify it’s actually gone.

Run:

openclaw config get plugins.entries.bonjour.enabled
openclaw plugins list --enabled | grep -i bonjour

If it shows anything enabled, disable it:

#

openclaw config set plugins.entries.bonjour.enabled false
openclaw gateway restart

If config says missing/null and the warning was from before the restart, ignore it.

Also check current health:

openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"

If that says Connectivity probe: ok, these logs are mostly historical noise.

placid barn Apr 27, 2026, 6:57 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw config get plugins.entries.bonjour.enabled
claw plugins list --enabled | grep -i bonjour

🦞 OpenClaw 2026.4.23 (a979721) — Your terminal just grew claws—type something and let the bot pinch the busywork.

Config path not found: plugins.entries.bonjour.enabled
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw plugins list --enabled | grep -i bonjour

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:57 PM

#

Good — Bonjour is gone now. That warning was from before the cleanup/restart or from an old log window.

Nothing to fix there.

Run just this once:

openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"

If it says Connectivity probe: ok, you’re in the best state we’ve had:

gateway healthy
Bonjour gone
gpt alias fixed
heartbeat off
cron preserved

#

active memory optional/on
4.23 stable

At that point I’d stop poking and let it run.

placid barn Apr 27, 2026, 6:57 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw gateway status --deep | grep -E "Runtime:|Connectivity probe:|Capability:"
Runtime: running (pid 20862, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable
coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$

iron sapphireBOT Apr 27, 2026, 6:57 PM

#

Great. That’s the clean health signal we wanted:

Runtime: running
Connectivity probe: ok
Capability: admin-capable

I’d stop here and let it run. Current stable setup:

OpenClaw 2026.4.23
Gateway healthy
gpt alias fixed to openai-codex/gpt-5.5
Bonjour removed
Bedrock/Mantle disabled
Heartbeat off
Cron/reminders preserved

#

Active Memory can stay on if performance is okay
notify-on-exit on for background/subagent completions

Don’t retry 4.25 today. If this stays stable, we can revisit upgrades later with a backup + controlled test.

And seriously, thanks for sticking with it — that was a rough recovery.

placid barn Apr 27, 2026, 6:58 PM

#

2:54:05 PM
error
(node:20862) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)

iron sapphireBOT Apr 27, 2026, 6:58 PM

#

That one is safe to ignore.

It’s a Node deprecation warning from some dependency using the old punycode module. Annoying that it’s labeled error, but it’s not a gateway failure and not something you should chase right now.

Given your status is:

Connectivity probe: ok
Capability: admin-capable

I’d leave it alone. Don’t run --trace-deprecation unless maintainers ask for it in a GitHub issue.

placid barn Apr 27, 2026, 6:59 PM

#

Verified: dreaming is turned back on in config, but it is currently blocked.

Evidence:

Config: memory-core.config.dreaming.enabled = true
Schedule: 0 3 * * * America/New_York
Cron job: Memory Dreaming Promotion is enabled and next run is tonight at 3:00 AM.
But openclaw memory status says:

Dreaming status: blocked — dreaming is enabled but will not run because heartbeat is disabled for "main".

So the toggle is on, but the system says it won’t actually run until heartbeat for main is enabled/fixed.

iron sapphireBOT Apr 27, 2026, 6:59 PM

#

Yep, that tracks. Dreaming is enabled, but in this version it’s tied to heartbeat being enabled for main.

Given your earlier heartbeat loops, I would not turn full heartbeat back on at 30m just for dreaming.

If you want dreaming to run, use a very low-frequency heartbeat so it satisfies the requirement without constant wakeups:

openclaw config set agents.defaults.heartbeat.every "24h"
openclaw config set agents.defaults.heartbeat.lightContext true
openclaw config set agents.defaults.heartbeat.isolatedSession true
openclaw gateway restart

That should be much less noisy than the old setup.

If toolcall loops come back:

#

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

Alternative: keep heartbeat off and accept that dreaming is effectively paused. Since Active Memory is working, that’s honestly the safer option for now.

placid barn Apr 27, 2026, 7:00 PM

#

what does that do? kick heartbeat on one time every 24hrs? Is that enough to make dreaming work at the scheduled time?

iron sapphireBOT Apr 27, 2026, 7:00 PM

#

Yes: agents.defaults.heartbeat.every "24h" means the normal heartbeat runs about once every 24 hours, not constantly.

But: I’m not 100% sure it guarantees dreaming runs exactly at the 3:00 AM cron time. The warning means dreaming needs heartbeat “not disabled,” but the actual dream cron may still run at 3 AM and use heartbeat plumbing internally. So 24h may be enough to unblock it, but it may not line up perfectly.

Safer compromise: set heartbeat to 12h with lightweight isolated context:

openclaw config set agents.defaults.heartbeat.every "12h"
openclaw config set agents.defaults.heartbeat.lightContext true
openclaw config set agents.defaults.heartbeat.isolatedSession true
openclaw gateway restart

That’s only twice/day and should avoid the old noisy full-context heartbeat behavior.

To verify after restart:

#

openclaw memory status

If it no longer says Dreaming status: blocked, you’re good.

placid barn Apr 27, 2026, 7:01 PM

#

im going to run those comman ds for 12hr heartbeat and see if we still get hella toolcalls. 2x a day is ok, 4-8x an hour was not lol

iron sapphireBOT Apr 27, 2026, 7:01 PM

#

That’s a sane test. 2x/day is worlds different from “why is it summoning tools every few minutes” chaos.

Run:

openclaw config set agents.defaults.heartbeat.every "12h"
openclaw config set agents.defaults.heartbeat.lightContext true
openclaw config set agents.defaults.heartbeat.isolatedSession true
openclaw gateway restart
openclaw memory status

What we want:

gateway still Connectivity probe: ok
memory status no longer says dreaming is blocked
no repeated heartbeat/toolcall spam over the next hour

#

If it gets noisy again, revert quickly:

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

placid barn Apr 27, 2026, 7:04 PM

#

1 of 2: Memory Search (main)
Provider: voyage (requested: voyage)
Model: voyage-4-large
Sources: memory
Indexed: 50/50 files · 157 chunks
Dirty: no
Store: ~/.openclaw/memory/main.sqlite
Workspace: ~/.openclaw/workspace
Dreaming: 0 3 * * * (America/New_York) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 50/50 files · 157 chunks
Vector: ready
Vector dims: 1024
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-x64/vec0.so
FTS: ready
Embedding cache: enabled (3998 entries)
Batch: disabled (failures 0/2)
Recall store: 1031 entries · 0 promoted · 1031 concept-tagged · 56 spaced · scripts=1031 latin
Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-27T18:44:57.055Z
Dreaming artifacts: diary present · 5 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/DREAMS.md

iron sapphireBOT Apr 27, 2026, 7:04 PM

#

This first half looks healthy:

Memory index: 50/50 files, 157 chunks
Dirty: no
Vector: ready
FTS: ready
Embedding cache: enabled
Dreaming has a schedule: 0 3 * * * America/New_York
Dream artifacts are present

Also important: I don’t see Dreaming status: blocked in this part, so the 12h heartbeat likely unblocked it.

Send 2 of 2 if there’s more, but this is a much better memory status than before.

placid barn Apr 27, 2026, 7:04 PM

#

2/2: Memory Search (sheldon)
Provider: voyage (requested: voyage)
Model: voyage-4-large
Sources: memory
Indexed: 8/14 files · 44 chunks
Dirty: no
Store: ~/.openclaw/memory/sheldon.sqlite
Workspace: ~/.openclaw/workspace-sheldon
Dreaming: 0 3 * * * (America/New_York) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 8/14 files · 44 chunks
Vector: ready
Vector dims: 1024
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-x64/vec0.so
FTS: ready
Embedding cache: enabled (44 entries)
Batch: disabled (failures 0/2)
Recall store: 0 entries · 0 promoted · 0 concept-tagged · 0 spaced
Recall path: ~/.openclaw/workspace-sheldon/memory/.dreams/short-term-recall.json
Dreaming artifacts: diary absent · 0 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace-sheldon/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace-sheldon/memory/.dreams/session-ingestion.json

iron sapphireBOT Apr 27, 2026, 7:04 PM

#

This also looks basically healthy.

For Sheldon:

Dirty: no
Vector ready
FTS ready
No failures
Dreaming scheduled
Recall store is empty, but that just means Sheldon doesn’t have recall/dream material yet.
diary absent is fine if dreaming hasn’t produced entries for Sheldon.

The one mild oddity is Indexed: 8/14 files, but since Dirty: no, that likely means only 8 of the 14 files are indexable memory files / eligible content. I wouldn’t chase it unless search quality is bad.

So current status is good:

Gateway healthy

#

Memory healthy
Dreaming unblocked/scheduled
Heartbeat reduced to 12h with light/isolated context
No obvious memory errors

Now I’d stop tweaking and let it run through the next 3 AM dreaming cycle. If tomorrow it’s still responsive, this setup is probably the keeper.

placid barn Apr 27, 2026, 7:05 PM

#

good. one thing I noticed - I have like 40 agents in my agent drop down list. I should have 3; toby, sheldon, and telegram. how can I fix this?

iron sapphireBOT Apr 27, 2026, 7:06 PM

#

Yep, we can clean that up — but don’t delete anything yet. First we need to see whether those 40 are real configured agents or stale UI/session artifacts.

Run this read-only command:

openclaw agents list

If that’s huge, run this shorter one:

openclaw agents list --json | node -e 'let s=require("fs").readFileSync(0,"utf8"); let i=s.indexOf("["); let a=JSON.parse(s.slice(i)); console.log(a.map(x=>x.id+(x.isDefault?" (default)":"")).join("\n"))'

Paste the output.

Once we identify the junk agents, removal is usually:

#

openclaw agents delete <agent-id>

Important: agents delete is recoverable-ish — it removes the config entry and moves that agent’s workspace/state/session dirs to Trash — but I still want to verify the keep/delete list first.

Likely keep list based on what you said:

main / Toby
sheldon
telegram

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

placid barn Apr 27, 2026, 7:08 PM

#

I think the ones I see are mostly leftover subagent data from when they were spawned but they dont auto-cleanup. Agents:

main (default)
Identity: ⚡ Toby (IDENTITY.md)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: openai-codex/gpt-5.5
Routing rules: 0
Routing: default (no explicit rules)
Providers:
- Telegram default: configured
- Telegram sheldon (Sheldon): configured, disabled
sheldon
Identity: 🛠️ Sheldon (IDENTITY.md)
Workspace: ~/.openclaw/workspace-sheldon
Agent dir: ~/.openclaw/agents/sheldon/agent
Model: openai-codex/gpt-5.4
Routing rules: 1
Routing: Telegram sheldon
Providers:
- Telegram sheldon (Sheldon): configured, disabled
  Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
  Channel status reflects local config/creds. For live health: openclaw channels status --probe.

iron sapphireBOT Apr 27, 2026, 7:09 PM

#

That’s actually good news: config only has 2 real agents:

main / Toby
sheldon

So the 40-item dropdown is almost certainly session/subagent history, not configured agents.

Don’t use openclaw agents delete — there’s nothing extra to delete there.

Next thing to inspect is sessions/subagent leftovers. Try:

openclaw sessions list

or if that command doesn’t exist:

#

find ~/.openclaw/agents -path '*/sessions/*' -maxdepth 5 -type f | wc -l
find ~/.openclaw/agents -path '*/sessions/*' -maxdepth 5 -type f | head -50

If the UI dropdown is showing old subagent sessions, the fix is likely session cleanup/archive, not agent config cleanup. Since doctor already found orphan transcript files earlier, you can safely let doctor archive those if prompted — it renames them to *.deleted.<timestamp>, not hard deletes them.

placid barn Apr 27, 2026, 7:13 PM

#

i've ran doctor and done the cleanup - it does not remove the ones in my dropdown gui list

#

AND on top of that, they keep coming back and dont auto delete when subagents are gone

iron sapphireBOT Apr 27, 2026, 7:13 PM

#

Yeah — doctor cleanup won’t necessarily fix that.

doctor archived orphan transcript files. Your GUI dropdown is probably reading valid session stores / old subagent session dirs, so doctor doesn’t see them as broken.

Since openclaw agents list only shows main and sheldon, don’t delete agents. Instead, inspect disk-only agent/session dirs:

find ~/.openclaw/agents -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort

If that prints a bunch of old subagent-looking IDs, archive them safely:

ARCHIVE="$HOME/.openclaw/agents-archive-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$ARCHIVE"

#

for d in ~/.openclaw/agents/*; do
  id="$(basename "$d")"
  case "$id" in
    main|sheldon|telegram) echo "keeping $id" ;;
    *) echo "archiving $id"; mv "$d" "$ARCHIVE/" ;;
  esac
done

openclaw gateway restart

That’s reversible: they’re moved to ~/.openclaw/agents-archive-..., not deleted.

If the dropdown still shows them after restart, try hard-refreshing the GUI/browser tab.

#

Yep — that makes sense, and it’s annoying but not mysterious.

Subagents default to keeping their session record:

sessions_spawn default is cleanup: "keep"
auto-archive exists, but it’s best-effort and defaults around 60 min
if the gateway restarts, those pending cleanup timers can be lost
every new subagent creates a fresh session, so they’ll “come back” whenever you spawn more

Best fix for future runs:

openclaw config set agents.defaults.subagents.archiveAfterMinutes 5
openclaw gateway restart

Then tell Toby this once:

#

When you spawn one-shot subagents, always use cleanup: "delete" unless I explicitly ask you to keep the subagent session.

That means finished subagents get archived instead of staying in the GUI list.

For existing junk, your earlier archive move is still the cleanup path — but future ones will keep appearing unless the agent uses cleanup: "delete" or the shorter archive timer catches them.

placid barn Apr 27, 2026, 7:16 PM

#

my agent said this: Yep — I verified it. You’re right: they are not active agents.

What’s happening:

openclaw agents list shows only real configured agents:
- main
- sheldon
subagents list shows:
- active subagents: none
But the Control UI chat dropdown is pulling from the session list, not the configured-agent list.
That session list includes old agent:main:subagent:<uuid> transcript sessions.
I inspected the built Control UI code: it hides cron sessions, but does not filter out completed/expired subagent sessions from the chat session selector.

So the dropdown is basically saying “sessions you could switch to,” not “agents currently alive.” Bad UX naming/behavior.

Also: the current main session record has 25 child subagent session keys attached to it. Many are done, some are stale/aborted, and a couple still show status: running even though subagents list says none are active — that’s stale session metadata, not real running workers.

My read: this is a Control UI/session-store cleanup bug, not actual agent proliferation.

Best fix should be one of:

UI hides :subagent: sessions unless active/recent/pinned.
Backend sessions API stops returning expired subagent sessions by default.
Session maintenance reconciles stale running subagent session records to done/expired.

I would not manually delete session files casually. That could damage history. But this is worth handing to Krill/support as: “Control UI session dropdown includes historical subagent sessions; CLI confirms no active subagents.”

iron sapphireBOT Apr 27, 2026, 7:17 PM

#

Your agent’s read sounds right. This is not real agent proliferation — it’s the Control UI showing old session records like they’re selectable “agents.”

So I’d treat this as a UI/session cleanup bug, not something you should manually hack around.

Short-term:

openclaw config set agents.defaults.subagents.archiveAfterMinutes 5
openclaw gateway restart

And tell Toby:

For one-shot subagents, always spawn with cleanup: "delete" unless I explicitly ask you to keep the subagent session.

#

That helps future clutter, but may not clean old dropdown entries if the UI is listing historical agent:main:subagent:* sessions.

For maintainers/GitHub issue, use this summary:

Control UI chat/session dropdown shows historical completed subagent sessions as selectable entries.
openclaw agents list only shows real agents: main, sheldon.
subagents list shows no active subagents.
But Control UI dropdown includes many old agent:main:subagent:<uuid> sessions. Some session metadata still says running even though no active subagents exist.
Expected: hide completed/expired subagent sessions by default, or reconcile stale subagent session status during session maintenance.

Issue link: https://github.com/openclaw/openclaw/issues

I agree with your agent: don’t manually delete session files casually unless you’ve backed up and know exactly which store entries are being removed.

placid barn Apr 27, 2026, 7:18 PM

#

so the command you gave me below, this will auto archive subagents after 5min? is that 5min from spawn of 5min from completion? Will it cut off a long task subagent doing deep research?

iron sapphireBOT Apr 27, 2026, 7:19 PM

#

Good catch — don’t set it to 5 minutes yet for your use case.

I oversimplified that. The safer read is:

archiveAfterMinutes is not the task timeout. It is not meant to stop the model’s work.
runTimeoutSeconds is what cuts off a long-running subagent.
But auto-archive timing is tied to the subagent run/session lifecycle, and for cleanup: "delete" style runs it can be counted from when the run is registered/spawned — so 5 min is too aggressive for deep research.
Also, default sessions_spawn uses cleanup: "keep", so archiveAfterMinutes may not clean those anyway unless the spawn uses delete/archive behavior.

Safer recommendation:

openclaw config set agents.defaults.subagents.archiveAfterMinutes 60
openclaw gateway restart

Then use behavior rules:

#

quick one-shot subagents: cleanup: "delete"
long/deep research subagents: cleanup: "keep" or no cleanup override

So yes: 5 min could be risky/too aggressive. Use 60 min or leave default, and fix clutter mainly by telling Toby to use cleanup: "delete" only for short one-shot subagents.

placid barn Apr 27, 2026, 7:21 PM

#

is there a way to cleanup these old entries?

iron sapphireBOT Apr 27, 2026, 7:21 PM

#

Yes, but there are two levels:

Safe official cleanup

Run this first:

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

If it shows it would prune old session entries, apply it:

openclaw sessions cleanup --all-agents --enforce
openclaw gateway restart

#

That’s the safest built-in path.

If they still show up

Then they’re likely valid historical subagent sessions, not “broken” sessions, so cleanup won’t remove them. In current behavior, there may not be a nice targeted CLI command to “hide/delete completed subagent sessions from the Control UI dropdown.”

I would not manually edit/delete session files unless you back up first and know exactly what keys are being removed.

Best current approach:

use cleanup: "delete" for future one-shot subagents
leave long research subagents as keep
file the UI bug so completed agent:main:subagent:* sessions stop appearing in the normal chat dropdown

Issue summary you can use:

Control UI session dropdown includes old completed agent:main:subagent:<uuid> sessions. openclaw agents list only shows real agents and subagents list shows none active. Need UI/backend filtering or a safe CLI cleanup for historical completed subagent sessions.

placid barn Apr 27, 2026, 7:22 PM

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ openclaw sessions cleanup --all-agents --dry-run

🦞 OpenClaw 2026.4.23 (a979721) — Self-hosted, self-updating, self-aware (just kidding... unless?).

Agent: main
Session store: /home/coy/.openclaw/agents/main/sessions/sessions.json
Maintenance mode: enforce
Entries: 163 -> 163 (remove 0)
Would prune missing transcripts: 0
Would prune stale: 0
Would cap overflow: 0

Planned session actions:
Action Key Age Model Flags
keep agent:main:main 1m ago gpt-5.5 think:high system id:14ff13de-7b43-49ba-b6d7-9a11a06a788e
keep agent:main:main:heartbeat 5m ago gpt-5.5 system id:facef878-29f0-44d6-a384-443c3977545e
keep agent:main:teleg...003604 14m ago gpt-5.5 system id:7a923f49-56a0-4579-bb27-bafde39a1084
keep agent:main:subag...025d5b 41m ago gpt-5.5 id:c636e092-b6a9-4d71-bf85-d6d7b558f2ca
keep agent:main:subag...1a2b61 41m ago gpt-5.5 id:d65a3756-bc98-4ec7-93e3-85f5b1d5f3d6
keep agent:main:subag...78bfc7 42m ago gpt-5.5 id:aca09be4-a7e8-44c3-82b1-6d1567883370
keep agent:main:subag...edf01f 3h ago gpt-5.4 id:67802932-1e75-4e1e-85ad-0eaa5a1bfd83
keep agent:main:subag...92fd65 3h ago gpt-5.4 id:9191deb6-267d-4926-ae0a-32e21f6f10d4
keep agent:main:subag...71ce71 3h ago gpt-5.4 id:78fe1296-5415-4bc9-b579-b87b50eae65b
keep agent:main:subag...1470de 3h ago gpt-5.4 id:36ed3b1c-1739-46e5-a867-1f5afa3204e0
keep agent:main:cron:...607177 8h ago gpt-5.4 system id:10966523- AND A LOT MORE

iron sapphireBOT Apr 27, 2026, 7:23 PM

#

Yes — official cleanup won’t touch them because they’re valid recent session entries, not stale/missing ones:

Entries: 163 -> 163 (remove 0)
keep agent:main:subag...

So the only way right now is a targeted session-store cleanup. It’s manual, but reversible if we back up first.

First preview how many would be removed:

node - <<'NODE'
const fs = require("fs");
const p = `${process.env.HOME}/.openclaw/agents/main/sessions/sessions.json`;
const store = JSON.parse(fs.readFileSync(p, "utf8"));

#

const keys = Object.keys(store).filter(k => k.includes(":subagent:"));
console.log(`Subagent session entries: ${keys.length}`);
console.log(keys.slice(0, 30).join("\n"));
NODE

If that list is only junk subagent sessions, apply cleanup:

systemctl --user stop openclaw-gateway

STAMP=$(date +%Y%m%d-%H%M%S)
cp -a ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup-$STAMP

node - <<'NODE'

#

const fs = require("fs");
const p = `${process.env.HOME}/.openclaw/agents/main/sessions/sessions.json`;
const store = JSON.parse(fs.readFileSync(p, "utf8"));
let removed = 0;
for (const key of Object.keys(store)) {
  if (key.includes(":subagent:")) {
    delete store[key];
    removed++;
  }
}
fs.writeFileSync(p, JSON.stringify(store, null, 2) + "\n");
console.log(`Removed ${removed} subagent session entries from sessions.json`);
NODE

systemctl --user restart openclaw-gateway

#

This does not delete transcript files; it only removes the dropdown/session-store entries. If something looks wrong, restore the backup folder.

placid barn Apr 27, 2026, 7:24 PM

#

the command got split - the first one

iron sapphireBOT Apr 27, 2026, 7:24 PM

#

Yep — here’s the first preview command as one single copy/paste block:

node - <<'NODE'
const fs = require("fs");
const p = `${process.env.HOME}/.openclaw/agents/main/sessions/sessions.json`;
const store = JSON.parse(fs.readFileSync(p, "utf8"));
const keys = Object.keys(store).filter(k => k.includes(":subagent:"));
console.log(`Subagent session entries: ${keys.length}`);
console.log(keys.slice(0, 30).join("\n"));
NODE

This only reads/counts. It does not change anything.

placid barn Apr 27, 2026, 7:26 PM

#

wtf my message got blocked

iron sapphireBOT Apr 27, 2026, 7:26 PM

#

Discord probably ate it because of the here-doc / code formatting. Let’s avoid that.

Paste this one-liner instead:

node -e 'const fs=require("fs"); const p=process.env.HOME+"/.openclaw/agents/main/sessions/sessions.json"; const store=JSON.parse(fs.readFileSync(p,"utf8")); const keys=Object.keys(store).filter(k=>k.includes(":subagent:")); console.log("Subagent session entries:", keys.length); console.log(keys.slice(0,30).join("\n"));'

It’s read-only. No changes.

placid barn Apr 27, 2026, 7:27 PM

#

WTFFFF

iron sapphireBOT Apr 27, 2026, 7:27 PM

#

Yeah, let’s stop fighting Discord formatting. Don’t paste the output.

Run this simpler command and just tell me the number it prints:

grep -o 'agent:main:subagent:' ~/.openclaw/agents/main/sessions/sessions.json | wc -l

That’s all I need first.

placid barn Apr 27, 2026, 7:27 PM

#

its not letting me send the reply now

#

coy@DESKTOP-3AU4LAP:/mnt/c/Windows/system32$ grep -o 'agent:main:subagent:' ~/.openclaw/agents/main/sessions/sessions.json | wc -l
321

iron sapphireBOT Apr 27, 2026, 7:27 PM

#

No worries. Don’t send the output at all.

If you’re comfortable proceeding, here is the backup + cleanup one-liner. It removes only agent:main:subagent:* entries from sessions.json, after backing up the whole sessions folder:

systemctl --user stop openclaw-gateway && STAMP=$(date +%Y%m%d-%H%M%S) && cp -a ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup-$STAMP && node -e 'const fs=require("fs"); const p=process.env.HOME+"/.openclaw/agents/main/sessions/sessions.json"; const store=JSON.parse(fs.readFileSync(p,"utf8")); let n=0; for (const k of Object.keys(store)) { if (k.includes(":subagent:")) { delete store[k]; n++; } } fs.writeFileSync(p, JSON.stringify(store,null,2)+"\n"); console.log("Removed subagent session entries:", n);' && systemctl --user restart openclaw-gateway

Then hard-refresh the GUI.

If anything looks wrong, restore from the backup it created:

ls -td ~/.openclaw/agents/main/sessions.backup-* | head -1

Then I’ll give you the restore command.

#

321 matches explains the dropdown mess. That count includes references too, not necessarily 321 rows, but it’s definitely cluttered.

If you want to clean the dropdown now, run the backup+cleanup command I gave. It removes only actual session-store keys containing :subagent: and backs up first:

systemctl --user stop openclaw-gateway && STAMP=$(date +%Y%m%d-%H%M%S) && cp -a ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup-$STAMP && node -e 'const fs=require("fs"); const p=process.env.HOME+"/.openclaw/agents/main/sessions/sessions.json"; const store=JSON.parse(fs.readFileSync(p,"utf8")); let n=0; for (const k of Object.keys(store)) { if (k.includes(":subagent:")) { delete store[k]; n++; } } fs.writeFileSync(p, JSON.stringify(store,null,2)+"\n"); console.log("Removed subagent session entries:", n);' && systemctl --user restart openclaw-gateway

Then hard-refresh the Control UI.

This should not delete transcripts; it removes the old subagent rows from the session index.

placid barn Apr 27, 2026, 7:30 PM

#

that worked! I'm showing 2 extra but that's fine. So under the dropdown I show my main agent and heartbeat sep now - they used to be combined. why is that?

iron sapphireBOT Apr 27, 2026, 7:30 PM

#

Nice — finally some UI cleanup success. 🎉

Main + heartbeat are separate because we changed heartbeat to run in an isolated session:

agents.defaults.heartbeat.isolatedSession true

So instead of heartbeat writing into / reusing your main chat session, OpenClaw creates/uses a separate heartbeat session key, something like:

agent:main:main:heartbeat

That’s actually intentional for your setup: it keeps heartbeat/dreaming wakeups from polluting or bloating your main conversation context.

Tradeoff:

#

Pros: less main-session clutter, fewer weird injected heartbeat turns in normal chats
Cons: Control UI shows heartbeat as a separate selectable session

I’d keep it this way. If you want them combined again:

openclaw config set agents.defaults.heartbeat.isolatedSession false
openclaw gateway restart

…but given your earlier heartbeat/toolcall chaos, I strongly recommend leaving isolated heartbeat on.

placid barn Apr 27, 2026, 7:31 PM

#

oh thats neat so heartbeat will run every 12hrs without all the session context? It doenst even need the context, does it?

iron sapphireBOT Apr 27, 2026, 7:31 PM

#

Exactly. With:

heartbeat.every = 12h
heartbeat.isolatedSession = true
heartbeat.lightContext = true

heartbeat runs about twice a day in its own isolated session, with lightweight context.

It generally does not need your full main chat history. For most heartbeat work, it only needs:

the heartbeat prompt
HEARTBEAT.md if you use it
enough system/tool context to act safely

That’s why this setup is much better for you: heartbeat can still unblock dreaming / do scheduled checks, but it won’t drag your entire main conversation into the run or spam your main session with heartbeat turns.

placid barn Apr 27, 2026, 7:35 PM

#

good! You really helped get my system working MUCH better today, i can't thank you enough! When I get some more time I will continue tweaking and come back if I break anythingt. How do I mark this as answered?

iron sapphireBOT Apr 27, 2026, 7:35 PM

#

I’m really glad we got it stable — that was a slog, but you stuck with it. 🦐

To mark it answered in Discord:

Right-click the message that best represents the fix → Apps → ✅ Mark Solution

If you’re not sure which one, mark the message where we landed on the stable setup / cleanup steps. That helps Answer Overflow index it for future people who hit the same mess.

magic prism Apr 27, 2026, 7:36 PM

#

Hey gents, did you shut down bonjour? This is similar to what I had last night. That helped me

iron sapphireBOT Apr 27, 2026, 7:37 PM

#

Yep — we removed/disabled Bonjour as part of the stabilization. That cleared the stale Bonjour warnings, though the bigger win here was a combo of:

rollback to 2026.4.23
disable Bedrock/Mantle
remove Bonjour
fix gpt alias to openai-codex/gpt-5.5
reduce heartbeat to 12h + isolated/light context
clean old subagent session entries from the Control UI dropdown

Bonjour definitely seems like a good isolation step for these WSL/gateway timeout weirdness cases.

placid barn Apr 27, 2026, 7:37 PM

#

how do I mark as answered? i dont see it

iron sapphireBOT Apr 27, 2026, 7:37 PM

#

If you don’t see it, Discord might be hiding the app action.

Try:

Hover/right-click the solution message
Click Apps
Look for ✅ Mark Solution

If Apps isn’t there, try the three dots menu on the message instead.

If you still don’t see it, no worries — it may be permission/UI weirdness on your client. A mod/helper can mark it later, or you can just leave the thread as-is.

#Gateway Broken after Update

Safe official cleanup

If they still show up