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