CLI Memory-Befehle stürzen mit 'Unknown memory embedding provider: ollama' ab

Beim Ausführen eines beliebigen CLI-Memory-Befehls mit dem konfigurierten ollama-Provider wird der Befehl sofort mit einem JavaScript-Fehler beendet.

Fehlerausgabe

$ openclaw memory status
Error: Unknown memory embedding provider: ollama
    at getAdapter (manager-FzeN0TEi.js:341:22)
    at createEmbeddingProvider (manager-FzeN0TEi.js:393:25)
    at MemoryIndexManager.loadProviderResult (manager-FzeN0TEi.js:2759:16)

$ openclaw memory backup
Error: Unknown memory embedding provider: ollama
    at getAdapter (manager-FzeN0TEi.js:341:22)
    at createEmbeddingProvider (manager-FzeN0TEi.js:393:25)
    at MemoryIndexManager.loadProviderResult (manager-FzeN0TEi.js:2759:16)

$ openclaw memory rebuild
Error: Unknown memory embedding provider: ollama
    at getAdapter (manager-FzeN0TEi.js:341:22)
    at createEmbeddingProvider (manager-FzeN0TEi.js:393:25)
    at MemoryIndexManager.loadProviderResult (manager-FzeN0TEi.js:2759:16)

Betroffene Befehle

• openclaw memory status
• openclaw memory backup
• openclaw memory rebuild

Funktionierender Code-Pfad (Gateway)

Der Gateway-Runtime verarbeitet Memory-Suchen korrekt, da die Plugin-Initialisierung vor der Initialisierung des Memory-Systems erfolgt:

# Gateway memory_search funktioniert einwandfrei
$ openclaw gateway memory_search "test query"
[Returns results using ollama embeddings]

Konfiguration, die den Bug auslöst

# ~/.openclaw/config.yaml
agents:
  defaults:
    memorySearch:
      provider: "ollama"
      model: "snowflake-arctic-embed2"
      remote:
        baseUrl: "http://192.168.1.100:11434"
      fallback: "none"

Architektonische Abweichung: Plugin-Registrierung vs. CLI-Code-Pfade

Das Memory-Embedding-Provider-System verfügt über zwei Registrierungsmechanismen mit inkompatiblen Initialisierungssequenzen.

Mechanismus 1: Plugin-basierte Registrierung (Gateway-bereit)

Das ollama-Plugin registriert seinen Embedding-Provider zur Laufzeit über die Plugin-API:

// extensions/ollama/index.js
api.registerMemoryEmbeddingProvider(ollamaMemoryEmbeddingProviderAdapter);

Diese Registrierung erfolgt während der Plugin-Initialisierungsphase, die im Gateway-Runtime vor der vollständigen Initialisierung des Memory-Systems ausgeführt wird.

Mechanismus 2: Hardcodierte Builtin-Registrierung (nur CLI)

CLI-Memory-Befehle rufen registerBuiltInMemoryEmbeddingProviders() auf, was ein hardcodiertes Array befüllt:

// manager-FzeN0TEi.js (kompiliertes Bundle)
const builtinMemoryEmbeddingProviderAdapters = [
  'local',
  'openai',
  'gemini',
  'voyage',
  'mistral'
];

function registerBuiltInMemoryEmbeddingProviders() {
  for (const adapter of builtinMemoryEmbeddingProviderAdapters) {
    // Registriert jeden Adapter mit seinen zugehörigen Metadaten
  }
}

Die Fehlersequenz

1. Benutzer ruft openclaw memory status auf
2. CLI initialisiert eine MemoryIndexManager-Instanz
3. MemoryIndexManager.loadProviderResult() wird mit dem konfigurierten Provider ("ollama") aufgerufen
4. createEmbeddingProvider() ruft getAdapter() auf
5. getAdapter() prüft das interne Registry nach "ollama"
6. Da CLI nie Plugins geladen hat, ist "ollama" nicht im Registry
7. Fehler wird ausgelöst: "Unknown memory embedding provider: ollama"

Warum Gateway funktioniert

Der Gateway-Runtime lädt und initialisiert alle aktivierten Plugins explizit, bevor ein Subsystem initialisiert wird:

// Gateway-Initialisierungssequenz (vereinfacht)
await pluginManager.loadPlugins();           // Lädt extensions/ollama/index.js
await pluginManager.initializePlugins();     // Ruft api.registerMemoryEmbeddingProvider() auf
await memoryManager.initialize();            // Hat jetzt ollama im Registry

Breitere Auswirkungen

Dem builtinMemoryEmbeddingProviderAdapters-Array fehlen mehrere dokumentierte Provider:

• ollama - Erstanbieter-gebündelte Erweiterung (dieser Bug)
• lmstudio - Als gültig dokumentiert im Runtime-Schema
• bedrock - Als gültig dokumentiert im Runtime-Schema

Alle diese würden identisches Absturzverhalten zeigen, wenn sie als CLI-Memory-Provider konfiguriert sind.

Datenschutz-/Sicherheits-Nebeneffekt

Bei Verwendung von provider: “auto” als Workaround ist die Auto-Select-Prioritätskette:

local(10) → openai(20) → gemini(30) → voyage(40) → mistral(50)

Da ollama keine autoSelectPriority definiert hat, wird es niemals durch Auto-Select ausgewählt. Benutzer, die lokale/self-hosted Embeddings suchen, könnten versehentlich Memory-Daten an OpenAI-Server übertragen.

Empfohlene Lösung: Ollama zu Builtin-Providers hinzufügen

Ändern Sie das builtinMemoryEmbeddingProviderAdapters-Array im Manager-Bundle, um ollama einzuschließen.

Vorher

// manager-FzeN0TEi.js (Zeile ~XXX)
const builtinMemoryEmbeddingProviderAdapters = [
  'local',
  'openai',
  'gemini',
  'voyage',
  'mistral'
];

Nachher

// manager-FzeN0TEi.js (Zeile ~XXX)
const builtinMemoryEmbeddingProviderAdapters = [
  'local',
  'openai',
  'gemini',
  'voyage',
  'mistral',
  'ollama'
];

Implementierungsschritte

1. Finden Sie die builtinMemoryEmbeddingProviderAdapters-Definition in der Quell-Manager-Datei (nicht im kompilierten Bundle)
2. Fügen Sie 'ollama' als letztes Element im Array hinzu
3. Erstellen Sie das Anwendungs-Bundle neu
4. Alternativ: Reichen Sie einen Pull-Request im OpenClaw-Repository ein

Alternative Lösung: Plugins in CLI-Memory-Befehlen laden

Wenn die bevorzugte Lösung darin besteht, Feature-Parität zwischen CLI und Gateway aufrechtzuerhalten:

// In CLI-Memory-Befehlsinitialisierung (Pseudo-Code)
async function initializeMemoryCommands() {
  // Plugins laden, bevor das Memory-System initialisiert wird
  await pluginManager.loadPlugins();
  await pluginManager.initializePlugins();
  
  // Jetzt sind ollama (und andere Plugin-Provider) registriert
  registerBuiltInMemoryEmbeddingProviders();
  
  // Mit dem Befehls-Setup fortfahren
}

Temporärer Workaround (nicht für Produktion empfohlen)

Ändern Sie den Provider zu einem der Builtin-Provider:

# ~/.openclaw/config.yaml
agents:
  defaults:
    memorySearch:
      provider: "local"  # Verwenden Sie local statt ollama
      # Oder verwenden Sie "openai", wenn Sie einen API-Key haben
      # Oder verwenden Sie "auto" (beachten Sie jedoch die Datenschutzimplikationen)

Nachdem Sie die Lösung angewendet haben, verifizieren Sie dies durch Ausführung der betroffenen CLI-Befehle.

Testbefehle

# Test 1: Memory-Status-Befehl
$ openclaw memory status
✓ Connected to memory index
✓ Provider: ollama
✓ Model: snowflake-arctic-embed2
✓ Endpoint: http://192.168.1.100:11434
✓ Status: Ready

# Test 2: Memory-Backup-Befehl
$ openclaw memory backup --output ./memory-backup.json
✓ Backup completed successfully
✓ Records: 1,247 entries
✓ File: ./memory-backup.json

# Test 3: Memory-Rebuild-Befehl
$ openclaw memory rebuild --provider ollama
✓ Rebuild initiated
✓ Processing embeddings...
✓ Complete: 1,247 records re-embedded

Erwartete Exit-Codes

Alle Befehle sollten bei Erfolg mit dem Code 0 beendet werden.

Integrationstest: CLI vs Gateway-Parität

Verifizieren Sie, dass beide Code-Pfade identische Ergebnisse liefern:

# Dieselbe Abfrage über CLI ausführen
$ openclaw memory search "meeting notes from last week" --limit 5
[
  {
    "id": "mem_abc123",
    "content": "Quarterly planning meeting...",
    "score": 0.94
  }
]

# Dieselbe Abfrage über Gateway ausführen
$ openclaw gateway memory_search "meeting notes from last week"
[
  {
    "id": "mem_abc123",
    "content": "Quarterly planning meeting...",
    "score": 0.94
  }
]

# Ergebnisse sollten übereinstimmen

Test mit allen zuvor betroffenen Providern

Verifizieren Sie, dass andere Plugin-basierte Provider (lmstudio, bedrock) ebenfalls behoben würden, wenn sie hinzugefügt wurden:

# Wenn lmstudio zu Builtin-Providern hinzugefügt wurde
$ openclaw memory status --provider lmstudio
✓ Provider: lmstudio
✓ Model: your-configured-model
✓ Status: Ready

Umgebungsspezifische Fallen

• Apple Silicon (macOS arm64): Ollama auf Apple Silicon kann für bestimmte Modelle Rosetta 2 erfordern. Stellen Sie sicher, dass ollama serve läuft, bevor Sie Memory-Befehle ausführen.
• Docker-Umgebungen: Wenn OpenClaw in Docker läuft, stellen Sie sicher, dass der Ollama-Endpunkt aus dem Container-Netzwerk erreichbar ist. Verwenden Sie --network=host oder konfigurieren Sie eine ordnungsgemäße Netzwerkverbindung.
• Tailscale/Remote-Endpunkte: Wenn Sie Tailnet-IPs verwenden, verifizieren Sie, dass der Tailscale-Daemon läuft und das Subnetz beworben wird.

Konfigurationsfallen

• Endpunkt-URL-Format: Die Base-URL muss den Port enthalten. Falsch: http://192.168.1.100/ollama, Richtig: http://192.168.1.100:11434
• Modellnamensabweichung: Stellen Sie sicher, dass der Modellname genau einem in Ollama verfügbaren Modell entspricht. Führen Sie ollama list aus, um dies zu verifizieren.
• Fallback-Konfiguration: Die Einstellung fallback: "none" führt zu sofortigem Fehlschlag, wenn Ollama nicht erreichbar ist. Erwägen Sie fallback: "local" für Ausfallsicherheit.

Datenschutzimplikationen des “auto”-Workarounds

# FALSCH: Auto-Select als Workaround verwenden
agents:
  defaults:
    memorySearch:
      provider: "auto"  # ⚠️ Sendet Daten an OpenAI!

# RICHTIG: Explizit lokalen Provider angeben
agents:
  defaults:
    memorySearch:
      provider: "ollama"  # ✓ Bleibt lokal

Missverständnis: Plugin vs Builtin-Unterscheidung

Viele Benutzer sind sich nicht bewusst, dass Provider in zwei Kategorien fallen:

• Builtin-Provider: Im Manager hardcodiert, immer verfügbar
• Plugin-Provider: Von Plugins zur Laufzeit registriert

Dieser Unterschied ist nicht dokumentiert, was zu Verwirrung führt, wenn CLI-Befehle fehlschlagen.

Versionskompatibilität

Der Bug betrifft Version 2026.4.12. Wenn Sie von einer früheren Version aktualisieren, verifizieren Sie, dass das ollama-Plugin mit dem neuen Manager-Bundle kompatibel ist.

Direkt zugehörige Fehler

• Unknown memory embedding provider: lmstudio — Derselbe Bug betrifft den lmstudio-Provider (auch Plugin-registriert)
• Unknown memory embedding provider: bedrock — Derselbe Bug betrifft den bedrock-Provider (auch Plugin-registriert)
• Unknown memory embedding provider: [any plugin-registered provider] — Generalisierung dieses Bugs

Kontextuell zugehörige Fehler

• Plugin initialization failed: ollama — Tritt auf, wenn das ollama-Plugin nicht geladen werden kann, was diesen Fehler in einigen Szenarien verdecken kann
• ECONNREFUSED — Netzwerkfehler, wenn der Ollama-Endpunkt nicht erreichbar ist; unterscheidet sich vom Provider-Registrierungsfehler
• Model not found: [model-name] — Ollama-Server hat das angeforderte Modell nicht; anderer Fehlerpfad

Historischer Kontext

• 2026.3.x: Plugin-System für Erweiterungen eingeführt, einschließlich ollama-Provider
• 2026.4.x: CLI-Memory-Befehle in separaten Einstiegspunkt extrahiert, der die Plugin-Initialisierung umgeht
• 2026.4.12: Aktuelle Version mit dem Divergenz-Bug (dieses Problem)

Ähnliche Muster in der Codebasis

Dasselbe architektonische Muster (Builtin vs. Plugin-Registrierung) existiert in:

• Memory-Retrieval-Providern
• LLM-Providern
• Tool-Adaptern

Diese können ähnliche CLI-vs-Gateway-Inkonsistenzen aufweisen.