エラーの内容
保存ボタンを押すと、VS Code が次のエラーを表示します：
EPERM: operation not permitted, open 'C:\Users\username\project\src\index.ts'
一度だけ発生して終わることもあれば、VS Code を再起動するまで — あるいはマシンを再起動しても翌朝また同じエラーが返ってくるまで — すべての保存操作をブロックし続けることもあります。実際に何が起きているのか、そして根本的に解決する方法を説明します。
Windows で EPERM が発生する原因
EPERM は、OS がシステムコールレベルでファイル操作を拒否していることを示します。Windows では、この拒否は通常以下のいずれかに起因します：
- ウイルス対策ソフト／セキュリティソフトウェア が保存中にファイルをロックしてスキャンしている
- OneDrive または Dropbox の同期 が、VS Code が書き込もうとしたまさにその瞬間にファイルの排他ロックを保持している
- 別のプロセス（Node.js のウォッチャー、別のエディターインスタンス、ビルドツールなど）が排他ロックでファイルを開いている
- ファイルまたはフォルダーの権限が不十分 — 別のユーザーがプロジェクトを作成した場合や、Administrator としてクローンした場合によく発生する
- Windows のパス長制限 — 深くネストされた
node_modulesが 260 文字の上限に達している場合など
修正方法 1：プロジェクトフォルダーをウイルス対策の除外リストに追加する（最も一般的な解決策）
Windows Defender をはじめほぼすべてのサードパーティ製ウイルス対策ソフトは、ファイルの書き込みにフックします。VS Code の保存操作を検知すると、スキャンを実行するためにファイルハンドルを一時的にロックします。このスキャンには 50ms から数百ミリ秒かかることがあります。VS Code の書き込みがタイムアウトし、EPERM が発生します。
Windows Defender の場合
- Windows セキュリティ を開き、ウイルスと脅威の防止 に進む
- ウイルスと脅威の防止の設定 → 除外 → 除外の追加または削除 を選択
- 除外を追加 → フォルダー をクリック
- プロジェクトのルートフォルダーを選択する（例：
C:\Users\username\project）
ついでに VS Code の実行ファイルも除外に追加しておきましょう：
C:\Users\username\AppData\Local\Programs\Microsoft VS Code\Code.exe
再度ファイルを保存してみてください。十中八九、これだけで解決します。
修正方法 2：プロジェクトを同期フォルダーの外に移動するか、同期を一時停止する
OneDrive、Dropbox、または Google Drive 内に置いたプロジェクトはトラブルの元として知られています。VS Code が書き込もうとしたまさにその瞬間に同期クライアントがファイルの排他ロックを取得し、OS がそのロックを強制することで EPERM が発生します。
手っ取り早い診断方法として、プロジェクトを C:\dev\project に移動してエラーが消えるか確認してください。消えた場合、それが原因です。開発作業は同期フォルダーの外で行うか、コーディング中は同期を一時停止してください。
OneDrive の場合、トレイアイコンを右クリック → 同期の一時停止 → 時間を選択します。コーディングセッションなら 2 時間あれば十分でしょう。
修正方法 3：フォルダーの権限をリセットする
Administrator として git clone を実行したことが原因であることがよくあります。昇格したセッションで作成されたファイルに対して、通常のユーザーアカウントが書き込みアクセス権を持てなくなります。
所有者を確認するには：
icacls "C:\Users\username\project" /T
権限をリセットし、ユーザーにフルコントロールを付与するには：
icacls "C:\Users\username\project" /reset /T /C
icacls "C:\Users\username\project" /grant %USERNAME%:F /T /C
/T はサブディレクトリを再帰的に処理し、F はフルコントロールを意味し、/C はエラーが発生しても処理を続行します。標準（非昇格）のコマンドプロンプトで実行してください。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
修正方法 4：ロックしているプロセスを特定して終了する
別の何かがファイルを開いたまま手放さない状態です。Sysinternals の Process Explorer と組み込みの リソース モニター のどちらでも、それが何であるかを確認できます。
リソース モニター（スタートメニューで検索）の場合：
- CPU タブ → 関連するハンドル に進む
- ファイル名（例：
index.ts）を検索する - ロックしているプロセスを右クリック → プロセスの終了
Node.js プロジェクトでは、ファイルウォッチャーが主な原因です — nodemon、webpack-dev-server、ts-node --watch など。開発サーバーを停止してからファイルを保存し、その後再起動してください。10 秒で終わり、たいていうまくいきます。
修正方法 5：長いパスのサポートを有効にする
Windows はデフォルトでファイルパスを 260 文字に制限しています。深くネストされた node_modules 内のパスは常にこの制限を超え、権限の問題とまったく同じように見える EPERM エラーを発生させますが、実際には権限の問題ではありません。
PowerShell で長いパスのサポートを有効にする（管理者として実行）：
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name LongPathsEnabled -Value 1
グループポリシーで設定する場合は：gpedit.msc → コンピューターの構成 → 管理用テンプレート → システム → ファイルシステム → Win32 の長いパスを有効にする。
変更後は VS Code を再起動してください。この修正にデメリットはありません — すべての Windows 開発マシンで実施しましょう。
修正方法 6：昇格モードを一つに統一して使い続ける
VS Code を Administrator として起動したり通常ユーザーとして起動したりと交互に切り替えることは、意外にも EPERM の一般的な原因です。一方のモードで書き込まれたファイルが、もう一方のモードではアクセスできない所有権を持つことになります。
どちらか一方に決めて統一してください。ほとんどの開発作業では、通常ユーザーのセッションが適切なデフォルトです。特定の操作で管理者権限が本当に必要な場合は、別に昇格したターミナルを開いてください — VS Code 自体を管理者として実行しないようにしましょう。
修正が成功したか確認する
以前に失敗していたファイルを保存してみてください。保存できた場合は、PowerShell でOS レベルの書き込みアクセスも直接確認しておきましょう：
$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"
このコードはファイルの内容を変更せずに読み書きモードで開きます。エラーなく完了すれば、権限の問題は VS Code 内だけでなく OS レベルで解消されています。
VS Code の出力パネル（Ctrl+Shift+U を押して「Log (Extension Host)」を選択）も確認する価値があります — EPERM のエントリーがないクリーンなログが表示されれば問題ないことが確認できます。
再発防止策
- 初日からプロジェクトフォルダーをウイルス対策のスキャン対象から除外する — 後からの思いつきではなく、開発マシンのセットアップチェックリストの一部にしましょう。
- 開発プロジェクトを OneDrive/Dropbox の外に置く — 専用の
C:\dev\やD:\projects\フォルダーを使うことで、同期関連のトラブル全般を回避できます。 - 特別な理由がない限り Administrator としてリポジトリをクローンしない — 権限の問題はすぐには現れず、保存が失敗し始めて初めて数時間後に気づくことになります。
- すべての Windows 開発マシンで長いパスのサポートをシステム全体で有効にする — デメリットはなく、
node_modules関連のエラーが発生する前に根絶できます。
Linux と Windows をまたいで作業していてファイル権限が頻繁に問題になる場合、ToolCraft の Unix パーミッション計算機が chmod の値を視覚的に確認するのに役立ちます — シェルスクリプトや CI 設定で Linux 側の特定の権限ビットを正しく設定する必要がある場合に便利です。