cursor permission deniedエラーを完全解決!OSごとの原因と直し方をどこよりも丁寧にまとめた
CursorでコードやNext.jsプロジェクトを開こうとした瞬間、突然「EACCES: permission denied」「EACCESS: permission denied」というエラーが表示されて手が止まる――そんな経験をしている人は少なくない。このエラーはWindowsとmacOSとLinuxで原因の場所が微妙に異なり、検索しても断片的な情報しか出てこないため、解決に時間がかかることが多い。この記事ではCursorのpermission deniedエラーについて、OS別の発生原因・エラーコードの意味・具体的なコマンドによる解決手順を徹底的に整理した。
実際にCursorのコミュニティフォーラムやGitHub Issues・Stack Overflowなどに寄せられた事例を横断的に調査し、初心者でも手順どおりに試せるよう細かく説明している。「新しいNext.jsプロジェクトを作るたびにsudoが必要になる」「macOS Tahoeにアップグレードしてからエラーが出るようになった」「AppImageを使っているUbuntu環境でファイル保存のたびにpermission deniedが出る」といったパターンごとに解決策を分けて紹介しているので、自分の状況に合ったものを探してほしい。
| この記事のポイント |
|---|
| ✅ cursor permission deniedはEACCES/EACCESSを示すOSレベルの権限エラーで、Cursor自体のバグではなくディレクトリ所有権・パーミッション設定が原因であることがほとんど |
| ✅ macOSはchownコマンドでCursorデータフォルダの所有者を自分に戻すだけで解消できるケースが多い |
| ✅ LinuxのAppImage環境では/tmpパーティションのnoexecマウントが原因になることがあり、remount,execで解決できる |
| ✅ GitやSSHのpermission deniedは別問題であり、Cursorのフォルダ権限問題とは切り分けて対応する必要がある |
cursor permission deniedの原因と基礎知識

- cursor permission deniedとはどんなエラーなのか
- Permission deniedのエラーコードはEACCESとEACCESSの2種類
- Permission deniedを解消するにはどうすればいいですか
- macOSでcursor permission deniedが起きる主な原因はフォルダ所有権の誤り
- WindowsやLinuxでもcursor permission deniedが発生するケースがある
- エラーが出るタイミングと状況別の特徴まとめ
cursor permission deniedとはどんなエラーなのか

「cursor permission denied」というエラーは、AIコードエディタCursorがファイルやディレクトリに対してアクセス権限(読み書き・作成・削除など)を持っていない場合に発生するエラーだ。Cursorはアプリケーション内部でキャッシュ・ログ・拡張機能のデータを専用フォルダに書き込もうとするが、そのフォルダの所有者がCursorを起動しているユーザー以外になっているとき、あるいはパーミッション(アクセス権)の設定が制限されているときにこのエラーが発生する。
エラーメッセージの典型的な表示形式は下記のようなものだ。
A system error occurred (EACCES: permission denied, mkdir '/Users/username/Library/Application Support/Cursor/logs/YYYYMMDDTHHMMSS')
Please make sure the following directories are writeable:
~/Library/Application Support/Cursor
~/.cursor/extensions
(引用元: https://github.com/yuaotian/go-cursor-help/issues/536)
このメッセージが意味するのは、「Cursorがログフォルダを作ろうとしたが、書き込み権限がなかった」ということだ。エラー自体はCursorのコードバグではなく、OSのファイルシステムレベルの権限管理の問題である。だからこそ、Cursorを再インストールするだけでは直らないケースが多い。
🔑 Cursorのpermission deniedが影響するフォルダ(macOS)
| フォルダパス | 役割 |
|---|---|
~/Library/Application Support/Cursor |
ユーザーデータ・設定・ログ・キャッシュ |
~/.cursor/extensions |
インストールした拡張機能の格納場所 |
~/Library/Application Support/Cursor/User/globalStorage/storage.json |
グローバル設定ファイル |
~/Library/Application Support/Cursor/logs/ |
起動ログ・デバッグログ |
~/Library/Application Support/Cursor/CachedData/ |
キャッシュデータ |
これらのフォルダのどれかの所有権が「root」や他のユーザー名になっていると、Cursorが起動時または使用中に書き込みを拒否されてエラーになる。
重要なのは、このエラーが特定の操作をきっかけに突然起きることが多いという点だ。よくあるきっかけとしては以下のようなものが挙げられる。
✅ macOSのメジャーアップグレード(TahoeやSequoiaへの更新など)
✅ go-cursor-helpなどのサードパーティスクリプトを実行した後
✅ sudoを使ってCursorを起動したことがある
✅ 別ユーザーアカウントでCursorを一度起動した
✅ 新しいプロジェクトフォルダを別の場所に作った
特にsudoを使ってCursorを起動すると、その際に作成されたフォルダの所有者がrootになってしまい、以後通常ユーザーとして起動すると権限エラーが出続けるという問題が起きやすい。
Permission deniedのエラーコードはEACCESとEACCESSの2種類

「permission denied」という言葉と一緒によく出てくる文字列として、EACCES(またはEACCESS) がある。これはUnix/Linux系のシステムで定義されているPOSIX標準のエラーコードで、「アクセス権限がない(Error Access)」を示す。
📋 主なEACCES関連エラーの表示パターン
| 表示パターン | 意味 |
|---|---|
EACCES: permission denied, mkdir '...' |
ディレクトリを作成する権限がない |
EACCES: permission denied, open '...' |
ファイルを開く(読み書き)権限がない |
EACCES: permission denied, access '...' |
ファイル・フォルダへのアクセス権限がない |
Error: EACCES: permission denied |
Node.js(Electronベース)がアクセス拒否された |
NoPermissions (FileSystemError): Error: EACCES |
VSCode/Cursor独自のファイルシステムエラー表記 |
CursorはElectron(Node.js)ベースのアプリケーションなので、内部的にはNode.jsのファイルシステムAPIを使っている。そのためエラーメッセージもNode.jsスタイルのEACCES形式で出力されることが多い。
なお、フォーラムやissueを見ると「EACCESS」(Sが2つ)という表記も混在しているが、これは単なるスペルゆれで同じ問題を指している。正式なPOSIX定義では「EACCES」(Sは1つ)が正しい表記だ。
"EACCESS: Permission denied" error in Cursor points to a permissions issue. This usually occurs when Cursor tries to access a file or directory it doesn't have enough rights to.
(引用元: https://forum.cursor.com/t/cursor-eaccess-permission-denied/23527)
エラーコードそのものを理解しておくと、エラーメッセージの後半に書かれているパス情報を読み解きやすくなる。たとえばmkdir '/Users/a123/Library/Application Support/Cursor/CachedData/2f2737de...'という表示なら、「CachedDataフォルダを作ろうとして拒否された」とわかる。どのフォルダに問題があるかを特定することが、次のステップでの対応を速くする。
エラーコードを覚えておくメリットはもう一つあって、同じ「permission denied」でもGitや他ツールで出る場合と区別できる点だ。CursorのEACCESエラーはほぼ必ずパスが~/Library/Application Support/Cursorか~/.cursorを含んでいるため、それ以外のパスが表示されていたら原因の場所が違うと判断できる。
Permission deniedを解消するにはどうすればいいですか

最も基本的かつ効果的な解決策は、chownコマンドを使ってCursorのデータフォルダの所有権を現在のログインユーザーに戻すことだ。
macOSの場合、ターミナルで以下の2つのコマンドを実行する。
sudo chown -R $(whoami) ~/Library/Application\ Support/Cursor
sudo chown -R $(whoami) ~/.cursor
-Rは「Recursive(再帰的)」の意味で、指定フォルダの中にあるサブフォルダ・ファイルも含めてすべての所有権を変更する。$(whoami)は現在ログインしているユーザー名を自動的に取得するコマンドなので、自分のユーザー名を手打ちする必要がない。
🛠️ macOSでのpermission denied解消フロー
| ステップ | 操作内容 | コマンド |
|---|---|---|
| 1 | Cursorを完全に終了する | アプリを閉じる |
| 2 | ターミナルを開く | Spotlight → terminal |
| 3 | CursorデータフォルダのchownをLogged-inユーザーに変更 | sudo chown -R $(whoami) ~/Library/Application\ Support/Cursor |
| 4 | .cursorフォルダの所有権も変更 | sudo chown -R $(whoami) ~/.cursor |
| 5 | 変更を確認 | ls -la ~/Library/Application\ Support/ \| grep Cursor |
| 6 | Cursorを再起動 | 通常起動 |
上記のchownコマンドで解決しない場合は、続けてchmodコマンドも試してみる。chmodはパーミッション(読み書き実行の許可設定)そのものを変更するコマンドだ。
sudo chmod -R 755 ~/Library/Application\ Support/Cursor
sudo chmod -R 755 ~/.cursor
755は「所有者は読み書き実行可、グループと他者は読み込み実行のみ可」という意味のパーミッション設定だ。これによってCursorがフォルダを読み書きできるようになる。
もし特定のプロジェクトフォルダで問題が起きているなら、そのフォルダに対して同様にchmodを適用する。
sudo chmod 755 /path/to/your/folder/
(引用元: https://forum.cursor.com/t/cursor-eaccess-permission-denied/23527)
さらにそれでも解決しない場合、Cursorを別のディレクトリで新規プロジェクトとして作成して試す方法も有効だ。元のフォルダの上位階層に権限問題がある場合、より上流から権限が継承されてしまっているケースがあり、その場合は別ロケーションに移動するのが最もシンプルな解決策になる。
macOSでcursor permission deniedが起きる主な原因はフォルダ所有権の誤り

macOSでcursor permission deniedが発生する最も多い原因は、Cursorが使うデータフォルダの「所有者(Owner)」が意図せず変わってしまっていることだ。
通常、~/Library/Application Support/Cursorや~/.cursorフォルダはCursorをインストールしたログインユーザーが所有者になっている。しかし以下のような状況でrootユーザーや別のユーザーが所有者になってしまうことがある。
⚠️ macOSで所有権が変わってしまう主な状況
| 状況 | なぜ所有権が変わるか |
|---|---|
sudo cursorで起動した |
sudoはrootとして実行するため、作成ファイルの所有者がrootになる |
| go-cursor-helpなどのリセットスクリプトを実行した | スクリプト内でsudoを使ってフォルダを作り直す場合がある |
| macOSをメジャーアップグレードした | OSアップグレード時にApplicationSupportフォルダの権限が変わることがある |
| Time MachineやFinderからフォルダを復元した | 復元元の所有権情報がそのまま引き継がれる場合がある |
macOS Tahoe(macOS 26)など最新バージョンにアップグレード後にこの問題が起きやすいという報告も複数確認されている。
System : MacOS Tahoe
After executing the script, running cursor encountered the following error:
A system error occurred (EACCES: permission denied, mkdir '/Users/ethan/Library/Application Support/Cursor/logs/20250701T172848')
(引用元: https://github.com/yuaotian/go-cursor-help/issues/536)
この事例では、サードパーティのリセットスクリプト(go-cursor-help)を使った後にCursorが起動できなくなったというケースだ。スクリプト自体がsudoでフォルダを作り直したため、所有者がrootになってしまったと推測される。
📊 所有者確認コマンドと出力の読み方
| コマンド | 確認できること |
|---|---|
ls -la ~/Library/Application\ Support/ \| grep Cursor |
Cursorフォルダの所有者・権限を表示 |
ls -la ~/.cursor |
.cursorフォルダの所有者・権限を表示 |
whoami |
現在のログインユーザー名を表示 |
解決策は前述のchownコマンドで所有権を戻すことが基本だが、それでも解消しない場合は問題のフォルダを完全削除してCursorに再生成させる方法も有効だ。ただしCursorの設定・履歴・拡張機能も消える点は注意が必要だ。削除前に~/.cursor/extensionsや~/Library/Application Support/Cursor/Userの中身を別の場所にバックアップしておくと安心だ。
macOSの場合、Finderの「情報を見る」(⌘ + I)でフォルダを選択して下部の「共有とアクセス権」を確認するGUI的な方法もある。ただし再帰的に変更するにはやはりターミナルのコマンドの方が確実で速い。
WindowsやLinuxでもcursor permission deniedが発生するケースがある

cursor permission deniedはmacOSに限った問題ではなく、WindowsとLinuxでもそれぞれ異なる形で発生する。
Windowsの場合:
Windowsでは~/Library/...のようなUnixスタイルのパスはないが、C:\Users\ユーザー名\AppData\Roaming\CursorやC:\Users\ユーザー名\.cursorに相当するフォルダの権限が問題になることがある。企業のグループポリシーによってAppdataフォルダへの書き込みが制限されている場合や、管理者権限なしでインストールした際に起きやすい。
Linuxの場合(AppImage):
LinuxではCursorをAppImage形式で配布していることが多い。このとき、AppImageはマウントして実行される仕組みだが、/tmpパーティションがnoexec(実行不可)オプションでマウントされていると権限エラーが出る。
Failed to save 'file.ts': Command failed: ... /tmp/.mount_cursor86DJYP/usr/share/cursor/bin/cursor: Permission denied
(引用元: https://stackoverflow.com/questions/79761157/)
この場合の解決策は/tmpをexecオプションで再マウントすることだ。
sudo mount -o remount,exec /tmp
また、AppImageファイル自体に実行権限が付いていない場合も同様のエラーが出る。
chmod +x Cursor.AppImage
📋 OS別cursor permission deniedの特徴
| OS | 主な原因 | 主な解決策 |
|---|---|---|
| macOS | Cursorデータフォルダの所有者がroot | sudo chown -R $(whoami) ~/Library/Application\ Support/Cursor |
| Linux (AppImage) | /tmpのnoexecマウント / AppImageの実行権限なし | sudo mount -o remount,exec /tmp / chmod +x |
| Windows | Appdata権限制限 / グループポリシー | 管理者として実行 / 権限設定の確認 |
| 共通 | sudoで起動してroot所有者になった | chownで所有者を戻す |
Windowsでは「管理者として実行」でCursorを起動すれば一時的に回避できる場合があるが、根本解決としては問題のフォルダのプロパティから「セキュリティ」タブを開き、現在のユーザーにフルコントロールの権限を付与する方法が確実だ。
エラーが出るタイミングと状況別の特徴まとめ

cursor permission deniedは発生タイミングによって原因が異なる。エラーが出た状況を正確に把握することで、適切な解決策に素早くたどり着ける。
🕐 エラー発生タイミング別の傾向
| タイミング | 典型的なエラー内容 | 疑うべき原因 |
|---|---|---|
| Cursor起動直後 | EACCES: permission denied, mkdir ...logs/... |
データフォルダの所有権問題 |
| 新規ファイル作成時 | EACCES: permission denied |
プロジェクトフォルダの権限不足 |
| 拡張機能インストール時 | EACCES: permission denied, mkdir .../.cursor/extensions |
.cursor/extensionsフォルダの権限 |
| ファイル保存時(Linux) | cursor: Permission denied |
/tmpのnoexecマウント or AppImage実行権限 |
| git操作時 | Permission to repository denied to user |
SSH鍵・Git認証情報の問題(フォルダ権限とは別問題) |
| Claude Codeインストール時 | EACCES: permission denied, mkdir .../.local/state/claude |
.localフォルダのstate所有権問題 |
エラーメッセージのパスをよく読むと、どのフォルダが問題になっているかがわかる。例えばlogsフォルダで起きているのか、extensionsで起きているのか、それとも全体が読み込めないのかによって影響範囲が変わる。
特に注意が必要なのは、「git操作でPermission deniedが出る場合」とCursorのデータフォルダでのpermission deniedは別問題という点だ。GitのPermission deniedはSSH鍵の設定や認証トークンの問題であり、Cursorのディレクトリ権限を変えても解決しない。混同しないよう、エラーメッセージを正確に読むことが重要だ。
また、新しいプロジェクトを別の場所に作ったときだけエラーが出るという場合、問題はCursorのデータフォルダではなく、そのプロジェクトフォルダ自体の権限設定にある可能性が高い。この場合は、プロジェクトフォルダ自体のパーミッションを確認してchmodで調整するか、ホームディレクトリ配下など権限が十分な場所にプロジェクトを移動することで解決できることが多い。
✅ 状況別・最初に試すべき対応のまとめ
- 起動時にエラー →
sudo chown -R $(whoami) ~/Library/Application\ Support/Cursor && sudo chown -R $(whoami) ~/.cursor - 特定フォルダだけエラー → そのフォルダに
sudo chmod 755 - アップグレード後に発生 → chownコマンドを実行してから再起動
- Linux AppImage →
sudo mount -o remount,exec /tmp - git操作でエラー → SSH鍵やトークンの確認
cursor permission deniedの具体的な解決手順と応用ケース

- ディレクトリ所有者を変更するchownコマンドが最も効果的な解決策
- chmod 755でフォルダ権限を変更する具体的な手順
- CursorのキャッシュフォルダをリセットしてPermission deniedを解消する方法
- LinuxのAppImage環境でpermission deniedが出たときの解決策
- Claude Codeインストール時のpermission deniedは.localフォルダの権限変更で解決
- GitでPermission deniedが出た場合はSSH鍵・認証情報の確認が必要
- 総括:cursor permission deniedのまとめ
ディレクトリ所有者を変更するchownコマンドが最も効果的な解決策

前のセクションでも触れたが、cursor permission deniedの解決でまず試すべきコマンドがchownだ。ここでは実際の操作手順をより詳しく説明する。
chownは「change owner(所有者を変更する)」の略で、ファイルやディレクトリの所有者を指定したユーザーに変更するUnix系コマンドだ。-Rオプションを付けることで、そのディレクトリの下にある全ファイル・サブフォルダにも再帰的に適用される。
【手順1】まずCursorを完全に終了する
macOSなら⌘ + Qでアプリを終了するか、アクティビティモニタからCursorプロセスを強制終了する。Cursorが起動中だとファイルがロックされてchownが効かない場合がある。
【手順2】ターミナルで自分のユーザー名を確認する
whoami
これで表示された文字列が自分のユーザー名だ。以後の操作で使う。
【手順3】chownを実行する
sudo chown -R $(whoami) ~/Library/Application\ Support/Cursor
sudo chown -R $(whoami) ~/.cursor
sudoを実行するとパスワードを求められる。macOSのログインパスワードを入力する(入力中は何も表示されないが正常)。
【手順4】変更を確認する
ls -la ~/Library/Application\ Support/ | grep Cursor
🔍 ls -laの出力例(修正前後の比較)
| 状態 | 出力例 | 所有者 |
|---|---|---|
| 修正後(正常) | drwx------+ 30 yourname staff 960 May 29 10:00 Cursor |
yourname(自分) |
| 修正前(問題あり) | drwx------+ 30 root staff 960 May 29 10:00 Cursor |
root(要chown) |
表示された行の所有者が自分のユーザー名になっていれば成功だ。その後Cursorを通常起動して問題が解消されているか確認する。
このchownコマンドは https://github.com/yuaotian/go-cursor-help/issues/598 のようなGitHubのissueでも繰り返し推奨されている解決策だ。実際に世界中のCursorユーザーが同じ問題に直面して同じ解決策にたどり着いており、再現性が高い手法として定評がある。特にサードパーティのリセットツールを使った後に試してほしい方法だ。
また、.cursorフォルダだけでなく~/Library/Application Support/Cursorも忘れずに実行するのがポイントだ。片方だけ修正してもエラーが残るケースがあるため、必ず両方に対してコマンドを実行することを推奨する。
chmod 755でフォルダ権限を変更する具体的な手順

chownでは解決しないケースや、chownに加えて権限設定も直したい場合に使うのがchmodコマンドだ。chmodは「change mode(権限モードを変更する)」の略で、ファイル・ディレクトリの読み書き実行権限を数字または記号で指定して変更できる。
📊 chmod数字の読み方
| 桁 | 対象 | 数字の意味 | 権限の内訳 |
|---|---|---|---|
| 1桁目 | 所有者(Owner) | 7 | 読み取り(4) + 書き込み(2) + 実行(1) |
| 2桁目 | グループ(Group) | 5 | 読み取り(4) + 実行(1) |
| 3桁目 | その他(Others) | 5 | 読み取り(4) + 実行(1) |
| まとめ | 755全体 | 755 | 所有者は読み書き実行OK、他は読み込み実行のみ |
通常のCursorデータフォルダには755を適用する。
sudo chmod -R 755 ~/Library/Application\ Support/Cursor
sudo chmod -R 755 ~/.cursor/extensions
特定のプロジェクトフォルダに問題がある場合はそのパスを直接指定する。
sudo chmod 755 /path/to/your/project/folder/
(引用元: https://forum.cursor.com/t/cursor-eaccess-permission-denied/23527)
⚠️ chmod適用時の注意点
✅ -R(再帰的)を使うと大量のファイルに一括で権限が変わるので、対象フォルダのパスを間違えないようにする
✅ ホームディレクトリ全体(~/)に対して実行すると意図しないファイルの権限も変わるため、なるべくCursor関連フォルダのみに絞る
✅ chownとchmodはセットで実行することで確実に解消できるケースが多い
✅ chmod 777(全ユーザーに全権限)は権限を広げすぎてセキュリティリスクになるため使わない
chmodとchownを組み合わせて使う場合、まずchownで所有者を正しくしてからchmodで権限を設定するのが基本的な順序だ。所有者が正しくないまま権限だけ変えても、rootが所有するフォルダには通常ユーザーで書き込めないという問題が残る。
macOS Finder上でも権限を確認・変更できる。対象フォルダを選択して⌘ + I(情報を見る)を開き、下部の「共有とアクセス権」セクションで権限設定を確認することができる。ただしターミナルのコマンドの方が再帰的に一括変更できて確実で速いため、基本はコマンドラインでの操作を推奨する。
CursorのキャッシュフォルダをリセットしてPermission deniedを解消する方法

chownとchmodを試してもまだエラーが解消しない場合や、Cursorのアップデート後に急にエラーが出るようになった場合は、キャッシュフォルダごと削除して再生成させる方法が効果的なことがある。
Cursorは起動時に必要なフォルダが存在しない場合、自動的に作り直す仕組みを持っている。そのため、壊れたり所有権がおかしくなったフォルダを削除してしまえば、次の起動時にクリーンな状態で再作成される。
macOSでの手順:
# Cursorを完全に終了した状態で実行
rm -rf ~/Library/Application\ Support/Cursor/logs
rm -rf ~/Library/Application\ Support/Cursor/CachedData
rm -rf ~/Library/Application\ Support/Cursor/Code\ Cache
📁 削除してOKなフォルダ vs 残すべきフォルダ
| フォルダ | 削除可否 | 内容・注意 |
|---|---|---|
logs/ |
✅ 削除OK | 起動ログ(再生成される) |
CachedData/ |
✅ 削除OK | ダウンロードキャッシュ(再生成される) |
Code Cache/ |
✅ 削除OK | Chromiumキャッシュ(再生成される) |
User/ |
❌ 残す | 設定ファイル・keybindings・履歴 |
.cursor/extensions/ |
❌ 残す(権限修正のみ) | 拡張機能データ(削除すると再インストールが必要) |
ここで注意したいのは、User/フォルダやextensions/フォルダは削除しないことだ。これらには設定情報や拡張機能データが含まれているため、削除すると設定がリセットされてしまう。まずはlogsとキャッシュ系のフォルダだけを削除して試すのが安全だ。
削除後はCursorを起動すると自動的に空のフォルダが再作成される。このとき所有者は現在のログインユーザーになるため、permission deniedは解消されるはずだ。
もし完全にリセットしても構わない状況なら(拡張機能の再インストールが許容できるなら)、~/.cursorごと削除してから起動し直す方法もある。その場合は以下を実行する。
rm -rf ~/Library/Application\ Support/Cursor
rm -rf ~/.cursor
次回Cursorを起動したとき、フォルダが存在しないため自動的に新規作成される。
LinuxのAppImage環境でpermission deniedが出たときの解決策

Linux環境でCursorをAppImageとして使っている場合、macOSとは異なる原因でpermission deniedが発生することがある。特によく見られるのは、/tmpパーティションがnoexecオプションでマウントされているケースだ。
AppImageはファイルシステムイメージをループバックマウントして実行する仕組みで、デフォルトでは/tmpディレクトリにマウントポイントを作る。しかし多くのLinuxディストリビューションでは、セキュリティ対策として/tmpをnoexec(実行不可)でマウントしている設定になっていることがある。
この場合、以下のエラーが表示される。
/bin/bash: line 1: /tmp/.mount_cursor86DJYP/usr/share/cursor/bin/cursor: Permission denied
(引用元: https://stackoverflow.com/questions/79761157/)
🐧 Linux AppImage環境での解決策一覧
| 原因 | 解決策 | コマンド |
|---|---|---|
| /tmpがnoexecマウント | /tmpを再マウント | sudo mount -o remount,exec /tmp |
| AppImageに実行権限なし | 実行権限を付与 | chmod +x Cursor.AppImage |
| /tmpスペース不足 | 直接実行モード | ./Cursor.AppImage --appimage-extract-and-run |
| 恒久的に/tmpのnoexecを回避したい | /etc/fstabを編集 | tmpfsのオプションからnoexecを削除 |
sudo mount -o remount,exec /tmpはシステム再起動後に元に戻るため、恒久的に直したい場合は/etc/fstabの設定を変更するか、AppImageの実行先を/tmp以外に変更する必要がある。
もう一つよく使われる方法が--appimage-extract-and-runオプションだ。これはAppImageをマウントせずに一時ディレクトリに展開して実行するモードで、/tmpのnoexec制限を回避できる。
./Cursor.AppImage --appimage-extract-and-run
または、AppImageを/optや/usr/local/binなどのexecが許可されたパーティションに移動して実行するのも有効な回避策だ。どの方法が自分の環境に合っているかはディストリビューションやパーティション構成によって異なるため、まずsudo mount -o remount,exec /tmpを試して効果を確認してから判断するのがよいだろう。
Ubuntuの場合、デフォルトでは/tmpがnoexecになっていないケースも多いが、企業のセキュリティポリシーで制限されている環境では起きやすい。mount | grep /tmpでnoexecオプションが付いているか確認することができる。
Claude Codeインストール時のpermission deniedは.localフォルダの権限変更で解決

CursorとClaude Codeを組み合わせて使おうとしている人の間で、Claude Codeのインストール時にpermission deniedが出るという問題も報告されている。このケースはCursor本体のフォルダ権限ではなく、Claude Codeがインストール先に使う~/.local/state/フォルダの権限が原因だ。
EACCES: permission denied, mkdir '/Users/tsanengineer/.local/state/claude'
Try running with --force to override checks
(引用元: https://tsanengineer.com/tech/start-cursor-claude-code/)
このエラーが出る場合、~/.local/stateディレクトリの所有者がrootになっていることが多い。確認方法は以下のとおりだ。
ls -la ~/.local
stateという行の所有者がrootになっていたら、以下のコマンドで所有者を自分に変更する。
sudo chown ユーザー名 ~/.local/state
ユーザー名の部分はwhoamiで確認した自分のユーザー名に置き換える。
🔧 Claude Codeインストール時のpermission denied解決フロー
| ステップ | コマンド | 説明 |
|---|---|---|
| 1 | ls -la ~/.local |
stateディレクトリの所有者を確認 |
| 2 | whoami |
自分のユーザー名を確認 |
| 3 | sudo chown ユーザー名 ~/.local/state |
所有者を自分に変更 |
| 4 | ls -la ~/.local |
変更を確認(stateの所有者が自分になっていればOK) |
| 5 | curl -fsSL https://claude.ai/install.sh \| bash |
再度インストールを実行 |
この修正を行ったあとにインストールコマンドを再実行すると、エラーなくインストールが完了する。CursorのターミナルからClaude Codeを起動し、AIを活用した開発環境を整えることができるようになる。
なお、この問題が起きるのはmacOSで~/.local/stateディレクトリが何らかの理由(別ツールのインストールや別ユーザーの操作など)でroot所有になっているケースだ。一度修正してしまえば以後の再インストールでは出なくなる。
将来的に同様の問題が起きないようにするために、~/.localディレクトリ全体の所有者を一括で自分に変更しておく方法もある。
sudo chown -R $(whoami) ~/.local
ただしこれは~/.local配下のすべてのフォルダ・ファイルに影響するため、他のツールが同フォルダを共有している場合は注意が必要だ。まずstateフォルダだけを対象にした修正から試すことを推奨する。
GitでPermission deniedが出た場合はSSH鍵・認証情報の確認が必要

CursorでGitを使っている際に「Permission to repository denied to user」や「Permission denied (publickey)」というエラーが出ることがある。これはCursorのフォルダ権限とはまったく別の問題であり、GitのSSH認証やHTTPS認証に関わるエラーだ。
🔐 GitのPermission deniedの主な原因
| エラーメッセージ | 原因 | 解決策 |
|---|---|---|
Permission to repository denied to user |
GitHubのアカウント・トークンが間違っている | Cursorのgit認証情報をリセット |
Permission denied (publickey) |
SSH鍵が登録されていない、または対応していない | SSH鍵を再作成・GitHubに登録 |
Permission denied (仮想マシン再作成後) |
仮想マシンのIPが同じだが鍵が変わった | known_hostsの古いエントリを削除し鍵を再作成 |
特にSSHの鍵問題でよく起きるのは、仮想マシンやコンテナを再作成した後に同じIPで接続しようとするケースだ。
Permission denied (publickey).
(引用元: https://zenn.dev/masaru21/articles/db4576e3163694)
この記事では、削除した仮想マシンの秘密鍵を新しい仮想マシンに流用しようとしても接続できなかったという事例が紹介されている。同じIPアドレスで新しく作った仮想マシンに古い秘密鍵を使おうとすると、VSCode/CursorのSSH拡張機能が記録しているキーと一致しないためエラーになる。この場合は秘密鍵を作り直すのが確実だ。
ssh-keygen -t ed25519 -C "your-email@example.com"
新しい公開鍵(~/.ssh/id_ed25519.pubの内容)をGitHubのSSH Keysページに登録すれば、SSH経由でのPermission deniedは解消される。
✅ CursorのGit認証エラー解消チェックリスト
- [ ] GitHubのパスワードではなくPersonal Access Token(PAT)を使っているか確認
- [ ]
git config --global credential.helperでキャッシュの設定を確認 - [ ] macOSのキーチェーンに古い認証情報が残っていないか確認
- [ ] SSH使用の場合は
ssh-add ~/.ssh/id_ed25519で鍵をssh-agentに追加 - [ ]
ssh -T git@github.comでSSH接続自体が通るか確認 - [ ] 仮想マシン再作成後は
known_hostsから該当エントリを削除
Cursorのフォルダ権限(EACCES)とGit認証(Permission denied publickey)は同じ「permission denied」という言葉を含んでいても根本原因が完全に異なるため、混同しないように注意が必要だ。エラーメッセージをよく読んで、どちらの問題かを正確に判断した上で対応することが解決の早道だ。
なお、CursorにはGitHub連携機能があり、設定画面からGitHubアカウントを再認証することができる。HTTPSを使っている場合はここから認証をリセットするのが最も手軽な解決策になることもある。
総括:cursor permission deniedのまとめ

最後に記事のポイントをまとめます。
- cursor permission deniedはCursorのバグではなく、OSのファイルシステムレベルの権限設定(ディレクトリ所有権・パーミッション)が原因で起きるエラーである
- エラーコードはEACCES(またはEACCESS)と表示され、「アクセス権限がない」という意味を持つPOSIX標準のエラーコードである
- macOSでの最も効果的な解決策は
sudo chown -R $(whoami) ~/Library/Application\ Support/Cursorとsudo chown -R $(whoami) ~/.cursorのchownコマンドで所有者を現在ユーザーに戻すことである - Permission deniedを解消するには、chownで所有者を変更した上でchmodで755を設定するとより確実に解決できる
- sudoでCursorを起動すると所有者がrootになって以後通常ユーザーで起動できなくなるため、sudoでの起動は避けることが重要である
- macOSのメジャーアップグレードやgo-cursor-helpなどのサードパーティスクリプト実行後にも同様の問題が起きやすい
- LinuxのAppImage環境では/tmpのnoexecマウントがpermission deniedの原因になることがあり、
sudo mount -o remount,exec /tmpまたはAppImageへのchmod +xで解決できる - Claude Codeインストール時のpermission deniedは
~/.local/stateフォルダの所有権問題であり、sudo chownで所有者を変更することで解消できる - GitのPermission deniedはCursorのフォルダ権限とは別問題であり、SSH鍵の再作成またはGit認証情報のリセットで対応する必要がある
- エラーメッセージに含まれるパスを確認することで原因箇所が特定でき、適切な解決策に素早くたどり着ける
- chownとchmodで解決しない場合はCursorのlogsやCachedDataフォルダを削除して再生成させる方法も有効である
- macOS Tahoe(macOS 26)など最新OSへのアップグレード後はCursorのフォルダ権限が変わりやすいため、アップグレード後にエラーが出たらまずchownコマンドを試すことが推奨される
記事作成にあたり参考にさせて頂いたサイト
- https://forum.cursor.com/t/cursor-eaccess-permission-denied/23527
- https://github.com/yuaotian/go-cursor-help/issues/598
- https://cursor.com/docs/cli/reference/permissions
- https://qiita.com/sophytoeat/items/586769eb22cc350a6a97
- https://www.youtube.com/watch?v=dHm5yLI7-iw
- https://tsanengineer.com/tech/start-cursor-claude-code/
- https://github.com/yuaotian/go-cursor-help/issues/536
- https://zenn.dev/masaru21/articles/db4576e3163694
- https://stackoverflow.com/questions/79761157/bin-bash-line-1-tmp-mount-cursor86djyp-usr-share-cursor-bin-cursor-permiss
- https://blog.cloudnative.co.jp/26826/
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。
