Claude Code auto memory oder Obsidian: prüfbarer Kontext

Für persönliche Vorlieben ist auto memory von Claude Code ein guter Anfang. Für Entscheidungen, die ein Team zwischen Werkzeugen besprechen und übertragen muss, sind getrennte Markdown-Notizen mit Verantwortlichen und Quelle sinnvoller. Obsidian kann ein Editor für diese Sammlung sein; durch die Installation werden Notizen nicht automatisch mit dem Agenten verbunden.

Sie müssen nicht für alle Informationen dieselbe Methode wählen. Teilen Sie den Kontext danach auf, wer für die Richtigkeit des Eintrags verantwortlich ist. Eine persönliche Präferenz kann im Speicher bleiben; eine Teamentscheidung zur Migration gehört in eine gemeinsame Notiz mit Verweis auf die Entscheidung. Prüfen Sie Pfade und Befehle, die bereits im aktuellen Repository-Code stehen, statt eine zusätzliche Faktenkopie zu pflegen.

Was tatsächlich gespeichert wird

Die Claude-Code-Dokumentation beschreibt auto memory als lokale Markdown-Dateien des Projekts. Sie lassen sich über /memory öffnen, bearbeiten und löschen. Worktrees desselben Git-Repositorys teilen den Speicher, er wird aber nicht automatisch zwischen Maschinen übertragen. Mit /context prüfen Sie die geladenen memory files. Eine Notiz auf der Festplatte beweist nicht, dass ihr Inhalt in der aktuellen Sitzung angekommen ist.

Ein Obsidian-Vault ist ein Ordner mit Notizen und Einstellungen. Normale Markdown-Dateien bleiben außerhalb der Anwendung verfügbar. Damit der Agent sie verwendet, geben Sie die zu lesenden Dateien an und erlauben den Zugriff. Dieser Ansatz benötigt weder ein Obsidian-Plugin noch einen MCP-Server.

Frage	Auto memory	Separates Markdown-Vault
Wer schlägt den Eintrag vor?	Claude bei der Arbeit; ein Mensch prüft	Notizautor oder ausdrücklich beauftragter Agent
Wer korrigiert einen strittigen Fakt?	Projektnutzer	Benannter Entscheidungsverantwortlicher
Wie zeigt man eine Änderung?	Gewählten Eintrag weitergeben	Datei oder abgestimmten Git diff teilen
Wie erfolgt der Umzug auf eine Maschine?	Transfer gesondert organisieren	Ordnerzugriff oder Synchronisierung organisieren
Wo sucht man nach Veraltung?	In gespeicherten Notizen	In Quelle und nächstem Prüftermin

Die rechte Spalte beschreibt eine vorgeschlagene Arbeitsorganisation. Das Öffnen eines Ordners in Obsidian erzeugt nicht automatisch Git, Verantwortung oder Prüffrist.

Modellverbindung für den Gedächtnistest vorbereiten

Wenn Sie beide Wege in Claude Code über die API testen wollen, bietet BetterToken eine Anthropic-kompatible Verbindung. Richten Sie den Client nach dem BetterToken-Leitfaden für Claude Code ein: Verwenden Sie Ihren eigenen API Key und die Base URL https://bettertoken.ai ohne /v1, starten Sie den Client neu und erhalten Sie eine Antwort auf eine kurze Nachricht. Damit testen Sie den Modellzugriff; die folgenden Schritte testen die Arbeit mit Notizen.

Behalten Sie dieselbe model und dieselbe Aufgabe: Lassen Sie erst den Eintrag lesen, ändern Sie ihn, und wiederholen Sie die Frage in einer neuen Sitzung. Die Verbindungsänderung wird dadurch keine weitere Versuchsvariable. BetterToken stellt API-Aufrufe bereit; auto memory und Vault werden weiter auf Ihrer Werkzeugseite verwaltet. Vom Agenten gelesene Auszüge können in die Modellanfrage gelangen. Verwenden Sie daher eine nicht geheime Übungsnotiz und speichern Sie keinen API Key im Vault.

Richten Sie Claude Code über BetterToken ein und testen Sie eine Notiz, bevor Sie zum Beispiel gehen.

Geben Sie jedem Fakt einen Hauptort

Beginnen Sie mit einer nicht geheimen Notiz. Im Beispiel bespricht das Team ein Exportformat; Werte und Namen sind erfunden. Speichern Sie decisions/report-export.md:

# Report export decision

Status: proposed
Owner: reporting-team
Verified: 2026-09-08
Review-by: 2026-09-22
Source: team decision record to be attached

The proposed export format is CSV.
This is not an approved production requirement.
Before implementation, ask the owner for the approved decision.

Die Notiz trennt einen Vorschlag von einer verbindlichen Anforderung. Geben Sie im echten Projekt eine verfügbare Quelle an: Aufgabe, Protokoll oder Entscheidungsdokument. Solange die Bestätigung fehlt, muss der Agent die Unsicherheit erhalten.

Senden Sie in einer neuen Sitzung diese konkrete Aufgabe:

Read decisions/report-export.md.
What export format is proposed, and is it approved for production?
Cite the file and identify the missing evidence.
Do not change code or infer approval from the proposal.

Das erwartete Ergebnis lautet: CSV ist vorgeschlagen, eine Produktionsfreigabe fehlt, und die Entscheidungsquelle wird benötigt. Das ist ein Prüfmaßstab, keine Zusage für die korrekte Modellantwort. Wenn der Agent CSV implementieren will, sehen Sie nach, welche Datei er las und zitierte; eine doppelte Notiz, ein alter Dialog oder ein falsch verstandener Status kommen infrage.

Aktualisierung und Löschung prüfen

Ändern Sie die Übungsnotiz: Das Format ist nun JSONL, der Status bleibt proposed. Starten Sie eine neue Sitzung und wiederholen Sie die Frage. Der Agent muss JSONL und dieselbe Einschränkung nennen. Antwortet er CSV, fügen Sie keine widersprüchliche Regel hinzu; finden Sie die Quelle des alten Werts.

Löschen Sie anschließend die Notiz im Dateimanager und fragen Sie in einer weiteren Sitzung, wo die bestätigte Entscheidung liegt. Fehlt eine andere Quelle, ist der Hinweis auf unzureichende Daten nützlich. Eine alte Antwort bedeutet, dass es eine weitere Kopie oder Quelle gibt; prüfen Sie /memory, Projektdateien und Anweisungen.

Das Löschen einer Notiz entfernt sie nicht automatisch aus Git history, Sicherungen, synchronisierten Geräten oder einem bereits offenen Gespräch. Dieser Test prüft die neue Sitzung, nicht vollständige Datenlöschung. Nehmen Sie keine API keys, Passwörter oder personenbezogenen Daten in die Übung auf.

Den Modus am Fehlerpreis ausrichten

Wenn Sie allein arbeiten und der Speicher vor allem Präferenzen enthält, behalten Sie auto memory und prüfen Sie Einträge nach wichtigen Projektänderungen. Hängt eine Teamaktion von einem Fakt ab, verschieben Sie dessen Hauptversion in ein kontrolliertes Dokument. In auto memory kann ein Hinweis auf die aktuelle Quelle stehen, ohne die Entscheidung zu kopieren.

Bei Bedarf lässt sich auto memory über /memory deaktivieren; der offizielle Parameter autoMemoryEnabled steuert die Funktion. Das Abschalten ersetzt nicht die Prüfung vorhandener Dateien und bereits geladenen Kontexts.

Weisen Sie in einem Team-Vault wichtigen Einträgen einen Verantwortlichen und ein Prüfevent zu: API-Änderung, Projektabbruch oder abgeschlossene Migration. Ein Datum hilft, vergessene Notizen zu finden, schafft aber keine automatische Gültigkeit. Prüfen Sie mit Git die genauen Dateien vor dem commit; fügen Sie nicht den ganzen Ordner mit persönlichen Einstellungen und Anhängen hinzu.

Beginnen Sie mit einer Entscheidung und drei Fragen in neuen Sitzungen: Was ist bekannt, was hat sich geändert und was ist nicht mehr bestätigt? Wenn die Antworten aktuelle Dateien zitieren und Unsicherheit bewahren, erfüllt die Methode ihren Zweck. Andernfalls korrigieren Sie zuerst Quelle und Lesereihenfolge; ein anderer Editor allein beseitigt keine Widersprüche.