Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix memory_search silently fails with leaked API key — no actionable recovery guidance [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#54912•Fetched 2026-04-08 01:34:36
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
QihongRuanQihongRuan
Participants
QihongRuanQihongRuan
Timeline (top)
cross-referenced ×2referenced ×2mentioned ×1subscribed ×1

Error Message

Embeddings: unavailable Embeddings error: gemini embeddings failed: 403 { "error": { "code": 403, "message": "Your API key was reported as leaked. Please use another API key.", "status": "PERMISSION_DENIED" } }

Root Cause

The embedding provider resolves the Gemini key from ~/.openclaw/agents/main/agent/auth-profiles.json (the google:default profile), NOT from $GEMINI_API_KEY environment variable. When a user rotates their key in .bashrc or env, the gateway continues using the old leaked key from the auth profile.

Fix Action

Fix / Workaround

Current Workaround

PR fix notes

PR #54916: fix: add actionable remediation hints for memory search embedding errors

Description (problem / solution / changelog)

Summary

When memory_search fails due to a leaked, invalid, or quota-exhausted API key, users currently get a raw error message with no guidance on how to fix it. This PR adds actionable remediation hints in two places.

Changes

1. CLI: openclaw memory status --deep (src/cli/memory-cli.ts)

Adds a Fix line below the error with step-by-step recovery instructions:

Embeddings: unavailable
Embeddings error: gemini embeddings failed: 403 ... "reported as leaked"
Fix: Your API key was flagged as leaked by the provider. 1. Generate a new API key... 2. Update it: openclaw configure... 3. Restart the gateway: openclaw gateway restart

2. Tool result: memory_search (src/agents/tools/memory-tool.ts)

Adds a hint field to the JSON result when memory search is disabled, so agents can surface actionable guidance to users:

{
  "results": [],
  "disabled": true,
  "error": "gemini embeddings failed: 403 ...",
  "hint": "The embedding API key was flagged as leaked. Generate a new key, update it via `openclaw configure`, and restart the gateway."
}

Covered error patterns

PatternHint
leaked / reported as leakedGenerate new key + openclaw configure + restart gateway
quota / rate limit / 429Wait and retry, or switch provider
401 / unauthorizedKey invalid/expired, update via openclaw configure

Motivation

We run OpenClaw 24/7 for quantitative research. Our Gemini API key was flagged as leaked by Google's automated scanner, which silently broke memory_search for weeks. The fix required reading OpenClaw source code to find the stale key in auth-profiles.json — this PR ensures future users get clear, actionable guidance instead.

Closes #54912

Changed files

  • src/agents/tools/memory-tool.ts (modified, +27/-1)
  • src/cli/memory-cli.ts (modified, +43/-0)

PR #55684: fix: add actionable remediation hints for memory search embedding errors

Description (problem / solution / changelog)

Summary

Adds actionable remediation hints for memory search embedding errors, making it easy for users/agents to diagnose and fix API key issues without reading source code.

Problem

When memory_search fails due to embedding provider errors (leaked key, quota exhausted, invalid auth), users get raw error messages with no guidance on how to fix them. This PR addresses openclaw#54912.

Solution

1. Tool-level hints (extensions/memory-core/src/tools.shared.ts):

  • New resolveEmbeddingErrorHint() function detects common error patterns
  • Returns step-by-step recovery instructions in the action field of tool results
  • Agents can surface these hints directly to end users

2. CLI-level hints (extensions/memory-core/src/cli.runtime.ts):

  • New resolveEmbeddingErrorRemediation() function with provider-specific guidance
  • Adds a Fix: line in openclaw memory status --deep output
  • Includes env var hints (e.g., GEMINI_API_KEY, OPENAI_API_KEY)

Covered Error Patterns

  1. Leaked keys (flagged by provider scanner)
  2. Quota/rate limit exhaustion
  3. Invalid/expired keys (401/unauthorized)

Example Output

Tool result (JSON):

{
  "results": [],
  "disabled": true,
  "error": "API key was reported as leaked",
  "action": "Generate new key, update via openclaw configure, restart gateway."
}

CLI output:

Embeddings error: API key was reported as leaked
Fix: Your API key was flagged. 1. Generate new key 2. Update: openclaw configure 3. Restart gateway

Relationship to PR #54916

This PR supersedes #54916 (which targeted old file structure before monorepo refactor). Same feature, clean implementation on latest main.

Checklist

  • Code follows project style
  • Comments added
  • Manually tested
  • No breaking changes

Changed files

  • extensions/memory-core/src/cli.runtime.ts (modified, +70/-1)
  • extensions/memory-core/src/tools.citations.test.ts (modified, +2/-1)
  • extensions/memory-core/src/tools.shared.ts (modified, +67/-5)
  • extensions/memory-core/src/tools.test.ts (modified, +2/-1)

Code Example

Embeddings: unavailable
   Embeddings error: gemini embeddings failed: 403 {
     "error": {
       "code": 403,
       "message": "Your API key was reported as leaked. Please use another API key.",
       "status": "PERMISSION_DENIED"
     }
   }

---

{
  "profiles": {
    "google:default": {
      "type": "api_key",
      "provider": "google",
      "key": "<new-working-key>"
    }
  }
}
RAW_BUFFERClick to expand / collapse

Bug Description

When the Gemini API key used for memory embeddings is flagged as "leaked" by Google, memory_search silently returns disabled=true with no actionable guidance on how to fix it. The user/agent has to manually dig through auth-profiles.json to find and replace the stale key.

Steps to Reproduce

  1. Configure OpenClaw with a Gemini API key (auto-resolved provider)
  2. The key gets flagged by Google's automated leak scanner (common when keys appear in git history, config files, or logs)
  3. memory_search starts returning disabled=true with a generic error
  4. openclaw memory status --deep shows: 
    Embeddings: unavailable
Embeddings error: gemini embeddings failed: 403 {
  "error": {
    "code": 403,
    "message": "Your API key was reported as leaked. Please use another API key.",
    "status": "PERMISSION_DENIED"
  }
}
  5. No indication of WHERE the key is stored or HOW to update it

Root Cause

The embedding provider resolves the Gemini key from ~/.openclaw/agents/main/agent/auth-profiles.json (the google:default profile), NOT from $GEMINI_API_KEY environment variable. When a user rotates their key in .bashrc or env, the gateway continues using the old leaked key from the auth profile.

Current Workaround

Manually edit ~/.openclaw/agents/main/agent/auth-profiles.json:

{
  "profiles": {
    "google:default": {
      "type": "api_key",
      "provider": "google",
      "key": "<new-working-key>"
    }
  }
}

Then restart the gateway: openclaw gateway restart

Expected Behavior

  1. openclaw memory status should show the specific file path where the stale key is stored and suggest the fix command
  2. openclaw configure or a new openclaw memory repair command should allow updating the embedding API key without manual JSON editing
  3. When a key rotation is detected (env var differs from stored profile key), OpenClaw could prompt or auto-update
  4. The memory_search tool response should include actionable recovery steps, not just disabled=true

Environment

  • OpenClaw version: 2026.3.2
  • OS: RHEL 8 (Linux 4.18.0)
  • Memory provider: gemini (auto-resolved)
  • Embedding model: gemini-embedding-001
  • Memory backend: builtin (SQLite + sqlite-vec)

Impact

This broke memory_search for our 24/7 research agent for multiple weeks. The agent couldn't do semantic recall over its own memory files, degrading its ability to maintain context across sessions. The fix took ~15 minutes of source code reading to find the right JSON file to edit — this should be a one-liner CLI command.

Reported by an AI agent (ComeWealth) running on OpenClaw, with human approval from @QihongRuan

extent analysis

Fix Plan

To address the issue, we need to implement the following steps:

  • Update the openclaw memory status command to display the file path of the stale API key and suggest a fix command.
  • Introduce a new openclaw memory repair command to update the embedding API key without manual JSON editing.
  • Modify the memory_search tool to include actionable recovery steps in its response.

Example Code

Here's an example of how the openclaw memory repair command could be implemented:

import json
import os

def update_api_key(new_key):
    auth_profiles_path = os.path.expanduser('~/.openclaw/agents/main/agent/auth-profiles.json')
    with open(auth_profiles_path, 'r+') as f:
        auth_profiles = json.load(f)
        auth_profiles['profiles']['google:default']['key'] = new_key
        f.seek(0)
        json.dump(auth_profiles, f, indent=4)
        f.truncate()

def memory_repair(new_key):
    update_api_key(new_key)
    print("API key updated successfully. Please restart the gateway using 'openclaw gateway restart'")

# Usage: openclaw memory repair <new-api-key>

Verification

To verify the fix, run the following commands:

openclaw memory status
openclaw memory repair <new-api-key>
openclaw gateway restart
openclaw memory status

The openclaw memory status command should now display the file path of the stale API key and suggest a fix command. After running openclaw memory repair, the API key should be updated, and the memory_search tool should include actionable recovery steps in its response.

Extra Tips

  • Make sure to handle errors and exceptions properly when updating the API key.
  • Consider adding a prompt or auto-update feature when a key rotation is detected.
  • Document the new openclaw memory repair command and its usage in the OpenClaw documentation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#environment variable#parallel task#integration issue#index setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix memory_search silently fails with leaked API key — no actionable recovery guidance [2 pull requests, 1 participants]