openclaw - 💡(How to fix) Fix [Bug]: memory_search with Gemini embeddings does not honor HTTP(S) proxy in 2026.3.23-2 [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

On OpenClaw 2026.3.23-2, Gemini-based memory embeddings fail behind a normal HTTP/HTTPS proxy, even though direct Gemini embedding requests succeed on the same machine.

This affects both:

• in-app memory_search
• openclaw memory status/search/index

The failure shows up as:

{ "results": [], "disabled": true, "unavailable": true, "error": "fetch failed", "warning": "Memory search is unavailable due to an embedding/provider error.", "action": "Check embedding provider configuration and retry memory_search." }

Steps to reproduce

1. Configure Gemini memory embeddings under agents.defaults.memorySearch
2. Run OpenClaw behind a standard outbound proxy
3. Run either:

openclaw memory status --agent main --deep --index

or:

openclaw memory search --agent main "test"

or trigger memory_search inside the app.

Expected behavior

Memory indexing and search should work normally through the configured proxy, just like other outbound HTTP paths.

Actual behavior

Memory embeddings fail with fetch failed.

Typical CLI output:

Embeddings: unavailable Embeddings error: fetch failed

App/tool output:

{ "results": [], "disabled": true, "unavailable": true, "error": "fetch failed" }

OpenClaw version

2026.3.23-2

Operating system

Ubuntu 24.04

Install method

No response

Model

gemini/gemini-embedding-001

Provider / routing chain

openclaw -> local proxies -> gemini

Additional provider/model setup details

Important debugging result

Direct Gemini embedding requests succeed on the same machine, with the same API key, through the same proxy.

Both of these work:

• embedContent
• batchEmbedContents

So this does not appear to be:

• a bad Gemini API key
• a Gemini endpoint outage
• a malformed embedding payload
• invalid memory file contents

It looks specific to the OpenClaw memory embedding HTTP path.

———

Suspected root cause

In 2026.3.23-2, the memory embedding path still appears to use a strict guarded fetch path for remote memory HTTP calls.

Relevant bundle section:

[dist/pi-embedded-CbCYZxIb.js]

async function withRemoteHttpResponse(params) { const { response, release } = await fetchWithSsrFGuard({ url: params.url, init: params.init, policy: params.ssrfPolicy, auditContext: params.auditContext ?? "memory-remote" }); try { return await params.onResponse(response); } finally { await release(); } }

From local testing, changing this memory path to use the env-proxy-aware guarded fetch helper fixes the issue.

For example, switching to:

fetchWithSsrFGuard(withTrustedEnvProxyGuardedFetchMode(...))

restores successful memory indexing and memory_search behind proxy.

So the issue seems to be that memory remote embedding requests do not honor env-proxy handling consistently, even though other OpenClaw network paths already do.

———

Suggested fix

Please make the memory remote embedding HTTP path proxy-aware in the same way as other OpenClaw outbound HTTP paths.

It should honor:

• HTTP_PROXY
• HTTPS_PROXY
• ALL_PROXY
• NO_PROXY
• NODE_USE_ENV_PROXY

or reuse the existing env-proxy-aware guarded fetch mode already used elsewhere in the codebase.

———

Temporary workaround

A local patch to the memory remote HTTP helper fixes the issue.

After patching the memory fetch path to use the env-proxy-aware guarded fetch helper and restarting the gateway:

• openclaw memory status --agent main --deep shows Embeddings: ready
• openclaw memory search ... returns normal results
• in-app memory_search works again

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response