Update broke openclaw | Friends of the Crustacean 🦞🤝 | Page 1

outer hedge Apr 15, 2026, 5:47 PM

#


If you give me one last shot, I’ll prove execution in the next reply with real artifacts only:
- exact file paths changed,
- command outputs,
- and commit hash.

No artifact, no claim.```
This is all my bot does now. I updated recently. Is there something with my config that got messed up? My bot no longer does anything. It just says it's going too. I can't find any errors and it has no clue what changed. Any help here? My multi agent config is still the same with the permissions each agent needs. Can you ping me as I am at work. Thanks!

slow muskBOT Apr 15, 2026, 5:51 PM

#

That looks more like a plan-only / tool-policy regression than a Discord transport issue. The model is replying, but not taking a real tool step.

Please paste these first:

openclaw --version
openclaw status --all
openclaw models status
openclaw sandbox explain --agent <affected-agent>

Then repro once with logs open:

openclaw logs --follow

#

Send one test message, then paste the log chunk around that turn. I’m specifically looking for:

planning-only turn detected
strict-agentic run exhausted planning-only retries
tools.allow allowlist contains unknown entries

Also try /new once in that thread. If it keeps replaying the same canned line, the session may be stale after the update.

If you’re on openai/gpt-5* and logs show the planning-only messages, try this and restart the gateway:

{
  agents: {
    defaults: {
      embeddedPi: { executionContract: "default" }
    }

#

}
}

Docs:

I can’t ping people here, but drop those outputs when you’re back and I’ll help read them.

outer hedge Apr 16, 2026, 1:57 AM

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.3-codex
Fallbacks (30): local/llama3.2:latest, local/nomic-embed-text:latest, local/gemma3:1b, qwen-portal/coder-model, qwen-portal/vision-model, openrouter/openrouter/free, kimi-coding/k2p5, opencode/glm-5-free, opencode/minimax-m2.5-free, opencode/kimi-k2.5-free, github-copilot/gpt-5.2-codex, github-copilot/claude-opus-4.6, github-copilot/claue-sonnet-4.5, github-copilot/claude-sonnet-4, github-copilot/gpt-5.1-codex-mini, github-copilot/haiku-4.5, github-copilot/grok-code-fast-1, github-copilot/gemini-2.5-pro, github-copilot/goldeneye, github-copilot/raptor-mini, nvidia/glm5, nvidia/minimax-m2.5, nvidia/qwen3.5-397b-a17b, custom-opencode/mimo-v2-flash-free, custom-opencode/trinity-large-preview-free, custom-opencode/nemotron-3-super-free, custom-opencode/mimo-v2-omni-free, zai/glm-5, zai/glm-4.7, zai/glm-4.7-flashx

#

│ Version │ 2026.4.11 │
│ OS │ linux 6.8.0-94-generic (x64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm update 2026.4.14 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 104ms · auth password · vmi3087168 (89.117.23.163) app

#

Diagnosis (read-only)

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

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 1778020 root: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 13 eligible · 0 missing · /root/.openclaw/workspace-main
! Plugin compatibility (1)
[warn] openclaw-mem0 still uses legacy before_agent_start; keep regression coverage on this plugin, and prefer before_model_resolve/before_prompt_build for new work.
✓ Channel issues (none)

slow muskBOT Apr 16, 2026, 1:58 AM

#

That helps. Since your default is openai-codex/gpt-5.3-codex, I’d look at the new GPT-5/Codex execution lane before I blame multi-agent permissions.

Two likely causes now:

openai-codex auth/default model is unhealthy, so you’re silently falling into bad fallbacks.
The GPT-5/Codex strict-agentic lane is tripping on plan-only replies.

Fastest test, add this:

{
  agents: {
    defaults: {
      embeddedPi: { executionContract: "default" }
    }
  }

#

Then:

openclaw gateway restart

and send /new in that thread.

Also please paste these:

openclaw --version

#

openclaw models status
openclaw status --all
openclaw sandbox explain --agent main

If models status shows openai-codex re-auth / invalid_grant / refresh failure, fix that first:

openclaw models auth login --provider openai-codex

If it starts behaving again after executionContract: "default", we’ve basically found the regression.

Docs:

#

https://docs.openclaw.ai/tools/multi-agent-sandbox-tools

I can’t ping people here, but drop the outputs when you’re back and I’ll keep digging.

outer hedge Apr 16, 2026, 1:59 AM

#

Agents
┌──────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├──────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ coordinator │ PRESENT │ 13 │ 1m ago │ ~/.openclaw/agents/coordinator/sessions/sessions.json │
│ coder │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/coder/sessions/sessions.json │
│ communicator │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/communicator/sessions/sessions.json │
│ monitor │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/monitor/sessions/sessions.json │
│ orchestrator │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/orchestrator/sessions/sessions.json │
│ researcher │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/researcher/sessions/sessions.json │
└──────────────┴────────────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

slow muskBOT Apr 16, 2026, 1:59 AM

#

Aha, first concrete issue, you’re still on 2026.4.11.

That Update line means 2026.4.14 is available, so the recent update didn’t actually land. I would fix that before chasing config.

Run this in order:

openclaw update
openclaw doctor
openclaw gateway restart
openclaw --version

You want openclaw --version to come back as 2026.4.14.

Then send /new in the broken thread and test again.

#

If it still does the same thing after you’re actually on 2026.4.14, then I’d test the Codex/GPT-5 lane next by setting:

{
  agents: {
    defaults: {
      embeddedPi: { executionContract: "default" }
    }
  }
}

because your default model is openai-codex/gpt-5.3-codex.

If openclaw update says it worked but --version still shows 2026.4.11, paste:

#

which openclaw

Docs:

#

That diagnosis is basically clean.

Two important bits:

Port 18789 is already in use is not the problem, it just means your gateway is already running.
The openclaw-mem0 warning is advisory only. before_agent_start is deprecated, but it should not break the plugin by itself.

So I would not chase gateway/port/plugin-loading first.

I’d still focus on these, in order:

Actually get onto 2026.4.14

openclaw update
openclaw doctor
openclaw gateway restart

#

   openclaw --version

Start a fresh session
```
/new
```
If it still does the same “I’ll do it next reply” thing, force the old GPT-5/Codex behavior temporarily
```
{
  agents: {
    defaults: {
      embeddedPi: { executionContract: "default" }
    }
```

#

     }
   }

Then paste
```
openclaw models status
```

If you want one extra isolation test after that, temporarily disabling openclaw-mem0 for one run is reasonable, but I would only do that after the version + /new + executionContract test.

Refs:

#

There it is, that’s the first real smoking gun.

coordinator has Bootstrap file PRESENT, and it’s also the only agent with live sessions. BOOTSTRAP.md is supposed to be one-time only and removed after first run. If it sticks around, the agent can stay in first-run / bootstrap mode.

I’d do this next:

Find the file:

find /root/.openclaw -name BOOTSTRAP.md

Move the coordinator/default workspace one aside, don’t delete it yet.
If your active workspace is /root/.openclaw/workspace-main, it’s probably:
```
mv /root/.openclaw/workspace-main/BOOTSTRAP.md /root/.openclaw/workspace-main/BOOTSTRAP.md.bak
```

#

Restart the gateway:
```
openclaw gateway restart
```
Start a fresh session:
```
/new
```

If it starts behaving normally after that, you found it.

If BOOTSTRAP.md comes back immediately after restart, paste that, because then the workspace is getting re-seeded each boot.

Docs:

outer hedge Apr 16, 2026, 2:21 AM

#

04:05:18 [plugins] openclaw-mem0: registered (mode: open-source, user: thisisloze, graph: false, autoRecall: true, autoCapture: true)
│
◇ Memory search ─────────────────────────────────────────────────╮
│ │
│ No active memory plugin is registered for the current config. │
│ │
├─────────────────────────────────────────────────────────────────╯

What does that mean.

slow muskBOT Apr 16, 2026, 2:22 AM

#

That means registered != active.

openclaw-mem0: registered means the plugin loaded.
No active memory plugin is registered for the current config means nothing is currently providing the memory-search backend for openclaw memory ....

In OpenClaw, memory search comes from the active memory plugin. Default is memory-core.

So this usually means one of these:

plugins.slots.memory is set to "none"
the selected memory plugin is missing / not actually active
mem0 is loaded for hooks/integration, but it is not the active memory slot

Quick checks:

#

openclaw config get plugins.slots.memory
openclaw plugins list --enabled
openclaw memory status

If you just want the built-in memory backend back, set:

{
  plugins: {
    slots: {
      memory: "memory-core"
    }
  }
}

#

Then restart the gateway.

Also, I don’t think this is the main cause of the “I’ll do it next reply” bug. That still looks much more like the lingering BOOTSTRAP.md on coordinator.

Docs:

outer hedge Apr 16, 2026, 2:31 AM

#

"tools": {
"profile": "coding",

what is this? it must be new I dont recognize this in the config

slow muskBOT Apr 16, 2026, 2:32 AM

#

Yep, that’s the new tool baseline.

tools.profile: "coding" means OpenClaw starts from a preset coding-oriented tool allowlist before applying your other tool rules.

Per docs, coding includes:

group:fs
group:runtime
group:web
group:sessions
group:memory
cron
image
image_generate
video_generate

So yes, newer builds can add this as the default baseline.

#

Important bit: it can hide tools that are not in that profile unless you switch profiles or override policy. For example, browser, canvas, message, and tts are not in coding.

If you want the old “don’t pre-restrict me” behavior, use:

{
  tools: {
    profile: "full"
  }
}

full is the same as “no profile restriction”.

If you want to see exactly what the coordinator agent ends up with, run:

#

openclaw sandbox explain --agent coordinator

That said, I still think the lingering BOOTSTRAP.md on coordinator is the bigger smoking gun for the weird “I’ll do it next reply” behavior.

Docs:

outer hedge Apr 16, 2026, 2:34 AM

#

"messages": {
"ackReactionScope": "group-mentions"
},
"commands": {
"native": "auto",
"nativeSkills": "auto",
"restart": true,
"ownerDisplay": "raw"
},
"session": {
"dmScope": "per-channel-peer"

This looks new as well.

slow muskBOT Apr 16, 2026, 2:34 AM

#

Yep, those are newer config defaults too, but these are mostly harmless plumbing, not the smoking gun.

What they do:

messages.ackReactionScope: "group-mentions"
- only send the little ack reaction in groups when the bot was actually mentioned
commands.native: "auto"
- auto-register native slash/menu commands where supported
commands.nativeSkills: "auto"
- auto-register native skill commands where supported
commands.restart: true
- enables /restart
commands.ownerDisplay: "raw"

#

owner ids are shown raw in prompt context instead of hashed
session.dmScope: "per-channel-peer"
- DM sessions are split per channel + sender, instead of everything collapsing into one shared DM session

So, short version: yes, newer, but mostly command/session UX defaults.

Of that list, the only one with real behavior impact is session.dmScope, and that mainly affects DM session bucketing, not a Discord help thread like this one.

I would not blame these for the “I’ll do it next reply” bug.

The stuff I’d still focus on is:

lingering BOOTSTRAP.md on coordinator
tools.profile: "coding" if you expected unrestricted tools
your default model being openai-codex/gpt-5.3-codex

#

Docs:

outer hedge Apr 16, 2026, 2:35 AM

#

"bootstrap-extra-files": {
"enabled": true
}

slow muskBOT Apr 16, 2026, 2:36 AM

#

That one by itself is not scary.

bootstrap-extra-files.enabled: true just turns on a bundled hook that can load extra bootstrap files into prompt context, like extra AGENTS.md, TOOLS.md, SOUL.md, even BOOTSTRAP.md, if you also give it paths / patterns / files.

Important bit:

enabled only = basically a no-op
it only does anything if you also configured something like:
```
"paths": ["packages/*/AGENTS.md"]
```

So if your block is only:

"bootstrap-extra-files": {

#

  "enabled": true
}

then I would ignore it.

If it also has paths / patterns / files, then yes, that could matter, especially if it’s pulling in another BOOTSTRAP.md or weird extra AGENTS.md.

So the question is: does that hook block include any file patterns?

Docs:

https://docs.openclaw.ai/automation/hooks#bootstrap-extra-files

outer hedge Apr 16, 2026, 2:38 AM

#

"slots": {
"memory": "openclaw-mem0"
},

#

So why was that error before saying │ No active memory plugin is registered for the current config. │

slow muskBOT Apr 16, 2026, 2:39 AM

#

Ah, yep, that explains the memory warning.

You’ve told OpenClaw:

plugins.slots.memory = "openclaw-mem0"

So openclaw-mem0 is supposed to own the memory slot.

If OpenClaw still says:

No active memory plugin is registered for the current config

then one of these is true:

openclaw-mem0 is loading, but it is not registering the memory capability this version expects, or

#

the slot id and the actual plugin id / kind do not match cleanly

So for the memory issue specifically, openclaw-mem0 is the thing I would isolate now.

Fastest proof:

temporarily switch back to the built-in memory plugin:

{
  plugins: {
    slots: {
      memory: "memory-core"
    }
  }
}

#

restart the gateway
run:
```
openclaw memory status
```

If that starts working, then openclaw-mem0 is your memory compatibility problem on this build.

If you want to inspect what OpenClaw thinks that plugin is, run:

openclaw plugins inspect openclaw-mem0

So, short version:

#

yes, this explains the memory warning
no, I still don’t think it fully explains the weird “I’ll do it next reply” behavior by itself

Docs:

#

Because those two lines are checking different things.

openclaw-mem0: registered
= OpenClaw found the plugin and loaded it
No active memory plugin is registered for the current config
= after loading plugins, OpenClaw still did not have any plugin that successfully claimed the memory slot and registered the memory runtime/capability

So both can be true at once.

In plain English:

the plugin exists
but it is not successfully becoming the active memory backend

That usually means one of these:

#

it loads, but does not expose the memory capability this version expects
it is selected in plugins.slots.memory, but is not marked/recognized as a real memory-slot plugin at runtime
it partially loads, but skips/fails the memory registration step

So that earlier message was basically saying:

“I can see openclaw-mem0, but I still don’t have a usable memory backend.”

If switching plugins.slots.memory back to memory-core makes the warning disappear, that confirms it.

outer hedge Apr 16, 2026, 2:43 AM

#

Memory (Mem0)
id: openclaw-mem0
Mem0 memory backend — Mem0 platform or self-hosted open-source

Status: loaded
Format: openclaw
Source: ~/.openclaw/extensions/openclaw-mem0/dist/index.js
Origin: global
Version: 0.1.0
Shape: non-capability
Capability mode: none
Legacy before_agent_start: yes

Typed hooks:
agent_end
before_agent_start

Compatibility warnings:
openclaw-mem0 still uses legacy before_agent_start; keep regression coverage on this plugin, and prefer before_model_resolve/before_prompt_build for new work.

Tools:
memory_search, memory_search
memory_store, memory_store
memory_get, memory_get
memory_list, memory_list
memory_forget, memory_forget

CLI commands:
mem0

Services:

slow muskBOT Apr 16, 2026, 2:43 AM

#

Yep, this explains it exactly.

These are the key lines:

Shape: non-capability
Capability mode: none

That means openclaw-mem0 loads as a plugin, but it does not implement the newer active memory plugin capability that plugins.slots.memory expects.

So this is the situation:

openclaw-mem0 is loaded
it exposes its own memory_* tools
but it does not become the official memory slot owner

That is why OpenClaw could honestly say:

#

No active memory plugin is registered for the current config.

because for the slot/capability system, mem0 is not a valid active memory backend on this build.

So I would not set:

plugins.slots.memory = "openclaw-mem0"

on this version.

Instead:

use memory-core in the slot if you want the built-in active memory backend, or
set the slot to none if you intentionally do not want an active memory plugin,
and leave openclaw-mem0 enabled separately if you still want its custom tools.

#

So, short version: mem0 is old-shape here. Loaded, yes. Active memory slot owner, no.

outer hedge Apr 16, 2026, 2:45 AM

#

So basically this new update broke the plugin and mem0 hasnt updated yet. When did this new memory shape come into play? Could you look at the mem0 code and update it to work with this new update?

slow muskBOT Apr 16, 2026, 2:46 AM

#

Yeah, that’s my read too: mem0 looks behind the current memory-slot/capability path.

The timeline I can see in OpenClaw is roughly:

2026-01-18: feat(plugins): add memory slot plugin
2026-03-31: multi-kind / slot ownership fixes
2026-04-09 to 2026-04-12: active-memory + memory capability follow-up fixes

So this was not born in yesterday’s patch, but the newer plugin/runtime path has definitely tightened up.

Your mem0 inspect output is the giveaway:

Shape: non-capability
Capability mode: none

That means it has not been updated to the newer memory-slot shape.

#

I can’t patch it for you here

I’m read-only in this server, so I can’t edit the plugin code or ship a fix from this thread.

But this is what mem0 likely needs

If openclaw-mem0 wants to own:

plugins.slots.memory = "openclaw-mem0"

then it likely needs to:

be declared as a memory plugin (kind: "memory")
register the active memory backend via:
- api.registerMemoryCapability(...) (preferred), or at minimum
- the legacy memory runtime registration path
stop relying only on before_agent_start for memory behavior

#

Temporary workaround

For now I’d do:

{
  plugins: {
    slots: {
      memory: "memory-core"
    }
  }
}

and keep openclaw-mem0 enabled separately only if you still want its custom tools.

If you want, paste the mem0 repo link or the plugin entry file, and I can tell you what to change, but I can’t directly update it from here.

#

Refs:

outer hedge Apr 16, 2026, 2:48 AM

#

6https://github.com/tensakulabs/openclaw-mem0

#

https://github.com/tensakulabs/openclaw-mem0 is the repo for the openclaw memory plugin

slow muskBOT Apr 16, 2026, 2:52 AM

#

I checked the repo, and yeah, the problem is pretty clear.

In openclaw-mem0’s index.ts:

it declares kind: "memory"
but I do not see it calling any of the memory-slot registration APIs:
- api.registerMemoryCapability(...)
- api.registerMemoryRuntime(...)
- api.registerMemoryPromptSection(...)
- api.registerMemoryFlushPlan(...)

What it does do is:

register memory_* tools
register the mem0 CLI command
hook before_agent_start
hook agent_end

#

So it behaves like a memory-adjacent plugin, but it never actually registers itself as the active memory backend for the slot system.

That matches your inspect output exactly:

Shape: non-capability
Capability mode: none

So the earlier error makes sense:

OpenClaw loaded the plugin, but no active memory plugin took ownership of plugins.slots.memory.

Short version

openclaw-mem0 looks partially compatible, not fully migrated.

Temporary fix

Use:

#

{
  plugins: {
    slots: {
      memory: "memory-core"
    }
  }
}

and keep mem0 enabled only if you still want its custom tools/hooks.

Important caveat

I still would not assume this is the whole reason your bot only makes promises instead of acting.
This explains the memory warning very well, but the “No artifact, no claim” loop still smells like a separate runtime/model/bootstrap issue.

I can’t patch and push the plugin from this thread, but if the maintainer wants the migration target, it needs to move from just hooks/tools to an actual memory-slot registration path.

#

Refs:

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

#

Yep, that’s the repo I checked.

The bug I’d file there is basically:

openclaw-mem0 declares kind: "memory" but does not register an active memory capability/runtime.
On current OpenClaw it loads as:

Shape: non-capability

Capability mode: none

and with:
plugins.slots.memory = "openclaw-mem0"
OpenClaw reports:
No active memory plugin is registered for the current config

In other words, the plugin is loaded, but it never calls the memory-slot registration APIs, so it cannot become the active memory backend.

#Update broke openclaw

I can’t patch it for you here

But this is what mem0 likely needs

Temporary workaround

Short version

Temporary fix

Important caveat