Updated from 2026.4.10 to 2026.4.26 - Stuck sessions and delays | Friends of the Crustacean 🦞🤝 | Page 1

trim coral Apr 29, 2026, 1:57 AM

#

Hi Krill, back again with a memory issue. I just upgraded from 2026.4.10 to 2026.4.26, and responses are sluggish. My agent dug into it and it thinks it's because of Node.js 22.22.0 blocking native extension loading, causing sqlite-vec to not load. Is there some way to fix this?

Pasting my "openclaw memory status" here in case it's relevant.

19:51:46 [memory] chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Further duplicate warnings suppressed.
◇
Memory index complete.
Memory Search (main)
Provider: none (requested: auto)
Model: none
Sources: memory
Indexed: 50/50 files · 150 chunks
Dirty: no
Store: ~/.openclaw/memory/main.sqlite
Workspace: ~/.openclaw/workspace
Dreaming: off
Embeddings: unavailable
Embeddings error: No GitHub token available for Copilot embedding provider

By source:
memory · 50/50 files · 150 chunks
Vector: unknown
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-x64/vec0.so
FTS: ready
Embedding cache: enabled (0 entries)
Batch: disabled (failures 0/2)
Recall store: 6 entries · 0 promoted · 6 concept-tagged · 2 spaced · scripts=6 latin
Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-29T01:11:59.163Z
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json

dark sedgeBOT Apr 29, 2026, 1:57 AM

#

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

scenic vectorBOT Apr 29, 2026, 2:01 AM

#

I don’t think Node 22.22.0 by itself is the smoking gun. Your status says Provider: none / Model: none / Embeddings unavailable, so semantic/vector memory isn’t actually running; without embeddings OpenClaw is keyword/FTS-only, and sqlite-vec is optional acceleration with fallback. (docs.openclaw.ai)

The real Node gotcha: if the gateway is running with Node’s Permission Model (--permission via NODE_OPTIONS or service env), Node blocks runtime-loadable SQLite extensions. Node 22 docs call that out specifically. (nodejs.org)

Check this:

openclaw --version
node -p 'process.version'
echo "$NODE_OPTIONS"
openclaw logs --limit 300 --plain | grep -Ei 'sqlite-vec|chunks_vec|active-memory|memory sync|embedding'

If NODE_OPTIONS contains --permission, remove that from the gateway service env, then:

#

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

If you just want to stop sqlite-vec from being involved while debugging:

openclaw config set agents.defaults.memorySearch.store.vector.enabled false
openclaw gateway restart

Also: Codex OAuth won’t satisfy embedding requests, so if you want semantic memory back, pin/configure an embedding provider or fix the Copilot/GitHub token path.

trim coral Apr 29, 2026, 2:07 AM

#

Hmm, node options look blank.

OpenClaw 2026.4.26 (be8c246)
openclaw@openclaw2:~$ node -p 'process.version'
v22.22.0
openclaw@openclaw2:~$ echo "$NODE_OPTIONS"

openclaw@openclaw2:~$```


I'm using MiniMax Token Plan High Speed. Can I use it for embeddings, or do I need embeddings? responses definitely seem slower than 2026.4.10.

scenic vectorBOT Apr 29, 2026, 2:08 AM

#

Yep, blank NODE_OPTIONS makes the Node permission-model theory much less likely.

MiniMax High Speed is a chat/reasoning model, not a memory embedding provider in OpenClaw right now. For memory embeddings use one of the supported embedding providers: GitHub Copilot, OpenAI, Gemini, Voyage, Mistral, DeepInfra, Bedrock, Ollama, or local. Docs: https://docs.openclaw.ai/reference/memory-config

Do you need embeddings? No. With only 150 chunks, FTS-only memory should be fine and probably isn’t the main cause of sluggish replies. The sqlite-vec warning is ugly, but if embeddings are unavailable anyway, vector search isn’t doing much.

What I’d test next is Active Memory, because it’s blocking before replies and can make everything feel slower:

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

Then try a few replies. If speed is back, re-enable it but make it cheaper/faster:

#

openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw config set plugins.entries.active-memory.config.timeoutMs 3000 --strict-json
openclaw gateway restart

There are also several Active Memory fixes already on main after 2026.4.26, but npm latest is still 2026.4.26 from what I can see, so disabling/tuning it is the safest workaround for now.

trim coral Apr 29, 2026, 2:18 AM

#

Active memory hasn't been turned on yet. I tested again, and it might have just been api latency and me getting antsy due to updating from a bunch of versions behind. 😛

scenic vectorBOT Apr 29, 2026, 2:18 AM

#

Ahh yep, that tracks 😄

If Active Memory is off and you only have ~150 memory chunks, the sqlite-vec warning is probably just a degraded-feature warning, not the source of big latency. FTS is ready, so basic memory search still works.

If it keeps feeling slow, I’d compare with:

openclaw logs --limit 300 --plain | grep -Ei 'model|latency|duration|active-memory|memory|sqlite-vec'

But honestly: after jumping from 2026.4.10 → 2026.4.26, a little “is everything slower or am I staring at the spinner too hard?” paranoia is very understandable. 🦐

trim coral Apr 29, 2026, 2:19 AM

#

While I'm here can I send you a sanitized version of my openclaw.json to see if there are any best practices I'm missing out on, or any modules/plugins I should consider trying out?

scenic vectorBOT Apr 29, 2026, 2:20 AM

#

Yep, send it over — just remember this thread is public / Answer Overflow indexed, so sanitize aggressively first.

Please redact/remove:

API keys, OAuth tokens, gateway tokens/passwords
Discord/Telegram/etc bot tokens
allowFrom, user IDs, channel IDs if you care about privacy
private hostnames, Tailscale names, LAN IPs, webhook URLs
secret refs or env var names that reveal too much

Helpful extras:

openclaw config validate
openclaw status --all

#

status --all is designed to be safe-ish/shareable with redaction, and the config validate result helps catch schema drift.

I can review for: config shape, model/provider setup, memory settings, gateway/security posture, useful bundled plugins, and “you probably don’t need this anymore” cleanup. 🦐

trim coral Apr 29, 2026, 2:22 AM

#

can you read a github gist, or is there a better way to send it?

scenic vectorBOT Apr 29, 2026, 2:22 AM

#

Yep, I can read a GitHub Gist. Best options:

Best: make a secret gist, paste the sanitized config there, and send the gist link here.
Also fine: paste it directly in a code block if it’s not huge.
Most private: paste only the sections you want reviewed: models, agents, plugins, memorySearch, gateway, tools, channels minus secrets.

If using a gist, double-check it has no tokens/passwords first — secret gists are unlisted, not truly private.

trim coral Apr 29, 2026, 2:29 AM

#

Here's the gist: https://gist.github.com/Myles512/83f0158afbc1e168fe5b1f3e29397d98

It's running in yolo exec mode (or what passed for that in 2026.4.10), which is fine. It has its own machine that it can destroy if it wants. 😉 Other than that, anything you would suggest would be appreciated.

scenic vectorBOT Apr 29, 2026, 2:31 AM

#

Read it. Overall: this is pretty clean, especially for a dedicated “it may destroy itself” box. A few tweaks I’d consider:

Clean up model fallbacks. You have anthropic/claude-haiku-4-5 twice, and the gist only shows OpenRouter + MiniMax auth profiles. If you don’t also have Anthropic auth via env/profile, that direct Anthropic fallback may just add failure noise when failover happens. Run openclaw models status and keep only fallbacks that show healthy. (gist.github.com)
YOLO exec is fine, but your approval config is probably misleading. tools.exec.host=gateway, security=full, ask=off is the YOLO/no-prompt shape; docs say approvals stack on top unless elevated/full skips them, and YOLO is specifically security=full + ask=off. So the Discord execApprovals / approvals.exec blocks may not do what you expect in this mode. Verify with:
```
openclaw approvals get --gateway
openclaw exec-policy show
```
(gist.github.com)
Move gateway.auth.token to an env SecretRef if it’s plaintext in the real config. You already do this nicely for channels.discord.token; I’d do the same for the gateway token. openclaw config set supports SecretRef builder mode and dry-run validation. (gist.github.com)
Memory: either ignore it or explicitly disable vector until you add embeddings. MiniMax isn’t listed as a memory embedding provider in the docs; supported memory providers are things like OpenAI/Gemini/Voyage/Mistral/Bedrock/Ollama/local. sqlite-vec fallback is automatic, but if you want to stop the warning:
```
openclaw config set agents.defaults.memorySearch.store.vector.enabled false --strict-json
```

#

   openclaw gateway restart

(docs.openclaw.ai)

Plugin/tool surface: you’ve got tools.profile: full plus DuckDuckGo, Perplexity, MiniMax, OpenRouter, Anthropic, browser. Not wrong, but if the agent feels indecisive or slow, prune plugins you don’t actively use. MiniMax web search is already selected.
Worth trying: since you already have MiniMax configured, you can try MiniMax image generation by setting agents.defaults.imageGenerationModel.primary to minimax/image-01; the MiniMax plugin uses the same auth path for that. (docs.openclaw.ai)

Small cleanup command I’d run first:

openclaw config validate
openclaw security audit --deep
openclaw models status

#

Nothing here screams “bad config.” Biggest practical fix is fallback hygiene + deciding whether you want true YOLO or actual approvals.

trim coral Apr 29, 2026, 2:34 AM

#

Thanks, Krill!

scenic vectorBOT Apr 29, 2026, 2:34 AM

#

You’re welcome! 🦐

If any of those checks turns up something weird, paste the output and I’ll help untangle it.

trim coral Apr 29, 2026, 2:38 AM

#

Oh, I just noticed ollama as an embeddings provider. Can I use a local model for embeddings? or is that going to be slow? It's going to be running on an older Xeon Proxmox VM server, but I can give it a bunch of cores and ram if needed.

scenic vectorBOT Apr 29, 2026, 2:39 AM

#

Yes — you can use Ollama for local memory embeddings. It’s explicitly supported, but not auto-detected, so you have to set it.

For your box: older Xeon is fine for experimenting, especially with only ~150 chunks. Initial indexing may be slow-ish; normal query-time should be okay. I’d start conservative and only increase concurrency if it’s clearly underusing the machine.

Basic shape:

ollama pull <embedding-model>

openclaw config set agents.defaults.memorySearch.provider ollama
openclaw config set agents.defaults.memorySearch.model "<embedding-model>"
openclaw config set agents.defaults.memorySearch.remote.nonBatchConcurrency 1 --strict-json

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

#

If Ollama runs on another VM/host, configure the native Ollama URL — no /v1:

openclaw config set models.providers.ollama.baseUrl "http://ollama-host:11434"

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

My practical take: embeddings are nice, not mandatory. With your current tiny memory corpus, FTS-only is probably already fine. Use local embeddings if you want semantic recall/privacy/no hosted API calls; skip it if you want maximum simplicity.

trim coral Apr 29, 2026, 2:57 AM

#

ok, dumb question, I don't remember how I set my discord_bot_token env variable. Is it permanent somewhere? I don't see it in my current env. I want to set my gateway token to env, but I don't remember how, haha.

scenic vectorBOT Apr 29, 2026, 2:57 AM

#

Not dumb at all — service env is confusing. If you don’t see it in your shell, it’s probably in one of:

~/.openclaw/.env
the systemd user service env / env file
inline config SecretRef from the wizard

OpenClaw loads ~/.openclaw/.env for daemon/service cases, so that’s the easiest permanent place.

To rotate/set gateway token via env:

TOKEN="$(openssl rand -hex 32)"

mkdir -p ~/.openclaw
touch ~/.openclaw/.env
chmod 600 ~/.openclaw/.env

#


grep -v '^OPENCLAW_GATEWAY_TOKEN=' ~/.openclaw/.env > ~/.openclaw/.env.tmp
printf 'OPENCLAW_GATEWAY_TOKEN=%s\n' "$TOKEN" >> ~/.openclaw/.env.tmp
mv ~/.openclaw/.env.tmp ~/.openclaw/.env

openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token \
  --ref-provider default \
  --ref-source env \
  --ref-id OPENCLAW_GATEWAY_TOKEN

openclaw gateway restart

Then update any Control UI / remote clients with the new token.

#

To inspect how Discord is currently referenced without revealing the token:

openclaw config get channels.discord.token --json

Docs: https://docs.openclaw.ai/help/faq#env-vars-and-env-loading and https://docs.openclaw.ai/cli/config

trim coral Apr 29, 2026, 3:10 AM

#

Thanks! I was also thinking of turning on Dreaming. Good idea? or is that only if you have vector/embeddings?

scenic vectorBOT Apr 29, 2026, 3:10 AM

#

Not only for vector/embeddings. Dreaming can run without embeddings — it works from short-term recall traces, daily memory files, and session signals. Embeddings just make the recall/search side smarter; they’re not a hard requirement.

My take: worth trying, but treat it as a background memory experiment, not a must-have. It’s opt-in, scheduled, and mostly reviewable:

writes machine state to memory/.dreams/
writes human-readable summaries to DREAMS.md
only the deep phase can promote durable items into MEMORY.md
promotions are thresholded, so it shouldn’t dump everything into long-term memory

For your setup, I’d start with defaults:

openclaw config set plugins.entries.memory-core.config.dreaming.enabled true --strict-json
openclaw gateway restart
openclaw memory status --deep

#Updated from 2026.4.10 to 2026.4.26 - Stuck sessions and delays