I'm on 2026.4.29 and it's missing or

[raven bison]

argh it's not just control UI, happening in telegram too. the agent is responding to the penulimate question and ignores the most recent turn from me.

actually it can be three turns behind, and totally unware of more recent ones.

Maybe I triy 2026.5.2-beta.1 and if that doesn't resolve the turn churn go back to 2026.4.23

[hexed cobalt]

• deactivate lossless-claw
• check these folders for bloat (bug with dependencies can cause up to multiple GB of duplicate dependencies in there): .openclaw-pnpm-store and .openclaw/plugin-runtime-deps for bloat. These folders shouldnt be bigger than a couple MB.
• check if your QMD is running on CPU-only (ideally it should run on GPU acceleration if your hardware supports it)
• check if you use QMD in query mode or search mode.

then do the following:

1. Perform a full backup of at least the ~/.openclaw/openclaw.json file, the agents/, workspace/ (and every other workspace you might habe) and QMD directories, and the lossless-claw database.
2. Shut down Gateway properly.
3. Install Hackable using the Git method.
4. Check Gateway/LaunchAgent; do not blindly overwrite the old configuration.
5. Only run openclaw doctor in a controlled manner
6. Start Gateway and check the logs for ‘ready’, the plugin list, QMD mode, and active memory times.

Ideally you tell codex or claude code to change your openclaw installation to the so called "hackable" install (https://x.com/steipete/status/2050616320975130907)

then you tell codex/claude code to check the following:

`My OpenClaw Active Memory is failing with:

"No callable tools remain after resolving explicit tool allowlist"

Direct openclaw memory status and openclaw memory search work, and memory-core is enabled. Please inspect the OpenClaw source for the Active Memory embedded recall run. Check whether active-memory is launching runEmbeddedPiAgent with an explicit toolsAllow that includes memory_recall together with memory_search and memory_get.

If memory_recall is included but memory-lancedb is not enabled, patch Active Memory so the embedded recall subagent only allows the memory-core tools:

["memory_search", "memory_get"]

Also update the Active Memory prompt so it no longer tells the subagent to prefer memory_recall, but instead tells it to use memory_search and memory_get.

After patching:

1. Run the Active Memory tests.
2. Rebuild OpenClaw.
3. Restart the gateway.
4. Check the gateway logs for new No callable tools remain errors.`

Ideally your codex or claude code already has context about openclaw, if not you give it the links to the following:
https://github.com/openclaw/openclaw/
https://github.com/tobi/qmd
https://github.com/badlogic/pi-mono

and the openclaw documentation either via context7 or straight up: https://docs.openclaw.ai/help/faq-first-run#difference-between-the-hackable-git-install-and-npm-install

Peter Steinberger 🦞 (@steipete)

@bensen @crypto_sam_974 @Tfalwell New beta is up! https://t.co/UHnvDA3Ecg
curl -fsSL https://t.co/yjjVIN9fzw | bash -s -- --beta

X · May 2, 2026, 4:40 PM

[manic iris]

@steipete via Twitter

Peter Steinberger 🦞 (@steipete)

↩ (@bensen)
@bensen @crypto_sam_974 @Tfalwell New beta is up! www.npmjs.com/package/openclaw/v/2026.4.30-beta.1
︀︀curl -fsSL openclaw.ai/install.sh | bash -s -- --beta

**💬 1 ❤️ 3 👁️ 170 **

FxTwitter · May 2, 2026, 4:40 PM

[hexed cobalt]

lossless-claw + qmd (query mode) + qmd falsely running on CPU instead of GPU (as a result of a hiccup during update) + active memory "smart recovery features" + memory tool bug = your agents time out on start/memory load = slow responses, memory not working, failure/timeouts vicious cycle.

additionally, the update could have nuked node-llama-cpp depending on your prior setup and version before updating to .29.

But hackable install method should fix that

"hackable install" just means you install directly from the source code of openclaw instead of installing openclaw prepackaged via npm

[raven bison]

Thanks for the suggetions Ben even if not all may apply. I have lossless-claw, qmd (query mode) running on GPU and not using active memory.

Also I usually use another openclaw instance to do updates (not claude or codex)

[hexed cobalt]

Even better

[raven bison]

I'm in a heavy state of regression, both instances hosed 🙁 Time for a mental break

[raven bison]

@hexed cobalt One thing that's not clear to me, am I suppposed to leave lossless-claw deactivated after doing the hackable install?

enables lossless-claw to find out

[hexed cobalt]

I would leave it deactivated until you hear otherwise from its devs or until you are sure there are no dependencies issues with it anymore

[raven bison]

ooof, that's been a critical plugin to me. I would hate to see it go

[blissful trench]

I'm in roughly the same boat. My OpenClaw is finally responsive (I changed to channel dev) but it's taking 11-22 seconds for any response from the gateway, which makes actual conversations take around 7 minutes just to get a response from my 'claw. Which is not functional.

Any suggestions on how to debug this? I'm asking my 'claw to look, but it's taking...a...very...long...time...to...investigate.

This is the first update (the .29 update) that has seriously, fully broken my assistant, and I'm still trying to recover. 🙁

[raven bison]

@blissful trench I feel your pain, and yeah I'd had a good run until .29 (other than cpu pegged on restarts for some pre .29 version). Are you using lossless-claw plugin?

[blissful trench]

I don't think so. I installed back in January, and really haven't configured the plugins, or anything like that. It was really, really good, without anything extra, although the SOUL and AGENT files got pretty heavily customized.

Not even QMD (which I have a dislike for, after some research) and so I'm not sure what's causing this.

I'm seriously considering spinning up a secondary claw on another node of my homelab, so it can ssh into the original one and repair it. 🤣

Huh... No, losslessclaw or qmd aren't installed, but there's a LOT of plugins installed that I don't need. Let me try killing/disabling some of those.

[raven bison]

@blissful trench there's been a lot of change since January. it's probably worth installing a second claw to help with the original

[blissful trench]

Yeah... I mean I've updated, and the last one that was working...okay, was around the .23 release, but it's been getting progressively slower, and now it's unusable. So... time to try to really revamp it and figure out what's going on. Got a new one up, have to configure it now...

[raven bison]

.23 might be a good working version to use for now

there are known plugin issues after .23 that can grind a system to a near halt (well 30 second startup on modern hardware)

and I've been experiencing turn mismatch with .29 at least which has been driving me batty

[blissful trench]

Oh yeah, I've had turn mismatch for brief periods in the past, and bouncing the gateway has always stopped that cold. But if that persisted, yeah, I'd be tearing my hair out.

[raven bison]

After getting onto v2026.5.2 I'm noticing a boat load of sessions.list calls - not sure if this many were there before but it's too many

[blissful trench]

So I set up a new claw and pointed it at the old one, and had it diagnose it, and it turns out that my 'heartbeat' agent (an agent dedicated to just heartbeats) was absolutely slamming the gateway with session list, and other calls. Monopolizing the gateway, and making everything else much slower. And the new agent runs fast so I know it's not a core OpenClaw setup. So I'm having it try to fix the older one, and see how that works out. But it's really helping a lot to have a claw that can diagnose another OC instance.

Specifically:

Now I see a big part of the problem:

- **Main agent: 239 sessions** — and the `sessions.json` index file is **2.3 MB**
- **Monitor agent: 62 sessions** — despite being disabled, these still exist on disk
- The sessions.json file is probably being read/written on every `sessions.list` call, and on a VM with 178ms disk write latency, a 2.3MB JSON file is painful

Let me check how big that sessions.json is and whether there's a way to prune old sessions:

It suggested pruning old sessions, basically, to speed that up a lot.

[raven bison]

Thanks @blissful trench for in the info. I'm going to look into sessions today. I'm still not out of the woods yet even on 2026.5.2 as I still have some turn mismatch. It seems better but definitely not gone.

[raven bison]

my numerous sessions.list are taking ~ 800ms each

[raven bison]

On a fresh install I can get sessions.list of 60ms but I still have turn mismatch right out of the gate (no lossless-claw, no qmd). This is disappointing

@hexed cobalt you might want to be aware of ^^

[hexed cobalt]

now you can update/activate lossless-claw https://fxtwitter.com/jlehman_/status/2050932878843015234

Josh Lehman (@jlehman_)

lossless-claw 0.9.3 — the "please just keep working" release
︀︀
︀︀🧠 cache-aware compaction fires before overflow
︀︀🔁 fewer repeated old instructions
︀︀🧰 lcm tools load on OpenClaw 2026.5.2+
︀︀🔌 Codex, DeepSeek, Bedrock fixes
︀︀🛡️ safer migrations, payloads, and replay

**💬 4 🔁 1 ❤️ 27 👁️ 1.6K **

FxTwitter · May 3, 2026, 1:37 PM

[raven bison]

i'm losing the battle on getting out of turn mismatch. I'm not sure what to do next. Everything I try doesn't work. I think the issue is entrenced deeper than I can manage

my main instance that I moved to git install just decides to periodically clear the response input/output, answer questions way late, forgets to answer unless nudged.

90% of openclaw I probably don't need/use but stability is one thing I do need and it's just not there currently. I'm spending a lot of time in vain. I've always been able to overcome the frequent breaks, but this time it's breaking me - can I yell? 😄

[blissful trench]

Yeah, you can yell. One thing I've noticed in the most recent version in a raw install is that it'll keep answering questions it had answered in previous responses. It didn't used to do that, and my previous one doesn't seem to, so I'm not sure what's up.

'Forgets to answer unless nudged' is always a model quality problem in my experience. I'll get that with smaller local models, but something like GLM-5.1 never does it.

I'd suggest radical monitoring. Set up something like Tailscale Aperture, which can log all your back-and-forth with the model at the protocol level, and then look to see what's actually being sent.

But yeah, absolutely you can yell. Stability is really important when you rely on your agent to Get Shit Done with you.

[raven bison]

Thanks Cypherfox, I've experienced the repeat answers too on a fresh install. I'm typically using gpt 5.5 so my model should be sufficient. Thanks for the monitor tip, while I've used tailscale I haven't tried their aperture.

[hexed cobalt]

are you on mac?

[raven bison]

I'm using debian 13 lxcs on proxmox for two, and the third (new) instance is on proxmox 9 directly

[blissful trench]

Oh, hey... A significant part of my problem was my tab addiction. I had nine different browser tabs in different windows pointing to the OpenClaw web monitor, and each one fires a session list every ten seconds which was hammering the shit out of my gateway. Add in delays when it's actually doing work, and it had a huge backlog of work that it was constantly trying to do, and never caught up with.

Closing those tabs solved a lot of my issues, along with purging my model list, old sessions, shutting down two of my unnecessary agents, clearing out my plugin list, etc...

The big win that made everything better was stopping the abusive web clients, though.

[raven bison]

2026.5.4 seems to have restored my sanity, thanks openclaw team.