{"slug": "i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both", "title": "I Configured Claude Desktop's File Access Twice. It Was the Same Setting Both Times.", "summary": "A developer discovered that Claude Desktop's file access settings are duplicated under two different sidebar labels, 'Extensions' and 'Connectors', which lead to the identical Filesystem settings screen with no cross-reference. The developer found that the GUI settings were already active before they edited the legacy claude_desktop_config.json, leading to unintended folder access. The issue highlights confusion in Anthropic's UI navigation.", "body_md": "*File access in Claude Desktop's chat mode had been flaky for a while: sometimes there, sometimes not, no obvious pattern. The standard fix, the one Claude itself gives you in a plain chat, is to hand-edit claude_desktop_config.json. I did that, and before I'd even confirmed it worked on its own, found something else: the same Filesystem settings, filed under two completely different sidebar labels, with nothing anywhere saying they're the same page. I only noticed because I'd enabled an unrelated extension that gives Claude direct control of the Mac, and used it to go audit the settings properly.*\n\nI run a personal ops wiki, mostly read and written by Claude, across two Macs. File access from Claude Desktop's plain chat mode never felt fully trustworthy. It would work fine one session and fail the next, with no config change I was aware of in between. The easy answer is \"just use Cowork mode instead,\" and that's fine advice, but it's a workaround, not a diagnosis. I wanted to know what was actually configured before deciding the lighter chat-mode access wasn't worth fixing.\n\nAsk Claude in a plain chat how to set this up, and it points you at `claude_desktop_config.json`\n\n: the classic `mcpServers`\n\nJSON block, hand-edited, one entry per server. That's the answer in most guides.\n\nI wrote a scoped filesystem entry and restarted. What I didn't do, and should have, was check whether that entry was actually controlling access, versus something already running underneath it. I never isolated a clean test of \"JSON entry alone, nothing else present.\" Going to check what was actually granting access, I found a second settings screen already live and already configured, with no idea how long it had been running or how it related to what I'd just written.\n\nFinding a settings screen I didn't know existed was reason enough to stop guessing. I had Claude use a separate extension, enabled earlier for unrelated automation and giving it direct AppleScript and shell control of the Mac, to read every settings file involved rather than trust what any single screen claimed.\n\nWhat that turned up wasn't three independent systems fighting each other. It was more specifically annoying than that: **the same Filesystem settings screen, reachable from two entirely different places in the sidebar, styled identically, with no cross-reference telling you they're the same page.** Navigate in via `Desktop app → Extensions → Filesystem`\n\nand you land on a page. Navigate in via `Customize → Connectors → Filesystem`\n\nand you land on the exact same page: same toggle, same two allowed directories, same tool-permission list, pixel for pixel. Two doors, one room, and nothing on either door mentions the other.\n\nUnderneath that is a genuinely separate second thing: the raw `claude_desktop_config.json`\n\n`mcpServers`\n\nblock, which is the old way of doing this and is still correct for anything Anthropic hasn't folded into the unified screen (a third-party server like GitHub's, for instance).\n\nSo the real shape isn't three settings surfaces. It's one legacy JSON method and one current GUI system that Anthropic's own navigation apparently can't decide whether to call \"Extensions\" or \"Connectors,\" filing the identical screen under both mid-rename, with nothing explaining the overlap. If you've used Claude Desktop across months of incremental UI changes, that's exactly the setup for believing you configured two different things when you configured one thing twice, through two different-looking menus, at two different points in time.\n\nFilesystem access was already being controlled by the GUI screen before I ever wrote the JSON entry, set at some earlier point I don't have a clean memory of, to a longer list of folders than the two I actually wanted. Old folders from old projects, added one at a time over months and never reviewed as a whole. Nothing dramatic in the contents. Just more than intended, with no memory of deliberately choosing all of it.\n\nThe part that actually mattered: the JSON entry I'd just written was now sitting live in `mcpServers`\n\nat the same time as the GUI screen's own config, and I had no idea whether the JSON one was doing anything, doing something partial, or fully inert. I didn't want to find out by trial and error what two separate filesystem MCP servers both claiming the same job actually produces. Best guess: duplicate tools in the picker, maybe ambiguous tool selection if both register something like `read_file`\n\n. That's a guess, not a confirmed failure mode. So I removed the uncertainty instead of resolving it: reverted the JSON entry back to an empty `mcpServers: {}`\n\n, and let the GUI screen be the only thing live.\n\nThe real risk here isn't that the JSON method is dead, which I can't claim to have proven either way. It's that if the Extensions-labeled view and the Connectors-labeled view of the same feature ever show *different* folder lists, not just two doors to one room but two doors that have genuinely drifted apart, nothing in the UI tells you which one is real, or that they've diverged at all. That's worth actually checking side by side rather than assuming they're in sync.\n\nSeparately, I wanted GitHub push access. Anthropic has a native GitHub Integration connector: Settings → Connectors, click, authorize, done. The obvious path.\n\nExcept as of late July 2026, there's an [open, unresolved bug](https://github.com/anthropics/claude-code/issues/80874) where that connector's OAuth grants read access fine, but every write operation fails with `403 Resource not accessible by integration`\n\n, including `git push`\n\n. Confirmed, reported, still open when I checked. Flip that toggle without checking, and you get a connector that looks connected and silently fails the one thing you needed it for.\n\nThe workaround: GitHub's own official MCP server, run locally via Docker, authenticated with a fine-grained personal access token instead of Anthropic's GitHub App.\n\n```\n{\n  \"mcpServers\": {\n    \"github\": {\n      \"command\": \"docker\",\n      \"args\": [\"run\", \"-i\", \"--rm\", \"-e\", \"GITHUB_PERSONAL_ACCESS_TOKEN\", \"ghcr.io/github/github-mcp-server\"],\n      \"env\": { \"GITHUB_PERSONAL_ACCESS_TOKEN\": \"<fine-grained PAT>\" }\n    }\n  }\n}\n```\n\nThis one genuinely belongs in `mcpServers`\n\n. GitHub isn't shipped as a Claude Extension, so the old method is the correct method here, which is its own small trap: the right place to configure something depends entirely on whether Anthropic happened to ship it as an Extension, and nothing tells you that up front either.\n\nGiven how wrong \"it looks configured\" turned out to be for filesystem access, GitHub got three separate checks before I trusted it.\n\nDoes the token actually authenticate:\n\n```\ncurl -s -H \"Authorization: Bearer $TOKEN\" https://api.github.com/user\n```\n\nDoes it have write permission on a real repo, not just a valid token:\n\n```\ncurl -s -H \"Authorization: Bearer $TOKEN\" https://api.github.com/repos/me/my-repo\n```\n\nI checked the `permissions`\n\nobject for `\"push\": true`\n\nspecifically.\n\nDid the actual Claude Desktop process connect cleanly, not just a manual test, by tailing:\n\n```\n~/Library/Logs/Claude/mcp-server-github.log\n```\n\nLooking for `readOnly=false`\n\n, `lockdownEnabled=false`\n\n, and a clean `Server started and connected successfully`\n\nafter a real restart.\n\nIf you're running Claude Desktop and think you know what has file access right now, here's the actual answer, not the guide's answer.\n\nCheck both `Desktop app → Extensions → Filesystem`\n\nand `Customize → Connectors → Filesystem`\n\n, and compare what each one shows. For me, after correcting the folder list, they matched, consistent with one underlying screen filed under two labels. I haven't verified that's guaranteed across every install, so check your own rather than take my word for it. If yours show different folders on each, that's the version of this that actually bites: two settings both plausibly \"the real one,\" disagreeing, with nothing telling you which one Claude is using.\n\nThen check the JSON method isn't also quietly in the mix:\n\n```\ncat ~/Library/Application\\ Support/Claude/claude_desktop_config.json\n```\n\nIf a `filesystem`\n\nkey shows up under `mcpServers`\n\n, that's a third thing potentially live at once. I don't know what happens when it and the GUI screen are both active, and I chose not to find out. I'd remove it rather than test it.\n\nFor anything Anthropic hasn't folded into the unified screen, a third-party MCP server without its own Extension, the JSON file is the correct, current place, since there's no GUI card for it at all.\n\nWhether Extensions and Connectors are one data store behind two doors, two stores kept in sync, or two stores that can silently drift, I only have direct evidence for my own case, and it settled into consistent once corrected. What I can say with more confidence: nothing in the product tells you which of those it is, and that's worth checking for yourself rather than taking on faith.\n\nEverything sorted here is local-Mac config. The bigger, still-untouched piece is a custom MCP server meant to run on a home Proxmox LXC: a small TypeScript service exposing read-only search and lint tools over the network, reached via an `mcp-remote`\n\nstdio bridge rather than Anthropic's Custom Connectors, which require public internet reachability and aren't a fit for a home LAN. That's a design doc right now, zero code written. Whether that setup turns out to have two doors as well feels like a safe bet.\n\nIf you've dug into your own Claude Desktop settings and found something that didn't match what you thought was configured, I'd like to hear what it was.", "url": "https://wpnews.pro/news/i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both", "canonical_source": "https://dev.to/mediblacksand_f0ea36c53fb/i-configured-claude-desktops-file-access-twice-it-was-the-same-setting-both-times-46lo", "published_at": "2026-08-03 04:30:20+00:00", "updated_at": "2026-08-03 05:09:51.882653+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-products"], "entities": ["Claude Desktop", "Anthropic", "Filesystem", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both", "markdown": "https://wpnews.pro/news/i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both.md", "text": "https://wpnews.pro/news/i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both.txt", "jsonld": "https://wpnews.pro/news/i-configured-claude-desktop-s-file-access-twice-it-was-the-same-setting-both.jsonld"}}