OpenClaw setup stuck: no memory, no tool execution, agent behaves like a chatbot | Friends of the Crustacean 🦞🤝 | Page 1

slow ice Apr 13, 2026, 9:06 PM

#

Hi, I’m trying to set up an OpenClaw-based autonomous system, but I’m currently stuck and could really use some guidance.

Setup
Host: Ubuntu Server
Architecture:
OpenClaw running on main node
Ollama running on separate GPU node
Postgres + Milvus running in Docker
Goal: Multi-agent system with tool execution (DevOps, debugging, etc.)
What works
OpenClaw is installed and running
Ollama is running and reachable
Embedding model available: nomic-embed-text
Basic agent responses work
Problems

Agent cannot execute actions
The agent behaves like a chatbot
It does NOT:
interact with the system
use tools
execute commands
It only describes what should be done instead of doing it
Tool system not working
No real tool execution layer (API / services) seems active
Agent does not trigger any actual system actions
Memory system not working
openclaw memory status shows:
0 files
0 chunks
provider = none (initially)
Active Memory does not seem to run or inject context
No persistence or recall behavior
Active Memory unclear
Plugin configured, but:
not sure if it actually runs
no visible effect in responses
Unsure about correct provider setup (Ollama vs local vs API-based)
General configuration confusion
Not clear:
which settings are required vs optional
how to correctly wire:
memorySearch
active-memory plugin
embedding provider
Unsure how to properly enable:
wiki-style memory usage
dreaming feature
What I want to achieve
Agent that:
uses memory (long-term + session)
executes real actions via tools
can evolve into a self-improving system
Fully working:
memory (vector + retrieval)
active memory
tool execution layer
What I need help with
Correct minimal working configuration for:
memorySearch (with Ollama embeddings)
active-memory plugin
How to properly activate memory indexing
How to verify Active Memory is actually running
How to move from “chatbot” → “operator with tools”

Any guidance, example configs, or working setups would help a lot 🙏

remote vortexBOT Apr 13, 2026, 9:06 PM

#

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

normal merlinBOT Apr 13, 2026, 9:07 PM

#

stiff horizonBOT Apr 13, 2026, 9:12 PM

#

You’re probably mixing 4 separate systems together:

plugins.slots.memory / memory-core = the actual memory backend, indexing, promotion, dreaming
agents.defaults.memorySearch = embeddings + retrieval config
plugins.entries.active-memory = pre-reply recall for interactive chats
memory-wiki = optional wiki layer, separate from core memory

Two big clarifiers:

Built-in OpenClaw memory is not Postgres + Milvus. The documented minimal path is the built-in SQLite memory engine, or QMD if you explicitly switch to it. I would ignore Milvus/Postgres until the baseline works.
There is no separate “tool execution service” to start for built-in tools like exec, read, write, etc. They are part of the gateway, and are controlled by tool policy plus model behavior.

Minimal known-good baseline

#

  plugins: {
    slots: {
      memory: "memory-core",
    },
    entries: {
      "memory-core": {
        enabled: true,
        config: {
          dreaming: {
            enabled: false, // add later
          },
        },
      },
      "active-memory": {
        enabled: true,

#

        config: {
          enabled: true,
          agents: ["main"],
          allowedChatTypes: ["direct", "channel"], // include "channel" if testing in Discord threads/channels
          queryMode: "recent",
          promptStyle: "balanced",
          timeoutMs: 15000,
          maxSummaryChars: 220,
          persistTranscripts: false,
          logging: true,
        },
      },
    },
  },

#

  tools: {
    profile: "coding",
  },

  agents: {
    defaults: {
      memorySearch: {
        enabled: true,
        provider: "ollama",
        model: "nomic-embed-text",
        remote: {
          baseUrl: "http://YOUR_OLLAMA_HOST:11434",
        },
        sources: ["memory", "sessions"],
        experimental: {

#

          sessionMemory: true,
        },
        query: {
          hybrid: {
            mmr: { enabled: true },
            temporalDecay: { enabled: true },
          },
        },
      },
    },
  },
}

Important gotchas

#

If active-memory is set to allowedChatTypes: ["direct"], it will look dead in channels/threads.
Active Memory only runs for eligible interactive persistent chat sessions, not headless one-shot/background/internal runs.
Active Memory injects hidden context. To verify it live, use:
- /active-memory status
- /verbose on
- /trace on
0 files / 0 chunks usually means either:
- no memory files were indexed yet, or
- the provider/backend is not configured correctly.

Also, the built-in indexer only indexes MEMORY.md and memory/*.md by default, plus session transcripts if you enable experimental.sessionMemory and add "sessions" to sources.

Bring-up checklist

Restart gateway.
Run:

#

   openclaw --version
   openclaw status --all
   openclaw memory status --deep

If memory is empty, add a known test fact to MEMORY.md or ask the agent to remember something.
Rebuild:
```
openclaw memory index --force
```

Test retrieval:

openclaw memory search "your exact test phrase"

Test active memory in chat with /verbose on + /trace on.

Why it may still feel like a chatbot

#

If tools are configured but the agent still narrates instead of acting, the most common causes are:

tools.profile / tools.allow / tools.deny is restricting exec
the model is weak at tool calling
you’re testing active memory in a session type where it does not run

Docs explicitly recommend large models for tool-enabled bots. Smaller or heavily quantized local models can be much worse at actually using tools.

My recommendation

Get this working in this order:

builtin memory + Ollama embeddings
memory search CLI works
active-memory works in one chat
tool execution works
only then add dreaming

#

only then consider memory-wiki

If you want, paste these next and I’ll help you tighten it fast:

openclaw --version
openclaw status --all
openclaw memory status --deep

and the relevant parts of your openclaw.json for:

agents.defaults.memorySearch
plugins.entries.active-memory
plugins.entries.memory-core
tools

#

Docs:

slow ice Apr 13, 2026, 9:38 PM

#

this is my config, what do I need to adjust
{
"gateway": {
"mode": "local",
"remote": {
"url": "xxxx",
"token": "xxxx"
},
"auth": {
"mode": "token",
"token": "xxxx"
},
"port": 18789,
"bind": "loopback",
"tailscale": {
"mode": "off",
"resetOnExit": false
}
},
"wizard": {
"lastRunAt": "2026-04-11T13:18:39.146Z",
"lastRunVersion": "2026.4.10",
"lastRunCommand": "onboard",
"lastRunMode": "local"
},
"meta": {
"lastTouchedVersion": "2026.4.12",
"lastTouchedAt": "2026-04-13T14:05:53.198Z"
},
"agents": {
"defaults": {
"workspace": "/home/nexus/.openclaw/workspace",
"model": {
"primary": "xxxx"
}
},

#

"list": [
{
"id": "main",
"tools": {
"alsoAllow": [
"message",
"gateway",
"nodes",
"agents_list"
]
}
}
]
},
"session": {
"dmScope": "main",
"maintenance": {
"pruneDays": 1
}
},
"tools": {
"profile": "coding"
},
"plugins": {
"entries": {
"ollama": {
"enabled": true,
"config": {}
}
}
},
"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "xxxx",
"api": "ollama",
"apiKey": "OLLAMA_API_KEY",
"models": [
{
"id": "gemma4",
"name": "gemma4",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
},
{
"id": "xxxx",
"name": "xxxx",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192
},
{
"id": "xxxx",
"name": "xxxx",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192
},
{
"id": "mistral:latest",
"name": "mistral:latest",
"reasoning": false,
"input": [
"text"

#

],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"maxTokens": 8192
}
]
}
}

stiff horizonBOT Apr 13, 2026, 9:39 PM

#

Your paste is cut off, but from what’s visible the important parts are either missing or not shown yet:

no agents.defaults.memorySearch
no plugins.slots.memory
no plugins.entries.active-memory
no tools section

So yes, that would explain most of what you’re seeing.

Add/merge something like this:

{
  "agents": {
    "defaults": {
      "workspace": "/home/nexus/.openclaw/workspace",

#

      "model": {
        "primary": "xxxx"
      },
      "memorySearch": {
        "enabled": true,
        "provider": "ollama",
        "model": "nomic-embed-text",
        "remote": {
          "baseUrl": "http://YOUR_GPU_NODE_IP:11434"
        },
        "sources": ["memory", "sessions"],
        "experimental": {
          "sessionMemory": true
        }
      }

#

    }
  },
  "plugins": {
    "slots": {
      "memory": "memory-core"
    },
    "entries": {
      "memory-core": {
        "enabled": true
      },
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],

#

          "allowedChatTypes": ["direct", "channel"],
          "queryMode": "recent",
          "promptStyle": "balanced",
          "timeoutMs": 15000,
          "maxSummaryChars": 220,
          "persistTranscripts": false,
          "logging": true
        }
      }
    }
  },
  "tools": {
    "profile": "coding"
  }
}

#

A few important notes:

If you are testing in a Discord thread/channel, allowedChatTypes must include "channel", otherwise active memory will look like it never runs.
If you already have a tools.allow / tools.deny section later in the file, make sure you are not denying exec / process.
provider = none usually means memorySearch is not configured correctly, or the memory plugin slot is disabled/missing.
0 files / 0 chunks can also simply mean there is nothing to index yet.

After editing:

openclaw gateway restart
openclaw memory status --deep
openclaw memory index --force
openclaw memory search "test phrase"

And to verify active memory in chat:

#

/active-memory status
/verbose on
/trace on

Then ask about something you know is in MEMORY.md.

Also, make sure you actually have memory content, for example:

/home/nexus/.openclaw/workspace/MEMORY.md
/home/nexus/.openclaw/workspace/memory/2026-04-13.md

One more thing, if your redacted model.primary is a small local Ollama model, that can absolutely cause the “talks about actions instead of doing them” problem. Tool use gets much better with stronger models.

If you want, paste these next and I can tell you exactly what is still wrong:

#

openclaw --version
full agents.defaults
full plugins
full tools

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/active-memory
https://docs.openclaw.ai/reference/memory-config
https://docs.openclaw.ai/tools/exec

#

This helps a lot. The big takeaway is:

your tools profile is already basically fine ("profile": "coding")
your memory config is the part that’s missing
just enabling the ollama plugin does not enable memory search or active memory

So right now, provider = none is expected, because I still don’t see:

agents.defaults.memorySearch
plugins.slots.memory
plugins.entries["memory-core"]
plugins.entries["active-memory"]

What to change

Keep your existing tools.profile: "coding".

#

Add this:

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "ollama",
        "model": "nomic-embed-text",
        "remote": {
          "baseUrl": "http://YOUR_OLLAMA_HOST:11434"
        },
        "sources": ["memory", "sessions"],
        "experimental": {
          "sessionMemory": true

#

        }
      }
    }
  },
  "plugins": {
    "slots": {
      "memory": "memory-core"
    },
    "entries": {
      "ollama": {
        "enabled": true,
        "config": {}
      },
      "memory-core": {
        "enabled": true

#

      },
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],
          "allowedChatTypes": ["direct", "channel"],
          "queryMode": "recent",
          "promptStyle": "balanced",
          "logging": true
        }
      }
    }
  }
}

#

Why this matters

ollama plugin = model provider only
memorySearch = tells OpenClaw how to embed/search memory
memory-core = actual memory backend
active-memory = pre-reply memory injection for chat sessions

One more useful note

Your tools.profile: "coding" already means the agent should have access to exec, process, file tools, web tools, and memory tools. So if it still just narrates instead of acting after fixing memory, that points more to the chat model quality than to a missing tool API.

After editing

Run:

#

openclaw gateway restart
openclaw memory status --deep
openclaw memory index --force

Then make sure you actually have memory files, for example:

/home/nexus/.openclaw/workspace/MEMORY.md
/home/nexus/.openclaw/workspace/memory/2026-04-13.md

If those files are empty or missing, 0 files / 0 chunks can still happen.

To verify active memory is running

In chat:

#

/active-memory status
/verbose on
/trace on

Important: because you’re testing in a Discord thread/channel, allowedChatTypes needs "channel", otherwise it won’t run there.

Small extra warning

"pruneDays": 1 is pretty aggressive. It won’t cause provider = none, but it will limit how much session history survives. I’d revisit that after the basics work.

If you want, paste your updated full agents.defaults + plugins block, and I’ll sanity-check it line by line.

#

Yep, that confirms it.

Your config currently has:

gateway/session/models/ollama provider
tools.profile: "coding"

…but it still does not have the memory pieces.

So the fix is still to add these missing blocks:

{
  "agents": {
    "defaults": {
      "memorySearch": {

#

        "enabled": true,
        "provider": "ollama",
        "model": "nomic-embed-text",
        "remote": {
          "baseUrl": "http://YOUR_OLLAMA_HOST:11434"
        },
        "sources": ["memory", "sessions"],
        "experimental": {
          "sessionMemory": true
        }
      }
    }
  },
  "plugins": {
    "slots": {

#

      "memory": "memory-core"
    },
    "entries": {
      "ollama": {
        "enabled": true,
        "config": {}
      },
      "memory-core": {
        "enabled": true
      },
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],

#

          "allowedChatTypes": ["direct", "channel"],
          "queryMode": "recent",
          "promptStyle": "balanced",
          "logging": true
        }
      }
    }
  }
}

So, short version:

tools are probably not your main issue
memory is not configured yet
active-memory is not configured yet

#

ollama provider alone is not enough

After that:

openclaw gateway restart
openclaw memory status --deep
openclaw memory index --force

And make sure these actually exist with content:

/home/nexus/.openclaw/workspace/MEMORY.md
/home/nexus/.openclaw/workspace/memory/2026-04-13.md

#

If you want, send the updated full config after you add those blocks, and I’ll do one clean pass over it.

slow ice Apr 13, 2026, 9:50 PM

#

Do I have to do it by inserting it like this, or can I also activate it through the UI or through terminal commands?

stiff horizonBOT Apr 13, 2026, 9:51 PM

#

Yes, you can do it through the UI or terminal too.

Best practical split

For initial setup, I’d use either:

Control UI
- open the Config editor
- add the memorySearch, plugins.slots.memory, memory-core, and active-memory blocks
- apply + restart there
Terminal
- edit the config file directly, or use openclaw config ...
- then run validation / restart / memory checks

What each path is good for

#

Control UI

good for editing openclaw.json
good for apply + restart
good for checking Dreams later

CLI

good for validation and debugging:

openclaw config file
openclaw config validate
openclaw gateway restart
openclaw memory status --deep
openclaw memory index --force

Slash commands

good for toggling things after they already exist in config

#

examples:

/active-memory status
/active-memory on --global
/verbose on
/trace on
/dreaming status
/dreaming on

Important nuance

For active-memory, slash commands are not the best way to do the first wiring.
You still need the plugin/config present first.

So my recommendation is:

#

initial wiring: Control UI Config editor, or config file / CLI
after that: use /active-memory ... and /dreaming ... for toggles

Short answer

No, you do not have to hand-edit JSON only
Yes, UI works
Yes, terminal works
For the first setup, UI Config editor or config file is the cleanest
Slash commands are better for toggling later, not for building the whole config

If you want, I can give you the exact terminal command sequence next, or the exact UI path/click flow next.

slow ice Apr 13, 2026, 9:53 PM

#

please do that

stiff horizonBOT Apr 13, 2026, 9:53 PM

#

Yep, here’s the cleanest terminal-first flow.

1. Find your config file

openclaw config file

Open that file in your editor.

2. Merge in these blocks

Do not create a second plugins object.
Merge this into your existing config.

#

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "ollama",
        "model": "nomic-embed-text",
        "remote": {
          "baseUrl": "http://YOUR_OLLAMA_HOST:11434"
        },
        "sources": ["memory", "sessions"],
        "experimental": {
          "sessionMemory": true
        }
      }

#

    }
  },
  "plugins": {
    "slots": {
      "memory": "memory-core"
    },
    "entries": {
      "ollama": {
        "enabled": true,
        "config": {}
      },
      "memory-core": {
        "enabled": true
      },
      "active-memory": {

#

        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],
          "allowedChatTypes": ["direct", "channel"],
          "queryMode": "recent",
          "promptStyle": "balanced",
          "logging": true
        }
      }
    }
  }
}

3. Validate config

#

openclaw config validate

4. Restart gateway

openclaw gateway restart

5. Check memory health

openclaw memory status --deep

You want this to stop saying provider = none.

#

6. Make sure memory files actually exist

In your workspace:

MEMORY.md
memory/YYYY-MM-DD.md

If they’re missing or empty, memory can still show 0 files / 0 chunks.

7. Force indexing

openclaw memory index --force
openclaw memory search "test phrase"

8. Verify active memory in chat

#

Send these in chat:

/active-memory status
/verbose on
/trace on

Then ask something that should hit a known memory.

If you prefer the UI instead

You can do the same in the Control UI:

Open the Config editor

#

Merge the same blocks above
Apply + restart
Use the Dreams area later for dreaming, not for the initial memory wiring

One more important note

Your tools.profile: "coding" is already okay.
So if it still acts like a chatbot after this, the next likely culprit is the chat model, not the tool policy.

If you want, after you make those edits, paste:

openclaw config validate
openclaw memory status --deep

and I’ll sanity check the result.

slow ice Apr 13, 2026, 10:01 PM

#

the one that "workspace": "/home/nexus/.openclaw/workspace", comes out is correct?

stiff horizonBOT Apr 13, 2026, 10:01 PM

#

Yes, from what you pasted, that is the correct workspace path for main.

Because you have:

"agents": {
  "defaults": {
    "workspace": "/home/nexus/.openclaw/workspace"
  },
  "list": [
    {
      "id": "main"
    }
  ]
}

#

and I don’t see a per-agent workspace override for main, so it will use:

/home/nexus/.openclaw/workspace

That means these are the right locations to check/create:

/home/nexus/.openclaw/workspace/MEMORY.md
/home/nexus/.openclaw/workspace/memory/

If you want to double-check from CLI:

openclaw config get agents.defaults.workspace

#

So yes, that path is the one I’d use.

slow ice Apr 13, 2026, 10:11 PM

#

{
"agents": {
"defaults": {
"memorySearch": {
"enabled": true,
"provider": "ollama",
"model": "nomic-embed-text",
"remote": {
"baseUrl": "http://YOUR_OLLAMA_HOST:11434"
},
"sources": ["memory", "sessions"],
"experimental": {
"sessionMemory": true
}
}
}
},
"plugins": {
"slots": {
"memory": "memory-core"
},
"entries": {
"ollama": {
"enabled": true,
"config": {}
},
"memory-core": {
"enabled": true
},
"active-memory": {
"enabled": true,
"config": {
"enabled": true,
"agents": ["main"],
"allowedChatTypes": ["direct", "channel"],
"queryMode": "recent",
"promptStyle": "balanced",
"logging": true
}
}
}
}
}

that has to go in and what all has to come out, where does the }, I have meanwhile learned, that can cause problems if I do it wrong

stiff horizonBOT Apr 13, 2026, 10:12 PM

#

Yep, JSON brace pain is real 😅
The safest way is:

do not paste that as a second top-level block
instead, replace your existing agents block and your existing plugins block with these exact versions

1. Your `agents` block should look like this

"agents": {
  "defaults": {
    "workspace": "/home/nexus/.openclaw/workspace",
    "model": {
      "primary": "xxxx"
    },
    "memorySearch": {

#

      "enabled": true,
      "provider": "ollama",
      "model": "nomic-embed-text",
      "remote": {
        "baseUrl": "http://YOUR_OLLAMA_HOST:11434"
      },
      "sources": ["memory", "sessions"],
      "experimental": {
        "sessionMemory": true
      }
    }
  },
  "list": [
    {
      "id": "main",

#

      "tools": {
        "alsoAllow": [
          "message",
          "gateway",
          "nodes",
          "agents_list"
        ]
      }
    }
  ]
}

2. Your `plugins` block should look like this

Replace this:

#

"plugins": {
  "entries": {
    "ollama": {
      "enabled": true,
      "config": {}
    }
  }
}

with this:

"plugins": {
  "slots": {

#

    "memory": "memory-core"
  },
  "entries": {
    "ollama": {
      "enabled": true,
      "config": {}
    },
    "memory-core": {
      "enabled": true
    },
    "active-memory": {
      "enabled": true,
      "config": {
        "enabled": true,
        "agents": ["main"],

#

        "allowedChatTypes": ["direct", "channel"],
        "queryMode": "recent",
        "promptStyle": "balanced",
        "logging": true
      }
    }
  }
}

3. Important

keep your existing other top-level sections like gateway, session, tools, models
only replace agents and plugins
do not duplicate "agents": { ... } or "plugins": { ... }

#

4. Also replace this placeholder

http://YOUR_OLLAMA_HOST:11434

with your real Ollama URL.

5. Then run

openclaw config validate
openclaw gateway restart
openclaw memory status --deep

If you want, paste just your full updated agents + plugins blocks before saving, and I’ll check the braces/commas for you.

slow ice Apr 13, 2026, 10:21 PM

#

openclaw config file
Failed to read config at /home/nexus/.openclaw/openclaw.json SyntaxError: JSON5: invalid character '"' at 71:3
at syntaxError (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:1110:17)
at invalidChar (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:1055:12)
at Object.end (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:704:15)
at Object.default (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:168:37)
at lex (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js💯42)
at Object.parse (/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:25:17)
at Object.loadConfig (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/io-CNTgoVgA.js:18660:24)
at readCliBannerTaglineMode (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/banner-DRvsS64z.js:13:51)
at resolveTaglineMode (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/banner-DRvsS64z.js:291:9)
at formatCliBannerLine (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/banner-DRvsS64z.js:300:9) {
lineNumber: 71,
columnNumber: 3
}

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm not AI-powered, I'm AI-possessed. Big difference.

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

<root>: JSON5 parse failed: SyntaxError: JSON5: invalid character '"' at 71:3

Run: openclaw doctor --fix

stiff horizonBOT Apr 13, 2026, 10:21 PM

#

Good, we found the next blocker.

This is just a config syntax error now, not a memory/runtime mystery.

invalid character '"' at 71:3 usually means:

you started a new key like "plugins" or "models"
but the block above it did not end with a comma

Most likely you currently have something like this:

  }
  "plugins": {

when it needs to be:

#

  },
  "plugins": {

What to check

Open ~/.openclaw/openclaw.json and go to line 71.

Then check the line right above it.

Common fix

If you see:

"agents": {

#

  ...
}
"plugins": {

change it to:

"agents": {
  ...
},
"plugins": {

Also check this

#

At the root of the file, you should only have one outer { ... }.

So this is wrong:

{
  "gateway": { ... }
}
{
  "agents": { ... }
}

and this is right:

#

{
  "gateway": { ... },
  "agents": { ... },
  "plugins": { ... }
}

Fastest way forward

Paste lines 60 through 80 here, exactly as they are now.
That’ll make it very easy to spot the missing comma or extra }.

You’re close, this is almost certainly just one comma/bracket issue.

slow ice Apr 13, 2026, 10:23 PM

#

"logging": true
66 }
67 }
68 }
69 }
70 }
71 "session": {
72 "dmScope":

to

67 }
68 }
69 }
70 },
71 "session": {
72 "dmScope": "main",
73 "maintenance": {
74 "pruneDays": 10
75 }
76 },

stiff horizonBOT Apr 13, 2026, 10:24 PM

#

Yes, that fix looks correct.

The important part was this change:

70   }
71   "session": {

to:

70   },
71   "session": {

That missing comma was the parse error. Nice catch.

#

And this part is also fine:

72     "dmScope": "main",
73     "maintenance": {
74       "pruneDays": 10
75     }
76   },

pruneDays: 10 is safer than 1, so that’s a good change too.

Next step

Run:

#

openclaw config validate

If that passes, then:

openclaw gateway restart
openclaw memory status --deep

If you want, paste the result of openclaw config validate next and I’ll check the next step with you.

slow ice Apr 13, 2026, 10:25 PM

#

Config invalid at ~/.openclaw/openclaw.json:
× <root>: JSON5 parse failed: SyntaxError: JSON5: invalid character ',' at 70:4

Run openclaw doctor to repair, or fix the keys above manually.

stiff horizonBOT Apr 13, 2026, 10:26 PM

#

Yep, now it looks like the opposite problem, one } too many before "session".

You had 5 closing braces there, but that block should only need 4.

So instead of this shape:

      }
    }
  }
},
"session": {

you likely need this shape:

#

        }
      }
    }
  },
  "session": {

In plain English

delete one extra }
the comma should stay on the line that closes plugins
"session" should come right after that

Most likely fix

Change this area to:

#

          "logging": true
        }
      }
    }
  },
  "session": {
    "dmScope": "main",
    "maintenance": {
      "pruneDays": 10
    }
  },

So yes, the problem now is probably:

before: missing comma

#

now: extra closing brace

You’re very close.

If you want the fastest exact check, paste lines 62 to 74 exactly as they are now, and I’ll tell you the precise line to delete.

slow ice Apr 13, 2026, 10:28 PM

#

openclaw config validate

🦞 OpenClaw 2026.4.12 (1c0672b) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

Config valid: ~/.openclaw/openclaw.json

stiff horizonBOT Apr 13, 2026, 10:29 PM

#

Nice, that’s progress 🎉
The config is valid now.

Next, run these in order

openclaw gateway restart
openclaw memory status --deep

What I want to see next

Ideally memory status --deep should no longer show:

provider = none

If it still does, paste that output here.

#

After that

If memory provider looks okay, run:

openclaw memory index --force

Then check whether these files exist and contain at least a little test content:

/home/nexus/.openclaw/workspace/MEMORY.md
/home/nexus/.openclaw/workspace/memory/

If they’re empty, 0 files / 0 chunks can still happen even with correct config.

#

Then verify active memory

In chat:

/active-memory status
/verbose on
/trace on

You’ve done the annoying part now. Next output I want is:

openclaw memory status --deep

slow ice Apr 13, 2026, 10:30 PM

#

nexus@ai-nexus:~/Nexus-ai$ openclaw memory status --deep

🦞 OpenClaw 2026.4.12 (1c0672b) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
◇
[openclaw] Failed to start CLI: Error: Unknown memory embedding provider: ollama
at getAdapter (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:341:22)
at createEmbeddingProvider (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:393:25)
at MemoryIndexManager.loadProviderResult (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2759:16)
at file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2864:52
at MemoryIndexManager.ensureProviderInitialized (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2872:5)
at MemoryIndexManager.probeVectorAvailability (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:3223:14)
at file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:418:20
at withProgress (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/progress-EZ0eRtzP.js:116:16)
at Object.run (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:413:11)
at withManager (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli-utils-BpjfmMHH.js:10:16)
nexus@ai-nexus:~/Nexus-ai$

stiff horizonBOT Apr 13, 2026, 10:32 PM

#

Ah, this changes the diagnosis.

Your config is now syntactically valid, but your installed build is rejecting this:

"provider": "ollama"

for memory embeddings.

So the issue is no longer your JSON, it’s this:

models.providers.ollama works for your chat model
but on your current OpenClaw 2026.4.12, the memory embedding provider registry does not recognize ollama

Short version

#

memorySearch.provider: "ollama" is not supported by the build you’re running.

That error is pretty definitive:

Unknown memory embedding provider: ollama

Best fix

Update OpenClaw first, then retry the same config.

Docs:

Important warning

#

Do not use openclaw update expecting it to update the code.
That command is for config modernization, not binary upgrade.

If you want a temporary workaround right now

Switch memory search to:

"provider": "local"

instead of:

"provider": "ollama"

#

But that means embeddings run locally on the main node, not on your Ollama GPU node.

So I’d recommend:

upgrade OpenClaw
keep your current memorySearch.provider: "ollama" config

rerun:

openclaw gateway restart
openclaw memory status --deep

Why this happened

You’re hitting version skew:

the config shape is fine

#

the current docs / newer builds support more
your installed build does not know the ollama memory adapter yet

If you want, I can give you the safest upgrade path next, based on how you installed OpenClaw.

slow ice Apr 13, 2026, 10:42 PM

#

nexus@ai-nexus:~/Nexus-ai$ npx openclaw@latest --version
Need to install the following packages:
openclaw@2026.4.12
Ok to proceed? (y)

stiff horizonBOT Apr 13, 2026, 10:43 PM

#

That’s really helpful, and I need to correct my earlier guess.

If npx openclaw@latest still resolves to 2026.4.12, then this is not just your local install being outdated.

So the real situation looks like this:

published stable = 2026.4.12
that published build does not support memorySearch.provider: "ollama"
the docs/source I checked are ahead of what npm is currently shipping

What to do right now

For the released version you’re on, change your memory config from ollama to local.

Replace this:

#

"memorySearch": {
  "enabled": true,
  "provider": "ollama",
  "model": "nomic-embed-text",
  "remote": {
    "baseUrl": "http://YOUR_OLLAMA_HOST:11434"
  },
  "sources": ["memory", "sessions"],
  "experimental": {
    "sessionMemory": true
  }
}

With this:

#

"memorySearch": {
  "enabled": true,
  "provider": "local",
  "sources": ["memory", "sessions"],
  "experimental": {
    "sessionMemory": true
  }
}

Important

When you switch to local:

remove the remote block
remove model: "nomic-embed-text"

#

because those were specific to the Ollama plan.

Then test again

openclaw config validate
openclaw gateway restart
openclaw memory status --deep

What this means

this should get memory search working on the current stable release
but embeddings will run locally on the main node, not on your separate Ollama GPU node

If you specifically want Ollama embeddings on the GPU node

#

Then you’ll likely need a newer source build, not the current published npm release.

So I’d suggest:

get it working now with provider: "local"
verify memory + active-memory
only then decide whether you want to chase the newer source build path for remote Ollama embeddings

If you want, send your updated memorySearch block after switching it to local, and I’ll sanity-check it before you restart.

slow ice Apr 13, 2026, 10:47 PM

#

how do I get the version that works, so the 2026.4.13

stiff horizonBOT Apr 13, 2026, 10:48 PM

#

I just checked, and 2026.4.13 is not published on npm yet.
openclaw@latest is still 2026.4.12.

So:

you cannot get 2026.4.13 via npm/pnpm/npx right now
if you specifically want unreleased changes, you need a source/main install

Your two real options

Option 1, easiest and recommended

Stay on 2026.4.12 and switch memory embeddings to:

"provider": "local"

#

That gets you a working setup on the currently published release.

Option 2, if you really want the newer unreleased code

Install from source / git instead of npm.

Docs:

The repo-recommended git installer path is:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git

Or manually:

#

git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
pnpm ui:build
openclaw onboard

My honest recommendation

Because you’re already deep in config debugging, I’d not switch install methods yet unless you really need Ollama embeddings on the GPU node right now.

The shortest path to “working today” is:

stay on 2026.4.12
change memory provider to local

#

get memory + active-memory working
only then decide whether to move to a source install

If you want, I can give you the exact final memorySearch block for 2026.4.12 stable next, so you can copy-paste it cleanly.

slow ice Apr 13, 2026, 11:14 PM

#

have to go to bed now, will continue tomorrow

stiff horizonBOT Apr 13, 2026, 11:14 PM

#

No worries, get some sleep 😌

You made real progress tonight:

config syntax is fixed
config validates
main blocker is now clear: 2026.4.12 does not accept memorySearch.provider: "ollama"

So tomorrow, the next move is:

change memorySearch.provider from "ollama" to "local"
remove the Ollama-specific model + remote fields from that memory block

run:

openclaw gateway restart
openclaw memory status --deep

#

When you’re back, paste that output and we can pick up from there.

slow ice Apr 14, 2026, 6:52 AM

#

What kind of model has to run on the local PC, is that sufficient?

sudo apt update
sudo apt install -y build-essential python3 make g++
pnpm approve-builds
pnpm rebuild node-llama-cpp

stiff horizonBOT Apr 14, 2026, 6:53 AM

#

Close, but not quite the full picture.

For memorySearch.provider: "local", the thing that runs on the local PC is not an Ollama chat model.
It’s a local embedding model via node-llama-cpp.

What model?

By default, OpenClaw uses a small GGUF embedding model and auto-downloads it:

embeddinggemma-300m-qat-Q8_0.gguf

So for the stable build, you do not need to run nomic-embed-text locally through Ollama for memory embeddings.

Are your commands sufficient?

They are the right build prerequisites, but whether they are sufficient depends on how OpenClaw was installed.

#

You posted:

sudo apt update
sudo apt install -y build-essential python3 make g++
pnpm approve-builds
pnpm rebuild node-llama-cpp

That is good if you are using a pnpm/source install.

But in your case

Your OpenClaw path looked like a global install under nvm, so the more relevant path is:

keep provider: "local"
remove the Ollama-specific memory fields
if local embeddings fail, it usually means node-llama-cpp is missing for that install

#

in that case, reinstall OpenClaw for that environment

From the runtime/source behavior, local embeddings want:

Node 24 is recommended for installs/updates, though Node 22 LTS is still supported
node-llama-cpp installed correctly
then the default local embedding model is auto-downloaded

So I’d do this first

Use this memory block:

"memorySearch": {
  "enabled": true,
  "provider": "local",

#

  "sources": ["memory", "sessions"],
  "experimental": {
    "sessionMemory": true
  }
}

Then run:

openclaw gateway restart
openclaw memory status --deep

If `local` still fails

Paste that output.

#

If it complains about node-llama-cpp, then we know the next step is fixing the local native install, not the config.

So, short answer:

model type: local GGUF embedding model, not Ollama chat model
is your command set sufficient? yes for pnpm/source installs, maybe not for your current global install
best next step: switch to provider: "local" and test openclaw memory status --deep first

slow ice Apr 14, 2026, 7:03 AM

#

🦞 OpenClaw 2026.4.12 (1c0672b) — The only crab in your contacts you actually want to hear from. 🦞

│
◇
[openclaw] Failed to start CLI: Error: Local embeddings unavailable.
Reason: optional dependency node-llama-cpp is missing (or failed to install).
Detail: Cannot find package 'node-llama-cpp' imported from /home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/engine-embeddings-B3zaTJbS.js
To enable local embeddings:

Use Node 24 (recommended for installs/updates; Node 22 LTS, currently 22.14+, remains supported)
Reinstall OpenClaw (this should install node-llama-cpp): npm i -g openclaw@latest
If you use pnpm: pnpm approve-builds (select node-llama-cpp), then pnpm rebuild node-llama-cpp
Or set agents.defaults.memorySearch.provider = "openai" (remote).
Or set agents.defaults.memorySearch.provider = "gemini" (remote).
Or set agents.defaults.memorySearch.provider = "voyage" (remote).
Or set agents.defaults.memorySearch.provider = "mistral" (remote).
at createEmbeddingProvider (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:417:19)
at async MemoryIndexManager.loadProviderResult

#

(file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2759:10)
at async file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2864:27
at async MemoryIndexManager.ensureProviderInitialized (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:2874:4)
at async MemoryIndexManager.probeVectorAvailability (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/manager-FzeN0TEi.js:3223:3)
at async file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:418:6
at async withProgress (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/progress-EZ0eRtzP.js:116:10)
at async Object.run (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:413:5)
at async withManager (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli-utils-BpjfmMHH.js:10:3)
at async withMemoryManagerForAgent (file:///home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:253:2)

stiff horizonBOT Apr 14, 2026, 7:04 AM

#

Perfect, this is the real blocker now.

Your config is okay.
Your local embedding provider is failing because the actual OpenClaw install you are running is missing node-llama-cpp.

The key detail is this path:

/home/nexus/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/

So your earlier pnpm rebuild ... in ~/Nexus-ai would not fix the global OpenClaw install that is actually being used.

What I’d do

Cleanest fix

Reinstall the global OpenClaw install, ideally on Node 24.

#

nvm install 24
nvm use 24

npm uninstall -g openclaw
npm install -g openclaw@latest

openclaw doctor
openclaw gateway restart
openclaw memory status --deep

Why this should help

The runtime is explicitly telling you:

node-llama-cpp is missing

#

reinstalling OpenClaw should install it
Node 24 is recommended for installs/updates

Keep this config for now

"memorySearch": {
  "enabled": true,
  "provider": "local",
  "sources": ["memory", "sessions"],
  "experimental": {
    "sessionMemory": true
  }
}

Do not put back:

#

provider: "ollama"
model: "nomic-embed-text"
remote.baseUrl

for the stable build.

If reinstall works

Next command should stop erroring:

openclaw memory status --deep

If it still fails after reinstall

Paste these:

#

which openclaw
node -v
openclaw --version
openclaw memory status --deep

You’re actually very close now. This is down to one missing native dependency.

#

That stack trace is still pointing at:

/home/nexus/.nvm/versions/node/v22.22.2/

So it looks like you’re still running the old Node 22 global install, not a fresh Node 24 one yet.

Before we guess further, please run these exactly and paste the full output:

which node
node -v
which openclaw
openclaw --version

#

If you already tried nvm use 24, also run:

nvm current

What I’m checking

I want to confirm whether:

your shell is still on Node 22
openclaw is still coming from the old global path
the reinstall actually landed where the shell is looking

Because right now the trace strongly suggests:

either nvm use 24 was not active in this shell
or openclaw is still installed globally under the old Node 22 path

#

You’re not far off, this is probably just the shell still using the old binary.

normal merlinBOT Apr 14, 2026, 7:15 AM

#

slow ice Apr 14, 2026, 7:31 AM

#

he installation is now working correctly.
Local memory is fully operational — embeddings are running, the model was downloaded automatically (embeddinggemma), and openclaw memory status --deep shows everything as ready (vector, FTS, embeddings).

So the original issue (missing node-llama-cpp) is resolved.
Now I’m running into a different issue:

When Active Memory is enabled and I run:

/active-memory status
/trace on
/verbose on

the system appears to hang before producing a response.

It looks like the blocking Active Memory step is not completing properly (no response or very long delay).

stiff horizonBOT Apr 14, 2026, 7:32 AM

#

That’s actually good news, memory itself is working now.

What you’re seeing now is most likely Active Memory latency, not broken indexing.

Because Active Memory is a blocking pre-reply step, if it uses a slow local model it can feel like the whole reply is hanging.

First thing I’d change

Tighten the active-memory config to make it much cheaper:

"active-memory": {
  "enabled": true,
  "config": {
    "enabled": true,
    "agents": ["main"],

#

    "allowedChatTypes": ["direct", "channel"],
    "queryMode": "message",
    "promptStyle": "strict",
    "timeoutMs": 5000,
    "maxSummaryChars": 120,
    "thinking": "off",
    "logging": true
  }
}

Why

queryMode: "message" is cheaper than "recent"
timeoutMs: 5000 fails faster instead of feeling stuck
maxSummaryChars: 120 keeps the recall small
thinking: "off" avoids extra latency

#

Important detail

If config.model is unset, Active Memory tries to use the current session model first.

So if your main chat model is slow locally, Active Memory will inherit that slowness.
If needed, you can later set:

"model": "your-fastest-local-model"

inside the active-memory.config block, to force a faster recall model.

How to debug it properly

In one terminal:

#

openclaw logs --follow

Then in chat:

/trace on
/verbose on

Send one normal message and watch the logs.

You’re looking for lines like:

active-memory: ... start
active-memory: ... done

#

memory sync failed (search-bootstrap)
model/provider timeout errors

One important UX note

/trace on and /verbose on do not show before the reply.
Those diagnostics show after the normal assistant reply.

So if the reply never comes, the blocking sub-step is what’s slow.

My recommendation

change active-memory to the cheaper config above
restart gateway
test again
if it still hangs, paste the relevant openclaw logs --follow lines here

#

At this point you’re not in “nothing works” territory anymore, you’re in tuning/debugging territory. That’s a much better place to be.

slow ice Apr 14, 2026, 8:30 AM

#

08:28:44+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=d66c72d3a7d34220dc4bed9bc1b738763bbd29ee216c10cdccf322971d16962b ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=5f9800a3-85cb-4ea6-887e-01973886ea5f
08:28:44+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
08:28:44+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
gateway connect failed: GatewayClientRequestError: pairing required

stiff horizonBOT Apr 14, 2026, 8:30 AM

#

Nice, this log is actually very clear.

This is not Active Memory hanging by itself.
Your CLI/device auth is getting blocked by a scope upgrade:

current scopes: operator.read
requested scopes: operator.admin, operator.approvals, operator.pairing, operator.read, operator.talk.secrets, operator.write

That’s why you see:

GatewayClientRequestError: pairing required
reason=scope-upgrade

Fix

#

Approve the pending device/scope upgrade:

openclaw devices list

Then approve the current pending request:

openclaw devices approve <requestId>

Important

If the device retries, the old pending request can get superseded, so:

run openclaw devices list right before approval
use the current requestId

#

After that

Retry the thing that was failing, for example:

openclaw logs --follow

or your Active Memory test flow.

What happened

Your client/CLI connected with a narrower paired-device token, then tried to do something that needed broader operator scopes, so the gateway asked for re-approval.

So the next step is not memory config anymore, it’s:

openclaw devices list

#

openclaw devices approve <requestId>

If you want, paste the output of openclaw devices list and I’ll tell you exactly which request to approve.

slow ice Apr 14, 2026, 8:34 AM

#

nexus@ai-nexus:~$ openclaw devices approve 7fe8efa2-fa7d-4fb7-9508-5e1a88b7796e

🦞 OpenClaw 2026.4.12 (1c0672b) — More integrations than your therapist's intake form.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId

stiff horizonBOT Apr 14, 2026, 8:34 AM

#

Yep, that means the request ID you used is already stale.

unknown requestId here usually means the scope-upgrade request got superseded and a newer pending request replaced it.

Do this exactly

Stop retrying the failing command for a moment.
Run:

openclaw devices list

Find the current pending request for that device / scope upgrade.
Immediately approve that exact current ID:

#

openclaw devices approve <new-requestId>

Why this happens

For pairing / scope-upgrade flows, OpenClaw can create a new requestId if the device retries with changed auth details. So an older one becomes invalid fast.

If it helps

Use:

openclaw devices list --json

That can make the current pending request easier to spot.

#

If you paste the output of openclaw devices list, I can point to the exact one to approve.

slow ice Apr 14, 2026, 9:17 AM

#

We reinstalled OpenClaw using Node 24 via nvm. The CLI is correctly using Node 24 (which node → v24, which openclaw → v24 path), but the systemd service still runs on Node 22 (openclaw status shows node 22.22.2). So there is a mismatch between CLI/runtime and the service.

Additionally, we changed the model in the config to llama3:latest, but OpenClaw keeps reverting to gemma4 in active sessions, which causes 404 model errors. It looks like an old session state is overriding the config.

Questions:

How can we ensure the systemd service uses Node 24 (nvm) instead of Node 22?
How can we force OpenClaw to fully apply the new model config and avoid falling back to the old session model?

Thanks!

stiff horizonBOT Apr 14, 2026, 9:22 AM

#

Yep, those two symptoms fit together.

1) Make systemd use Node 24

The managed gateway service stores the absolute runtime path it was installed with.
So if it was installed while Node 22 was active, it will keep launching with Node 22 until you reinstall the service from a Node 24 shell.

Run this from the same shell where which node and which openclaw both point at Node 24:

nvm use 24
which node
which openclaw

openclaw gateway uninstall
openclaw gateway install --force

#

openclaw gateway restart
openclaw gateway status --deep

If you still have the old global install under Node 22, I’d also clean that up so it stops confusing things:

nvm exec 22 npm uninstall -g openclaw

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

2) Why it keeps reverting to `gemma4`

That’s very likely a persisted session model override.

#

In Discord threads, sessions are persistent. Changing config does not rewrite the already-running session.
And Active Memory inherits the current session model first when active-memory.config.model is unset, so the old session model can keep dragging gemma4 back in.

3) Fastest way to force the new model

In that same Discord thread, start a fresh session and set the model at the same time:

/new llama3:latest

That is the cleanest fix.

If you only edit config and keep using the same live thread session, the old override can keep winning.

Docs: https://docs.openclaw.ai/concepts/session
Active Memory model resolution: https://docs.openclaw.ai/concepts/active-memory

#

4) If you want this fully deterministic

Pin Active Memory to a model explicitly so it stops inheriting stale session state:

"plugins": {
  "entries": {
    "active-memory": {
      "enabled": true,
      "config": {
        "enabled": true,
        "agents": ["main"],
        "allowedChatTypes": ["direct", "channel"],
        "model": "llama3:latest",
        "queryMode": "message",
        "thinking": "off",

#

        "logging": true
      }
    }
  }
}

5) Recommended order

reinstall the gateway service from a Node 24 shell
verify with openclaw gateway status --deep
in the Discord thread, run /new llama3:latest
test again

If you want, paste the output of openclaw gateway status --deep after reinstall and I’ll sanity-check whether the service is finally pinned to Node 24.

slow ice Apr 14, 2026, 9:55 AM

#

error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=6042 error="Error: No API key found for provider "openai". Auth store: /home/nexus/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/nexus/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
09:45:42+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:temp:slug-generator durationMs=6044 error="Error: No API key found for provider "openai". Auth store: /home/nexus/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/nexus/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
09:45:42+00:00 error llm-slug-generator {"subsystem":"llm-slug-generator"} Failed to generate slug: Error: No API key found for provider "openai". Auth store: /home/nexus/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/nexus/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
at resolveApiKeyForProvider (file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/model-auth-Dveg7AM9.js:308:8)
at getApiKeyForModel (file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/model-auth-Dveg7AM9.js:372:9)
at resolveApiKeyForCandidate (file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/pi-embedded-runner-

#

CefZK1Pt.js:7439:10)
at applyApiKeyInfo (file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/pi-embedded-runner-CefZK1Pt.js:7449:28)
at initializeAuthProfile (file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/pi-embedded-runner-CefZK1Pt.js:7546:11)
at file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/pi-embedded-runner-CefZK1Pt.js:8127:10
at file:///home/nexus/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/command-queue-Deq0-o7-.js:119:22

stiff horizonBOT Apr 14, 2026, 9:56 AM

#

Aha, this is the missing piece.

That error means OpenClaw is still resolving some run to the openai provider, which is why it asks for an OpenAI API key.

The likely cause

You changed the model to:

llama3:latest

but OpenClaw model refs are safest as explicit provider/model.

So instead of:

#

llama3:latest

use:

ollama/llama3:latest

Docs: https://docs.openclaw.ai/concepts/models

Why this matters

Per the docs, if you omit the provider, OpenClaw may:

try alias resolution

#

try unique configured-provider matching
then fall back to the configured default provider

If that default provider is openai, you get exactly this error:

No API key found for provider "openai"

What I’d change right now

Use the explicit Ollama ref everywhere relevant:

agents.defaults.model.primary
any agents.defaults.model.fallbacks
any per-agent model
plugins.entries.active-memory.config.model if you set one

#

current live session via:

/new ollama/llama3:latest

Not /new llama3:latest.

Also check for stale fallbacks

If gemma4 keeps coming back, it may still exist in one of these places:

current session override
agents.defaults.model.fallbacks
per-agent model config
Active Memory config.model

#

Recommended sequence

make model refs explicit as ollama/llama3:latest
restart gateway
in the Discord thread run:

/new ollama/llama3:latest

verify with:

/model status

Short version

#

This is not “OpenClaw requires OpenAI”.
It’s “an unprefixed model ref is still resolving to the OpenAI provider somewhere”.

If you want, paste the current model-related part of openclaw.json and I’ll point out exactly which entries still need the ollama/ prefix.

#

Yep, that stack tail is just the crash path, not the root cause.

The important part is still:

No API key found for provider "openai"

So something is still resolving to openai/... or falling back to the default provider.

Next useful data

Please paste these exact outputs:

openclaw config get agents.defaults.model

#

openclaw config get agents.defaults.models
openclaw config get agents.list
openclaw config get plugins.entries.active-memory.config.model

And in the Discord thread:

/model status

What I’m checking for

llama3:latest used without ollama/
stale gemma4 in per-session override
fallbacks still pointing at an old model/provider

#

Active Memory pinned to a different model than the main agent

If you want the short likely fix right now, it’s still:

/new ollama/llama3:latest

But the config output above will tell us exactly where the bad provider resolution is coming from.

slow ice Apr 14, 2026, 10:28 AM

#

the issue is still not resolved, and here is our setup for context:

We are running a split setup:

Main node (this machine): OpenClaw + memory (local embeddings via CPU, node-llama-cpp)
Remote node: Ollama running in Docker (GPU) for LLM inference

We updated all model references to explicit provider format:
ollama/llama3

Specifically in:

agents.defaults.model.primary
active-memory config
restarted the gateway

We also started a fresh session:
/new ollama/llama3

Memory is working correctly (local provider), embeddings are loaded and indexed.

However, we still get:
"No API key found for provider 'openai'"

From logs, it appears that some internal components (e.g. slug-generator / diagnostic lane) are still resolving to the OpenAI provider, even though the main agent uses Ollama.

So current behavior:

Main agent → Ollama (remote GPU) ✅
Memory → local CPU embeddings ✅
Some internal subsystems → fallback to OpenAI ❌

Questions:

Where else could OpenClaw still resolve to the OpenAI provider in this architecture?
Is there a global default provider or hidden fallback we need to override?
Can we enforce Ollama as the only provider across all subsystems?
Is this expected behavior for internal lanes (slug-generator, diagnostics), or a misconfiguration?

Happy to provide full config or more logs if needed.

stiff horizonBOT Apr 14, 2026, 10:29 AM

#

This is finally specific enough to pin down.

I checked source, and the slug generator is not using a hidden separate model config. It does this:

resolve the default agent’s effective primary model
if that is missing/unusable, fall back to hardcoded defaults:
- DEFAULT_PROVIDER = "openai"
- DEFAULT_MODEL = "gpt-5.4"

So yes, there is a global built-in fallback, but you should only hit it when model resolution fails.

That means this is not “OpenAI is required”.
It means some internal run is failing to resolve a valid effective model for the default agent, so it drops to the built-in openai/gpt-5.4 fallback and then crashes because no OpenAI key exists.

Short answers

Where else can it still resolve to OpenAI?

#

Anywhere that falls back to the product default when no valid model is resolved.
From your logs, llm-slug-generator is definitely one of those places.

Is there a hidden global default?

Yes, in source there is a hardcoded default of openai/gpt-5.4.

Can you enforce Ollama everywhere?

Mostly yes, by making sure the effective default agent model always resolves to a valid ollama/... ref, and by clearing stale fallbacks/overrides. There isn’t a single “only provider = ollama” master switch that replaces all bad resolution paths.

Is this expected?

The fallback behavior is expected.
Hitting it in your Ollama-only setup is a misconfiguration / unresolved model path.

Most likely culprits now

agents.list.main.model still overrides the default
agents.defaults.model is in the wrong shape/path

#

the default agent is not the one you think
a fallback/model override is still stale somewhere

Please paste these exact outputs

openclaw config get agents.defaults.model
openclaw config get agents.list
openclaw config get agents.defaults.compaction.model
openclaw config get plugins.entries.active-memory.config.model
openclaw config validate

If you want the fastest interpretation:

slug-generator cares about the default agent model
so memorySearch is not the issue anymore

#

I’m specifically looking for a stale main agent override or malformed agents.defaults.model

Docs: https://docs.openclaw.ai/concepts/models
Also, model refs should stay explicit provider/model, exactly as you’ve started doing.

night radish Apr 14, 2026, 10:34 AM

#

Would try a qwen3.5 varient if you are using ollama, 4b or above. Gemma4 (e4b?) also had function calling problems for me, and llama3 is too old

stiff horizonBOT Apr 14, 2026, 10:35 AM

#

Yep, that’s a fair suggestion.

Tool calling quality is very model-dependent, especially with Ollama-served local models. So even after the config/auth issue is fixed, a weaker or older model can still act chatbot-y and avoid tools.

But I’d separate the two problems:

Current blocker: the unexpected openai fallback/auth error
Next tuning step: pick a more tool-reliable Ollama model once the runtime is actually resolving the right provider cleanly

So I wouldn’t treat model quality as the cause of the No API key found for provider "openai" error. That part is still a config/resolution issue.

For current model recommendations, I’d check:

docs: https://docs.openclaw.ai/concepts/models
community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
and the #models channel for fresh hands-on reports

Once the OpenAI fallback is gone, if it still behaves like a chatbot, then I’d absolutely test a stronger Ollama model next.

slow ice Apr 14, 2026, 11:05 AM

#

thanks a lot — with your help I was able to get the system running. Memory (local embeddings via CPU) and the LLM on a separate Ollama node are both working now.

However, I’m still running into issues with the execution flow. In particular:

The system still falls back to the OpenAI provider in some internal runs (e.g. slug generator), even though all models are explicitly set to ollama/...
This results in errors like:
No API key found for provider "openai"
Additionally, I’m seeing repeated tool misuse errors:
EISDIR: illegal operation on a directory
And multiple skills are being skipped due to size limits (SKILL.md oversized)

Example logs:

Error: No API key found for provider "openai"
Failed to generate slug
EISDIR: illegal operation on a directory
Skipping skill due to oversized SKILL.md

Since this seems to be a separate issue (likely model resolution / fallback behavior + tool handling), I will open a new ticket for this to keep things clean.

Thanks again for the support so far — the system is much closer to working now.

stiff horizonBOT Apr 14, 2026, 11:06 AM

#

Glad you got the big pieces working, that’s real progress 🎉

And yep, I agree, the remaining stuff looks like a separate runtime bug cluster, not the original memory setup issue:

internal openai fallback during slug generation
EISDIR: illegal operation on a directory
oversized SKILL.md skips

At this point I’d move that to a GitHub issue so it’s tracked properly:

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

If you file it, I’d include:

openclaw --version
the relevant agents.defaults.model / agent model config
the full error line for the openai fallback

#

the full EISDIR stack
one example of the oversized skill path/name
confirmation that memory now works with local embeddings and Ollama is remote

That’ll make it much easier to reproduce.

Also, if this thread solved the original setup blocker, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future users.

night radish Apr 14, 2026, 12:12 PM

#

Classic “ai generate this, I don’t read this” behavior kek

Don’t expect too much if the codebase is pushing out one release per day

stiff horizonBOT Apr 14, 2026, 12:12 PM

#

Fair roast 😅

But honestly, narrowing it from “nothing works” to:

memory works
remote Ollama works
these 2 to 3 runtime bugs remain

is exactly the kind of boring, specific bug report that actually gets fixed.

Fast release cadence definitely means rough edges show up faster, but it also means isolated repros usually have a shot.

#OpenClaw setup stuck: no memory, no tool execution, agent behaves like a chatbot

Minimal known-good baseline

Important gotchas

Bring-up checklist

Why it may still feel like a chatbot

My recommendation

What to change

Why this matters

One more useful note

After editing

To verify active memory is running

Small extra warning

Best practical split

What each path is good for

Important nuance

Short answer

1. Find your config file

2. Merge in these blocks

3. Validate config

4. Restart gateway

5. Check memory health

6. Make sure memory files actually exist

7. Force indexing

8. Verify active memory in chat

If you prefer the UI instead

One more important note

1. Your agents block should look like this

2. Your plugins block should look like this

3. Important

4. Also replace this placeholder

5. Then run

What to check

Common fix

Also check this

Fastest way forward

Next step

In plain English

Most likely fix

Next, run these in order

What I want to see next

After that

Then verify active memory

Short version

Best fix

Important warning

If you want a temporary workaround right now

Why this happened

What to do right now

Replace this:

With this:

Important

Then test again

What this means

If you specifically want Ollama embeddings on the GPU node

Your two real options

Option 1, easiest and recommended

Option 2, if you really want the newer unreleased code

My honest recommendation

What model?

Are your commands sufficient?

But in your case

So I’d do this first

If local still fails

What I’d do

Cleanest fix

Why this should help

Keep this config for now

If reinstall works

If it still fails after reinstall

What I’m checking

First thing I’d change

Why

Important detail

How to debug it properly

One important UX note

My recommendation

Fix

Important

After that

What happened

1. Your `agents` block should look like this

2. Your `plugins` block should look like this

If `local` still fails

2) Why it keeps reverting to `gemma4`