Permission Error Fixer

Two kinds of permission errors

When Claude Code says 'permission denied', it is one of two very different things - and telling them apart is the whole game. Either the operating system refused a file operation (classic EACCES/EPERM, usually from npm or from files owned by root), or Claude Code's own permission system stopped a tool or command per your settings.json rules. The fix for an OS error is about ownership and rights; the fix for a Claude Code block is about allow/ask/deny rules. Pick your error above and this tool gives you the safe fix for the right layer.

The word 'safe' matters here. There is a tempting shortcut for OS permission errors - chmod 777 or sudo - that makes the error disappear and quietly opens a security hole or plants root-owned files that break again later. This tool never recommends those. Every fix here is scoped to the minimum change that actually resolves the cause.

Claude Code permission rules: allow, ask, deny

• Allow - the tool or command runs without prompting. Scope it tightly to a command or path pattern.
• Ask - Claude Code pauses and asks you before running. This is the safe default for anything with side effects.
• Deny - the tool or command is blocked outright, and deny wins over allow. Use it for things you never want to happen.
• Precedence: deny beats ask beats allow. If something is blocked despite an allow rule, a deny rule is overriding it.
• Layers: rules live in project .claude/settings.json and in your global ~/.claude/settings.json. Check both.

The correct fix for npm EACCES

1. Give npm a folder your user owns: `mkdir -p ~/.npm-global`.
2. Point npm at it: `npm config set prefix ~/.npm-global`.
3. Add its bin to your PATH in your shell profile and open a new terminal.
4. Reinstall the global package without sudo.
5. If earlier sudo installs left root-owned files, reclaim just those: `sudo chown -R $(whoami) ~/.npm ~/.npm-global`.
6. Confirm with a fresh global install that no longer throws EACCES.

Fixing a blocked tool the right way

When Claude Code blocks a tool, the instinct is to open the permissions wide. Resist it. The value of the permission system is that it stops a runaway command before it does damage. When you add an allow rule, scope it to exactly what you need - allow `Bash(npm run test:*)`, not `Bash(*)`. Allow reads of `./src/**`, not the whole filesystem. A tight allow rule keeps the guardrail useful for everything except the specific thing you just approved. The Permissions Rule Builder tool generates these blocks with correct syntax so you are not guessing.

Why the same error keeps coming back

A permission error that returns every session is almost always an ownership problem you papered over. If you once ran `sudo npm install`, your npm folders are now root-owned, and every future global install fails the same way until you reclaim ownership. If you chmod'd a file to make one error go away, the underlying wrong owner is still there. The durable fix is to correct ownership once - user-owned npm prefix, targeted chown on stray root files - rather than re-fighting the symptom each time.

A permission setup that stays out of your way

The goal is a setup where permissions protect you without nagging you. That means: a user-owned npm prefix so global installs never hit EACCES, a small set of tight allow rules for the commands you run constantly, ask on anything with real side effects, and deny on the handful of things you never want. Get that dialed in once and permission errors become rare and meaningful rather than constant friction. The Claude Code Club setup module builds this out step by step.