Fix 'EPERM: operation not permitted' When Saving Files in VS Code on Windows

The Error

You hit Save, and VS Code throws:

EPERM: operation not permitted, open 'C:\Users\username\project\src\index.ts'

Sometimes it's a one-off fluke. Other times it blocks every save until you restart VS Code — or reboot your machine, only for the error to return the next morning. Here's what's actually happening and how to stop it for good.

What Causes EPERM on Windows

EPERM is the OS refusing a file operation at the syscall level. On Windows, that refusal usually traces back to one of these:

• Antivirus / security software locking the file mid-save to scan it
• OneDrive or Dropbox sync holding an exclusive lock on the file at the exact moment VS Code tries to write
• Another process (a Node.js watcher, a second editor instance, a build tool) has the file open with an exclusive lock
• Insufficient permissions on the file or folder — common when a project was created by a different user or cloned as Administrator
• Windows path length limits — particularly with deeply nested node_modules hitting the 260-character ceiling

Fix 1: Add Your Project Folder to Antivirus Exclusions (Most Common Fix)

Windows Defender — and virtually every third-party AV — hooks into file writes. When it intercepts VS Code's save, it briefly locks the file handle to run a scan. That scan can take anywhere from 50ms to several hundred milliseconds. VS Code's write times out, and you get EPERM.

For Windows Defender

• Open Windows Security → Virus & threat protection
• Go to Virus & threat protection settings → Exclusions → Add or remove exclusions
• Click Add an exclusion → Folder
• Select your project root (e.g., C:\Users\username\project)

Also exclude the VS Code binary while you're there:

C:\Users\username\AppData\Local\Programs\Microsoft VS Code\Code.exe

Try saving the file again. Nine times out of ten, this is all you need.

Fix 2: Pause or Move the Project Out of Sync Folders

Projects living inside OneDrive, Dropbox, or Google Drive are a known pain point. The sync client can grab an exclusive file lock right as VS Code is writing — and the EPERM is the OS enforcing that lock.

Quickest diagnostic: move the project to C:\dev\project and see if the error disappears. If it does, that's your culprit. Keep dev work outside the sync folder, or pause sync while coding.

For OneDrive, right-click the tray icon → Pause syncing → pick a time window. Two hours is usually enough for a coding session.

Fix 3: Reset Folder Permissions

Running git clone as Administrator is the usual suspect here. Your regular user account ends up without write access to files that were created under an elevated session.

Check who owns what:

icacls "C:\Users\username\project" /T

Then reset permissions and grant your user full control:

icacls "C:\Users\username\project" /reset /T /C
icacls "C:\Users\username\project" /grant %USERNAME%:F /T /C

/T recurses into subdirectories, F means full control, and /C continues past errors. Run this in a standard (non-elevated) Command Prompt. If you prefer PowerShell:

$path = "C:\Users\username\project"
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $env:USERNAME, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.SetAccessRule($rule)
Set-Acl $path $acl

Fix 4: Find and Kill the Locking Process

Something else has the file open — and won't let go. Sysinternals Process Explorer and the built-in Resource Monitor can both tell you what that something is.

In Resource Monitor (search it in Start):

• Go to the CPU tab → Associated Handles
• Search for the filename (e.g., index.ts)
• Right-click the locking process → End Process

On Node.js projects, file watchers are the usual offenders — nodemon, webpack-dev-server, ts-node --watch. Stop the dev server, save the file, then restart. Takes 10 seconds and usually works.

Fix 5: Enable Long Path Support

Windows caps file paths at 260 characters by default. Paths inside deeply nested node_modules blow past this constantly, producing EPERM errors that look identical to permission issues but aren't.

Enable long path support in PowerShell (run as Administrator):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
  -Name LongPathsEnabled -Value 1

Alternatively via Group Policy: gpedit.msc → Computer Configuration → Administrative Templates → System → Filesystem → Enable Win32 long paths.

Restart VS Code after the change. This fix has zero downside — just do it on every Windows dev machine.

Fix 6: Pick One Elevation Mode and Stick to It

Alternating between launching VS Code as Administrator and as a regular user is a surprisingly common source of EPERM. Files written in one mode end up with ownership that the other mode can't touch.

Pick one and commit. For most development work, a regular user session is the right default. When you genuinely need admin access for something specific, open a separate elevated terminal — don't run VS Code itself as admin.

Verify the Fix Worked

Save the previously failing file. If that works, also spot-check OS-level write access directly in PowerShell:

$f = [System.IO.File]::Open(
    "C:\Users\username\project\src\index.ts",
    [System.IO.FileMode]::Open,
    [System.IO.FileAccess]::ReadWrite
)
$f.Close()
Write-Host "Write access confirmed"

This opens the file for read-write without touching its content. If it completes without error, the permission issue is cleared at the OS level — not just inside VS Code.

Also worth a look: the VS Code Output panel (Ctrl+Shift+U, select "Log (Extension Host)") — a clean log with no EPERM entries confirms you're good.

Prevention

• Exclude project folders from AV scanning on day one — make it part of your dev machine setup checklist, not an afterthought.
• Keep dev projects outside OneDrive/Dropbox — a dedicated C:\dev\ or D:\projects\ folder avoids an entire class of sync-related headaches.
• Never clone repos as Administrator unless there's a specific reason — the permission fallout isn't obvious until hours later when saves start failing.
• Enable long paths system-wide on every Windows dev machine — there's no downside, and it eliminates a whole category of node_modules-related errors before they appear.

If your work spans Linux and Windows and file permissions are a regular concern, the Unix Permissions Calculator on ToolCraft is handy for visualizing chmod values — useful when shell scripts or CI configs need specific permission bits set correctly on the Linux side.