Setup: Windows 11 host running WSL2. Currently keep an Obsidian vault as a git repo inside the WSL filesystem (e.g. /home/user/projects/vault-name), synced to a private GitHub repo for backup.
Problem: I use two tools that need to touch the same vault files, but they live on opposite sides of the WSL/Windows boundary:
Obsidian — Windows desktop app. Can’t natively open a WSL ext4 path; it doesn’t reliably watch/edit files over the \wsl.localhost… UNC route (known flakiness — missed file-change events, occasional lock/corruption complaints from other users).
Claude Code — CLI tool I run inside WSL for editing/automating the vault. Needs a real filesystem path it can read/write directly.
I want one vault location that both tools treat as a normal local folder — not a synced copy, not a network path — while still keeping git-based backup to GitHub, and ideally also mirroring to Google Drive for redundancy.
Constraint I’m trying to avoid: cloning the GitHub repo separately on the Windows side (D:…\Obsidian\vault-name) just for Obsidian, because then Claude Code in WSL is working on a different physical copy — sync/merge overhead, and no reason to maintain two working trees of the same repo.
Candidate solution I’m evaluating: move the vault onto the Windows filesystem itself (e.g. D:\Users\name\Documents\Obsidian\vault-name), have Obsidian open it natively there, and have WSL/Claude Code access the same files through the /mnt/d/… mount instead of a separate WSL-side copy. Git operations and Google Drive Desktop sync would then both operate on that one Windows-resident folder.
Open questions:
Known tradeoff: WSL2 accessing the Windows filesystem via /mnt/d/… goes through the 9p protocol, which is measurably slower than native WSL ext4 — especially for operations that touch many small files (git status/diff across a repo, file-watcher-heavy tools). Windows Defender’s real-time scanner adds further overhead on that path unless the folder is excluded. Given Claude Code will be doing repeated reads/writes/git operations against the vault, how bad is this in practice for a folder of this scale (few hundred markdown files, not huge)? Is it a non-issue at this size, or does it get painful enough that I should exclude the folder from Defender / tune something to make it usable?
Anyone running Obsidian + a WSL-based CLI tool against a shared vault successfully with a different architecture (e.g. actually making the \wsl.localhost route work reliably, or something like Syncthing instead of a shared mount)?
Any gotchas combining git-based GitHub backup and Google Drive Desktop sync pointed at the same folder simultaneously (e.g. Drive syncing .git internals, conflict duplication)?
An alternative is to skip WSL entirely. I’m running Free Claude Code (FCC) and Hermes Agent on Windows 11 using Git Bash, with my Obsidian vault stored on NTFS, which I can access from my Linux Mint on a dual boot laptop, if I want UNIX environment.
Obsidian, Git, and the agents all work against the same files directly, so there’s no need to decide between a Windows or WSL filesystem or deal with \\wsl$//mnt/c performance and file-watching issues.
Unless you specifically need a Linux environment (Docker, Linux-only tooling, or matching a Linux deployment), Git Bash is a much simpler architecture (you’ll have to install needed packages manually though).
Free doesn’t mean free Claude models; it means FCC adds a wrapper where you add your own models (Deepseek, e.g., way cheaper or even free via OpenCode-Zen while it lasts).
Otherwise:
If you need help with ACP hook-up with Agent Client as well, that’ll be twenty pence.
Free means providers make models available for a limited time with caps to evaluate them and to gather other – ahem – data.
And as for the 20p joke, you can easily use Hermes Agent (a superior agent now than Claude Code) within Obsidian with the plugin mentioned without the hassle of hooking up the Claude with the wrapper, which took me 2 hrs…
I read the git repo of Hermes, but couldn’t really wrap my head around what to do with it, how to use it, what problem it solves. I’m kinda new at this, so I don’t even know what to ask about Hermes
Much the same as Claude Code but some things it does automatically (like using a skill, making a memory).
There are some videos on YT.
I really enjoy making skills via references/examples using Claude online. Show “him” an example, like Excalidraw skill, and make it work better for your own usecase (original Excalidraw is for the web, not for Obsidian Exc.), disable the original skill, copy the custom one to your skills folder and voila, use it, if you need a drawing.
As I said, I also have Linux on a dual boot comp and I can use the NTFS Hermes config from Linux, so I need to change things only on Win.
And to top it all, Kiro CLI can use the same skills; symlink the skills folder to the expected folder in Kiro and boom, you can use skills in Kiro within Obsidian, via Agent Client or its fork, Agent Console and say goodbye to terminal work (which you need to use for initializing only).
I read everything you wrote three times, and it doesn’t click. I guess I’m just not understanding the use cases for the tools and what problems do they solve. I’m new to Obsidian and I’m not a developer, but I’m a tech person… yet this just flies over my head right now
Performance gets overstated for a vault this size — few hundred files doing regular commits probably won’t feel sluggish. Defender exclusion is where it matters; add the folder to the exclusion list and you’ll cut most of the overhead. The Git Bash route is simpler if you don’t need Linux for anything else.
I think there is a misunderstanding here. I gave you two options, and you can absolutely keep using Claude Code and your exact YouTube memory-sync setup even if you install Obsidian inside WSL2.
As I mentioned, you can even launch it exactly like a normal Windows program using a desktop shortcut, so your daily workflow won’t change at all—it will just fix your filesystem speed completely by keeping the files natively in Linux.
Also, an RTX 4070 with 16GB VRAM is more than capable of running great local LLMs, whether specialized for text or general ones like Gemma 4. For comparison, I run a Qwen 3.5 14B Opus variant (with mxfw4 MoE) using a 262k KV-cache on a 16GB VRAM card. While the response time isn’t as instant as a massive cloud-based LLM, it is more than fast enough for heavy text processing, coding, and chatting with documents (for my use).
P.S. I highly recommend asking Claude to just write a simple Python script for you to handle the copying of those .md memory/chat files over to Obsidian automatically. Even better: since you are already using Claude, you could easily use an MCP (Model Context Protocol) toolset to handle this directly inside your workflow. You can just ask Claude to build a simple, file-based Python MCP server for you to bridge the gap automatically.
I’m accessing my Obsidian vault from both sides. I never even considered having two vaults, but I did ask which environment I should place the vault in. So, the decision came down to which side (Windows/WSL2) would be opening/reading/modifying/creating vault files most often and at a higher frequency? For me, that ended up as follows - using the Windows file system to host the vault, and deciding to run all of my vault maintenance, repair, lint functions on the windows side.
Claude projects in Windows and Claude projects in WSL2 access the same vault (different claude .json settings in WSL2, duplicate configuration of MCP servers, etc., but pointing to the same vault).
Note: This only is an issue for WSL2 Claude Code projects that access my second brain. If I’m running Claude Code in WSL2 and I don’t need the vault, then that WSL2 Claude Code project doesn’t get configured with the Obsidian MCP server and isn’t asked to write memory or state into the vault.
Which side, for you, will end up making the most writes to the vault? That’s your primary vault filesystem.
