Claude Code Permission Denied — How to Diagnose and Fix It

Claude Code is an agent that can run shell commands, edit files, and call MCP tools on your behalf. By default it asks before anything with real side effects — running Bash, writing a file, calling certain MCP tools — because an autonomous agent taking an irreversible action without a human glancing at it first is exactly the failure mode the prompt exists to prevent. That's the trust model: you are the approval step, not a bug in the tool.

You don't have to re-approve the same thing forever. Two ways to reduce repeat prompts:

A narrowly-scoped allowlist entry looks roughly like this (check your installed version's docs or run /permissions in a session for the exact current syntax):

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(git diff:*)"
    ]
  }
}

Scope allowlist entries to the exact command or tool you actually trust to run unattended — a broad "allow everything" entry defeats the point of the prompt in the first place.

If you already approved the action and it still fails with something like EACCES: permission denied, open '/path/to/file', that's coming from the operating system, not from Claude Code's approval system. The process you're running as genuinely doesn't have read/write/execute rights on that path. Common root causes: the directory is owned by a different user (often root, if something was previously run with sudo), the path is on a read-only mount, or you're running Claude Code as a different user than the one who owns the project directory.

Diagnose before fixing:

# Who am I actually running as?
whoami

# Who owns this file/directory, and what are the permission bits?
ls -l /path/to/file
ls -ld /path/to/directory

Then fix ownership or permissions directly, rather than escalating privileges:

# Give yourself ownership of a directory you should own
chown -R $(whoami) /path/to/directory

# Or fix the permission bits directly
chmod u+rw /path/to/file

Don't reach for sudo as the fix. Running Claude Code (or any agent) as root papers over the ownership mismatch instead of correcting it, and hands an AI agent unrestricted write access to your whole system. Fix the actual ownership, or work from a directory you already own.

MCP servers launched locally (via npx or uvx) run as a child process of whatever launched them. That child inherits the permissions — and the restrictions — of its parent, not of your interactive shell. Two situations cause permission failures here that look identical to a config problem but aren't:

• Restricted parent launch context: if the app that spawned the MCP server itself has limited filesystem access (e.g. it was granted access to only specific folders), every server it spawns is bound by the same limit, regardless of what the MCP config's args say.
• Sandboxed environments: a corporate-managed machine (MDM-enforced sandboxing on macOS, for example) or a containerized dev environment can block subprocess file access outright — the server process starts, but every file operation it attempts fails, no matter how the tool call itself is configured.

If a locally-spawned MCP server can read/write fine when you run the exact same command by hand in your terminal, but fails only when the client (Claude Code, Claude Desktop, Cursor) launches it, the sandbox or launch-context permissions of the parent app — not your MCP config — is the thing to investigate.

A Claude Code session runs at a trust level, and that level determines both how often you get prompted and, at the strict end, whether an action is silently refused instead of asked about. Concretely, sessions can range from "confirm nearly everything" up through modes that auto-accept file edits, and further up to more autonomous modes intended for sandboxed or CI-style runs. If a session feels like it's prompting far more — or far less — than you expect, or an action is being denied with no prompt at all, the session may simply be in a different mode than the one you think it's in.

The exact flag names and mode labels have changed across Claude Code releases, so rather than assert a specific one here, check the current mechanism directly: run claude --help for startup flags, look for an in-session permissions command (commonly something like /permissions), or check your project's and user's settings.json for a mode field. Whichever surface your installed version uses, the concept is the same: the session has a configured trust level, and it's worth confirming what it's actually set to before assuming a permission is broken.

This is the most common Windows-specific cause of "permission denied" and it's easy to miss because everything looks configured correctly. When a project lives on the Windows filesystem and is accessed from inside WSL through the /mnt/c/... mount (or, less commonly, a WSL path is referenced from native Windows), permission bits get translated across the two very different permission models rather than mapped 1:1. The result: chmod can report success without actually changing what's enforced, and Claude Code (or an MCP server it spawns) can hit permission denied on a file that looks perfectly readable in Explorer.

# Slow AND permission-fragile — Windows drive mounted into WSL
cd /mnt/c/Users/you/projects/my-app

# Fast AND permission-sane — native WSL ext4 filesystem
cd ~/projects/my-app

If you must keep the project on the Windows side, running Claude Code from native Windows (rather than from inside WSL against the same path) avoids the translation layer entirely — the tradeoff is you lose access to WSL-only tooling for that session.