Claude Code Auto Memory vs Obsidian: Store Verifiable Context

For personal working preferences, Claude Code auto memory is a convenient place to start. For decisions a team needs to discuss and carry across tools, separate Markdown notes with an owner and source are more useful. Obsidian can be the editor for that store; installing it does not by itself give an agent access to the notes.

You do not need one method for every kind of information. Divide context by who is accountable for a record being correct. For example, “I prefer short answers” can stay in personal memory, while “the team is moving reports to a new service” belongs in a shared note that links to the decision. Check paths and commands already visible in current code against the repository, rather than maintaining another copy of those facts.

What is stored

Claude Code documentation describes auto memory as local project Markdown files. You can open, edit, and delete them through /memory. Worktrees in one Git repository share that memory, but it is not transferred automatically between machines. Use /context to see which memory files are loaded. A note existing on disk does not prove that its contents are in the current session.

An Obsidian vault is a folder containing notes and settings. Ordinary Markdown files remain accessible outside the app. To use them with an agent, you must specify which files it should read and grant access. This approach does not require an Obsidian plugin or an MCP server.

Question	Auto memory	Separate Markdown vault
Who suggests the entry?	Claude during work; a person reviews it	The note author or an agent given an explicit task
Who corrects a disputed fact?	The project user	The named decision owner
How do you show a colleague a change?	Share the selected entry explicitly	Share the file or an agreed Git diff
How do you move it to another machine?	Arrange the transfer separately	Arrange folder access or synchronization
Where do you look for staleness?	In saved notes	In the source and the next review date

The right column is a proposed way to organize work. Opening a folder in Obsidian does not automatically create Git history, an owner, or a review deadline.

Prepare a model connection to test memory

If you want to test both approaches in Claude Code through an API, BetterToken provides an Anthropic-compatible connection. First configure the client with the BetterToken guide for Claude Code: use your own API Key and the Base URL https://bettertoken.ai without /v1, then restart the client and get a response to a short message. That checks model access; the following steps test how the notes behave.

For a fair comparison, keep the model and task the same: ask it to read the record, change the record, then repeat the question in a new session. Changing the connection will then not be another experimental variable. BetterToken handles API calls, while auto memory and the vault remain managed by your tool. Text an agent reads may be included in the model request, so use a non-secret practice note and do not store an API Key in the vault.

Configure Claude Code through BetterToken and test one note, then continue with the example.

Give each fact one primary home

Start with one non-secret note. In this practice example, a team is discussing an export format; names and values are fictional. Save 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.

This record distinguishes a proposal from a binding requirement. In a real project, name an available source: a task, meeting notes, or a decision document. Until confirmation exists, the agent should preserve that uncertainty.

In a new session, give it a specific task:

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.

The expected result is: CSV is proposed, production approval is absent, and a decision source is needed. That is a test criterion, not a promise that a model will answer correctly. If the agent says that CSV should be implemented, check which file it read and cited. A duplicate note, an old conversation, or a mistaken reading of the status may be responsible.

Test an update and deletion

Change the practice note: the format is now JSONL and the status remains proposed. Start a new session and repeat the question. The agent should name JSONL and retain the same limitation. If it returns CSV, do not add another conflicting rule; find the source of the old value.

Then delete the practice note with an ordinary file manager. In another new session, ask where the confirmed format decision is stored. If no other source exists, a useful result is an answer that the evidence is insufficient. An answer with the old value means another copy or source remains; check /memory, project files, and instructions.

Deleting a note does not automatically remove it from Git history, backups, synchronized devices, or an already open conversation. This test examines a new session’s behavior, not complete data erasure. Do not include API keys, passwords, or personal data in the exercise.

Match the method to the cost of error

If you work alone and memory mostly holds preferences, keep auto memory and review entries after substantial project changes. When a team action depends on a fact, move its primary version to a controlled document. Auto memory can point to the current source instead of copying the decision itself.

When needed, you can turn off auto memory through /memory; the official autoMemoryEnabled setting controls the feature. Turning it off does not replace checking existing files or context that is already loaded.

For a team vault, assign an owner to important records and define a review event: an API change, a cancelled project, or a completed migration. A date helps uncover forgotten notes, but it does not create an automatic expiry date. If you use Git, review the exact files before a commit; do not add the entire folder along with personal settings and attachments.

Begin with one decision and three questions in new sessions: what is known, what changed, and what is no longer confirmed? If the answers cite current files and preserve uncertainty, the chosen storage method is serving its purpose. If not, first correct the source and reading order; changing the editor alone will not resolve contradictions.