bot is not responding in discord & telegram | Friends of the Crustacean 🦞🤝 | Page 1

wet kelp Apr 13, 2026, 1:16 AM

#

for some reason i keep getting this message whenever the bot trys to respond in anything besides the site.
The model did not produce a response before the LLM idle timeout. Please try again, or increase agents.defaults.llm.idleTimeoutSeconds in your config (set to 0 to disable).

and i get this in the logs

01:15:08+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"2e97670a-cba4-489b-9b9c-d4522f004954","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":"timeout","provider":"github-copilot","model":"gpt-5.2","profileId":"sha256:bbb6682dd900","fallbackConfigured":false,"timedOut":true,"aborted":true} embedded run failover decision

grizzled creekBOT Apr 13, 2026, 1:16 AM

#

void fieldBOT Apr 13, 2026, 1:16 AM

#

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

grizzled creekBOT Apr 13, 2026, 1:16 AM

#

tulip oreBOT Apr 13, 2026, 1:19 AM

#

That log points to the model request timing out, not Discord/Telegram delivery.

timedOut:true + decision:"surface_error" means OpenClaw never got the first streamed chunk back from github-copilot/gpt-5.2 before the LLM idle timeout fired. fallbackConfigured:false means there was no backup model/profile to try, so it surfaced the timeout message.

First, please paste:

openclaw --version
openclaw status --all
openclaw models status

Quickest test:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json

#

openclaw gateway restart

If that fixes it, the provider/model is just too slow to first token for your current timeout. If you want, you can also test 0 to disable the idle watchdog entirely, but I’d use that as a diagnostic first, not as the long-term fix.

Also, your log shows fallbackConfigured:false, so after version/config confirmation I’d add a fallback model too.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/agent-loop
https://docs.openclaw.ai/concepts/model-failover
https://docs.openclaw.ai/cli/config

wet kelp Apr 13, 2026, 1:23 AM

#

OpenClaw 2026.4.11 (769908e)

🦞 OpenClaw 2026.4.11 (769908e) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
OpenClaw status --all

Overview

│ Item │ Value
│ Version │ 2026.4.11
│ OS │ windows 10.0.26200 (x64)
│ Node │ 24.14.1
│ Config │ ~.openclaw\openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off
│ Channel │ stable (default)
│ Update │ pnpm · up to date · npm latest 2026.4.11
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 35ms · auth token · AizensHomeLab (192. │
│ │ 168.137.1) app 2026.4.11 windows 10.0.26200
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ Scheduled Task installed · registered · running (pid 22416, Startup-folder login item installed; │
│ │ listener detected on port 18789.)
│ Node service │ Scheduled Task not installed
│ Agents │ 1 total · 1 bootstrapping · 1 active · 5 sessions
│ Secrets │ none

Channels

│ Channel │ Enabled │ State │ Detail

│ Discord │ ON │ OK │ token config (sha256:b5b730ca · len 72) · accounts 1/1 │
│ Telegram │ ON │ OK │ token config (sha256:d9b13bfc · len 46) · accounts 1/1

Discord accounts

│ Account │ Status │ Notes
┤
│ default │ OK │ token:config

Telegram accounts

│ Account │ Status │ Notes

│ default │ OK │ token:config

tulip oreBOT Apr 13, 2026, 1:24 AM

#

Nice, thanks, that helps.

Your version looks current, and your gateway + Discord/Telegram transport both look healthy, so this is looking even more like a model/provider stall than a channel problem.

What I’d check next:

openclaw models status
openclaw config get agents.defaults.llm.idleTimeoutSeconds
openclaw config get agents.defaults.timeoutSeconds
openclaw config get agents.defaults.model
openclaw infer model run --model github-copilot/gpt-5.2 --prompt "Reply with exactly: smoke-ok" --json

Why:

models status tells us whether the model/auth side is healthy.
the two config get calls show what timeout is actually in play.

#

infer model run isolates the model path from Discord/Telegram. If that times out too, we’ve basically confirmed it is GitHub Copilot / model latency.

Quick mitigation to test right now:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
openclaw gateway restart

One other thing I notice: your status shows 1 bootstrapping. If that stays stuck like that and never clears, tell me, because that’s a little suspicious too.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/agent-loop
https://docs.openclaw.ai/cli/infer

wet kelp Apr 13, 2026, 1:34 AM

#

how do i use skill commands

tulip oreBOT Apr 13, 2026, 1:34 AM

#

Usually you don’t need to call skills manually. If a skill is installed and eligible, the agent can use it automatically when you ask normally.

If you want to run one directly:

openclaw skills search "calendar"
openclaw skills install <skill-slug>
openclaw skills list --eligible
openclaw skills check

Then in chat:

/skill <name> [input]

#

Example:

/skill weather vienna

A few useful details:

Some skills also show up as their own slash command, not just /skill ...
If you made your own skill and want it callable, set user-invocable: true in its SKILL.md
New installs are picked up on the next session/thread if they do not appear immediately
If native per-skill commands are not showing, the generic /skill <name> ... path should still work

Docs:
https://docs.openclaw.ai/tools/skills
https://docs.openclaw.ai/tools/slash-commands

#

If you want, paste the skill name you installed and I can show the exact command syntax.

wet kelp Apr 13, 2026, 1:35 AM

#

i want to do this "freeride auto
"

tulip oreBOT Apr 13, 2026, 1:36 AM

#

Yep, if the skill name is freeride, try it like this:

/skill freeride auto

If that skill registered its own command, this may also work:

/freeride auto

A couple gotchas:

don’t include quotes
keep it on one line
if it was just installed, start a new session/thread first

#

To check whether it loaded:

/commands

or in CLI:

openclaw skills list --eligible

If you want, paste the skill’s SKILL.md frontmatter and I can tell you whether it expects /skill freeride auto or /freeride auto.

wet kelp Apr 13, 2026, 2:46 AM

#

how do i add multiple models

tulip oreBOT Apr 13, 2026, 2:46 AM

#

For your case, the usual setup is one primary model + multiple fallbacks.

Fastest way:

openclaw models set <provider/model-primary>
openclaw models fallbacks add <provider/model-fallback-1>
openclaw models fallbacks add <provider/model-fallback-2>
openclaw models status

Config-wise, that looks like:

{
  agents: {

#

    defaults: {
      model: {
        primary: "provider/model-primary",
        fallbacks: [
          "provider/model-fallback-1",
          "provider/model-fallback-2",
        ],
      },
    },
  },
}

A couple important notes:

order matters, OpenClaw tries fallbacks top to bottom

#

fallbacks are used for errors/failover, not for “pick the smartest one for this task”
if you want to manually switch during chat, use /model

Given your timeout issue, yes, I’d definitely add at least one fallback.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/model-failover

If you want, paste your current openclaw models status and I can tell you the exact commands to run.

wet kelp Apr 13, 2026, 2:47 AM

#

like how do i add a new provider like groq

tulip oreBOT Apr 13, 2026, 2:47 AM

#

Yep. For a new provider like Groq, the flow is basically:

add auth
pick a Groq model
set it as primary or fallback
restart the gateway

Since your gateway is running as a Windows Scheduled Task, the safest place for the key is ~/.openclaw/.env, not just a temporary terminal env var.

1) Add the key

In ~/.openclaw/.env:

GROQ_API_KEY=gsk_...

2) See Groq models

#

On Windows:

openclaw models list | findstr groq

3a) Make Groq your main model

openclaw models set groq/<model-id>

3b) Or keep your current model and add Groq as a fallback

openclaw models fallbacks add groq/<model-id>

4) Restart

#

openclaw gateway restart

If you prefer config, it looks like this:

{
  env: { GROQ_API_KEY: "gsk_..." },
  agents: {
    defaults: {
      model: {
        primary: "groq/<model-id>",
      },
    },
  },

#

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

If you want, paste the output of openclaw models list | findstr groq and I’ll tell you the exact models set / fallback commands to run.

wet kelp Apr 13, 2026, 3:18 AM

#

how do i reset my models to only use ollama ones

tulip oreBOT Apr 13, 2026, 3:18 AM

#

Easiest way is:

openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw models set ollama/<your-local-model>
openclaw models fallbacks clear
openclaw gateway restart

Then check what OpenClaw sees:

ollama list
openclaw models list | findstr ollama
openclaw models status

#

If you want the clean reset path instead, re-run:

openclaw onboard

Then choose Ollama and pick Local.

A couple gotchas:

if Ollama is remote, use the native base URL like http://host:11434, not /v1
clearing fallbacks is what stops it from hopping to other providers on failures

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

#

If you want, paste your ollama list output and I’ll turn it into the exact models set command.

wet kelp Apr 13, 2026, 3:19 AM

#

i have ollama installed

tulip oreBOT Apr 13, 2026, 3:19 AM

#

Perfect. Then use the simple auto-discovery path.

Small correction to my last note: for local Ollama, prefer OLLAMA_API_KEY in ~/.openclaw/.env, not an explicit models.providers.ollama entry, so OpenClaw can auto-discover your local models.

Do this:

ollama list

If you already see a model there, add this to ~/.openclaw/.env:

OLLAMA_API_KEY=ollama-local

Then:

#

openclaw models list | findstr ollama
openclaw models set ollama/<your-installed-model>
openclaw models fallbacks clear
openclaw gateway restart
openclaw models status

If ollama list is empty, pull one first:

ollama pull <model-name>

So the short version is:

OLLAMA_API_KEY=ollama-local
set ollama/<your-model> as primary

#

clear fallbacks
restart

Docs:
https://docs.openclaw.ai/providers/ollama

If you paste your ollama list, I’ll give you the exact openclaw models set ... line.

wet kelp Apr 13, 2026, 3:34 AM

#

ok here are the models i have

PS C:\Users\unkil> ollama list
NAME ID SIZE MODIFIED
tinyllama:latest 2644915ede35 637 MB 12 minutes ago
qwen2.5-coder:0.5b 4ff64a7f502a 397 MB 12 minutes ago
qwen2.5:0.5b a8b0c5157701 397 MB 12 minutes ago
smollm2:360m 297281b699fc 725 MB 40 minutes ago

tulip oreBOT Apr 13, 2026, 3:35 AM

#

Nice, that’s enough to wire it up.

If you want the best shot out of that list, I’d try:

openclaw models set ollama/qwen2.5-coder:0.5b
openclaw models fallbacks clear
openclaw gateway restart

And make sure ~/.openclaw/.env contains:

OLLAMA_API_KEY=ollama-local

Then verify:

#

openclaw models status
openclaw models list | findstr ollama

If you still hit timeout/stall issues, also bump the idle timeout:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
openclaw gateway restart

One honest warning: those models are very small, so they’re okay for a smoke test, but I would not expect reliable OpenClaw agent behavior from them. For real tool use, cloud models are still the much better path.

Docs:
https://docs.openclaw.ai/providers/ollama

#

If this gets it replying again, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

wet kelp Apr 13, 2026, 3:36 AM

#

add the other modls

tulip oreBOT Apr 13, 2026, 3:36 AM

#

Yep, you can chain the rest as fallbacks like this:

openclaw models set ollama/qwen2.5-coder:0.5b
openclaw models fallbacks clear
openclaw models fallbacks add ollama/qwen2.5:0.5b
openclaw models fallbacks add ollama/tinyllama:latest
openclaw models fallbacks add ollama/smollm2:360m
openclaw gateway restart
openclaw models status

That gives you this order:

ollama/qwen2.5-coder:0.5b
ollama/qwen2.5:0.5b
ollama/tinyllama:latest

#

ollama/smollm2:360m

And keep this in ~/.openclaw/.env:

OLLAMA_API_KEY=ollama-local

Real talk, those are all pretty tiny, so this is fine for testing but I would not expect great agent performance.

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

wet kelp Apr 13, 2026, 3:44 AM

#

why am i getting this

#

{
"name": "Sender (untrusted metadata)",
"arguments": {
"label": "openclaw-control-ui",
"id": "openclaw-control-ui"
}
}
Kim Dokja (김독자)
11:44 PM
↑16.1k
↓43
49% ctx
qwen2.5:0.5b

tulip oreBOT Apr 13, 2026, 3:45 AM

#

You’re getting it because OpenClaw is waiting for the first token from the model, and nothing arrives before the LLM idle timeout expires.

So the short version is: this is a model-side stall, not a Discord/Telegram send problem.

In your case, the most likely reasons are:

it’s still using the old model (github-copilot/gpt-5.2)
the Ollama switch didn’t apply yet
those local models are tiny, and they can stall or be too weak for agent/tool runs

Check what model is actually active right now:

openclaw models status

If it still shows GitHub Copilot, the switch didn’t take.

#

If it shows Ollama, then the timeout is probably because the local model is struggling. In that case, try:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
openclaw gateway restart

Honest answer, those 0.5b / 360m models are really just smoke-test territory for OpenClaw. They can work for tiny prompts, but they’re usually not reliable enough for normal agent behavior.

If you paste openclaw models status, I can tell you exactly which of the 3 cases you’re in.

#

Yep, that confirms it.

OpenClaw is using your Ollama model now, qwen2.5:0.5b, so the switch worked.
That means the timeout is no longer about GitHub Copilot or Discord. It’s the local model.

And honestly, 0.5b is tiny for OpenClaw. These very small local models often:

stall before producing a first token
fail at tool-calling
get weird once the prompt gets even moderately complex

So this is basically case 3 from before: the model is too weak / unstable for the workload.

You can try giving it more time:

#

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
openclaw gateway restart

But the real fix is usually:

use a much larger local model, or
switch back to a cloud model for reliable agent behavior

Docs:
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/gateway/local-models

If you want, tell me your GPU / RAM and I can point you toward a more realistic local setup.

wet kelp Apr 13, 2026, 3:53 AM

#

ok add llama3.1:8b

tulip oreBOT Apr 13, 2026, 3:54 AM

#

You can add it as a fallback, but honestly I’d make llama3.1:8b the primary. It’s a much saner pick than the 0.5b models.

ollama pull llama3.1:8b
openclaw models set ollama/llama3.1:8b
openclaw models fallbacks clear
openclaw models fallbacks add ollama/qwen2.5-coder:0.5b
openclaw models fallbacks add ollama/qwen2.5:0.5b
openclaw models fallbacks add ollama/tinyllama:latest
openclaw models fallbacks add ollama/smollm2:360m
openclaw gateway restart
openclaw models status

If you only want to add it without changing primary

#

ollama pull llama3.1:8b
openclaw models fallbacks add ollama/llama3.1:8b
openclaw gateway restart

Docs:
https://docs.openclaw.ai/providers/ollama

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

wet kelp Apr 13, 2026, 4:53 AM

#

and this one ollama mistral

tulip oreBOT Apr 13, 2026, 4:54 AM

#

Yep, add mistral too.

If you want a cleaner order, I’d do:

ollama pull mistral
openclaw models set ollama/llama3.1:8b
openclaw models fallbacks clear
openclaw models fallbacks add ollama/mistral
openclaw models fallbacks add ollama/qwen2.5-coder:0.5b
openclaw models fallbacks add ollama/qwen2.5:0.5b
openclaw models fallbacks add ollama/tinyllama:latest
openclaw models fallbacks add ollama/smollm2:360m
openclaw gateway restart
openclaw models status

#

So the order becomes:

ollama/llama3.1:8b
ollama/mistral
ollama/qwen2.5-coder:0.5b
ollama/qwen2.5:0.5b
ollama/tinyllama:latest
ollama/smollm2:360m

That’s a much better stack than starting on the tiny models.

wet kelp Apr 13, 2026, 6:26 AM

#

How do I turn on cloud models for Ollama

tulip oreBOT Apr 13, 2026, 6:26 AM

#

The clean way is:

ollama signin
openclaw onboard

Then choose:

Ollama
Cloud + Local

That’s the supported path for turning on Ollama cloud models.

A couple notes:

OLLAMA_API_KEY=ollama-local alone does not enable cloud models

#

cloud models come from being signed in to Ollama
cloud entries do not need ollama pull

After that, check what OpenClaw sees:

openclaw models list | findstr ollama

You should start seeing Ollama cloud entries alongside your local ones.

Docs:
https://docs.openclaw.ai/providers/ollama

If you want, I can also show you how to keep llama3.1:8b local as primary and add Ollama cloud models only as fallbacks.

wet kelp Apr 13, 2026, 6:27 AM

#

Is there another way besides doing the onboard

tulip oreBOT Apr 13, 2026, 6:28 AM

#

Yep, you don’t need to rerun full onboard.

Try this instead:

ollama signin
openclaw configure --section model

Then choose:

Ollama
Cloud + Local

That’s the cleaner alternative when you only want to redo the model setup.

If you mean “can I do it with no wizard at all?”, I don’t want to make up a config toggle here. The documented/supported path for Ollama cloud models is still the interactive setup flow after ollama signin.

#

Docs:
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/cli/configure

If you want, I can walk you through exactly what to click/select in the model section.

wet kelp Apr 13, 2026, 6:36 AM

#

Is there an exact command for this that I can do with a copy paste

tulip oreBOT Apr 13, 2026, 6:36 AM

#

Yep, the closest copy-paste version is:

ollama signin; openclaw configure --section model

Then in the model setup, choose:

Ollama
Cloud + Local

After that, verify with:

openclaw models list | findstr ollama

#

If you want a fully non-interactive one-liner for “switch existing setup to Ollama Cloud + Local”, I don’t want to invent flags that aren’t documented. The supported path is still the interactive model section after ollama signin.

wet kelp Apr 13, 2026, 6:36 AM

#

Without setup

tulip oreBOT Apr 13, 2026, 6:37 AM

#

Not a documented/supported one, no.

If you want to try the closest thing without setup, it would be:

ollama signin
openclaw models list | findstr ollama

If cloud models start showing up there, great.
If they don’t, then you’ll need the supported flow:

openclaw configure --section model

I just don’t want to make up a hidden config toggle for you here.

dark hawk Apr 13, 2026, 7:06 AM

#

When I try to join the OpenClaw chat, I get this message "Agent failed before reply: OAuth token refresh failed for openai-codex: Failed to refresh OpenAI Codex token. Please try again or re-authenticate. | OAuth token refresh failed for openai-codex: Failed to refresh OpenAI Codex token. Please try again or re-authenticate. | Failed to refresh OpenAI Codex token.
Logs: openclaw logs --follow"

tulip oreBOT Apr 13, 2026, 7:07 AM

#

That usually means the saved Codex OAuth login is stale or can’t be refreshed.

First, what does this show?

openclaw --version

Then, on the same machine/user account that runs the gateway, try:

openclaw models auth login --provider openai-codex
openclaw models status
openclaw doctor --deep

What I’d expect:

#

models auth login re-authenticates Codex OAuth
models status confirms the provider is healthy again
doctor --deep catches the two common gotchas:
1. TLS/certificate issues blocking the OAuth refresh
2. a stale legacy models.providers.openai-codex override shadowing the built-in Codex OAuth provider

Also, small but important: Codex OAuth is the openai-codex/* route, not openai/*.

Docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/gateway/doctor

If you paste the doctor --deep output, I can narrow it down pretty quickly.

dark hawk Apr 13, 2026, 7:08 AM

#

puedes traducir esta respuesta al español?

tulip oreBOT Apr 13, 2026, 7:08 AM

#

Sí. Eso normalmente significa que el inicio de sesión OAuth de Codex guardado está vencido o no se puede renovar.

Primero, ¿qué te muestra esto?

openclaw --version

Luego, en la misma máquina y con la misma cuenta de usuario que ejecuta el gateway, prueba esto:

openclaw models auth login --provider openai-codex
openclaw models status
openclaw doctor --deep

Lo que esperaría:

#

models auth login vuelve a autenticar Codex OAuth
models status confirma que el proveedor volvió a estar sano
doctor --deep detecta dos problemas comunes:
1. problemas de TLS/certificados que bloquean la renovación del OAuth
2. una configuración antigua de models.providers.openai-codex que está tapando el proveedor OAuth integrado de Codex

Y un detalle importante: Codex OAuth usa la ruta openai-codex/*, no openai/*.

Docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/gateway/doctor

Si pegas la salida de doctor --deep, te puedo decir mucho más rápido qué está fallando.

dark hawk Apr 13, 2026, 7:11 AM

#

Install missing bundled plugin runtime deps now?
│ ● Yes / ○ No

tulip oreBOT Apr 13, 2026, 7:11 AM

#

I’d pick Yes.

That prompt means OpenClaw found missing runtime dependencies for bundled plugins and wants to install them now. If you’re troubleshooting chat/plugin behavior, Yes is the right choice.

Short version:

Yes = install the missing bundled plugin deps now
No = skip it, but some bundled plugin features may stay broken

So for your case, Yes.

dark hawk Apr 13, 2026, 7:13 AM

#

channels.telegram: Telegram is in first-time setup mode. DMs use pairing mode, so new │
│ senders must start a chat and be approved before regular messages are accepted. Group │
│ messages stay blocked until you add allowed chats under channels.telegram.groups (and │
│ optional sender IDs under channels.telegram.groupAllowFrom), or set │
│ channels.telegram.groupPolicy to "open" if you want broad group access.

tulip oreBOT Apr 13, 2026, 7:14 AM

#

Eso significa que Telegram todavía está en modo de primera configuración.

En la práctica:

DMs: usuarios nuevos tienen que iniciar chat con el bot y ser aprobados
Grupos: están bloqueados por defecto hasta que los permitas explícitamente

Tienes 2 caminos:

Opción segura, permitir solo ciertos grupos

Añade el ID del grupo en channels.telegram.groups y, si quieres limitar quién puede usarlo dentro del grupo, añade usuarios en channels.telegram.groupAllowFrom.

Ejemplo:

#

  channels: {
    telegram: {
      groupPolicy: "allowlist",
      groups: {
        "-1001234567890": {},
      },
      groupAllowFrom: ["123456789"],
    },
  },
}

Opción abierta, permitir grupos en general

#

  channels: {
    telegram: {
      groupPolicy: "open",
    },
  },
}

Ojo con esto:

groups lleva IDs de chat/grupo de Telegram, normalmente negativos
groupAllowFrom lleva IDs de usuario, no IDs de grupo

Si quieres, te puedo ayudar a escribir el bloque exacto de Telegram para:

solo DM,
un grupo concreto, o

#

todos los grupos.

Docs:
https://docs.openclaw.ai/channels/telegram

dark hawk Apr 13, 2026, 7:16 AM

#

Ahora me da este error "Agent failed before reply: No credentials found for profile "openai-codex:manolocarrillo2@hotmail.com". | No credentials found for profile "openai-codex:manolocarrillo2@hotmail.com".
Logs: openclaw logs --follow"

tulip oreBOT Apr 13, 2026, 7:17 AM

#

Ese error significa que OpenClaw está intentando usar ese perfil OAuth:

openai-codex:manolocarrillo2@hotmail.com

pero no encuentra las credenciales reales de ese perfil en el auth-profiles.json del agente que está corriendo.

En corto: hay una referencia al perfil, pero no está el token guardado donde OpenClaw lo espera.

Prueba esto en la misma máquina y con el mismo usuario que ejecuta el gateway:

openclaw models auth login --provider openai-codex
openclaw models status
openclaw doctor

#

Las causas más comunes son:

el login OAuth no se guardó bien
el gateway está usando otro agente
las credenciales están en otro auth-profiles.json
quedó una referencia vieja a ese perfil de email

Importante: los auth profiles son por agente, no globales.

Si después del login sigue saliendo ese mismo error, pega aquí la salida de:

openclaw models status

y te digo exactamente cuál de esos 4 casos es.

dark hawk Apr 13, 2026, 7:20 AM

#

🦞 OpenClaw 2026.4.8 (9ece252) — WhatsApp automation without the "please accept our new privacy policy".

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

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

nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:manolocarrillo2@hotmail.com=OAuth (manolocarrillo2@hotmail.com)

OAuth/token status

openai-codex usage: 5h 100% left ⏱4h 59m · Week 61% left ⏱3d 9h
- openai-codex:manolocarrillo2@hotmail.com (manolocarrillo2@hotmail.com) ok expires in 10d

tulip oreBOT Apr 13, 2026, 7:21 AM

#

Esto ya se ve mucho mejor.

Según esa salida, OpenClaw sí encuentra el perfil openai-codex:manolocarrillo2@hotmail.com y además lo marca como:

ok expires in 10d

O sea, el problema de credenciales ya no parece ser el perfil OAuth.

Lo que yo haría ahora:

openclaw gateway restart

y luego vuelve a probar.

#

Dos cosas que me saltan a la vista:

estás en 2026.4.8, que ya va un poco atrás
models status dice que el perfil está bien, así que si sigue saliendo No credentials found, eso ya huele más a estado viejo del gateway o de la sesión, no a falta real de credenciales

Mi recomendación:

actualiza OpenClaw a la versión actual usando tu método normal de instalación
reinicia el gateway
vuelve a probar
si sigue fallando, corre esto mientras reproduces el error:

openclaw logs --follow

y pega aquí solo las líneas nuevas del momento exacto del fallo.

#

Ahora mismo, con esa salida, yo no volvería a hacer login OAuth. Primero haría restart + update.

dark hawk Apr 13, 2026, 7:26 AM

#

Log file: /tmp/openclaw/openclaw-2026-04-13.log
09:10:37+02:00 warn gateway/reload {"subsystem":"gateway/reload"} config watcher error: Error: EACCES: permission denied, watch '/data/.openclaw/openclaw.json'
09:15:27+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 185ms conn=38a984cf…d41f id=c5b1dc76…240e
09:15:28+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ doctor.memory.status 601ms conn=8eead8f3…51f2 id=fba05973…3fac
09:19:45+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 158ms conn=4c7a0928…f61d id=cd33caf7…4239
09:21:46+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ config.get 294ms conn=617d4d69…6db2 id=eeb20a9b…7d5c
09:21:46+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ status 327ms conn=617d4d69…6db2 id=489a3d5e…f92f

tulip oreBOT Apr 13, 2026, 7:27 AM

#

Gracias, eso ayuda.

Esas líneas no muestran el fallo de Codex. Lo que sí muestran es otro problema:

config watcher error: EACCES: permission denied, watch '/data/.openclaw/openclaw.json'

Eso significa que el gateway no tiene permisos para vigilar ese archivo de configuración.
Normalmente pasa por una de estas razones:

el archivo o la carpeta /data/.openclaw pertenece a otro usuario
estás corriendo OpenClaw en contenedor / volumen con permisos raros
el gateway puede leer la config, pero no puede poner el watcher para recarga en caliente

Importante: eso no explica por sí solo el error de openai-codex, pero sí es un problema real y puede dejar la config en un estado raro donde cambios nuevos no se recargan.

#

Yo haría esto:

arreglar permisos de /data/.openclaw/openclaw.json y de la carpeta /data/.openclaw
reiniciar el gateway
volver a probar
correr openclaw logs --follow y pegar las líneas exactas del momento del fallo de Codex, porque en este extracto no aparecen

Ahora mismo diría:

problema 1 real: permisos de la config (EACCES)
problema 2: el fallo de Codex todavía no está en este trozo de log

Si quieres, te ayudo a revisar el siguiente paso. Pega también la salida de:

ls -ld /data/.openclaw /data/.openclaw/openclaw.json

#

y te digo si es claramente un tema de permisos.

dark hawk Apr 13, 2026, 7:28 AM

#

drwx------ 19 node node 4096 Apr 13 09:19 /data/.openclaw
-rw------- 1 root root 3463 Apr 13 09:19 /data/.openclaw/openclaw.json

tulip oreBOT Apr 13, 2026, 7:29 AM

#

Ahí está el problema. 👍

La carpeta es de node, pero el archivo:

/data/.openclaw/openclaw.json

es de:

root root
-rw-------

O sea, el proceso que corre como node no puede acceder bien a ese archivo.
Por eso te sale:

#

EACCES: permission denied, watch '/data/.openclaw/openclaw.json'

Arreglo

Si el gateway corre como node, haz esto:

sudo chown node:node /data/.openclaw/openclaw.json
sudo chmod 600 /data/.openclaw/openclaw.json
openclaw gateway restart

Y luego prueba otra vez.

Recomendación

No edites openclaw.json con sudo a partir de ahora, porque te lo vuelve a dejar como root y reaparece el problema.

#

Si después del restart sigue fallando Codex, entonces sí toca mirar el error nuevo en logs, pero este problema de permisos sí hay que corregirlo primero.

dark hawk Apr 13, 2026, 7:30 AM

#

🦞 OpenClaw 2026.4.8 (9ece252) — WhatsApp automation without the "please accept our new privacy policy".

09:29:40+02:00 [restart] lsof failed during initial stale-pid scan for port 18789: ENOENT
Gateway service disabled.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: systemctl --user start openclaw-gateway.service
Start with: systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
Start with: If you're in a container, run the gateway in the foreground instead of openclaw gateway.

tulip oreBOT Apr 13, 2026, 7:30 AM

#

Bien, eso ya es otro problema distinto.

Lo que te está diciendo ahora es:

el gateway service está deshabilitado
no tienes systemd user services disponibles
probablemente estás en contenedor o en un entorno sin supervisor de usuario
lsof failed ... ENOENT solo significa que lsof no está instalado, no es el bloqueo principal

En tu caso, la pista importante es esta:

If you're in a container, run the gateway in the foreground instead of `openclaw gateway`.

Así que ahora mismo haz esto:

#

openclaw gateway

Eso arranca el gateway en primer plano.

Si quieres que quede persistente

Entonces no uses openclaw gateway restart como si hubiera servicio instalado.
En contenedor tienes que correr OpenClaw con:

tu supervisor
o como proceso principal del contenedor

Resumen

Ahora mismo el orden correcto sería:

arreglar permisos del openclaw.json ✅

#

arrancar el gateway manualmente con:
```
openclaw gateway
```
probar otra vez
si falla, mirar los logs nuevos

Si quieres, te ayudo a dejarlo bien para Docker / contenedor y te digo exactamente qué comando poner como proceso principal.

wet kelp Apr 13, 2026, 5:20 PM

#

what is the most minimal llm that you can locally run to use openclaw with

tulip oreBOT Apr 13, 2026, 5:21 PM

#

“Minimal” and “usable” are really different here.

My honest answer:

below ~7B to 8B, I’d treat it as toy / smoke-test only
0.5B / 1B-ish models are way too small for normal OpenClaw use
even at the low end of “usable”, local models are usually still shaky with tools, long prompts, and routing

So if the question is:

smallest that can technically run? very small models can start
smallest I’d actually try with OpenClaw? roughly 7B to 8B minimum
what I’d recommend for real reliability? honestly, cloud models

That’s why you were seeing timeouts and weird behavior with the tiny Ollama models earlier.

For fresh real-world model advice, ask in #models. That changes too fast for me to hardcode here.

#

Docs:
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

wet kelp Apr 13, 2026, 5:25 PM

#

what would be the best local model that you could use with 8gb if dedicated gpu memory and 24gb gpu memory, and 20 gigs of ram

tulip oreBOT Apr 13, 2026, 5:25 PM

#

With that setup, I’d mentally budget around the 8 GB dedicated VRAM, not the bigger shared-memory number. On Windows, that extra “GPU memory” is usually shared system memory, not real VRAM.

So for OpenClaw, I’d think:

realistic local target: roughly 7B to 8B class, usually quantized
maybe possible but not ideal: bigger than that, with more offloading and worse speed
what I’d actually recommend for reliability: local for testing, cloud fallback for real use

With 8 GB VRAM + 20 GB RAM, I would not plan around big local agentic models. I’d stay conservative.

So the honest answer is:

best practical local tier for you: about 7B to 8B
best overall experience: cloud model, with local only if you really want to experiment

For exact up-to-date model picks, ask in #models. That changes fast and I don’t want to give you stale names.

#

Docs:
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

wet kelp Apr 13, 2026, 5:44 PM

#

add qwen3.5:35b-a3b

tulip oreBOT Apr 13, 2026, 5:44 PM

#

You can add it like this:

ollama pull qwen3.5:35b-a3b
openclaw models fallbacks add ollama/qwen3.5:35b-a3b
openclaw gateway restart
openclaw models status

If you want to make it the primary instead:

ollama pull qwen3.5:35b-a3b
openclaw models set ollama/qwen3.5:35b-a3b
openclaw gateway restart

#

One warning though, with your 8 GB dedicated VRAM, that model is probably going to be pretty rough locally. Fine to try, but I would expect it to be slow or impractical.

wet kelp Apr 13, 2026, 5:58 PM

#

add gpt-oss:20b as a fallback

tulip oreBOT Apr 13, 2026, 5:58 PM

#

Yep, like this:

ollama pull gpt-oss:20b
openclaw models fallbacks add ollama/gpt-oss:20b
openclaw gateway restart
openclaw models status

With your hardware, I’d expect gpt-oss:20b to be a pretty heavy fallback, so fine to test, just don’t expect it to be fast.

wet kelp Apr 13, 2026, 5:59 PM

#

the cloud model

tulip oreBOT Apr 13, 2026, 5:59 PM

#

Ah, if you mean the Ollama Cloud version, first check the exact model id that Ollama exposes, because I don’t want to invent the wrong :cloud name.

Do this:

openclaw models list | findstr ollama

Then add the cloud model with the exact id it shows, for example:

openclaw models fallbacks add ollama/<exact-cloud-model-id>
openclaw gateway restart
openclaw models status

So yes, same idea, just use the exact :cloud model id from your list. If you paste that list, I’ll give you the exact copy-paste command.

wet kelp Apr 13, 2026, 6:00 PM

#

its gpt-oss:20b

tulip oreBOT Apr 13, 2026, 6:00 PM

#

Perfect, then use that exact ref:

openclaw models fallbacks add ollama/gpt-oss:20b
openclaw gateway restart
openclaw models status

If that gpt-oss:20b entry came from your Ollama Cloud list, this is the right command.

wet kelp Apr 13, 2026, 6:02 PM

#

its gpt-oss:20b-cloud

tulip oreBOT Apr 13, 2026, 6:02 PM

#

Nice, then use this exact command:

openclaw models fallbacks add ollama/gpt-oss:20b-cloud
openclaw gateway restart
openclaw models status

That should add the Ollama Cloud version as a fallback.

grizzled creekBOT Apr 13, 2026, 6:16 PM

#

wet kelp Apr 14, 2026, 12:00 AM

#

For local embeddings: configure agents.defaults.memorySearch.provider and local model │
│ path

i got the embedding model mxbai-embed-large:latest

tulip oreBOT Apr 14, 2026, 12:01 AM

#

Yep, if your embedding model is mxbai-embed-large:latest via Ollama, then you do not want local.modelPath.

local.modelPath is for the separate local embedding provider with a GGUF file on disk.

For Ollama embeddings, use:

openclaw config set agents.defaults.memorySearch.provider "ollama"
openclaw config set agents.defaults.memorySearch.model "mxbai-embed-large:latest"
openclaw gateway restart

And make sure Ollama is enabled for OpenClaw, for example in ~/.openclaw/.env:

OLLAMA_API_KEY=ollama-local

#

So the distinction is:

Ollama embeddings → memorySearch.provider = "ollama" + memorySearch.model
Local GGUF embeddings → memorySearch.provider = "local" + memorySearch.local.modelPath

Docs:
https://docs.openclaw.ai/reference/memory-config
https://docs.openclaw.ai/providers/ollama

If you want, I can give you the exact full JSON5 block for memory search too.

wet kelp Apr 14, 2026, 12:03 AM

#

│
◇ Memory search ────────────────────────────────────────────────────────────────────────────╮
│ │
│ Memory search is enabled, but no embedding provider is ready. │
│ Semantic recall needs at least one embedding provider. │
│ │
│ │
│ Fix (pick one): │
│ - Set OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, VOYAGE_API_KEY, MISTRAL_API_KEY in │
│ your environment │
│ - Configure credentials: openclaw configure --section model │
│ - For local embeddings: configure agents.defaults.memorySearch.provider and local model │
│ path │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled false │
│ │
│ Verify: openclaw memory status --deep │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Gateway ─────────────────────────────────────────────────────────────────────────────╮
│ │
│ Runtime: stopped (Startup-folder login item installed; no listener detected on port │
│ 18789.) │
│ Service is loaded but not running (likely exited immediately). │
│ File logs: C:\Users\unkil\AppData\Local\Temp\openclaw\openclaw-2026-04-13.log │
│ Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST │
│ │
├───────────────────────────────────────────────────────────────────────────────────────╯
Restarted Windows login item: OpenClaw Gateway
│
└ Doctor complete.

PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 12:03 AM

#

You’ve got 2 separate issues there:

1) Memory search

That warning is saying no embedding provider is ready yet.

Since you’re using Ollama with mxbai-embed-large:latest, use:

openclaw config set agents.defaults.memorySearch.provider "ollama"
openclaw config set agents.defaults.memorySearch.model "mxbai-embed-large:latest"

And make sure your ~/.openclaw/.env has:

OLLAMA_API_KEY=ollama-local

#

So for Ollama embeddings, ignore the “local model path” part. That is for the separate local GGUF provider, not Ollama.

2) Gateway

This is the bigger blocker right now:

Runtime: stopped
Service is loaded but not running

So even if memory config is right, it still won’t work until the gateway is actually up.

Try:

#

openclaw gateway start
openclaw gateway status
openclaw memory status --deep

If it still dies immediately, then open the file it pointed you to:

C:\Users\unkil\AppData\Local\Temp\openclaw\openclaw-2026-04-13.log

and paste the last error lines.

So the order is:

set Ollama memory provider/model

#

start the gateway
run openclaw memory status --deep
if it still fails, inspect the temp log file

If you want, I can give you the exact copy-paste block for all 4 commands in one shot.

wet kelp Apr 14, 2026, 12:10 AM

#

{"0":"{"subsystem":"gateway"}","1":"starting...","_meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-14T00:05:44.672Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:330:14","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:330","fileColumn":"14","fileLine":"330","filePath":"/C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:330","method":"logToFile"}},"time":"2026-04-13T20:05:44.672-04:00"}
{"0":"Gateway failed to start: Error: hooks.enabled requires hooks.token","_meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:06:09.716Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fileColumn":"68","fileLine":"161","filePath":"/C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},"time":"2026-04-13T20:06:09.716-04:00"}

tulip oreBOT Apr 14, 2026, 12:11 AM

#

Nice, we found the startup blocker.

Your gateway is failing because:

hooks.enabled requires hooks.token

So right now your config has hooks.enabled = true but no hooks.token.

Easiest fix, if you are not using hooks

Just disable hooks:

openclaw config set hooks.enabled false --strict-json
openclaw gateway start

#

If you do want hooks

Then set a token first, and it must be different from your gateway.auth.token:

openclaw config set hooks.token "put-a-long-random-token-here"
openclaw gateway start

Then verify:

openclaw gateway status
openclaw memory status --deep

For your case, I’d try the disable hooks path first, because it’s the smallest fix.

#

Docs:
https://docs.openclaw.ai/gateway/configuration-reference

wet kelp Apr 14, 2026, 12:22 AM

#

how do i have it use the embeddings

tulip oreBOT Apr 14, 2026, 12:22 AM

#

The important bit is: you don’t manually tell the chat model “use embeddings”.

Embeddings are used by memory search behind the scenes.

To make OpenClaw use your Ollama embedding model

Run:

openclaw config set agents.defaults.memorySearch.provider "ollama"
openclaw config set agents.defaults.memorySearch.model "mxbai-embed-large:latest"
openclaw gateway restart
openclaw memory status --deep

What happens after that

If openclaw memory status --deep looks healthy, OpenClaw can use embeddings for semantic recall.

#

So the flow is:

configure memorySearch.provider
configure memorySearch.model
make sure the gateway is running
verify with openclaw memory status --deep

One more important distinction

memorySearch = embedding/search backend
Active Memory = what makes memory show up automatically during chat replies

So if your goal is “I want the assistant to actually recall things in conversation”, then after embeddings are working, the next step is usually enabling Active Memory.

If you want, I can give you the exact copy-paste block for Active Memory too.

wet kelp Apr 14, 2026, 12:24 AM

#

🦞 OpenClaw 2026.4.12 (1c0672b) — I can't fix your code taste, but I can fix your build and your backlog.

│
◇
[openclaw] Failed to start CLI: Error: Unknown memory embedding provider: ollama
at getAdapter (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:341:22)
at createEmbeddingProvider (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:393:25)
at MemoryIndexManager.loadProviderResult (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:2759:16)
at file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:2864:52
at MemoryIndexManager.ensureProviderInitialized (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:2872:5)
at MemoryIndexManager.probeVectorAvailability (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/manager-FzeN0TEi.js:3223:14)
at file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:418:20
at withProgress (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/progress-EZ0eRtzP.js:116:16)
at Object.run (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:413:11)
at withManager (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli-utils-BpjfmMHH.js:10:16)
at async withMemoryManagerForAgent (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:253:2)
at async Proxy.runMemoryStatus (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:403:34)
at async runMemoryStatus (C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli-Rw7SJgRg.js:13:3)
at async Command.<anonymous> (C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/cli-Rw7SJgRg.js:50:5)
at async Command.parseAsync (C:\Users\unkil\AppData\Roaming\npm\node_modules\openclaw\node_modules\commander\lib\command.js:1122:5)
at async runCli (file:///C:/Users/unkil/AppData/Roaming/npm/node_modules/openclaw/dist/run-main-CqxhDA30.js:463:4)
PS C:\Users\unkil>
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 12:25 AM

#

Ah, that error is the key:

Unknown memory embedding provider: ollama

So on your installed build, memorySearch.provider = "ollama" is not actually supported by the CLI, even though newer docs/config hints mention it.

So the short answer is:

you cannot use your Ollama embedding model for memory search on this build
mxbai-embed-large:latest in Ollama is not usable here as memorySearch.provider = "ollama"

My bad, I pointed you down the wrong path earlier.

Fastest fix, if you just want OpenClaw working again

Disable memory search for now:

#

openclaw config set agents.defaults.memorySearch.enabled false --strict-json

If you want embeddings right now

Use one of these instead:

a supported remote embedding provider with an API key, or
the local embedding provider with a GGUF file via:

agents.defaults.memorySearch.provider = "local"
agents.defaults.memorySearch.local.modelPath = "..."

If you specifically want Ollama embeddings

Then you’ll need to upgrade to a build that actually supports it, once that support is in the release you’re running.

#

After disabling memory search, verify with:

openclaw memory status --deep

If you want, I can give you the exact copy-paste commands for the local GGUF embedding route next.

wet kelp Apr 14, 2026, 12:26 AM

#

i have
PS C:\Users\unkil> ollama list
NAME ID SIZE MODIFIED
mxbai-embed-large:latest 468836162de7 669 MB 4 hours ago

tulip oreBOT Apr 14, 2026, 12:26 AM

#

Yep, that confirms it.

The problem is not that Ollama is missing the model.
You do have:

mxbai-embed-large:latest

The problem is that your OpenClaw build is rejecting ollama as a memory embedding provider.

So the situation is:

Ollama side: fine
Model installed: fine
OpenClaw memory adapter on this build: does not accept provider = "ollama"

#

So unfortunately, that specific Ollama embedding model still won’t work for memory search on your current build.

Fastest unblock

Disable memory search for now:

openclaw config set agents.defaults.memorySearch.enabled false --strict-json

If you want embeddings right now

You need either:

a supported remote embedding provider, or
the local embedding route with a GGUF file

So basically, having it in ollama list is not enough here, because the missing piece is OpenClaw support for that provider in memory search.

#

If you want, I can help you switch to the local GGUF embedding route next.

wet kelp Apr 14, 2026, 12:27 AM

#

lets retry with the local one

tulip oreBOT Apr 14, 2026, 12:27 AM

#

Yep, let’s do the local GGUF embedding route.

Try this:

openclaw config set agents.defaults.memorySearch.provider "local"
openclaw config unset agents.defaults.memorySearch.model
pnpm approve-builds
pnpm rebuild node-llama-cpp
openclaw gateway restart
openclaw memory status --deep

What that does:

switches memory search to the local embedding provider
clears the old Ollama embedding model setting

#

rebuilds the native node-llama-cpp dependency that local embeddings need

OpenClaw should then use the default local embedding GGUF automatically.

If one of the pnpm steps fails, paste that error next, because that’ll be the next blocker.

wet kelp Apr 14, 2026, 12:28 AM

#

PS C:\Users\unkil> pnpm approve-builds
pnpm : The term 'pnpm' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

pnpm approve-builds

  + CategoryInfo          : ObjectNotFound: (pnpm:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

PS C:\Users\unkil>

#

use the model i told you to use mxbai-embed-large:latest 468836162de7 669 MB 4 hours ago

tulip oreBOT Apr 14, 2026, 12:29 AM

#

Yep, that error just means pnpm is not installed/enabled yet.

Since you’re on Node 24, the easiest way is:

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

But one more thing matters here: your OpenClaw install is currently under npm global (AppData\Roaming\npm\node_modules\openclaw), and the local GGUF embedding path is much cleaner if OpenClaw itself is installed with pnpm.

So if you want to keep going with the local embedding route, I’d do this:

npm uninstall -g openclaw

#

pnpm add -g openclaw@latest
pnpm approve-builds -g

Then retry the memory setup.

So the order is:

enable pnpm
reinstall OpenClaw with pnpm global
approve global build scripts
retry local memory embeddings

Docs:
https://docs.openclaw.ai/install

#

If you want, I can give you the next exact copy-paste block after the reinstall too.

#

I know, but I can’t honestly tell you to use it on this build.

mxbai-embed-large:latest is an Ollama model name, and your OpenClaw just told us:

Unknown memory embedding provider: ollama

So the blocker is not the model itself.
The blocker is that your current OpenClaw memory system does not accept ollama as an embedding provider.

So for this version/build, your choices are:

wait / upgrade to a build that supports Ollama embeddings for memory
use the local GGUF embedding route instead
use a remote embedding provider
disable memory search for now

#

So the answer is basically:

can OpenClaw see that Ollama model? yes
can this memory pipeline use it? no, not on this build

I’m glad you pushed on it, because that’s the real limit here.

wet kelp Apr 14, 2026, 12:33 AM

#

Memory Search
memory_search finds relevant notes from your memory files, even when the wording differs from the original text. It works by indexing memory into small chunks and searching them using embeddings, keywords, or both.

Quick start
If you have an OpenAI, Gemini, Voyage, or Mistral API key configured, memory search works automatically. To set a provider explicitly:
{
agents: {
defaults: {
memorySearch: {
provider: "openai", // or "gemini", "local", "ollama", etc.
},
},
},
}
For local embeddings with no API key, use provider: "local" (requires node-llama-cpp).

Supported providers
Provider ID Needs API key Notes
OpenAI openai Yes Auto-detected, fast
Gemini gemini Yes Supports image/audio indexing
Voyage voyage Yes Auto-detected
Mistral mistral Yes Auto-detected
Bedrock bedrock No Auto-detected when the AWS credential chain resolves
Ollama ollama No Local, must set explicitly
Local local No GGUF model, ~0.6 GB download

tulip oreBOT Apr 14, 2026, 12:33 AM

#

Yep, and that’s exactly why this is confusing.

The docs say ollama should work for memory search, but your actual runtime is saying:

Unknown memory embedding provider: ollama

So right now I’d trust the runtime error over the docs.

That usually means one of two things:

the docs are ahead of the release you’re on, or
there’s a real bug/regression in your build

So at this point, I think this is a docs/runtime mismatch or bug, not you misconfiguring it.

#

Practical answer

If you need it working today:

use memorySearch.provider = "local" with a GGUF embedding model, or
use a remote embedding provider, or
disable memory search for now

If you specifically want Ollama embeddings, I’d file a bug with:

your version: 2026.4.12
the exact traceback
the docs snippet that says ollama is supported

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

If you want, I can help you write the issue text in one clean paste.

wet kelp Apr 14, 2026, 12:34 AM

#

give me the command to set it to local

#

Ollama ollama No Local, must set explicitly

tulip oreBOT Apr 14, 2026, 12:34 AM

#

Yep, here’s the exact command:

openclaw config set agents.defaults.memorySearch.provider "local"

I’d also clear the old Ollama embedding model setting so it doesn’t confuse things:

openclaw config unset agents.defaults.memorySearch.model
openclaw gateway restart
openclaw memory status --deep

Small warning: local still needs the node-llama-cpp native dependency to work. If that becomes the next error, paste it and I’ll help with that step.

#

Yep, I see it, and that’s exactly the contradiction.

The docs say:

Ollama    ollama    No    Local, must set explicitly

but your actual build says:

Unknown memory embedding provider: ollama

So this is not you missing the right config key anymore.
This is a docs/runtime mismatch or a bug in your installed build.

#

That’s why I’m steering you to local for now, because your runtime is refusing ollama even though the docs claim it should work.

If you want to keep pushing the Ollama path, I’d file that as a bug:
https://github.com/openclaw/openclaw/issues

If you want the shortest path forward tonight, stick with:

openclaw config set agents.defaults.memorySearch.provider "local"

wet kelp Apr 14, 2026, 12:34 AM

#

try ollama again

tulip oreBOT Apr 14, 2026, 12:35 AM

#

Sure, if you want to test it one more time, use:

openclaw config set agents.defaults.memorySearch.provider "ollama"
openclaw config set agents.defaults.memorySearch.model "mxbai-embed-large:latest"
openclaw gateway restart
openclaw memory status --deep

If it throws the same:

Unknown memory embedding provider: ollama

then that’s basically the final proof that your current build/runtime does not support it, even though the docs say it should.

wet kelp Apr 14, 2026, 12:35 AM

#

try to have it to be local ollama

tulip oreBOT Apr 14, 2026, 12:35 AM

#

There isn’t a separate "local ollama" memory provider.

For memory search, Ollama already is the local one. So the setting is still just:

openclaw config set agents.defaults.memorySearch.provider "ollama"
openclaw config set agents.defaults.memorySearch.model "mxbai-embed-large:latest"
openclaw memory status --deep

So if that still fails with:

Unknown memory embedding provider: ollama

then the issue is not “cloud vs local Ollama”.

#

It means your current build just isn’t accepting ollama for memory embeddings.

wet kelp Apr 14, 2026, 12:38 AM

#

scan this page https://docs.openclaw.ai/reference/memory-config

tulip oreBOT Apr 14, 2026, 12:38 AM

#

Scanned it. The relevant bits are:

agents.defaults.memorySearch.provider supports:
- openai
- gemini
- voyage
- mistral
- bedrock
- ollama
- local
ollama is listed as supported, but not auto-detected, so it must be set explicitly.
local is a different path:
- it uses agents.defaults.memorySearch.local.modelPath
- it expects a GGUF embedding model
- it needs node-llama-cpp

#

the page also says the default local embedding model is auto-downloaded, and local embeddings require:
- pnpm approve-builds
- pnpm rebuild node-llama-cpp

So yes, the page does support your reading: docs say ollama should work for memory embeddings.

That’s why I think your Unknown memory embedding provider: ollama error is a real docs/runtime mismatch or bug, not just bad config.

wet kelp Apr 14, 2026, 12:52 AM

#

ok i installed openclaw with pnpm

tulip oreBOT Apr 14, 2026, 12:53 AM

#

Nice. Then let’s keep going with the local embedding path.

Run this next:

pnpm approve-builds -g
openclaw config set agents.defaults.memorySearch.provider "local"
openclaw config unset agents.defaults.memorySearch.model
openclaw gateway restart
openclaw memory status --deep

And before that, I’d also quickly confirm the active install/version:

openclaw --version

#

If memory status --deep now complains specifically about node-llama-cpp, paste that next error and we’ll do the rebuild step.

wet kelp Apr 14, 2026, 12:54 AM

#

PS C:\Users\unkil> openclaw gateway restart

🦞 OpenClaw 2026.4.12 (1c0672b) — Alexa, but with taste.

Restarted Windows login item: OpenClaw Gateway
Gateway restart failed after 28s: service stayed stopped and port 18789 stayed free.
Service runtime: status=stopped
Gateway port 18789 status: free.
Gateway restart failed after 28s: service stayed stopped and health checks never came up.
Tip: openclaw gateway status --deep
Tip: openclaw doctor
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 12:55 AM

#

Right, this means the gateway itself still isn’t starting, so the memory stuff is not the main blocker yet.

Given your earlier log, I’d bet it’s still this:

hooks.enabled requires hooks.token

Try this first:

openclaw config set hooks.enabled false --strict-json
openclaw gateway start
openclaw gateway status --deep

If it still stays stopped, then paste the latest startup error from the temp log, because that will be the real blocker now.

#

So the order is:

get the gateway to start
then retry memory config
then run openclaw memory status --deep

Right now step 1 is still failing.

wet kelp Apr 14, 2026, 12:57 AM

#

where do i get the logs from again

tulip oreBOT Apr 14, 2026, 12:57 AM

#

Easiest way:

openclaw logs --follow

Since you’re on Windows and the gateway is failing to start, you can also open the file log directly here:

C:\Users\unkil\AppData\Local\Temp\openclaw\

The file should look like:

openclaw-2026-04-13.log

#

In PowerShell, this is handy:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-13.log" -Tail 100

If you want the folder quickly:

ii "$env:LOCALAPPDATA\Temp\openclaw"

Paste the last error lines after a fresh openclaw gateway start and I’ll read them.

wet kelp Apr 14, 2026, 1:00 AM

#

{"0":"\u001b[38;2;255;176;32mGateway restart failed after 28s: service stayed stopped and port 18789 stayed free.\u001b[39m","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.981Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-13T20:59:43.983-04:00"}
{"0":"\u001b[38;2;139;127;119mService runtime: status=stopped\u001b[39m","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.989Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-13T20:59:43.989-04:00"}
{"0":"\u001b[38;2;139;127;119mGateway port 18789 status: free.\u001b[39m","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.990Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-13T20:59:43.990-04:00"}
{"0":"Gateway restart failed after 28s: service stayed stopped and health checks never came up.","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.991Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fileColumn":"68","fileLine":"161","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-

tulip oreBOT Apr 14, 2026, 1:01 AM

#

Yep, those lines are just the restart wrapper telling us it stayed down.
We still need the actual startup crash from the file log.

Do this:

openclaw gateway start
Get-ChildItem "$env:LOCALAPPDATA\Temp\openclaw\openclaw-*.log" |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1 |
  ForEach-Object { Get-Content $_.FullName -Tail 80 }

That will give the real last 80 lines from the newest OpenClaw log file.

What you pasted so far says only:

#

service stayed stopped
port 18789 stayed free

But not why it crashed.

So we need the output of that exact PowerShell block next.

wet kelp Apr 14, 2026, 1:01 AM

#

{"0":"Gateway restart failed after 28s: service stayed stopped and health checks never came up.","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.991Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fileColumn":"68","fileLine":"161","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},"time":"2026-04-13T20:59:43.991-04:00"}
{"0":"Tip: openclaw gateway status --deep","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.992Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-13T20:59:43.992-04:00"}
{"0":"Tip: openclaw doctor","meta":{"runtime":"node","runtimeVersion":"24.14.1","hostname":"AIZENSHOMELAB","name":"openclaw","date":"2026-04-14T00:59:43.993Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159:46","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:159","fileColumn":"46","fileLine":"159","filePath":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","method":"console.log"}},"time":"2026-04-13T20:59:43.993-04:00"}

tulip oreBOT Apr 14, 2026, 1:02 AM

#

Those still aren’t the real crash lines. That’s just the CLI summarizing that the background restart failed.

Let’s bypass the login item and run it in the foreground so it prints the real error directly:

openclaw gateway

Then paste the first actual error it prints after starting....

That’s the cleanest next step, because right now the background service is hiding the real startup failure.

wet kelp Apr 14, 2026, 1:04 AM

#

oh it started up

tulip oreBOT Apr 14, 2026, 1:05 AM

#

Nice, that’s actually really good news.

That means:

the gateway itself is fine
the thing that’s flaky is the Windows login item / background start path

So for now, keep that terminal open while it’s running.

Next step, while the gateway is up:

openclaw memory status --deep

If you still want the local embedding route, make sure you’ve got:

#

openclaw config set agents.defaults.memorySearch.provider "local"
openclaw config unset agents.defaults.memorySearch.model

Then re-run:

openclaw memory status --deep

If that works, we’re finally past the gateway blocker.

wet kelp Apr 14, 2026, 1:07 AM

#

🦞 OpenClaw 2026.4.12 (1c0672b) — I keep secrets like a vault... unless you print them in debug logs again.

│
◇
[openclaw] Failed to start CLI: Error: Local embeddings unavailable.
Reason: Cannot find module 'node-llama-cpp'
Require stack:

C:\Users\unkil\AppData\Local\pnpm\global\5.pnpm\openclaw@2026.4.12_@emnapi+_0cce31112b9f587783dcad3a63b36617\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)
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:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12_@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/manager-FzeN0TEi.js:417:19)
at async MemoryIndexManager.loadProviderResult (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/manager-FzeN0TEi.js:2759:10)
at async file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/manager-FzeN0TEi.js:2864:27
at async MemoryIndexManager.ensureProviderInitialized (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/manager-FzeN0TEi.js:2874:4)
at async MemoryIndexManager.probeVectorAvailability (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/manager-FzeN0TEi.js:3223:3)
at async file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:418:6
at async withProgress (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/progress-EZ0eRtzP.js:116:10)
at async Object.run (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:413:5)
at async withManager (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/cli-utils-BpjfmMHH.js:10:3)
at async withMemoryManagerForAgent (file:///C:/Users/unkil/AppData/Local/pnpm/global/5/.pnpm/openclaw@2026.4.12@emnapi+_0cce31112b9f587783dcad3a63b36617/node_modules/openclaw/dist/cli.runtime-e7km5Lnb.js:253:2)
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 1:08 AM

#

Perfect, now we’ve got the real blocker:

Cannot find module 'node-llama-cpp'

So the next step is exactly what the error says, but for your global pnpm install:

pnpm approve-builds -g
pnpm rebuild -g node-llama-cpp
openclaw memory status --deep

If pnpm rebuild -g node-llama-cpp complains or does nothing, then do the clean fix:

#

pnpm remove -g openclaw
pnpm add -g openclaw@latest
pnpm approve-builds -g

Then retry:

openclaw memory status --deep

So at this point the issue is no longer gateway or config. It’s specifically the missing native node-llama-cpp dependency.

wet kelp Apr 14, 2026, 1:09 AM

#

PS C:\Users\unkil> pnpm approve-builds -g
There are no packages awaiting approval
PS C:\Users\unkil> pnpm rebuild -g node-llama-cpp
ERROR Unknown option: 'global'
For help, run: pnpm help rebuild
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 1:10 AM

#

Yep, the issue there is just the pnpm syntax.

For global commands, put -g before the subcommand:

pnpm -g rebuild node-llama-cpp

So try this next:

pnpm -g rebuild node-llama-cpp
openclaw memory status --deep

And yeah, this part is fine:

#

There are no packages awaiting approval

If the rebuild still doesn’t fix it, then do the clean reinstall:

pnpm remove -g openclaw
pnpm add -g openclaw@latest
pnpm approve-builds -g
pnpm -g rebuild node-llama-cpp

So the immediate next command is:

#

pnpm -g rebuild node-llama-cpp

wet kelp Apr 14, 2026, 1:11 AM

#

PS C:\Users\unkil> pnpm -g rebuild node-llama-cpp
ERROR Unknown option: 'global'
For help, run: pnpm help rebuild
PS C:\Users\unkil> pnpm rebuild node-llama-cpp
PS C:\Users\unkil> pnpm rebuild node-llama-cpp
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 1:12 AM

#

Okay, good, the plain:

pnpm rebuild node-llama-cpp

at least didn’t error, so let’s check whether it actually fixed it.

Run:

openclaw memory status --deep

If it still says Cannot find module 'node-llama-cpp', then we’ll do the clean reinstall path next.

So the immediate next step is just:

#

openclaw memory status --deep

wet kelp Apr 14, 2026, 1:14 AM

#

PS C:\Users\unkil> openclaw memory status --deep

🦞 OpenClaw 2026.4.12 (1c0672b) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

│
◐ Probing embeddings…..Downloading to C:\Users\unkil.node-llama-cpp\models
✔ hf_ggml-org_embeddinggemma-300m-qat-Q8_0.gguf downloaded 328.58MB in 6s
◒ Probing embeddings…...Downloaded to C:\Users\unkil.node-llama-cpp\models\hf_ggml-org_embeddinggemma-300m-qat-Q8_0.gguf
◐ Probing embeddings….D:\a\node-llama-cpp\node-llama-cpp\llama\llama.cpp\ggml\src\ggml-cuda\ggml-cuda.cu:98: CUDA error
PS C:\Users\unkil>

grizzled creekBOT Apr 14, 2026, 1:16 AM

#

tulip oreBOT Apr 14, 2026, 1:20 AM

#

Good, that tells us a lot.

What this means

node-llama-cpp is now installed
the local GGUF model downloaded fine
the new blocker is CUDA, not config

This part:

ggml-cuda.cu:98: CUDA error

means the local embedding runtime is trying to use your NVIDIA GPU and crashing there.

Important

This is separate from your original Discord/Telegram timeout on github-copilot/gpt-5.2.

#

Fastest unblock

If you just want OpenClaw stable again tonight, disable memory search for now:

openclaw config set agents.defaults.memorySearch.enabled false --strict-json

Then start the gateway again, and if the background restart is still flaky, run:

openclaw gateway

If you want to debug the CUDA issue

Run this and paste the output:

#

npx --no node-llama-cpp inspect gpu

That’ll tell us whether node-llama-cpp can actually use your GPU cleanly.

My honest recommendation: disable memory search for now, get the bot stable, then come back to the CUDA issue after.

wet kelp Apr 14, 2026, 1:24 AM

#

PS C:\Users\unkil> npx --no node-llama-cpp inspect gpu
OS: Windows 10.0.26200 (x64)
Node: 24.14.1 (x64)

node-llama-cpp: 3.18.1
Prebuilt binaries: b8390

CUDA: available
Vulkan: available

CUDA device: NVIDIA GeForce RTX 2060 SUPER
CUDA used VRAM: 12.71% (1.02GB/8GB)
CUDA free VRAM: 87.28% (6.98GB/8GB)

Vulkan device: NVIDIA GeForce RTX 2060 SUPER
Vulkan used VRAM: 10.41% (856.38MB/8.03GB)
Vulkan free VRAM: 89.58% (7.19GB/8.03GB)

CPU model: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
Math cores: 0
Used RAM: 38.42% (12.26GB/31.91GB)
Free RAM: 61.57% (19.65GB/31.91GB)
Used swap: 2.49% (17.87GB/717.51GB)
Max swap size: 717.51GB
mmap: supported
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 1:24 AM

#

That’s actually very helpful.

npx --no node-llama-cpp inspect gpu proves:

your RTX 2060 SUPER is visible
CUDA/Vulkan are both detected
node-llama-cpp itself can inspect the GPU

So the failure is narrower now:

local embeddings install: works
model download: works
CUDA init inside OpenClaw’s local embedding path: crashes

I checked the OpenClaw code path for local memory embeddings, and on this build it just calls getLlama(...). I don’t see an exposed OpenClaw config knob to force CPU-only memory embeddings here.

So honestly, I’d stop burning time on this part for now and unblock the bot.

#

Recommended next step

Disable memory search, then go back to the original timeout:

openclaw config set agents.defaults.memorySearch.enabled false --strict-json
openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json

Then run the gateway in the foreground again:

openclaw gateway

And in another terminal, test the actual assistant model directly:

#

openclaw infer model run --model github-copilot/gpt-5.2 --prompt "Reply with exactly: smoke-ok" --json

Why this matters

If that infer test times out too, the problem is the model/provider path.
If it succeeds, but Discord/Telegram still fail, then we’ve narrowed it to the surface/runtime path.

Docs:
https://docs.openclaw.ai/reference/memory-config
https://docs.openclaw.ai/concepts/model-failover

If you want, paste the infer model run output next and I’ll keep narrowing it down.

wet kelp Apr 14, 2026, 1:33 AM

#

PS C:\Users\unkil> openclaw config set agents.defaults.memorySearch.enabled false --strict-json

🦞 OpenClaw 2026.4.12 (1c0672b) — Self-hosted, self-updating, self-aware (just kidding... unless?).

Config overwrite: C:\Users\unkil.openclaw\openclaw.json (sha256 e2049bca99a294005df4d351f4e73a3e7740184c94d228e6ea9088a0978c8073 -> 2412663afe4e86afae9546c78c71d137678581d5fd4962a76cc56be5d72a8a3d, backup=C:\Users\unkil.openclaw\openclaw.json.bak)
Updated agents.defaults.memorySearch.enabled. Restart the gateway to apply.
PS C:\Users\unkil> openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

Config overwrite: C:\Users\unkil.openclaw\openclaw.json (sha256 2412663afe4e86afae9546c78c71d137678581d5fd4962a76cc56be5d72a8a3d -> 46afa91e45a324463e403c1b9bb447bff59ae9a0041f0bf11087b1cab9d5313a, backup=C:\Users\unkil.openclaw\openclaw.json.bak)
Updated agents.defaults.llm.idleTimeoutSeconds. Restart the gateway to apply.
PS C:\Users\unkil> openclaw gateway restart

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Restarted Windows login item: OpenClaw Gateway
Gateway restart failed after 28s: service stayed stopped and port 18789 stayed free.
Service runtime: status=stopped
Gateway port 18789 status: free.
Gateway restart failed after 28s: service stayed stopped and health checks never came up.
Tip: openclaw gateway status --deep
Tip: openclaw doctor
PS C:\Users\unkil>

tulip oreBOT Apr 14, 2026, 1:33 AM

#

Yep, same background-start problem as before.

The good news is your config changes did save.
They just haven’t been applied through the Windows login item, because that launcher is still flaky.

So do this:

1) Start the gateway in the foreground again

openclaw gateway

Keep that terminal open.

2) In a second terminal, test the actual model path

#

openclaw infer model run --model github-copilot/gpt-5.2 --prompt "Reply with exactly: smoke-ok" --json

3) Optional but useful

openclaw models status

At this point we’ve separated the issues pretty cleanly:

Windows login item / service start is still busted
memory search is now disabled
idle timeout is now raised to 300
next question is whether github-copilot/gpt-5.2 itself still stalls

Paste the infer model run output next.

wet kelp Apr 14, 2026, 1:37 AM

#

well the model works

#

i want embedding though

tulip oreBOT Apr 14, 2026, 1:37 AM

#

Nice, that’s a big clue.

If the direct infer test works, then:

model auth is fine
provider connectivity is fine
github-copilot/gpt-5.2 can respond

So the remaining problem is the full assistant run path in Discord/Telegram, not the raw model itself.

That means the difference is probably one of these:

bigger prompt/context on the surface run
session/bootstrap state
tool/runtime path during embedded runs
channel-specific assistant flow, not delivery itself

#

Next test

Keep openclaw gateway running in the foreground, then from Discord or Telegram send something tiny like:

reply with exactly: smoke-ok

If it still fails, paste the new foreground gateway log lines right after that attempt.

At this point we’ve narrowed it down pretty cleanly:

not basic model access
not memory search anymore
probably the embedded/surface assistant run path

We’re close. Paste the next live log block after a failed Discord/Telegram smoke test.

#

Totally fair. If you want embeddings, I wouldn’t pretend “just disable it” solves your real goal.

On your current 2026.4.12 setup, the situation looks like this:

provider = "ollama"
Docs say it should work, but your runtime rejects it.
That smells like a bug/docs mismatch on this build.
provider = "local"
It now installs and downloads the GGUF fine, but crashes in node-llama-cpp with a CUDA error.
Remote embeddings (openai / gemini / voyage / mistral)
This is the path most likely to work right now.

My recommendation

If you want embeddings today, use a remote provider.
If you want local embeddings specifically, I think you’ve hit bug territory.

#

If you have a remote key already configured

Example with OpenAI:

openclaw config set agents.defaults.memorySearch.enabled true --strict-json
openclaw config set agents.defaults.memorySearch.provider "openai"
openclaw config unset agents.defaults.memorySearch.model

Or Gemini instead:

openclaw config set agents.defaults.memorySearch.enabled true --strict-json
openclaw config set agents.defaults.memorySearch.provider "gemini"
openclaw config unset agents.defaults.memorySearch.model

#

If you specifically want local/Ollama

Then I’d treat this as a bug and file it with:

Unknown memory embedding provider: ollama
local node-llama-cpp path downloading the model, then crashing with:
- ggml-cuda.cu:98: CUDA error
version:
- OpenClaw 2026.4.12 (1c0672b)

If you want, I can help you pick the best remote provider you already have configured, or help write the bug report cleanly.

wet kelp Apr 14, 2026, 1:53 AM

#

Local embedding config
Key Type Default Description
local.modelPath string auto-downloaded Path to GGUF model file
local.modelCacheDir string node-llama-cpp default Cache dir for downloaded models
Default model: embeddinggemma-300m-qat-Q8_0.gguf (~0.6 GB, auto-downloaded). Requires native build: pnpm approve-builds then pnpm rebuild node-llama-cpp.

tulip oreBOT Apr 14, 2026, 1:54 AM

#

Yep, and that’s the key point, you’re already past that part.

OpenClaw already did this successfully:

installed node-llama-cpp
auto-downloaded the default GGUF
resolved the local model cache path

You can see that from your own output:

Downloaded to C:\Users\unkil\.node-llama-cpp\models\hf_ggml-org_embeddinggemma-300m-qat-Q8_0.gguf

So local.modelPath / local.modelCacheDir are not the current problem.

The failure happens after that, here:

#

ggml-cuda.cu:98: CUDA error

So this is now a node-llama-cpp / llama.cpp GPU runtime issue, not “you forgot to set local.modelPath”.

That’s why I’m saying the local embedding config page doesn’t give us another obvious knob here. It explains how the model file is picked, but your crash happens after the file is already loaded/downloaded.

So unfortunately:

changing local.modelPath probably won’t fix this
rebuilding alone didn’t fix this
the next realistic path is either:
- remote embeddings, or
- treating this as a local embeddings bug on your setup/build

If you want, I can help you turn everything we found into one clean bug report.

grizzled creekBOT Apr 14, 2026, 3:14 AM

#

#bot is not responding in discord & telegram

1) Add the key

2) See Groq models

3a) Make Groq your main model

3b) Or keep your current model and add Groq as a fallback

4) Restart

Recommended

If you only want to add it without changing primary

Opción segura, permitir solo ciertos grupos

Opción abierta, permitir grupos en general

Arreglo

Recomendación

En tu caso, la pista importante es esta:

Así que ahora mismo haz esto:

Si quieres que quede persistente

Resumen

1) Memory search

2) Gateway

Easiest fix, if you are not using hooks

If you do want hooks

To make OpenClaw use your Ollama embedding model

What happens after that

One more important distinction

Fastest fix, if you just want OpenClaw working again

If you want embeddings right now

If you specifically want Ollama embeddings

Fastest unblock

If you want embeddings right now

Practical answer

What this means

Important

Fastest unblock

If you want to debug the CUDA issue

Recommended next step

Why this matters

1) Start the gateway in the foreground again

2) In a second terminal, test the actual model path

3) Optional but useful

Next test

My recommendation

If you have a remote key already configured

If you specifically want local/Ollama