I ditched Claude Code after giving my local LLM filesystem access

Published Jul 29, 2026, 6:00 PM EDT Nolen began their writing career in 2019, with three years dedicated to editing the Creative section at MakeUseOf. Their expertise lies at the crossroads of technology and creativity, covering areas like photography, video editing, and graphic design. Outside of work, you'll often find Nolen diving into a good book, writing their own stories, or playing video games. Claude Code has quickly become the tool a lot of people reach for when they need to handle stuff that isn't really coding. I'm mainly talking about computer admin such as renaming files in bulk, working through an Obsidian vault, organizing folders that have gotten out of hand, or quick markdown cleanups nobody wants to do by hand. It's genuinely brilliant at all of that and there aren't many complaints to make about it. Except for one thing. Every file it touches gets read into the conversation and sent to Anthropic's servers as part of that session, which is how it works and how any cloud tool has to work. For a folder of code, most people won't think twice about that. For a folder of tax paperwork or medical PDFs, the arrangement gets a little harder to love. And this is where a local LLM with filesystem access comes in… Want to stay in the loop with the latest in AI? The XDA AI Insider newsletter drops weekly with deep dives, tool recommendations, and hands-on coverage you won't find anywhere else on the site. Subscribe by modifying your newsletter preferences! What the filesystem MCP is The one config file that turned my local LLM into a file manager The thing you plug in is called the filesystem MCP server. It's a small Node.js server published on npm as @modelcontextprotocol/server-filesystem, and it's, ironically, maintained by the MCP team at Anthropic themselves, so it's not going to disappear any time soon. What it does is give whatever model you're running a set of tools for actually touching files inside a folder you specify. Reading, writing, editing lines with diff previews before anything commits, moving, renaming, searching, pulling metadata, listing the directory tree, the list goes on. It comes with a sandbox, so the model only ever sees the folder you point it at, so nothing outside that path is reachable. Setting it up in LM Studio (my daily driver) is just one mcp.json edit and a restart. Jan has filesystem in its default MCP server list, so you just enable it from settings. llama.cpp has an MCP client built into its web UI (not the backend itself), which you enable with --webui-mcp-proxy. Ollama is the odd one out: it doesn't natively speak MCP, so you'd need a bridge like MCPHost or ollmcp to get there. {"mcpServers": {"filesystem": {"command": "npx","args": ["-y","@modelcontextprotocol/server-filesystem","ENTER YOUR DIRECTORY"]}}} If you're already running local LLMs seriously, this probably isn't new information, but I think it's the piece that most people who haven't dug past chat-with-files are missing. Why I've been reaching for local filesystem over Claude Code The three things that changed how I use my local LLM The privacy thing is where I want to start because it's the one that actually changed my defaults. Claude Code sends every file it reads to Anthropic's servers as part of the conversation, and depending on your data settings, that data is retained for either five years or thirty days if you've opted out. There's also been at least one reported prompt-injection exploit in Claude's Code Interpreter path recently, which I don't think should be blown out of proportion, but it kind of reinforces the case for keeping personal folders local. None of this is me saying Claude Code is bad, just that some files are probably best kept on your own hardware. The other thing I want to mention is that this has genuinely changed how I think about local LLMs. Before I added the filesystem MCP, my local model was a chatbot in a box. I could talk to it, drop a file in, and get a response, sure. But adding filesystem access turned the same models into something that actually does things on my disk. It's the same model, same weights, same VRAM footprint, but the difference is the tool access. Model choice matters here. Tool calling is a specific skill and not every small model has it. The Qwen family has been consistently strong at this, and I've been running Qwen 3.5 9B on 8GB of VRAM without issues on multi-step sequences. Gemma 4 also jumped a lot on tool calling accuracy over its predecessor. Claude Code is still more capable for actual coding and agentic dev work. But for "look at this folder and tell me what's in there, then sort it into categories"? A local model with filesystem access does the same job at zero cost, data transfer, or rate limits. The biggest limit here will be your hardware. What this stack can and can't do on my hardware It's more than just moving files around The admin stuff is where I've been living. Point it at a messy folder, ask it to look at what's in there, suggest categories, create subfolders, and move files into them. It'll do that in one sequence if the model handles multi-step calls without getting confused. Renaming is another convenient task I hand off to my local LLM now too. The tooling goes further than moving and renaming, though. The filesystem MCP can read text files whole or by specific line ranges, write new ones, and do line-based edits with diff previews before anything commits. So it can genuinely rewrite the contents of your markdown notes, YAML frontmatter, plain-text configs, or any other text-based files. For example, you could bulk-update the frontmatter across an Obsidian vault, or rewrite a folder of markdown notes to match a new template. It can technically read PDFs too, though whether the model handles the extraction well depends on the model, so I wouldn't oversell that one. There's a hardware reality check though. Tool calling is more demanding than plain chat, and if you're on something like 6GB of VRAM, you're going to be running smaller models where multi-step reliability drops. My 8GB with Qwen 3.5 9B feels like roughly the floor for confident chained sequences. Below that you can still get useful single-tool calls out of it, perhaps just not the full experience of sorting out an entire vault end-to-end. Which is honestly still more than most people are asking of their local model. The one thing that was missing from my local LLM setup Claude Code is still the tool I'd reach for when the work is actually complicated. Nothing in my local stack matches it there if we're being honest with ourselves. But most of what I was opening Claude Code for wasn't for development workflows, it was actually computer admin. This filesystem MCP is what made me notice how much of my day was drifting into the wrong tool for the size of the task.