The Error
You try to install an extension from the VS Code Marketplace and get something like this:
EACCES: permission denied, mkdir '/home/youruser/.vscode/extensions/...'
Or the install button in the Extensions panel spins for a few seconds, then shows a red error notification. Check the Output panel and you'll see the full message:
EACCES: permission denied
VS Code can't write to the extensions directory. The install fails — sometimes silently, sometimes with that unhelpful error.
Why This Happens
VS Code stores extensions in ~/.vscode/extensions on Linux and macOS. When you see this error, it's almost always one of two things:
- The
~/.vscodedirectory is owned byroot— usually because someone ran VS Code withsudoat some point. - The directory permissions are too restrictive, locking out your own user account.
Here's the kicker: running sudo code . just once is enough to flip ownership of ~/.vscode to root. After that, every extension install fails until you fix it.
Step-by-Step Fix
Step 1 — Check Who Owns the Extensions Directory
Open a terminal and run:
ls -la ~/.vscode/
Look at the owner column. If it shows root instead of your username, that's your problem:
drwx------ 3 root root 4096 Mar 18 10:00 extensions
Step 2 — Fix Ownership
Take back the directory by resetting ownership to your own user:
sudo chown -R $USER:$USER ~/.vscode
The -R flag makes this recursive — it fixes ~/.vscode and every file and folder inside it. $USER expands automatically to your current username, so you don't need to type it manually.
Step 3 — Fix Directory Permissions
Once ownership is sorted, set the permissions correctly:
chmod -R 755 ~/.vscode
Mode 755 means you get full read/write/execute access (7), while others can only read and execute (5). Extensions install cleanly with these permissions.
Step 4 — If the Error Is on a System-Wide VS Code Installation
Some Linux distros install VS Code system-wide via snap, apt, or rpm, and the extensions directory may live somewhere else. For Snap installs, extensions are typically stored under ~/snap/code/. Fix it the same way:
sudo chown -R $USER:$USER ~/snap/code/
Not sure where your extensions actually are? Run ls -la ~/.vscode/extensions/ and ls -la ~/snap/code/ and compare which one has root ownership.
Step 5 — Stop Running VS Code With sudo
This is the root cause most of the time. If you've been doing this:
# DON'T do this
sudo code .
Stop. Just launch VS Code as your normal user:
# Do this instead
code .
Need to edit a system file that requires root access? Use sudoedit /path/to/file in the terminal, or VS Code's built-in Save as Root prompt when saving. Never sudo code.
Verify the Fix Worked
- Quit VS Code completely. On macOS, closing the window isn't enough — use Cmd+Q.
- Reopen VS Code normally (without
sudo). - Open the Extensions panel with Ctrl+Shift+X (or Cmd+Shift+X on Mac).
- Search for any extension — say, Prettier or GitLens — and click Install.
No red notification? You're good. To double-check from the terminal:
ls -la ~/.vscode/extensions/
New extension folders should appear, owned by your username — not root.
Tips
Understand the Permissions Before Changing Them
Not sure what chmod 755 actually means? The Unix Permissions Calculator on ToolCraft lets you build chmod values visually. Click the permission bits, see the octal value and what it allows — before you run anything. I use it whenever I need to set permissions beyond the usual 755/644.
Shared Extensions Cache on a Multi-User Machine
Got a dev team sharing one Linux box? Instead of each user maintaining their own extensions, set up a shared extensions directory with group permissions:
sudo mkdir -p /opt/vscode-extensions
sudo chown -R root:developers /opt/vscode-extensions
sudo chmod -R 775 /opt/vscode-extensions
Then point VS Code to it at launch:
code --extensions-dir /opt/vscode-extensions .
Everyone in the developers group can install extensions into the shared cache. No duplicate downloads, no permission fights.
Rule Out Disk Quota Issues
On managed systems — university servers, corporate workstations — EACCES: permission denied can also show up when you've hit your disk quota. It's a misleading error. Run these two commands to rule it out:
df -h ~
quota -u $USER
If your home partition is at 100% or you're over quota, free up some space first, then retry the extension install.