openclaw - 💡(How to fix) Fix [Bug]: memorySearch remote embeddings fail with `fetch failed` even when provider API is reachable [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Summary

memorySearch remote embeddings fail with fetch failed in a real deployment where the provider API is reachable via curl.

This does not look like a simple API key / provider configuration issue.

From our testing, the failure appears to be specifically in the Node/OpenClaw fetch path used by memory embeddings.

Environment

• OpenClaw: 2026.3.13 (61d171a)
• Node: v22.22.0
• OS: macOS
• Gateway managed by: PM2
• Proxy env injected into the gateway process:
• HTTP_PROXY=http://127.0.0.1:7897
• HTTPS_PROXY=http://127.0.0.1:7897

Symptoms

openclaw memory status --deep reports:

Memory Search (main)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Embeddings: unavailable
Embeddings error: fetch failed

We saw the same behavior when testing Gemini as the memory embedding provider.

What we tested

1) OpenAI embeddings

Using the same configured OpenAI API key:

• curl [https://api.openai.com/v1/embeddings](https://api.openai.com/v1/embeddings%60) → success
• node fetch(...) to the same endpoint → TypeError: fetch failed
• openclaw memory status --deep / openclaw memory search → fetch failed

So the provider API itself is reachable, but the Node/OpenClaw fetch path fails.

2) Gemini embeddings

Using a valid Gemini embedding key:

• curl to Gemini embedding endpoint → success
• node fetch(...) to the same endpoint → TypeError: fetch failed
• openclaw memory status --deep / openclaw memory search → fetch failed

Again, provider API is reachable, but memorySearch still fails in the OpenClaw/Node fetch path.

3) Volcengine Ark embeddings (control test)

We also tested Volcengine Ark as a control:

• node fetch(...) to Ark does reach the server and returns structured JSON API errors such as:
• NotFound
• ModelNotOpen

This is important because it suggests not all Node fetch traffic is broken in our environment.

In other words:

• OpenAI/Gemini path → fetch failed
• Ark path → reaches server and gets API response

Local code observation

In the installed build, the memory remote embedding path appears to call:

fetchWithSsrFGuard({
url: params.url,
init: params.init,
policy: params.ssrfPolicy,
auditContext: params.auditContext ?? "memory-remote"
})

But it does not appear to pass proxy: "env" or use withTrustedEnvProxyGuardedFetch Mode(...).

At the same time, OpenClaw clearly has env-proxy-aware guarded fetch support internally.

This suggests the memory remote embeddings path may be missing the env-proxy guarded mode, which would be consistent with the observed behavior.

Expected behavior

If the provider API is reachable from the host (for example via curl using the same env proxy setup), memorySearch remote embedding requests should also succeed.

Actual behavior

memorySearch remote embeddings fail with:

fetch failed

even when the provider endpoint is confirmed reachable outside the OpenClaw memory fetch path.

Related

This may be related in spirit to other guarded fetch / SSRF / proxy issues, such as:

• #28271 [Feature]: web_fetch: pass ssrfPolicy from config to fetchWithSsrFGuard (fix fake-IP/proxy environments)

The symptoms are not identical, but both seem to involve guarded fetch behavior in proxy-constrained environments.

Additional note

From our side, this does not look like:

• invalid OpenAI/Gemini keys
• wrong embedding model configuration
• broken vector store / sqlite-vec setup

It looks much more like a transport / guarded-fetch / env-proxy path issue in remote memory embeddings.

Happy to provide more logs or sanitized repro details if helpful. ``

Steps to reproduce

1. Run OpenClaw 2026.3.13 (61d171a) on macOS with Node v22.22.0. 2. Start the gateway under PM2 with proxy env set for the process:

   • HTTP_PROXY=http://127.0.0.1:7897
   • HTTPS_PROXY=http://127.0.0.1:7897
   1. Configure memorySearch to use a remote embedding provider such as:
   • OpenAI (text-embedding-3-small), or
   • Gemini (gemini-embedding-001)
   1. Verify that the provider API is reachable outside OpenClaw:
   • curl to the provider embedding endpoint succeeds
   1. Run:
   • openclaw memory status --deep
   • openclaw memory search "test"
   1. Observe that embeddings are unavailable and memory search fails with fetch failed.

   Additional control tests:

   • node fetch(...) to OpenAI embeddings fails with TypeError: fetch failed
   • node fetch(...) to Gemini embeddings also fails with TypeError: fetch failed
   • node fetch(...) to Volcengine Ark does reach the server and returns structured API errors, which suggests not all Node fetch traffic is broken in the environment

Expected behavior

If the embedding provider endpoint is reachable from the host (for example via curl using the same environment), memorySearch remote embedding requests should also succeed.

openclaw memory status --deep should show embeddings as available, and openclaw memory search should return normal results instead of failing at the embedding fetch stage.

Actual behavior

memorySearch remote embeddings fail with:

Embeddings: unavailable
Embeddings error: fetch failed

For example, openclaw memory status --deep reports:

  Memory Search (main)
  Provider: openai (requested: openai)
  Model: text-embedding-3-small
  Embeddings: unavailable
  Embeddings error: fetch failed

The same class of failure was also observed when Gemini was configured as the embedding provider.

Provider APIs themselves are reachable via curl, so this does not look like a simple provider outage or invalid key issue.

OpenClaw version

2026.3.13 (61d171a)

Operating system

macOS 26.3.1

Install method

No response

Model

text-embedding-3-small

Provider / routing chain

openai -> OpenClaw memorySearch remote embeddings -> guarded fetch / Node fetch -> HTTP_PROXY/HTTPS_PROXY via PM2

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response