memory-lancedb loaded but memory tools not exposed to agent session (2026.4.14 Windows) | Friends of the Crustacean 🦞🤝 | Page 1

reef plinth Apr 16, 2026, 2:29 PM

#

Hi — I've got memory-lancedb loaded and initialised successfully (LanceDB database created, plugin shows as loaded in gateway) but the memory_upsert and memory_search tools are not appearing in my agent's toolset. My agent only sees file operations, web search, exec, cron and session tools. Running OpenClaw 2026.4.14 on Windows. Memory slot is set to memory-lancedb and memory-core is disabled. Any idea why the tools aren't being exposed to the agent session

gritty muralBOT Apr 16, 2026, 2:29 PM

#

sullen thistleBOT Apr 16, 2026, 2:33 PM

#

Let me check the docs and source for how memory tools get registered, since this sounds more like a gating/config issue than LanceDB itself.

#

This looks like expected current behavior, not a Windows-specific thing.

Two separate gotchas are stacked here:

memory_upsert is not the current tool name
For memory-lancedb, the plugin registers:
- memory_recall
- memory_store
- memory_forget
memory_search / memory_get come from memory-core
In the current source, memory-core is the plugin that registers the standard active-memory tools:
- memory_search
- memory_get

So if you set:

#

plugins.slots.memory = "memory-lancedb"
plugins.entries["memory-core"].enabled = false

then it makes sense that memory_search disappears.

Then the second part is tool policy:

plugin tools are not part of group:memory
restrictive profiles/allowlists often hide them unless you explicitly allow the plugin or its tool names

So the likely fix is:

if you want LanceDB plugin tools, allow memory-lancedb (or memory_recall, memory_store, memory_forget) in your tool policy
if you specifically want memory_search, keep memory-core enabled/active instead

#

A couple good checks:

openclaw plugins inspect memory-lancedb
openclaw sandbox explain --agent main

What I’d look for:

does plugins inspect show memory_recall / memory_store / memory_forget
does sandbox explain show a tools.profile / tools.allow that excludes plugin tools

Relevant docs:

If you paste your tools.profile, tools.allow, and agents.list[].tools bits, I can tell you the exact config change.

reef plinth Apr 17, 2026, 8:43 AM

#

Thanks for the help. I tried adding memory_recall, memory_store, memory_forget to agents.list[1].tools.alsoAllow and agents.list[1].tools.allow via CLI but the tools still aren't appearing in the main Telegram session even after /new and gateway restart.
My agent already has allow: [""] set. Running openclaw plugins inspect memory-lancedb confirms the tools exist. But the agent session still only shows file, exec, web, image and session tools.*
Is there a specific config needed to expose memory-lancedb tools to the main conversational session rather than just sandbox sub-agents?

sullen thistleBOT Apr 17, 2026, 8:46 AM

#

I’m going to check the tool-policy behavior for allow: [""] and alsoAllow, because that smells like the real blocker here.

#

Yep, I think I see the trap.

For the main conversational session, the right knob is alsoAllow, not allow.

Why:

tools.profile: "coding" filters tools early
plugin tools like memory_recall / memory_store / memory_forget get dropped at that stage
alsoAllow is merged into the profile stage
plain allow is a later restrictive filter, so it does not bring plugin tools back

I also checked the config rules, and this part matters a lot:

allow: [""] is not the same as unset

It normalizes to nothing at runtime, but it still means “this scope has an allow field”, and it can conflict with alsoAllow in the same scope.

What to change

#

On the agent that backs the Telegram chat, use something like:

{
  agents: {
    list: [
      {
        id: "main",
        tools: {
          profile: "coding",
          alsoAllow: ["memory-lancedb"]
          // or: ["memory_recall", "memory_store", "memory_forget"]
        }
      }
    ]
  }

#

And remove this from that same scope:

tools: {
  allow: [""]
}

Also avoid mixing allow + alsoAllow in the same agents.list[].tools block.

Important extra check

Make sure you edited the actual agent used by that Telegram session.

#

agents.list[1] is brittle. If index 1 is not the Telegram-facing main agent, the change won’t show up there.

If it still doesn’t appear

Then I’d check provider/session-specific policy on the actual Telegram session:

openclaw sandbox explain --session <that-telegram-session-key>

and look for:

tools.byProvider.telegram
agents.list[].tools.byProvider.telegram
any group/topic tool overrides

So short version:

#

remove allow: [""]
use alsoAllow, not allow
put it on the real main agent for that Telegram session
restart gateway, then open a fresh session

If you paste the relevant agents.list[].tools block plus sandbox explain for that Telegram session, I can sanity-check the exact config.

reef plinth Apr 21, 2026, 1:03 PM

#

Memory tools are now showing in the agent session but memory_store/memory_recall are returning 401 from OpenAI. I've updated the OpenAI API key in openclaw.json under plugins.entries.memory-lancedb.config.embedding.apiKey and also ran openclaw configure to set it via CLI. Still getting 401. The key is valid — I tested it directly against the OpenAI API and it works. Where else could OpenClaw be reading the OpenAI key from for the memory backend?"

sullen thistleBOT Apr 21, 2026, 1:04 PM

#

Nice, glad the tools are showing now. I’m checking the LanceDB plugin code path for exactly where it resolves the embedding key from, because this smells like config source or service-env drift, not the plugin logic itself.

#

I checked the plugin code, and for memory-lancedb the answer is basically:

nowhere else, unless you used ${ENV_VAR} in that plugin config.

The plugin reads only:

plugins.entries["memory-lancedb"].config.embedding.apiKey
plugins.entries["memory-lancedb"].config.embedding.baseUrl

and if embedding.apiKey is something like:

"${OPENAI_API_KEY}"

#

then it resolves that from the Gateway process env.

A couple important implications:

openclaw configure does not drive this plugin
That sets normal provider auth, but memory-lancedb is using its own plugin config field.
If you hardcoded the key directly in embedding.apiKey, then the main suspect is:
- the running gateway is using a different config file than the one you edited
If you used ${OPENAI_API_KEY}, then the main suspect is:
- the gateway service has a different env than your shell
- on Windows, this is very plausible with Scheduled Task / service startup

What I would check first

1) Confirm which config file the running gateway is actually using

#

openclaw gateway status
openclaw gateway status --json

The docs note that this shows the CLI vs service config path snapshot, which is exactly what you want here.

2) Check whether `embedding.apiKey` is a raw key or `${OPENAI_API_KEY}`

If it is ${OPENAI_API_KEY}, check:
- process env for the gateway
- ~/.openclaw/.env
- shell-env import settings

Relevant FAQ section: https://docs.openclaw.ai/start/faq
Windows docs: https://docs.openclaw.ai/platforms/windows

#

3) Check `embedding.baseUrl`

If baseUrl is set, the plugin uses that instead of default OpenAI:

new OpenAI({ apiKey, baseURL: baseUrl })

So a stale/custom baseUrl can absolutely cause a 401 even with a good key.

Fastest sanity test

Temporarily set all 3 explicitly in the plugin config:

plugins: {

#

  entries: {
    "memory-lancedb": {
      enabled: true,
      config: {
        embedding: {
          apiKey: "sk-proj-...",
          model: "text-embedding-3-small",
          baseUrl: "https://api.openai.com/v1",
        },
      },
    },
  },
}

Then restart the gateway and test again.

#

If that works, it was env drift or baseUrl drift
If that still 401s, you are almost certainly editing the wrong config / wrong running gateway instance

If you want, paste:

redacted plugins.entries.memory-lancedb.config.embedding
openclaw gateway status
whether you’re on native Windows or WSL2

and I can narrow it down fast.

reef plinth Apr 21, 2026, 1:15 PM

#

Still 401. I've added baseUrl: 'https://api.openai.com/v1' explicitly to the config. The key is definitely valid — tested directly against OpenAI API and it works. Here's my redacted embedding config:
json"embedding": {
"apiKey": "sk-proj-...REDACTED...",
"model": "text-embedding-3-small",
"baseUrl": "https://api.openai.com/v1"
}
Running openclaw gateway status --json now to check which config file is actually being used. Windows 10, native (not WSL2)

#

o
{
"logFile": "C:\Users\admin\AppData\Local\Temp\openclaw\openclaw-2026-04-21.log",
"service": {
"label": "Scheduled Task",
"loaded": true,
"loadedText": "registered",
"notLoadedText": "missing",
"command": {
"programArguments": [
"C:\Program Files\nodejs\node.exe",
"C:\Users\admin\AppData\Roaming\npm\node_modules\openclaw\dist\index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "C:\Users\admin\.openclaw\gateway.cmd"
},
"runtime": {
"status": "running",
"state": "Running",
"lastRunTime": "21/04/2026 15:09:35",
"lastRunResult": "267009"
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "C:\Users\admin\.openclaw\openclaw.json",
"exists": true,
"valid": true
},
"daemon": {
"path": "C:\Users\admin\.openclaw\openclaw.json",
"exists": true,
"valid": true
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "busy",
"listeners": [
{
"pid": 3900,
"address": "127.0.0.1:18789",
"command": "node.exe",
"commandLine": ""C:\Program Files\nodejs\node.exe" C:\Users\admin\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789"
}
],
"hints": [
"Gateway already running locally. Stop it (openclaw gateway stop) or use a different port."
]
},
"rpc": {
"ok": true,
"url": "ws://127.0.0.1:18789"
},
"health": {
"healthy": true,
"staleGatewayPids": []
},
"extraServices": []
}

sullen thistleBOT Apr 21, 2026, 1:16 PM

#

Native Windows makes service/config drift more likely, yeah. Let me check one more thing in the plugin code, just in case the key is getting transformed or a different OpenAI client path is used than the one you tested.

#

That narrows it down a lot.

I checked the plugin path again, and it really is just:

new OpenAI({ apiKey, baseURL: baseUrl })
then client.embeddings.create({ model: "text-embedding-3-small", input: ... })

So there is no second auth source in the plugin at this point.

With your current config, the remaining likely causes are:

wrong running gateway / wrong config path
multiple native Windows gateway installs (old Scheduled Task / Startup instance)
whitespace in the stored key
The plugin does not trim embedding.apiKey
the key works generally, but not for the exact embeddings endpoint/model

#

Best next checks

1) On native Windows, use deep status too

openclaw gateway status --deep

I’m specifically looking for:

multiple gateway-like installs
service vs CLI config path mismatch
old Scheduled Task still running an older config

2) Test the exact endpoint the plugin uses

If your earlier direct test was not /v1/embeddings with text-embedding-3-small, do that exact call next.

#

If that exact embeddings call fails too, then it’s not an OpenClaw issue, it’s key/project/model access.

If that exact embeddings call succeeds, then it’s almost certainly service/config drift inside OpenClaw.

3) Re-enter the key once, carefully

Because the plugin passes it through verbatim, a hidden trailing space/newline is enough to break it.

My current bet

On native Windows, I’d honestly bet on old gateway instance / Scheduled Task drift first, especially since the tool exposure issue earlier was also policy/runtime-side.

If you paste the output from:

openclaw gateway status --json

#

openclaw gateway status --deep

I can help read it. If this gets solved, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

#

This status output is actually really helpful.

It says:

one gateway instance
CLI and daemon are using the same config path
no extra services
healthy RPC

So at this point, I don’t think OpenClaw is reading the key from somewhere else.

That leaves the likely causes as:

the exact embeddings call fails with that key/model
the stored key has hidden whitespace
the log has a more specific OpenAI error that we haven’t seen yet

#

Next best check

Please run:

openclaw logs --follow

Then trigger memory_store once, and paste the exact 401 message from the log.

That message should tell us a lot:

Incorrect API key provided → almost certainly key formatting / hidden whitespace
model / permission wording → embeddings-specific access issue
anything mentioning project / org → OpenAI-side auth scoping

Also test the exact endpoint OpenClaw uses

#

If your manual test was not this exact call, do this one:

$headers = @{
  Authorization = "Bearer sk-proj-REDACTED"
  "Content-Type" = "application/json"
}

$body = @{
  model = "text-embedding-3-small"
  input = "test"
} | ConvertTo-Json

Invoke-RestMethod `
  -Uri "https://api.openai.com/v1/embeddings" `
  -Method Post `

#

  -Headers $headers `
  -Body $body

That is the closest reproduction of what the plugin is doing.

One subtle thing I’d still check

Re-enter the key once manually in openclaw.json.

The plugin does not trim embedding.apiKey, so a trailing space or newline from clipboard paste would survive and could absolutely cause this.

If you paste the exact log error next, I think we can pin this down pretty fast.

reef plinth Apr 21, 2026, 1:45 PM

#

he log consistently shows the old revoked key (ending OqcA) being used despite openclaw.json having been updated with a new key (ending 0CQcoA). Even after gateway stop/start the old key persists. Where else could OpenClaw be caching or storing the embedding API key that survives a gateway restart?"

sullen thistleBOT Apr 21, 2026, 1:50 PM

#

I found one more Windows-specific place that can absolutely make this look like “the old key survived a restart”. Checking the service install path now.

#

Short answer, I don’t think there’s a separate memory-lancedb key cache here.

On 2026.4.14, the Windows gateway wrapper does not persist OPENAI_API_KEY into gateway.cmd, and the plugin just uses the resolved embedding.apiKey it gets at runtime. So if the log still shows the revoked ...OqcA key after restart, the usual places to check are:

State-dir .env
- %USERPROFILE%\.openclaw\.env
- or %USERPROFILE%\.openclaw-<profile>\.env
A working-directory .env if the gateway was ever started manually from a folder
Windows persistent env vars
- user or machine OPENAI_API_KEY
Wrong/stale Windows launcher
- %USERPROFILE%\.openclaw\gateway.cmd
- or profile variant
- also check Startup fallback:

#

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\OpenClaw Gateway.cmd

A still-running old listener/process that never actually died

A really important nuance:

If your plugin config now has a literal key in openclaw.json, .env and env vars should not override that.
So if the old key still shows up, I’d suspect wrong config/profile/path or an old process/startup entry, not plugin caching.

Best next checks

type $env:USERPROFILE\.openclaw\gateway.cmd
type $env:USERPROFILE\.openclaw\.env
[Environment]::GetEnvironmentVariable("OPENAI_API_KEY", "User")
[Environment]::GetEnvironmentVariable("OPENAI_API_KEY", "Machine")

#

openclaw gateway status --deep --json

If you want to fully rule out stale Windows service glue, I’d do a clean rewrite of the launcher:

openclaw gateway stop
schtasks /Delete /F /TN "OpenClaw Gateway"
Remove-Item -Force "$env:USERPROFILE\.openclaw\gateway.cmd"
Remove-Item -Force "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\OpenClaw Gateway.cmd" -ErrorAction SilentlyContinue
openclaw gateway install --force
openclaw gateway start

If you’re using a named profile, use OpenClaw Gateway (<profile>) and the matching .openclaw-<profile> paths.

#

Docs:

If you paste the contents of gateway.cmd and whether %USERPROFILE%\.openclaw\.env exists, I can narrow it down fast.

reef plinth Apr 22, 2026, 12:06 PM

#

Still showing the old revoked key (OqcA) in logs after: updating openclaw.json, gateway reinstall, schtasks delete, gateway.cmd delete, PowerShell execution policy reset. No .env file exists. No OPENAI_API_KEY Windows env vars. Only one openclaw.json on the machine. The file shows a new key but the plugin loads the old one every time. What else could be storing or caching this key?"

sullen thistleBOT Apr 22, 2026, 12:08 PM

#

That’s enough to rule out the obvious Windows service/env stuff. I’m checking whether OpenClaw persists a plugin config snapshot anywhere under state/plugin runtime metadata, because that’s the next thing I’d suspect.

#

At this point, I don’t think it’s stored in LanceDB, plugin-runtimes, auth.json, or auth-profiles.json.

I checked the source again, and for memory-lancedb the embedding key comes from the parsed plugin config only. So the remaining hidden sources are basically:

$include files in/under the config directory
OpenClaw supports JSON5 $include, so the visible openclaw.json can still be pulling in an older value from another file.
Duplicate JSON5 keys in the same file
A second plugins, memory-lancedb, embedding, or apiKey later in the file can silently win.
env.vars.OPENAI_API_KEY inside config
Separate from Windows env vars. This lives inside openclaw.json.
If none of the above apply, this is probably a bug in config loading/runtime handoff.

Best next check

#

Run this locally, and don’t paste the whole key, just compare the suffix:

openclaw config get plugins.entries.memory-lancedb.config.embedding.apiKey
openclaw config get env.vars.OPENAI_API_KEY

Interpretation

If config get ...embedding.apiKey already shows old ...OqcA, then the old key is being reintroduced during config parsing, most likely by:
- $include
- duplicate keys
- env.vars
If config get ...embedding.apiKey shows the new ...0CQcoA, but the plugin still logs old ...OqcA, then I’d treat that as a real OpenClaw bug.

Two good searches

#

Select-String -Path "$env:USERPROFILE\.openclaw\openclaw.json" -Pattern '\$include|OPENAI_API_KEY|memory-lancedb|apiKey'

Get-ChildItem "$env:USERPROFILE\.openclaw" -Recurse -Force -File -ErrorAction SilentlyContinue |
  Where-Object { $_.FullName -notmatch '\\logs\\' } |
  Select-String -SimpleMatch "OqcA"

If that second search finds OqcA in any non-log file, that’s your smoking gun.

If config get shows the new key and the search turns up nothing except logs, I’d file a bug with sanitized output from:

openclaw --version
openclaw gateway status --deep --json
openclaw config get plugins.entries.memory-lancedb.config.embedding.apiKey

#

GitHub issues: https://github.com/openclaw/openclaw/issues
Config docs: https://docs.openclaw.ai/cli/config

If you want, paste the sanitized output of those two config get commands and I’ll tell you which branch you’re in.

reef plinth Apr 22, 2026, 12:18 PM

#

config get plugins.entries.memory-lancedb.config.embedding.apiKey returns OPENCLAW_REDACTED so I can't verify what the runtime sees. The file has a new key ending 0CQcoA but the plugin logs show the old key ending OqcA. No env vars, no .env file. The old key also appears in session history files and TOOLS.md but those shouldn't affect plugin config. Is there a known issue where memory-lancedb reads a stale key at runtime despite openclaw.json being updated? Running 2026.4.15 on Windows."

sullen thistleBOT Apr 22, 2026, 12:19 PM

#

I’m checking one last code path, the LanceDB runtime bootstrap itself, just to rule out “config baked into the runtime install” before I call this a bug.

#

I don’t know of a known memory-lancedb stale-key bug on 2026.4.15, and I don’t see a code path that would intentionally cache that key across restarts.

A couple concrete things I can rule out from source:

plugin-runtimes\memory-lancedb\... only stores the LanceDB dependency/runtime, not plugin config or API keys.
session history and TOOLS.md can explain why OqcA still exists on disk, but they should not affect memory-lancedb config.
config get returning __OPENCLAW_REDACTED__ for embedding.apiKey is expected for sensitive paths, so that command won’t tell you the suffix.

Best next test, use a canary config change

Since the key is redacted, the cleanest way to prove what runtime config the plugin is actually using is to change a non-secret field temporarily.

Option A, easiest

Temporarily set:

#

plugins: {
  entries: {
    "memory-lancedb": {
      config: {
        embedding: {
          baseUrl: "http://127.0.0.1:9/v1"
        }
      }
    }
  }
}

Then restart and trigger memory_store / memory_recall.

What that tells you

#

If the error changes to something like connection refused / fetch failed, the plugin is reading the current file.
If it still shows the old OpenAI-key ...OqcA 401, then the gateway is loading stale runtime config, and I’d call that a bug.

My read right now

This doesn’t look like LanceDB caching. It looks more like one of:

hidden config composition, like $include / duplicate JSON5 keys
or a Windows/runtime config bug where the gateway is not actually using the updated parsed config

If you want one more quick check before filing a bug, search the config file for:

Select-String -Path "$env:USERPROFILE\.openclaw\openclaw.json" -Pattern '\$include|memory-lancedb|embedding|apiKey|baseUrl'

If there’s no $include and the baseUrl canary still doesn’t take, I’d file it as a bug.

#

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

What I’d include in the issue:

openclaw --version
openclaw gateway status --deep --json
sanitized plugins.entries.memory-lancedb.config
result of the baseUrl canary test
the exact log line still showing ...OqcA

If you paste the result of the baseUrl canary, I can tell you pretty quickly whether this is config layering or a real runtime bug.

reef plinth Apr 22, 2026, 3:24 PM

#

Canary test done. Set baseUrl to http://127.0.0.1:9/v1, restarted gateway, triggered memory_store. Error still shows the old OqcA key hitting api.openai.com — not the canary URL. The plugin is definitely not reading the current openclaw.json config at runtime. Filing as a bug. Here's the info:
— openclaw 2026.4.15
— Windows 10
— Error: 401 Incorrect API key provided: ...OqcA hitting api.openai.com
— baseUrl canary completely ignored
— New key ending 0CQcoA confirmed in openclaw.json
— No $include, no env vars, no .env file"

#

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

reef plinth Apr 22, 2026, 7:51 PM

#

can i get a response please

#memory-lancedb loaded but memory tools not exposed to agent session (2026.4.14 Windows)

What to change

Important extra check

If it still doesn’t appear

What I would check first

1) Confirm which config file the running gateway is actually using

2) Check whether embedding.apiKey is a raw key or ${OPENAI_API_KEY}

3) Check embedding.baseUrl

Fastest sanity test

Best next checks

1) On native Windows, use deep status too

2) Test the exact endpoint the plugin uses

3) Re-enter the key once, carefully

My current bet

Next best check

Also test the exact endpoint OpenClaw uses

One subtle thing I’d still check

Best next checks

Best next check

Interpretation

Two good searches

Best next test, use a canary config change

Option A, easiest

What that tells you

My read right now

2) Check whether `embedding.apiKey` is a raw key or `${OPENAI_API_KEY}`

3) Check `embedding.baseUrl`