Permission denied: what your terminal is actually saying (and the fix you should never copy-paste)

What it actually is

“Permission denied” is your operating system checking two things at once: who you are, and what the thing you’re touching allows that person to do. Picture an apartment building: your keycard, your user account, opens your own unit and the lobby, but not the maintenance room or your neighbor’s door, no matter how hard you push. The building isn’t broken. It’s doing exactly what it was built to do.

Two tools sit right next to this error, and they solve different problems. chmod changes what a file itself allows, read, write, or run, for its owner, its group, and everyone else; running chmod +x script.sh is what turns a plain text file into something you’re allowed to execute as a program. sudo, short for “superuser do,” goes the other direction: instead of changing the file, it changes who you are for one single command, acting as the administrator for that command only, and asking for your own account password to prove you’re allowed to do that.

Why your AI just did this

When your agent hits a wall it can’t write past, writing into a system folder, running a script it just created, installing something globally, it reports “permission denied” back and often proposes a fix: add chmod +x to make a file executable, or put sudo in front of the command to force it through. Both can be the right call. What matters is which kind of block you’re actually looking at. A file missing its execute bit is a one-line, no-risk fix. Being blocked from a folder you don’t own is a bigger decision, because sudo removes the safety net entirely for whatever command follows it.

This is also a different “permission” from the ones Claude Code itself asks you about before running a command it flags as risky. That’s Claude Code checking in with you before it acts. A Unix “permission denied” is your computer checking after the fact and refusing something that was already attempted.

When you’ll run into it

• -bash: ./script.sh: Permission denied right after you write or download a script, before it’s been made executable
• npm ERR! code EACCES while running npm install -g something, because npm’s global install folder is owned by an admin account, not yours
• git@github.com: Permission denied (publickey). when pushing to GitHub, a different cause entirely: your SSH key isn’t set up, not a file permission at all
• macOS blocking a downloaded script with “could not be executed. You do not have appropriate access privileges” when you double-click it instead of running it from the terminal
• Your agent tries to write into a directory it doesn’t have access to, then suggests running the exact same command again, just with sudo added

What to check

• Run ls -l on the file first, to see who owns it and what it already allows, before changing anything
• If the file isn’t marked executable, chmod +x <file> is the whole fix, no sudo needed
• If npm install -g keeps demanding sudo, the real fix is giving your own account ownership of npm’s install folder, or switching to a version manager like nvm, not typing sudo forever
• If the error mentions “publickey” instead of a file path, that’s a git or SSH authentication problem, a completely different fix from anything above
• Never paste in a “sudo rm -rf” command from a forum reply or joke answer to fix a permission error. If you don’t understand exactly what it targets, ask Claude what it does before you run it

Say it like a dev

Instead of: “just put sudo in front of it until it works” Say: “is this actually a permissions problem, or do I just not own this folder”

Instead of: “chmod it so it stops complaining” Say: “chmod +x makes it executable, that’s not the same thing as ownership or sudo”

Instead of: “someone online said to run this to fix it” Say: “before I run this, can you tell me exactly what it deletes and why”