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

cursor permission deniedとはどんなエラーなのか

【AI】【業務効率化】【職場】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種類

【AI】【業務効率化】【職場】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を解消するにはどうすればいいですか

【AI】【業務効率化】【職場】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が起きる主な原因はフォルダ所有権の誤り

【AI】【業務効率化】【職場】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が発生するケースがある

【AI】【業務効率化】【職場】WindowsやLinuxでもcursor permission deniedが発生するケースがある

cursor permission deniedはmacOSに限った問題ではなく、WindowsとLinuxでもそれぞれ異なる形で発生する

Windowsの場合:
Windowsでは~/Library/...のようなUnixスタイルのパスはないが、C:\Users\ユーザー名\AppData\Roaming\CursorC:\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/)

この場合の解決策は/tmpexecオプションで再マウントすることだ。

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を起動すれば一時的に回避できる場合があるが、根本解決としては問題のフォルダのプロパティから「セキュリティ」タブを開き、現在のユーザーにフルコントロールの権限を付与する方法が確実だ。


エラーが出るタイミングと状況別の特徴まとめ

【AI】【業務効率化】【職場】エラーが出るタイミングと状況別の特徴まとめ

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鍵やトークンの確認

ふるさと納税のポイント付与は2025年10月に廃止になりました。

cursor permission deniedの具体的な解決手順と応用ケース

【AI】【業務効率化】【職場】エラーが出るタイミングと状況別の特徴まとめ
  1. ディレクトリ所有者を変更するchownコマンドが最も効果的な解決策
  2. chmod 755でフォルダ権限を変更する具体的な手順
  3. CursorのキャッシュフォルダをリセットしてPermission deniedを解消する方法
  4. LinuxのAppImage環境でpermission deniedが出たときの解決策
  5. Claude Codeインストール時のpermission deniedは.localフォルダの権限変更で解決
  6. GitでPermission deniedが出た場合はSSH鍵・認証情報の確認が必要
  7. 総括:cursor permission deniedのまとめ

ディレクトリ所有者を変更するchownコマンドが最も効果的な解決策

【AI】【業務効率化】【職場】ディレクトリ所有者を変更する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でフォルダ権限を変更する具体的な手順

【AI】【業務効率化】【職場】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を解消する方法

【AI】【業務効率化】【職場】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が出たときの解決策

【AI】【業務効率化】【職場】LinuxのAppImage環境でpermission deniedが出たときの解決策

Linux環境でCursorをAppImageとして使っている場合、macOSとは異なる原因でpermission deniedが発生することがある。特によく見られるのは、/tmpパーティションがnoexecオプションでマウントされているケースだ。

AppImageはファイルシステムイメージをループバックマウントして実行する仕組みで、デフォルトでは/tmpディレクトリにマウントポイントを作る。しかし多くのLinuxディストリビューションでは、セキュリティ対策として/tmpnoexec(実行不可)でマウントしている設定になっていることがある。

この場合、以下のエラーが表示される。

/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フォルダの権限変更で解決

【AI】【業務効率化】【職場】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鍵・認証情報の確認が必要

【AI】【業務効率化】【職場】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のまとめ

【AI】【業務効率化】【職場】総括:cursor permission deniedのまとめ

最後に記事のポイントをまとめます。

  1. cursor permission deniedはCursorのバグではなく、OSのファイルシステムレベルの権限設定(ディレクトリ所有権・パーミッション)が原因で起きるエラーである
  2. エラーコードはEACCES(またはEACCESS)と表示され、「アクセス権限がない」という意味を持つPOSIX標準のエラーコードである
  3. macOSでの最も効果的な解決策はsudo chown -R $(whoami) ~/Library/Application\ Support/Cursorsudo chown -R $(whoami) ~/.cursorのchownコマンドで所有者を現在ユーザーに戻すことである
  4. Permission deniedを解消するには、chownで所有者を変更した上でchmodで755を設定するとより確実に解決できる
  5. sudoでCursorを起動すると所有者がrootになって以後通常ユーザーで起動できなくなるため、sudoでの起動は避けることが重要である
  6. macOSのメジャーアップグレードやgo-cursor-helpなどのサードパーティスクリプト実行後にも同様の問題が起きやすい
  7. LinuxのAppImage環境では/tmpのnoexecマウントがpermission deniedの原因になることがあり、sudo mount -o remount,exec /tmpまたはAppImageへのchmod +xで解決できる
  8. Claude Codeインストール時のpermission deniedは~/.local/stateフォルダの所有権問題であり、sudo chownで所有者を変更することで解消できる
  9. GitのPermission deniedはCursorのフォルダ権限とは別問題であり、SSH鍵の再作成またはGit認証情報のリセットで対応する必要がある
  10. エラーメッセージに含まれるパスを確認することで原因箇所が特定でき、適切な解決策に素早くたどり着ける
  11. chownとchmodで解決しない場合はCursorのlogsやCachedDataフォルダを削除して再生成させる方法も有効である
  12. macOS Tahoe(macOS 26)など最新OSへのアップグレード後はCursorのフォルダ権限が変わりやすいため、アップグレード後にエラーが出たらまずchownコマンドを試すことが推奨される

記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

ABOUT ME
カシワギ
『エグゼクティブワーク』編集長のカシワギです。 普段はITベンチャーで執行役員の40代男です。 元コンサルタントですが、今はテクノロジー企業で日々奮闘中。 仕事では厳しい顔をしていますが、家では小学生の子供2人のやんちゃなパパ。 休日はゴルフに行ったり、妻とワインを楽しんだり。
当サイトについて
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。