ObsidianClaw bringt OpenClaw direkt in den Obsidian-Vault

Eine halbfertige Notiz liegt offen: Links, Gesprächsfetzen, eine Gliederung, drei unbeantwortete Fragen. Genau in diesem Moment ist ein Agent neben dem Text hilfreicher als ein weiterer Chat-Tab. ObsidianClaw bringt diese Oberfläche in den Obsidian-Vault.

Das Projekt verbindet OpenClaw mit Obsidian über eine Chat-Sidebar. Die offene Notiz bleibt sichtbar, während der Agent Kontext erhält und antwortet. Für Wissensarbeit ist das ein plausibler Ansatz: Die Frage startet bei einer konkreten Datei statt bei einem leeren Prompt.

Der Chat arbeitet an der offenen Notiz

Das Repository beschreibt eine Sidebar für Obsidian-Tabs, Streaming-Antworten, Markdown-Darstellung, Nachrichtenhistorie aus dem Gateway und „Ask about this note“. Mit diesem Befehl kann eine geöffnete Notiz als Kontext an den Agenten gehen. Außerdem nennt das Projekt Wiederverbindung und eine Geräteauthentifizierung über ein Ed25519-Schlüsselpaar.

Die Arbeitsfolge zählt. Eine Person öffnet eine Projektnotiz, übergibt sie an den Agenten und fragt nach Lücken, einer Struktur oder dem nächsten Rechercheweg. Das Material bleibt sichtbar, sodass sich die Antwort direkt gegen die Notiz prüfen lässt.

Für mich ist das der stärkste Punkt des Plugins. Es macht aus dem Vault keinen magischen Speicher. Es verkürzt den Weg zwischen vorhandenem Material und einer brauchbaren Frage.

Kontext bleibt bei der Arbeit

Viele Agenten-Setups verteilen Kontext über mehrere Fenster. Das kostet Aufmerksamkeit und erschwert es, eine Antwort später auf ihre Grundlage zurückzuführen. ObsidianClaw setzt am Ort an, an dem diese Grundlage oft schon liegt: in lokalen Markdown-Dateien.

Ein konkreter Fall: Eine Produktnotiz enthält offene Entscheidungen, Links zu Quellen und eine unfertige Gliederung. Statt Auszüge in einen separaten Chat zu kopieren, kann der Agent genau diese Datei als Ausgangspunkt erhalten. Das hilft bei Recherche und Dokumentation, solange der Vault selbst gepflegt bleibt.

Die Grenze ist klar. Veraltete Notizen, unklare Dateinamen und gemischte Entwürfe führen auch mit Sidebar zu schwachem Kontext. Das Plugin erleichtert den Zugriff; es ersetzt keine Pflege des Wissensbestands.

Der Gateway bleibt Teil des Betriebs

ObsidianClaw braucht einen laufenden OpenClaw-Gateway-Dienst und einen konfigurierten Gateway-Auth-Token. Das Projekt beschreibt für lokale Setups einen Ablauf über Obsidian-Community-Plugins, den Setup-Assistenten und einen vorhandenen Gateway. Der Vault erhält damit eine weitere Oberfläche für denselben Betrieb.

Bei Zugriff von einem anderen Gerät beginnt die eigentliche Betriebsfrage: Verbindung, Geräteautorisierung und Erreichbarkeit des Gateways müssen bewusst eingerichtet werden, weil hier lokale Netzwerkgrenzen und sensible Notizinhalte zusammentreffen. Das Repository verweist für solche Setups auf Tailscale. Welche Bindung, Freigaben und Neustart-Schritte zum eigenen OpenClaw-Setup passen, sollte die lokale Konfiguration und die aktuelle OpenClaw-Dokumentation bestimmen.¹

Ich würde vor dem produktiven Einsatz einen kleinen Test machen. Öffne eine unkritische Notiz, übergib den Kontext gezielt, prüfe die Antwort und halte fest, welches Gerät sowie welcher Gateway-Zugang beteiligt waren. Erst danach gehören sensible Projektnotizen in den Ablauf.

Für wen sich der Weg lohnt

Wer OpenClaw überwiegend per Messenger für kurze Rückfragen nutzt, braucht diese Integration nicht zwingend. Der Nutzen wächst mit einem Vault, der Arbeitsmaterial enthält und regelmäßig gepflegt wird.

ObsidianClaw steht für einen Arbeitsmodus, in dem der Agent dicht am Material bleibt und der Vault die sichtbare Ausgangsbasis der Unterhaltung ist. Die Mindestregel lautet: Erst den Gateway-Zugang und die Gerätegrenze klären, dann den Agenten an echte Notizen lassen.

Footnotes

1. https://docs.openclaw.ai/cli/config.md ↩