How to Restrict What Claude Desktop Can Access on Your Computer

A locally-installed AI assistant that can read your files, and possibly control your screen, is worth being careful with. That's a reasonable instinct, not paranoia — especially on a personal laptop that also holds tax returns, ID scans, or banking statements. Community threads about Claude Code accidentally rm -rf'ing an entire drive during a routine backup task aren't reassuring, even though that specific incident involved a developer-focused coding agent rather than the consumer Desktop app.

The good news: Claude Desktop's default access to your machine is much smaller than it looks. The bad news: most of the risk people worry about comes from things they added — MCP servers, extensions, Cowork — not from the base app. This guide covers what Claude Desktop can actually touch out of the box, where the built-in permission scoping genuinely breaks down, and the concrete OS-level and container-level fixes that close the gap — including for the specific case of keeping financial and identity documents completely off-limits.

TL;DR

What Claude Desktop can actually touch by default

This is the part worth being precise about, because it changes the whole risk picture. Claude Desktop, installed fresh with no configuration, behaves like a normal chat application: it can read files you upload into a conversation and nothing else. It has no standing permission to browse, read, or write anything on your disk.

Three things change that:

1. Local MCP servers. Anthropic's own Model Context Protocol lets you register a server — most commonly the official filesystem server, or a more capable community one like Desktop Commander — inside claude_desktop_config.json (reached via Settings → Developer → Edit Config on macOS and Windows). Only after that config exists and you restart the app does Claude gain any filesystem reach at all.
2. Desktop extensions. Settings → Extensions lets you install Anthropic-reviewed .mcpb packages, or side-load a custom one via Advanced Settings → Extension Developer. Each extension declares what it needs; you approve it once at install time.
3. Cowork and computer use. Claude's agentic Cowork mode can control your mouse, keyboard, and screen — but only after you explicitly grant macOS Accessibility and Screen Recording permissions (or the Windows equivalent) the first time it tries to act. See explainx.ai's guide to using Claude Cowork safely for the full risk model, including prompt injection and deletion protection.

If none of those three apply to your setup, the honest answer to "can Claude touch my banking documents" is: it structurally cannot see them. The risk shows up the moment any of the three gets added — which is also good news, because it means the fix is scoping those, not disabling the whole app.

The "Always Approve" trap

MCP tool calls in Claude Desktop show a permission dialog the first time a server tries to use a given tool, with an "Always approve" option for that tool going forward. It's convenient, and it's also where most of the real risk accumulates over time — not in the first careful approval, but in the tenth one, three weeks later, clicked on autopilot.

The same pattern shows up in Claude Cowork's "Act without asking" mode, which removes the per-step pause entirely. It's the Desktop-app equivalent of Claude Code's bypassPermissions / --dangerously-skip-permissions mode, and the same rule applies: only use it in a context you're actively supervising, never as a permanent default on a machine with sensitive files on it.

Two habits fix most of this:

• Treat "Always approve" as a decision about a tool, not a session — only grant it to tools whose blast radius you'd be fine with running unattended.
• Periodically audit Settings → Extensions and your MCP server list. An extension you installed for a one-off task in March, still holding filesystem access in August, is the most common way standing access quietly outlives its purpose. Team and Enterprise admins can additionally disable public extensions org-wide from the admin console if this is a shared-machine concern.

Where directory scoping actually breaks

The official filesystem MCP server, and most forks of it, use an allowedDirectories setting: list the folders Claude is allowed to touch, and the server refuses anything outside them. It's the single most useful control available, and you should use it — but it's worth understanding what kind of boundary it actually is.

It's an application-level allowlist, not an OS-level sandbox. The check happens in the server's own code, and code has bugs: security researchers at Embrace The Red documented a path-validation flaw in Anthropic's filesystem MCP server where a sibling directory sharing a name prefix with an allowed one could slip past a naive .startsWith() comparison — a class of bug, not a one-off.

More importantly, scoping one tool doesn't scope the server. Desktop Commander's own documentation is explicit about this: allowedDirectories restricts its filesystem tools, but its terminal tool can still run shell commands that reach paths outside those directories. A server with both filesystem and shell capability is only as contained as its least restricted tool — restricting the file-read tool while leaving terminal access open doesn't actually shrink the blast radius.

None of this is an argument against allowedDirectories. It stops accidental, well-behaved overreach reliably, and it's free to configure. It's an argument for not treating it as the only layer, especially for any server that also has shell or terminal capability. explainx.ai's broader MCP security guide covers the same allowlist-versus-sandbox distinction for production deployments — the logic is identical at consumer scale, just with lower stakes per incident.

Real sandboxing: containers, VMs, and dedicated accounts

If a process can't see a file, it can't read, edit, or delete it — no permission dialog required. That's the principle behind every genuine containment strategy, and it doesn't require being a developer to apply at a basic level:

• A dedicated OS user account for AI-agent use. Create a second, standard (non-admin) user account on your Mac or Windows machine. Run Claude Desktop and any MCP servers from that account, and keep your banking, tax, and ID documents entirely under your primary account instead. A second account without file permissions on your main account's home directory is a real OS-enforced boundary, not an application promise.
• A virtual machine (Parallels, UTM, VMware, or Windows' built-in Hyper-V/Sandbox) for anything higher-stakes — testing an unfamiliar MCP server or extension, for instance. Worst case, you discard the VM.
• Docker containers, for anyone comfortable with them. This is the approach developers converged on for containing Claude Code after the Reddit rm -rf incident — mount only the one directory the agent needs, read-write, and mount nothing else. The same doctrine applies to any filesystem- or shell-capable MCP server you run for Desktop: Desktop Commander's own docs recommend its Docker install specifically for this reason.

The common thread across all three: the boundary lives in the operating system or the container runtime, not in a setting the AI's own tool-calling code is trusted to respect.

OS-native safeguards you can turn on today

Two built-in, zero-cost controls are worth enabling regardless of how much you trust any given AI tool — they protect against misconfiguration, not just malice.

Windows: Controlled Folder Access. This is a Microsoft Defender feature that blocks any application not on your trusted list from modifying files in folders you designate as protected — Documents, Pictures, Desktop, and any custom folder you add, including wherever you keep financial records. Enable it under Windows Security → Virus & threat protection → Ransomware protection. It was built for ransomware, but the mechanism doesn't care what category of software is doing the writing — an MCP server or extension running amok hits the same wall an unauthorized process would.

macOS: Accessibility and Screen Recording permissions. Cowork's computer-use features cannot click, type, scroll, or see your screen without both permissions explicitly granted in System Settings → Privacy & Security. If you're not actively using Cowork's computer-control features, leaving both toggled off is a legitimate way to keep that entire capability class unavailable — and toggling either off immediately revokes it, no app restart negotiation required.

Neither of these is MCP-specific or Claude-specific. Both are worth having on generally, and both directly address the "what if something goes wrong and starts deleting or modifying files" fear at the OS layer, independent of anything the AI application itself does right or wrong.

If you're also using Claude Code or Cowork

Everything above covers Claude Desktop's own surface — MCP, extensions, computer use. If you also use Claude Code for development work, its permission and sandboxing model is more mature, because the threat model (an agent with shell access to a repo) has been the product's core concern from the start:

• Permission modes — default (asks before bash and writes), acceptEdits (auto-approves file edits, still asks for bash), and bypassPermissions (asks nothing — sandboxed environments only).
• .claude/settings.json — persistent allow/deny lists for specific tools and command patterns.
• The /sandbox command and Claude Code's built-in sandboxing — filesystem and network isolation that Anthropic reports reduces permission prompts by 84% in internal usage, by giving Claude a bounded space to act freely in rather than asking per-action.
• Destructive Command Guard and similar hook-based tools, for an extra pattern-matching layer in front of the shell.

For Cowork specifically, Anthropic's own deletion-protection prompts and the Cowork safety guide cover the agentic-desktop-automation risk surface — prompt injection through browsed content being the sharpest edge, since Cowork also drives Claude in Chrome.

Keeping banking and ID documents completely off-limits

This is the specific worry worth answering directly, since "restrict Claude generally" and "keep my banking and ID documents untouchable" are related but not identical goals — the second is achievable with much less effort than full sandboxing.

• Never point a filesystem MCP server, extension, or Cowork session at your home directory, Desktop, or Documents folder wholesale. Scope allowedDirectories to a specific working folder for the specific task, and nothing broader.
• Move sensitive documents out of any directory that's ever likely to be in scope. A dedicated folder outside ~/Documents (or its Windows equivalent) that you never add to an allowlist is the simplest version of this.
• Watch for cloud-sync overlap. iCloud's Desktop & Documents sync and OneDrive's Known Folder Move both silently redirect your Desktop and Documents folders into a synced location — meaning a scan of your passport sitting on the Desktop "for convenience" is in the same folder you may have already granted an MCP server access to. Check where those folders actually point before assuming a scoped allowlist excludes them.
• Use an encrypted, normally-unmounted container (VeraCrypt, Cryptomator, or your OS's built-in FileVault/BitLocker-backed encrypted volume) for banking statements, tax filings, and ID scans specifically. A file that isn't mounted isn't reachable by anything, AI or otherwise.
• Prefer a dedicated low-privilege account (see above) for any machine where you're actively experimenting with new MCP servers or extensions, keeping the account holding sensitive documents separate and logged out.

None of this requires distrust of any particular tool — it's the same "don't keep your passport next to the door" logic that applies to physical security, applied to a filesystem.

What people are asking

Is there an official "sandbox mode" toggle for Claude Desktop itself? Not as a single switch, no. Sandboxing as a first-class feature (the /sandbox command, container-based isolation) currently belongs to Claude Code. For Desktop, the boundary is one you build yourself with allowedDirectories, a dedicated OS account, or a VM/container around any file- or shell-capable MCP server.

Does antivirus software help here? Indirectly. Standard antivirus won't understand MCP-level scoping, but OS-level features that ship alongside it — Windows' Controlled Folder Access being the clearest example — do apply generally to any process, AI-driven or not, attempting unauthorized writes to protected folders.

Can I make this fully airtight? Not with certainty, and no vendor claims otherwise for any AI agent with real file or shell access — the honest goal is reducing blast radius, not achieving a mathematical guarantee. A process that genuinely cannot see a file is the closest thing to airtight available; everything else (allowlists, permission prompts, "Always approve" habits) is a meaningfully weaker but still worthwhile second line.

What if I'm on a Team or Enterprise Claude plan? Admins get additional levers — disabling public desktop extensions organization-wide, and (per Anthropic's own guidance) Cowork activity isn't currently captured by the Compliance API, which is itself a reason to keep Cowork off regulated or highly sensitive workflows at the org level, not just the individual level.

Should I just avoid MCP and extensions entirely if I'm nervous? That's a legitimate choice, and it costs you very little — Claude Desktop without any MCP servers configured is already the safest possible configuration by default, at the cost of losing local file/tool integration. Most people who add MCP servers do it for a specific workflow; scoping that server tightly gets you most of the benefit with a small fraction of the exposure.

The minimum-viable checklist

If you do nothing else after reading this:

1. Check Settings → Developer → Edit Config — if claude_desktop_config.json is empty or absent, Claude Desktop currently has no filesystem access at all.
2. If you do run a filesystem or shell MCP server, set allowedDirectories to one specific folder — never your home directory.
3. Turn on Controlled Folder Access (Windows) or leave Accessibility/Screen Recording off until needed (macOS).
4. Keep banking, tax, and ID documents in a folder that is never on any allowlist — ideally encrypted and unmounted by default.
5. Review Settings → Extensions periodically and remove anything you no longer actively use.
6. For anything higher-stakes, run it in a container, VM, or a dedicated low-privilege OS account instead of your daily-driver login.

Related reading

• Claude Opus 5 rm -rf'd a Reddit User's Drive: The Sandbox Guide
• How to Use Claude Cowork Safely: Official Security Guide
• Claude Code Permission Modes Explained
• Claude Code Settings File (.claude/settings.json): Every Option Explained
• Desktop Commander MCP Setup Guide
• MCP Security Guide 2026
• Claude in Chrome: Features, Access & Safety
• What is MCP? Model Context Protocol Complete Guide

Official resources: Getting started with local MCP servers on Claude Desktop · Use Claude Cowork safely · Claude Code sandboxing docs · Microsoft: Controlled folder access

Product settings, menu paths, and permission behavior reflect Claude Desktop, Claude Code, and Claude Cowork as of August 10, 2026. Anthropic ships frequent updates to permission dialogs and default settings — verify current menu locations in-app before relying on any specific path described here.