Cursor で Dev Container が起動できない（.cursor 配下のシンボリックリンクが原因のときの対処法）

（追記: 2026.03.20）その後の調査で.cursorに限らずコンテナ内でシンボリックリンクを作成することが原因だったことが判明したため、「.cursor.bak からの復元」は推奨しません。詳しくは次の記事を参照してください。: Cursor で Dev Container 上での ln -s が原因で Dev Container が起動できなくなる話

はじめに

Cursor で Dev Container を使っていると、Extension host terminated unexpectedly でリモートが起動できなくなることがあります。とくに、複数リポジトリで .cursor の rules / commands / skills をシンボリックリンクで共有している構成で、リンク切れを起こしているときに発生しがちです。（ジャンクションの場合は発生しません。ジャンクションをシンボリックリンクに変換すると発生します）

（訂正: 2026.03.20）「ジャンクションかどうか」そのものではなく、Windows NTFS を bind mount している Dev Container 環境で、Dev Container 内 ln -s により LX_SYMLINK（reparse tag: 0xa000001d）相当が作られる経路がトリガーになり得ることが分かりました（.cursor やリンク切れに限定されません）。

本記事では、その現象・原因の整理と、**暫定対応（.cursor.bak からの復元）**をまとめます。同じ事象で困っている方の参考になれば幸いです。

現象

• 症状: プロジェクトを「フォルダで開く」で開いたあと、Extension host が終了し、Dev Container が起動できない。
• 発生条件: プロジェクトの .cursor 配下の commands・rules・skills・mcp.json が、別リポジトリや別パスへのシンボリックリンクになっており、かつリンク切れを起こしている場合。
  • Windows ホストで Cursor + Dev Containers 拡張の「Reopen in Container」を使用し、Dev Container 側で参照するワークスペースが Windows NTFS を bind mount していること。
  • さらに、Dev Container の起動スクリプト等で ln -s が実行され、ホスト側 NTFS に LX_SYMLINK（reparse tag: 0xa000001d）相当が作られること（.cursor に限定されません）。
  • LX_SYMLINK 相当にならない状態では、本現象が発生しにくいです。
• 環境: Windows ホスト、Cursor + Dev Containers 拡張で「Reopen in Container」を使用。

コラム：ジャンクションとは？

ジャンクション（Junction）は、Windows の「ディレクトリを別のディレクトリへ向ける」ための仕組みの一つで、再解析ポイント（Reparse Point）の一種です。見た目はフォルダですが、実体は別パスを指しています。

• シンボリックリンク（シンボリックリンク ディレクトリ）と似ていますが、歴史的にはジャンクションの方が古く、主にローカルドライブ内のディレクトリを指す用途で使われます。Windows の mklink /J で作成できます。
• Git の mode 120000（シンボリックリンクとして登録されたファイル）を Windows で checkout すると、環境によってはリンク先パスが書かれた通常ファイルやジャンクションとして取り出され、Linux のような「シンボリックリンク」にはならないことがあります。
• 本記事で「ジャンクションの場合は発生しない」と書いているのは、その「ジャンクションやファイルとして見えている状態」では Cursor の Extension host は落ちないという意味です。同じリポジトリをシンボリックリンクに変換（例: restore_symlinks.sh で ln -s を実行）すると、リンク解決の挙動が変わり、リンク切れ時に本現象が発生しやすくなります。

出典: Microsoft Learn Reparse Points、mklink

背景：ディレクトリ構成

複数リポジトリで Cursor の設定を共有するため、次のような構成にしているケースです。

• 各プロジェクトのルートに .cursor ディレクトリ（実体）を置く。
• その中身の一部（commands / rules / skills / mcp.json）だけ、別リポジトリの共有設定ディレクトリ（下記例ではaidd）へのリンクにする。
• settings.json はリンクにせず、プロジェクトごとに実体で持つ。
• 運用として各プロジェクトでDev Containerのビルド後に、別リポジトリも含むワークスペースファイルを開いている。

/workspace/
├── project/                           （各プロジェクトのルート）
│   ├── .cursor/                       （実体のディレクトリ）
│   │   ├── commands      ──────────→ リンク（先: aidd/cursor/.cursor/commands）
│   │   ├── rules         ──────────→ リンク（先: aidd/cursor/.cursor/rules）
│   │   ├── skills        ──────────→ リンク（先: aidd/cursor/.cursor/skills）
│   │   ├── mcp.json      ──────────→ リンク（先: aidd/cursor/.cursor/mcp.json）
│   │   └── settings.json             （実体。リンクではない）
│   └── （その他プロジェクトのファイル）
│
└── aidd/
    └── cursor/
        └── .cursor/                   （共有設定の実体）
            ├── commands
            ├── rules
            ├── skills
            └── mcp.json

この「.cursor 配下にシンボリックリンクがありリンク切れしている」状態でフォルダを開くと、Cursor がリンクを解決する過程で Extension host が落ちると考えられます（ジャンクションでは発生せず、シンボリックリンクにしたときのみ発生するため、Cursor のシンボリックリンク解決まわりの挙動が関与している可能性があります）。

このような構成（例: .cursor 配下で共有するためにシンボリックリンクを使っている）にすると、Dev Container の起動スクリプト等で ln -s が実行され、結果としてホスト側 NTFS に LX_SYMLINK（reparse tag: 0xa000001d）相当が作られやすくなります。その状態でフォルダを開くと、Cursor が参照/解決する過程で Extension host が落ちると考えられます。

## 暫定対応：.cursor.bak から復元する

ホストに シンボリックリンクを含む.cursor が存在するままでは Cursor が不安定になるため、フォルダを開くときは「.cursor がない状態」にしておく運用にします。

### 手順

1. Cursor を終了する。
2. プロジェクトルート直下の .cursor を削除する。実体を残したい場合は、事前に .cursor.bak など別名でコピーしておく。
3. プロジェクトフォルダをフォルダで開く（.cursor が無い状態で開く）。
4. 「Reopen in Container」 を実行する。
5. コンテナ作成時に postCreateCommand で、.cursor.bak の内容を .cursor にコピーするスクリプトを実行する。

これで、コンテナ内では .cursor が復元され、Cursor が commands / rules / skills 等を参照できるようになります。ワークスペースがバインドマウントなので、復元された .cursor はホストからも見えますが、ホスト上ではジャンクションに見えます。

### 運用上の注意

- 次に同じプロジェクトを開く前に、ホスト上で再度 .cursor を削除する必要があります（.cursor.bak は残す）。でないと、また Extension host が落ちて Dev Container が起動しません。
- そのため「毎回フォルダを開く前に .cursor を手動削除」という手間が発生します。

復元スクリプトの例（.cursor.bak を .cursor にコピーするだけのシンプルなもの）は、.devcontainer/restore_cursor_from_bak.sh のような名前で用意し、postCreateCommand から呼び出す形にするとよいです。cp -r でコピーすれば、シンボリックリンクはシンボリックリンクのまま復元されます。

（追記: 2026.03.20）このrestore_symlinks.shそのものがトラブルの原因でした
## 補足：Git のシンボリックリンクをコンテナ内で復元する（restore_symlinks.sh）

Windows で通常の権限で clone すると、Git の mode 120000（シンボリックリンク） が「リンク先パスが書かれた普通のファイル」（ジャンクション）として checkout されることがあります。Dev Container 内ではシンボリックリンクとして使いたいため、postCreateCommand で Git の 120000 エントリを走査し、ln -s でリンクに戻すスクリプトを実行しています。

例: .devcontainer/restore_symlinks.sh で、git ls-files -s の結果から 120000 のパスを抽出し、git show ":$path" でリンク先を取得して ln -s で復元する。
このスクリプトは .cursor に限らずリポジトリ全体のシンボリックリンクを復元する汎用用途です。

今回のトラブルでは結局この運用がCursorと相性が悪かったようです。ジャンクションからシンボリックリンクに変換しなければ問題は起こらないので、git clone直後の状態ではExtension host terminated unexpectedlyは発生しません。~~

（追記: 2026.03.20）上記の「.cursor.bak から復元する」「restore_symlinks.sh」相当の運用は誤っているため推奨しません。実際の対応は次の記事を参照してください。: Cursor で Dev Container 上での ln -s が原因で Dev Container が起動できなくなる話

VS Code では発生しない

同じディレクトリ構成・同じ Dev Container 設定でも、VS Code で開いた場合は本現象は発生しません。VS Code は起動時に .cursor を参照しないため当然です。.cursor 配下にリンクがある状態のまま「Reopen in Container」しても、Extension host は落ちず、Dev Container は正常に起動します。そのため、VS Code では .cursor.bak を復元する運用は不要です。なお、.cursor ではなく .vscode 配下で同様にシンボリックリンクで共有した場合にどうなるかは試していません。

おわりに

• Cursor で Dev Container が起動しない場合、.cursor 配下にシンボリックリンクがありリンク切れしていないかを確認してみてください （ジャンクションの場合は本現象は発生しません）。
  • Windows NTFS を bind mount しているワークスペース上で、Dev Container 内の ln -s により LX_SYMLINK 相当（reparse tag: 0xa000001d）が作られていないかを確認してみてください。
• （追記: 2026.03.20）上記の「.cursor を削除 → フォルダを開く → Reopen in Container → postCreateCommand で .cursor.bak から復元」の手順は推奨しません。対応は次の記事を参照してください。: Cursor で Dev Container 上での ln -s が原因で Dev Container が起動できなくなる話
  - 上記のとおり 「.cursor を削除 → フォルダを開く → Reopen in Container → postCreateCommand で .cursor.bak から復元」 の流れで、暫定的に Dev Container を利用することは可能です。
  - 根本対応としては、Cursor 側で「.cursor 配下にリンクがある場合でも Extension host が落ちないようにする」改善が行われると、.cursor.bak 運用が不要になり望ましいです。Cursor のサポートには報告と改善要望提出済みです。

---

動作確認環境:

• Cursor 2.6.13 (user setup) / VS Code 1.105.1 ベース
• OS: Windows_NT x64 10.0.26200
• Dev Containers: anysphere.remote-containers 1.0.32