VS Codeのエージェントモードを拡張するには、を試してください！

リモート開発のヒントとテクニック

この記事では、Visual Studio Code の リモート開発 拡張機能ごとのトラブルシューティングのヒントとテクニックについて説明します。各拡張機能の設定と使用の詳細については、SSH、コンテナ、および WSL の記事を参照してください。または、入門的な チュートリアル を試して、リモート環境で迅速に作業を開始することもできます。

GitHub Codespaces に関するヒントと質問については、GitHub Codespaces ドキュメントを参照してください。

SSH のヒント

SSH は強力で柔軟ですが、その分セットアップの複雑さも増します。このセクションでは、Remote - SSH 拡張機能をさまざまな環境で起動して実行するためのヒントとテクニックを紹介します。

AI チャット応答のカスタマイズ

カスタム指示 を使用すると、一般的なガイドラインやルールを記述して、特定のコーディングプラクティスや技術スタックに一致する応答を得ることができます。

カスタム指示を使用して、接続しているリモート環境の種類 (どのような種類の言語やツールチェーンがインストールされているかなど) に関する詳細情報を Copilot に提供できます。ローカルと同じように copilot-instructions.md ファイルを使用できます。dev コンテナを使用する際には、追加の指示設定手順 を実行することもできます。

$EDITOR 変数の構成

macOS / Linux のリモートホストの場合、このスニペットをシェル設定ファイル (.bashrc や .zshrc など) に追加します。

if [ "$VSCODE_INJECTION" = "1" ]; then
    export EDITOR="code --wait" # or 'code-insiders' if you're using VS Code Insiders
fi

Windows ホストの場合、同等の PowerShell は次のとおりです。

if ($env:VSCODE_INJECTION -eq "1") {
    $env:EDITOR = "code --wait"  # or 'code-insiders' for VS Code Insiders
}

これで、git commit のように $EDITOR 変数を使用するターミナルコマンドを実行すると、デフォルトのターミナルベースエディタ (vim や nano など) の代わりに VS Code でファイルが開きます。

キーベース認証の構成

SSH 公開鍵認証 は、ローカルの「秘密鍵」と、SSH ホストのユーザーアカウントに関連付ける「公開鍵」を組み合わせた、便利でセキュリティの高い認証方法です。このセクションでは、これらの鍵を生成し、ホストに追加する方法を説明します。

ヒント: Windows 用の PuTTY は サポートされているクライアント ではありませんが、PuTTYGen で生成された鍵を変換する ことができます。

クイックスタート: SSH 鍵の使用

リモートホストの SSH 鍵ベース認証を設定します。まず、鍵ペアを作成し、次に公開鍵をホストにコピーします。

ローカル SSH 鍵ペアの作成

ローカルマシンに SSH 鍵が既に存在するかどうかを確認します。macOS / Linux では通常 ~/.ssh/id_ed25519.pub に、Windows ではユーザープロファイルフォルダーの .ssh ディレクトリにあります (例: C:\Users\your-user\.ssh\id_ed25519.pub)。

鍵がない場合は、ローカルターミナル / PowerShell で次のコマンドを実行して SSH 鍵ペアを生成します。

ssh-keygen -t ed25519 -b 4096

ヒント: ssh-keygen がありませんか？サポートされている SSH クライアントをインストール してください。

秘密鍵ファイルのアクセス許可を制限する

  • macOS / Linux の場合、必要に応じて秘密鍵へのパスを置き換えて、次のシェルコマンドを実行します。

    chmod 400 ~/.ssh/id_ed25519

  • Windows の場合、PowerShell で次のコマンドを実行して、ユーザー名に明示的な読み取りアクセス権を付与します。

    icacls "privateKeyPath" /grant <username>:R

    次に、Windows Explorer で秘密鍵ファイルに移動し、右クリックして [プロパティ] を選択します。[セキュリティ] タブ > [詳細設定] > [継承を無効にする] > [このオブジェクトから継承されたすべてのアクセス許可を削除する] を選択します。

macOS または Linux マシンを接続用に承認する

ローカルターミナルウィンドウで、ユーザー名とホスト名を適切に置き換えて、次のコマンドのいずれかを実行し、ローカル公開鍵を SSH ホストにコピーします。

  • macOS または Linux SSH ホストへの接続

    export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh-copy-id -i "$PUBKEYPATH" "$USER_AT_HOST"

  • Windows SSH ホストへの接続

    • ホストは OpenSSH Server を使用しており、ユーザーは 管理者グループに属しています。

      export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh $USER_AT_HOST "powershell Add-Content -Force -Path \"\$Env:PROGRAMDATA\\ssh\\administrators_authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"

    • それ以外の場合

      export USER_AT_HOST="your-user-name-on-host@hostname"
export PUBKEYPATH="$HOME/.ssh/id_ed25519.pub"

ssh $USER_AT_HOST "powershell New-Item -Force -ItemType Directory -Path \"\$HOME\\.ssh\"; Add-Content -Force -Path \"\$HOME\\.ssh\\authorized_keys\" -Value '$(tr -d '\n\r' < "$PUBKEYPATH")'"

      SSH ホスト上のリモートユーザーの .ssh フォルダ内の authorized_keys ファイルがあなたによって所有されており、他のユーザーがアクセスする許可がないことを検証することをお勧めします。詳細については、OpenSSH Wiki を参照してください。

Windows マシンを接続用に承認する

ローカル PowerShell ウィンドウで、ユーザー名とホスト名を適切に置き換えて、次のコマンドのいずれかを実行し、ローカル公開鍵を SSH ホストにコピーします。

  • macOS または Linux SSH ホストへの接続

    $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

$pubKey=(Get-Content "$PUBKEYPATH" | Out-String); ssh "$USER_AT_HOST" "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '${pubKey}' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

  • Windows SSH ホストへの接続

    • ホストは OpenSSH Server を使用しており、ユーザーは 管理者グループに属しています。

      $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"Add-Content -Force -Path `"`$Env:PROGRAMDATA\ssh\administrators_authorized_keys`" `""

    • それ以外の場合

      $USER_AT_HOST="your-user-name-on-host@hostname"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"

Get-Content "$PUBKEYPATH" | Out-String | ssh $USER_AT_HOST "powershell `"New-Item -Force -ItemType Directory -Path `"`$HOME\.ssh`"; Add-Content -Force -Path `"`$HOME\.ssh\authorized_keys`" `""

      SSH ホスト上のリモートユーザーの .ssh フォルダー内の authorized_keys ファイルがあなたによって所有されており、他のユーザーがアクセスする権限がないことを検証してください。詳細については、OpenSSH wiki を参照してください。

専用鍵によるセキュリティ強化

すべての SSH ホストで単一の SSH 鍵を使用すると便利ですが、誰かがあなたの秘密鍵にアクセスした場合、すべてのホストにもアクセスできるようになります。これを防ぐには、開発ホスト用に別の SSH 鍵を作成します。以下の手順に従ってください。

  1. 別のファイルに個別の SSH 鍵を生成します。

    macOS / Linux: ローカルターミナルで次のコマンドを実行します。

    ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519-remote-ssh

    Windows: ローカル PowerShell で次のコマンドを実行します。

    ssh-keygen -t ed25519 -f "$HOME\.ssh\id_ed25519-remote-ssh"

  2. SSH ホストで鍵を承認するために クイックスタート と同じ手順に従いますが、PUBKEYPATH を id_ed25519-remote-ssh.pub ファイルに設定します。

  3. VS Code で、コマンドパレット (F1) から Remote-SSH: Open Configuration File... を実行し、SSH 設定ファイルを選択して、次のようにホストエントリを追加 (または変更) します。

    Host name-of-ssh-host-here
    User your-user-name-on-host
    HostName host-fqdn-or-ip-goes-here
    IdentityFile ~/.ssh/id_ed25519-remote-ssh

    ヒント: Windows パスにも / を使用できます。\ を使用する場合は、2 つのスラッシュが必要になります。例: C:\\path\\to\\my\\id_ed25519。

PuTTYGen で生成された鍵の再利用

接続先のホストに SSH 公開鍵認証を設定するために PuTTYGen を使用した場合、他の SSH クライアントが使用できるように秘密鍵を変換する必要があります。これを行うには

  1. ローカルで PuTTYGen を開き、変換したい秘密鍵をロードします。

  2. アプリケーションメニューから [変換] > [OpenSSH 鍵のエクスポート] を選択します。変換された鍵を、ユーザープロファイルフォルダーの .ssh ディレクトリ (例: C:\Users\youruser\.ssh) 内のローカルの場所に保存します。

  3. この新しいローカルファイルがあなたによって所有されており、他のユーザーがアクセスする権限がないことを検証してください。

  4. VS Code で、コマンドパレット (F1) から Remote-SSH: Open Configuration File... を実行し、変更したい SSH 設定ファイルを選択して、ファイルを参照するように設定ファイルに次のようにホストエントリを追加 (または変更) します。

    Host name-of-ssh-host-here
    User your-user-name-on-host
    HostName host-fqdn-or-ip-goes-here
    IdentityFile ~/.ssh/exported-keyfile-from-putty

マルチユーザーサーバーのセキュリティ強化

Remote - SSH 拡張機能は、「VS Code Server」をインストールし、維持します。サーバーはランダムに生成されたキーで起動され、サーバーへの新しい接続はすべてキーを提供する必要があります。キーはリモートのディスクに保存され、現在のユーザーのみが読み取り可能です。認証なしで利用可能な HTTP パスは /version が1つだけです。

デフォルトでは、サーバーはランダムな TCP ポートで localhost をリッスンし、そのポートはローカルマシンに転送されます。Linux または macOS ホストに接続している場合、特定のユーザーにロックダウンされた Unix ソケットを使用するように切り替えることができます。このソケットはポートの代わりに転送されます。

注: この設定は 接続の多重化を無効にする ため、公開鍵認証の構成 をお勧めします。

設定するには

  1. Windows、macOS、または Linux に ローカル OpenSSH 6.7+ SSH クライアント と OpenSSH 6.7+ Linux または macOS ホスト があることを確認してください (Windows はこのモードをサポートしていません)。

  2. ローカル VS Code ユーザー設定 で Remote.SSH: Remote Server Listen On Socket を有効にして、Remote - SSH をソケットモードに切り替えます。

    Listen on socket VS Code setting

  3. すでに SSH ホストに接続している場合は、コマンドパレット (F1) から Remote-SSH: Kill VS Code Server on Host... を選択して、設定を有効にします。

接続時にエラーが発生した場合は、SSH ホストの sshd 設定 でソケット転送を有効にする必要があるかもしれません。そのためには

  1. SSH ホスト (ローカルではない) で、テキストエディタ (vi、nano、pico など) を使って /etc/ssh/sshd_config を開きます。
  2. AllowStreamLocalForwarding yes の設定を追加します。
  3. SSH サーバーを再起動します。(Ubuntu では sudo systemctl restart sshd を実行します。)
  4. 再試行します。

ハングまたは接続失敗のトラブルシューティング

VS Code が接続しようとしているときにハングしたり (そしてタイムアウトしたりする可能性もあります)、問題が発生した場合は、いくつかのことを試して解決できます。

一般的なトラブルシューティング: サーバーの削除

Remote-SSH のさまざまな問題をトラブルシューティングするのに役立つコマンドの1つは Remote-SSH: Kill VS Code Server on Host です。これによりサーバーが削除され、「server_name への接続を確立できませんでした: VS Code Server が起動できませんでした。」といった広範な問題やエラーメッセージを修正できます。

VS Code がプロンプトを待っているかどうかを確認する

VS Code の remote.SSH.showLoginTerminal 設定 を有効にして再試行します。パスワードまたはトークンの入力を求められた場合は、プロンプトの頻度を減らす方法の詳細について 代替 SSH 認証方法の有効化 を参照してください。

それでも問題が解決しない場合は、settings.json に次のプロパティを設定して再試行してください。

"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false

Windows OpenSSH サーバーの一部のバージョンにおけるバグの回避策

特定のバージョンの Windows 用 OpenSSH サーバーのバグにより、ホストが Windows を実行しているかどうかを判断するためのデフォルトのチェックが正しく機能しない場合があります。これは、Windows 1909 以前に付属している OpenSSH サーバーでは発生しません。

幸いなことに、settings.json に次を追加して、SSH ホストが Windows を実行しているかどうかを VS Code に明示的に伝えることで、この問題を回避できます。

"remote.SSH.useLocalServer": false

また、次のプロパティを使用して、特定のホストを Windows として強制的に識別させることもできます。

"remote.SSH.remotePlatform": {
    "host-in-ssh-config-or-fqdn": "windows"
}

修正がマージされたため、この問題はバージョン 8.1.0.0 より大きいサーバーで解決されるはずです。

リモートホストでの TCP 転送の有効化

Remote - SSH 拡張機能は、ホストとの通信を容易にするために SSH トンネルを利用しています。場合によっては、これが SSH サーバーで無効になっていることがあります。これが問題であるかどうかを確認するには、出力ウィンドウで Remote - SSH カテゴリを開き、次のメッセージを確認してください。

open failed: administratively prohibited: open failed

このメッセージが表示された場合は、次の手順に従って SSH サーバーの sshd 設定 を更新してください。

  1. SSH ホスト (ローカルではない) で、テキストエディタ (Vim、nano、Pico、Notepad など) を使って /etc/ssh/sshd_config または C:\ProgramData\ssh\sshd_config を開きます。
  2. AllowTcpForwarding yes の設定を追加します。
  3. SSH サーバーを再起動します。(Ubuntu では sudo systemctl restart sshd を実行します。Windows では、管理者 PowerShell で Restart-Service sshd を実行します。)
  4. 再試行します。

SSH 設定ファイルで ProxyCommand パラメータを設定する

プロキシの背後にいて SSH ホストに接続できない場合は、ローカル SSH 設定ファイル でホストの ProxyCommand パラメータを使用する必要があるかもしれません。使用例については、この SSH ProxyCommand の記事 を参照してください。

リモートマシンにインターネットアクセスがあることを確認する

リモートマシンは、Marketplace から VS Code Server と拡張機能をダウンロードできるように、インターネットアクセスを持っている必要があります。接続要件の詳細については、FAQ を参照してください。

リモートホストで HTTP_PROXY / HTTPS_PROXY を設定する

リモートホストがプロキシの背後にある場合、SSH ホストで HTTP_PROXY または HTTPS_PROXY 環境変数を設定する必要があるかもしれません。~/.bashrc ファイルを開き、次の行を追加します (proxy.fqdn.or.ip:3128 を適切なホスト名 / IP とポートに置き換えてください)。

export HTTP_PROXY=http://proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY

# Or if an authenticated proxy
export HTTP_PROXY=http://username:password@proxy.fqdn.or.ip:3128
export HTTPS_PROXY=$HTTP_PROXY

noexec でマウントされた /tmp の回避策

一部のリモートサーバーは、/tmp からのスクリプトの実行を許可しないように設定されています。VS Code はインストールスクリプトをシステムの一時ディレクトリに書き込み、そこから実行しようとします。システム管理者に相談して、これを回避できるかどうかを判断できます。

インストール中に別のシェルが起動するかどうかを確認する

一部のユーザーは、デフォルトとは異なるシェルを使用したいという理由で、SSH ホストの .bash_profile やその他のスタートアップスクリプトから別のシェルを起動します。これは VS Code のリモートサーバーインストールスクリプトを破損させる可能性があり、お勧めできません。代わりに、chsh を使用してリモートマシンのデフォルトシェルを変更してください。

接続ごとにマシンを動的に割り当てるシステムへの接続

一部のシステムでは、SSH 接続が行われるたびに、SSH 接続をクラスターから 1 つのノードに動的にルーティングします。これは VS Code にとって問題となります。なぜなら、リモートウィンドウを開くために 2 つの接続を行うからです。1 つ目は VS Code Server をインストールまたは起動するため (または既に実行中のインスタンスを見つけるため)、2 つ目は VS Code がサーバーと通信するために使用する SSH ポートトンネルを作成するためです。VS Code が 2 つ目の接続を作成するときに別のマシンにルーティングされた場合、VS Code Server と通信できません。

これを回避する 1 つの方法は、代替 SSH 認証方法の有効化 で説明されている OpenSSH の ControlMaster オプション (macOS/Linux クライアントのみ) を使用することです。これにより、VS Code の 2 つの接続が単一の SSH 接続を介して同じノードに多重化されます。

設定のヘルプについてはシステム管理者に連絡してください

SSH は非常に柔軟なプロトコルであり、多くの構成をサポートしています。ログインターミナルまたは Remote-SSH 出力ウィンドウで他のエラーが表示された場合、それは設定の不足が原因である可能性があります。

SSH ホストとクライアントに必要な設定については、システム管理者に問い合わせてください。SSH ホストへの接続に特定のコマンドライン引数を SSH 設定ファイル に追加できます。

設定ファイルにアクセスするには、コマンドパレット (F1) で Remote-SSH: Open Configuration File... を実行します。その後、管理者と協力して必要な設定を追加できます。

代替 SSH 認証方法の有効化

SSH リモートホストに接続していて、

  • 二要素認証で接続する場合
  • パスワード認証を使用する場合
  • SSH エージェント が実行されていないかアクセスできない場合に、パスフレーズ付きの SSH キーを使用する場合

VS Code は必要な情報の入力を自動的に促します。プロンプトが表示されない場合は、VS Code の remote.SSH.showLoginTerminal 設定 を有効にしてください。この設定は、VS Code が SSH コマンドを実行するたびにターミナルを表示します。ターミナルが表示されたら、認証コード、パスワード、またはパスフレーズを入力できます。

それでも問題が解決しない場合は、settings.json に次のプロパティを追加して再試行する必要があるかもしれません。

"remote.SSH.showLoginTerminal": true,
"remote.SSH.useLocalServer": false

macOS と Linux を使用していて、パスワードまたはトークンを入力する頻度を減らしたい場合は、ローカルマシンで ControlMaster 機能を有効にして、OpenSSH が単一の接続で複数の SSH セッションを実行できるようにすることができます。

ControlMaster を有効にするには

  1. SSH 設定ファイルに次のようなエントリを追加します。

    Host *
    ControlMaster auto
    ControlPath  ~/.ssh/sockets/%r@%h-%p
    ControlPersist  600

  2. 次に、mkdir -p ~/.ssh/sockets を実行してソケットフォルダを作成します。

SSH エージェントのセットアップ

パスフレーズ付きのキーを使用して SSH ホストに接続する場合は、SSH Agent がローカルで実行されていることを確認する必要があります。VS Code はキーをエージェントに自動的に追加するため、リモート VS Code ウィンドウを開くたびにパスフレーズを入力する必要はありません。

エージェントが実行されており、VS Code の環境から到達可能であることを確認するには、ローカル VS Code ウィンドウのターミナルで ssh-add -l を実行します。エージェント内の鍵のリスト (または鍵がないというメッセージ) が表示されるはずです。エージェントが実行されていない場合は、これらの手順に従って起動してください。エージェントを起動した後、VS Code を再起動してください。

Windows

Windows で SSH エージェントを自動的に有効にするには、ローカル管理者 PowerShell を起動し、次のコマンドを実行します。

# Make sure you're running as an Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

これで、ログイン時にエージェントが自動的に起動するようになります。

Linux

SSH エージェントをバックグラウンドで起動するには、以下を実行します。

eval "$(ssh-agent -s)"

ログイン時に SSH エージェントを自動的に起動するには、これらの行を ~/.bash_profile に追加します。

if [ -z "$SSH_AUTH_SOCK" ]; then
   # Check for a currently running instance of the agent
   RUNNING_AGENT="`ps -ax | grep 'ssh-agent -s' | grep -v grep | wc -l | tr -d '[:space:]'`"
   if [ "$RUNNING_AGENT" = "0" ]; then
        # Launch a new instance of the agent
        ssh-agent -s &> .ssh/ssh-agent
   fi
   eval `cat .ssh/ssh-agent`
fi

macOS

macOS では、エージェントはデフォルトで実行されているはずです。

リモートでローカル SSH エージェントを利用できるようにする

ローカルマシン上の SSH エージェントは、Remote - SSH 拡張機能がパスフレーズを繰り返し求めることなく、選択したリモートシステムに接続できるようにしますが、リモートで実行される Git などのツールは、ローカルでアンロックされた秘密鍵にアクセスできません。

これは、リモートで統合ターミナルを開き、ssh-add -l を実行することで確認できます。コマンドはアンロックされたキーをリストするはずですが、代わりに認証エージェントに接続できないというエラーが報告されます。ForwardAgent yes を設定すると、ローカル SSH エージェントがリモート環境で利用可能になり、この問題が解決します。

これは、.ssh/config ファイル (または Remote.SSH.configFile が設定されているもの - 確認のために Remote-SSH: Open SSH Configuration File... コマンドを使用してください) を編集して、次を追加することで行うことができます。

Host *
    ForwardAgent yes

より制限を厳しくして、特定の名前付きホストに対してのみオプションを設定したい場合があることに注意してください。

SSH ファイル権限エラーの修正

SSH はファイル権限に関して厳格であり、誤って設定されていると「WARNING: UNPROTECTED PRIVATE KEY FILE!」などのエラーが表示されることがあります。これを修正するためにファイル権限を更新する方法はいくつかあり、以下のセクションで説明します。

ローカル SSH ファイルとフォルダーのアクセス許可

macOS / Linux

ローカルマシンで、次の権限が設定されていることを確認してください。

フォルダー/ファイル アクセス許可
ユーザーフォルダー内の .ssh chmod 700 ~/.ssh
ユーザーフォルダー内の .ssh/config chmod 600 ~/.ssh/config
ユーザーフォルダー内の .ssh/id_ed25519.pub chmod 600 ~/.ssh/id_ed25519.pub
その他の鍵ファイル chmod 600 /path/to/key/file

Windows

予想される特定の権限は、使用している SSH の実装によって異なる場合があります。箱から出してすぐに使える Windows 10 OpenSSH クライアント の使用をお勧めします。

この場合、SSH ホストのリモートユーザーの .ssh フォルダー内のすべてのファイルがあなたによって所有されており、他のユーザーがアクセスする権限がないことを確認してください。詳細については、Windows OpenSSH Wiki を参照してください。

その他のクライアントについては、実装が何を期待しているかについてクライアントのドキュメントを参照してください。

サーバーの SSH ファイルとフォルダーのアクセス許可

macOS / Linux

接続するリモートマシンで、次の権限が設定されていることを確認してください。

フォルダー/ファイル Linux / macOS の権限
サーバー上のユーザーフォルダ内の .ssh chmod 700 ~/.ssh
サーバー上のユーザーフォルダ内の .ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

現在、Linux ホストのみがサポートされており、そのため macOS および Windows 10 の権限は省略されています。

Windows

Windows OpenSSH サーバーの適切なファイル権限の設定方法の詳細については、Windows OpenSSH wiki を参照してください。

サポートされている SSH クライアントのインストール

OS 手順
Windows 10 1803+ / Server 2016/2019 1803+ Windows OpenSSH クライアント をインストールします。
以前の Windows Windows 用 Git をインストールします。
macOS プリインストールされています。
Debian/Ubuntu sudo apt-get install openssh-client を実行します。
RHEL / Fedora / CentOS sudo yum install openssh-clients を実行します。

VS Code は PATH で ssh コマンドを探します。見つからない場合、Windows ではデフォルトの Windows 用 Git インストールパスで ssh.exe を見つけようとします。remote.SSH.path プロパティを settings.json に追加することで、SSH クライアントを見つける場所を VS Code に明示的に伝えることもできます。

サポートされている SSH サーバーのインストール

OS 手順 詳細
Debian 8+ / Ubuntu 16.04+ sudo apt-get install openssh-server を実行します。 詳細については、Ubuntu SSH ドキュメントを参照してください。
RHEL / CentOS 7+ sudo yum install openssh-server && sudo systemctl start sshd.service && sudo systemctl enable sshd.service を実行します。 詳細については、RedHat SSH ドキュメントを参照してください。
SuSE 12+ / openSUSE 42.3+ Yast で、サービスマネージャーに移動し、リストで「sshd」を選択して [有効にする] をクリックします。次にファイアウォールに移動し、[永続的] 設定を選択し、サービスの下で [sshd] をチェックします。 詳細については、SuSE SSH ドキュメントを参照してください。
Windows 10 1803+ / Server 2016/2019 1803+ Windows OpenSSH サーバー をインストールします。
macOS 10.14+ (Mojave) リモートログイン を有効にします。

SSH ホストでの Git プッシュまたは同期時のハングの解決

SSH を使用して Git リポジトリをクローンし、SSH キーにパスフレーズがある場合、VS Code のプルおよび同期機能は、リモートで実行されるとハングする可能性があります。

パスフレーズなしの SSH キーを使用するか、HTTPS を使用してクローンするか、またはコマンドラインから git push を実行して問題を回避します。

SSHFS を使用したリモートホスト上のファイルへのアクセス

SSHFS は、SFTP をベースにした安全なリモートファイルシステムアクセスプロトコルです。CIFS / Samba 共有のようなものと比較して、マシンへの SSH アクセスのみが必要であるという利点があります。

注: パフォーマンス上の理由から、SSHFS は単一ファイルの編集やコンテンツのアップロード/ダウンロードに最適です。一度に多数のファイルに対して一括読み取り/書き込みを行うアプリケーション (ローカルのソース管理ツールなど) を使用する必要がある場合は、rsync の方が良い選択です。

macOS / Linux:

Linux では、ディストリビューションのパッケージマネージャーを使用して SSHFS をインストールできます。Debian/Ubuntu の場合: sudo apt-get install sshfs

注: WSL 1 は FUSE または SSHFS をサポートしていないため、Windows の手順は現在異なります。WSL 2 には FUSE および SSHFS のサポートが含まれていますので、これはすぐに変更されます。

macOS では、Homebrew を使用して SSHFS をインストールできます。

brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac
brew link --overwrite sshfs-mac

さらに、コマンドラインを使用せずにリモートファイルシステムをマウントしたい場合は、SSHFS GUI をインストールすることもできます。

コマンドラインを使用するには、ローカルターミナルから次のコマンドを実行します (user@hostname をリモートユーザーとホスト名/IP に置き換えてください)。

export USER_AT_HOST=user@hostname
# Make the directory where the remote filesystem will be mounted
mkdir -p "$HOME/sshfs/$USER_AT_HOST"
# Mount the remote filesystem
sshfs "$USER_AT_HOST:" "$HOME/sshfs/$USER_AT_HOST" -ovolname="$USER_AT_HOST" -p 22  \
    -o workaround=nonodelay -o transform_symlinks -o idmap=user  -C

これにより、リモートマシンのホームフォルダが ~/sshfs で利用可能になります。完了したら、OS の Finder / ファイルエクスプローラーを使用するか、コマンドラインを使用してアンマウントできます。

umount "$HOME/sshfs/$USER_AT_HOST"

Windows

次の手順に従ってください

  1. Linux では、.gitattributes ファイルをプロジェクトに追加して、Linux と Windows の間で 一貫した改行を強制 し、両方のオペレーティングシステム間の CRLF/LF の違いによる予期せぬ問題を回避します。詳細については、Git の改行問題の解決 を参照してください。

  2. 次に、Chocolatey を使用して SSHFS-Win をインストールします: choco install sshfs

  3. SSHFS for Windows をインストールしたら、ファイルエクスプローラーの [ネットワークドライブの割り当て...] オプションをパス \\sshfs\user@hostname で使用できます。ここで user@hostname はリモートユーザーとホスト名 / IP です。これをコマンドプロンプトを使用して次のようにスクリプト化できます: net use /PERSISTENT:NO X: \\sshfs\user@hostname

  4. 完了したら、ファイルエクスプローラーでドライブを右クリックし、[切断] を選択して切断します。

ターミナルからリモートホストに接続する

ホストが設定されたら、リモート URI を渡すことでターミナルから直接接続できます。

たとえば、remote_server に接続して /code/my_project フォルダを開くには、次を実行します。

code --remote ssh-remote+remote_server /code/my_project

入力パスがファイルかフォルダかを推測する必要があります。ファイル拡張子がある場合はファイルと見なされます。

フォルダを開くように強制するには、パスにスラッシュを追加するか、

code --folder-uri vscode-remote://ssh-remote+remote_server/code/folder.with.dot

ファイルを強制的に開くには、--goto を追加するか、

code --file-uri vscode-remote://ssh-remote+remote_server/code/fileWithoutExtension

rsync を使用してソースコードのローカルコピーを維持する

SSHFS を使用してリモートファイルにアクセスする 方法の代替手段として、rsync を使用して、リモートホスト上のフォルダーの全コンテンツをローカルマシンにコピーする方法があります。rsync コマンドは、実行されるたびに更新が必要なファイルを判別するため、scp や sftp のようなものを使用するよりもはるかに効率的で便利です。これは主に、マルチファイルまたはパフォーマンス集約型のローカルツールを本当に使用する必要がある場合に検討すべきことです。

rsync コマンドは macOS に標準で付属しており、Linux パッケージマネージャー (例: Debian/Ubuntu の sudo apt-get install rsync) を使用してインストールできます。Windows の場合、このコマンドにアクセスするには WSL または Cygwin を使用する必要があります。

コマンドを使用するには、同期されたコンテンツを保存したいフォルダーに移動し、user@hostname をリモートユーザーとホスト名/IP に、/remote/source/code/path をリモートソースコードの場所に置き換えて、次を実行します。

macOS、Linux、または WSL 内

rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" .

または Windows の PowerShell から WSL を使用

wsl rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" "`$(wslpath -a '$PWD')"

このコマンドをファイルシステムの最新コピーを取得したいときに実行すると、更新されたファイルのみが転送されます。.git フォルダーは、パフォーマンス上の理由と、リモートホストの状態を気にせずにローカルの Git ツールを使用できるようにするために意図的に除外されています。

コンテンツをプッシュするには、コマンドのソースとターゲットのパラメータを逆にします。ただし、Windows では、これを行う前に .gitattributes ファイルをプロジェクトに追加して 一貫した改行を強制 する必要があります。詳細については、Git の改行問題の解決 を参照してください。

rsync -rlptzv --progress --delete --exclude=.git . "user@hostname:/remote/source/code/path"

リモートでの VS Code Server のクリーンアップ

SSH 拡張機能は、リモートマシンから VS Code Server をクリーンアップするためのコマンド、Remote-SSH: Uninstall VS Code Server from Host... を提供します。このコマンドは、実行中の VS Code Server プロセスをすべて終了し、サーバーがインストールされていたフォルダを削除します。

これらの手順を手動で実行したい場合、またはコマンドが機能しない場合は、次のようなスクリプトを実行できます。

# Kill server processes
kill -9 $(ps aux | grep vscode-server | grep $USER | grep -v grep | awk '{print $2}')
# Delete related files and folder
rm -rf $HOME/.vscode-server # Or ~/.vscode-server-insiders

VS Code Server は以前 ~/.vscode-remote にインストールされていたので、その場所も確認できます。

リモート WSL 2 ホストへの SSH 接続

SSH を使用して、リモートマシンで実行されている WSL ディストリビューションに接続したい場合があります。外部マシンから Windows 10 の Bash および WSL 2 に SSH で接続する方法については、このガイド を参照してください。

問題の報告

Remote-SSH 拡張機能の使用で問題が発生し、問題を報告する必要があると思われる場合は、まずこのサイトのドキュメントを読み、次に トラブルシューティングの Wiki ドキュメント を参照して、ログファイルの取得方法と、問題の原因を特定するのに役立つ可能性のある追加の手順を確認してください。

Dev Containers のヒント

Dev Containers の使用に関するヒントについては、Dev Containers の ヒントとテクニック を参照してください。

WSL のヒント

初回起動: VS Code Server の前提条件

一部の WSL Linux ディストリビューションには、VS Code Server の起動に必要なライブラリが不足している場合があります。そのパッケージマネージャーを使用して、追加のライブラリを Linux ディストリビューションに追加できます。

Debian と Ubuntu

Debian または Ubuntu WSL シェルを開いて wget と ca-certificates を追加します。

sudo apt-get update && sudo apt-get install wget ca-certificates

Alpine

ルートとして Alpine WSL シェル (wsl -d Alpine -u root) を開いて libstdc++ を追加します。

apk update && apk add libstdc++

Windows 10 April 2018 Update (ビルド 1803) 以前では、/bin/bash が必要です。

apk update && apk add bash

WSL 拡張機能が使用するディストリビューションの選択

WSL: New Window はデフォルトとして登録されている WSL ディストリビューションを開きます。

デフォルト以外のディストリビューションを開くには、使用するディストリビューションの WSL シェルから code . を実行するか、WSL: New Window using Distro を使用します。

Windows 10, May 2019 Update (バージョン 1903) よりも古い WSL バージョンでは、WSL コマンドは デフォルトのディストリビューション のみを使用できます。このため、WSL 拡張機能はデフォルトのディストリビューションを変更することに同意するかどうかを尋ねる場合があります。

wslconfig.exe を使用して、いつでもデフォルトを変更できます。

例

wslconfig /setdefault Ubuntu

インストールされているディストリビューションを確認するには、次を実行します。

wslconfig /l

サーバー起動のための環境を構成する

WSL 拡張機能が WSL で VS Code サーバーを起動するとき、シェル構成スクリプトは実行されません。これは、カスタム構成スクリプトが起動を妨げないようにするためです。

起動環境を構成する必要がある場合は、こちらで説明されている環境設定スクリプトを使用できます。

リモート拡張機能ホストの環境を構成する

リモート拡張機能ホストとターミナルの環境は、デフォルトシェルの設定スクリプトに基づいています。リモート拡張機能ホストプロセスの環境変数を評価するために、サーバーはデフォルトシェルのインスタンスを対話型ログインシェルとして作成します。そこから環境変数をプローブし、それらをリモート拡張機能ホストプロセスの初期環境として使用します。したがって、環境変数の値は、デフォルトとして構成されているシェルと、そのシェルの設定スクリプトの内容に依存します。

各シェルの設定スクリプトの概要については、Unix シェル初期化 を参照してください。ほとんどの WSL ディストリビューションでは、/bin/bash がデフォルトシェルとして設定されています。/bin/bash は、まず /etc/profile、次に ~/.bash_profile、~/.bash_login、~/.profile の下にあるスタートアップファイルを探します。

WSL ディストリビューションのデフォルトシェルを変更するには、このブログ記事 の手順に従ってください。

code コマンドが動作しない問題の修正

Window の WSL ターミナルから code と入力しても code が見つからないために動作しない場合、WSL の PATH にいくつかの重要な場所が欠けている可能性があります。

WSL ターミナルを開き、echo $PATH と入力して確認します。VS Code のインストールパスがリストされているはずです。デフォルトでは次のようになります。

/mnt/c/Users/Your Username/AppData/Local/Programs/Microsoft VS Code/bin

ただし、システムインストーラーを使用した場合は、インストールパスは次のようになります。

/mnt/c/Program Files/Microsoft VS Code/bin

...または...

/mnt/c/Program Files (x86)/Microsoft VS Code/bin

WSL の機能として、Windows の PATH 変数からパスが継承されます。Windows の PATH 変数を変更するには、Windows のスタートメニューから [アカウントの環境変数を編集] コマンドを使用します。

パス共有機能を無効にしている場合は、.bashrc を編集し、次の行を追加して、新しいターミナルを起動してください。

WINDOWS_USERNAME="Your Windows Alias"

export PATH="$PATH:/mnt/c/Windows/System32:/mnt/c/Users/${WINDOWS_USERNAME}/AppData/Local/Programs/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files/Microsoft VS Code/bin"
# or...
# export PATH="$PATH:/mnt/c/Program Files (x86)/Microsoft VS Code/bin"

注: ディレクトリ名にスペース文字がある場合は、引用符で囲むかエスケープしてください。

「code」コマンドの問題を見つける

Windows コマンドプロンプトから code と入力しても VS Code が起動しない場合は、VSCODE_WSL_DEBUG_INFO=true code . を実行して問題の診断にご協力ください。

問題を報告し、完全な出力を添付してください。

サーバーの起動または接続の問題を見つける

WSL ウィンドウがリモートサーバーに接続できない場合、WSL ログで詳細情報を取得できます。問題を報告する際には、WSL ログの全内容を常に送信することが重要です。

WSL: Open Log コマンドを実行して WSL ログを開きます。ログはターミナルビューの WSL タブに表示されます。

WSL Log

さらに詳細なログを取得するには、ユーザー設定で remote.WSL.debug 設定を有効にします。

サーバーがセグメンテーション違反で起動に失敗する

この問題を調査するために、コアダンプファイルを送っていただけると助かります。コアダンプファイルを取得するには、次の手順に従ってください。

Windows コマンドプロンプトで

  • code --locate-extension ms-vscode-remote.remote-wsl を実行して、WSL 拡張機能のフォルダを特定します。
  • 返されたパスに cd します。
  • VS Code で wslServer.sh スクリプトを開きます (code .\scripts\wslServer.sh)。
  • 最後の行 ("$VSCODE_REMOTE_BIN/$COMMIT/bin/$SERVER_APPNAME" "$@" の前) の前に ulimit -C unlimited を追加します。
  • リモートサーバーを実行している WSL ウィンドウを起動し、セグメンテーション違反が発生するまで待ちます。

コアファイルは、上記の WSL 拡張機能フォルダ内にあります。

開いているワークスペースでフォルダ名を変更しようとすると、EACCES: permission denied エラーが表示されます。

これは、VS Code でアクティブなファイルウォッチャーによって引き起こされる WSL ファイルシステムの実装の既知の問題です (Microsoft/WSL#3395、Microsoft/WSL#1956)。この問題は WSL 2 でのみ修正されます。

この問題を回避するには、remote.WSL.fileWatcher.polling を true に設定します。ただし、ポーリングベースでは大規模なワークスペースでパフォーマンスに影響が出ます。

大規模なワークスペースの場合、ポーリング間隔 remote.WSL.fileWatcher.pollingInterval を増やし、files.watcherExclude で監視されるフォルダを制御することができます。

WSL 2 にはこのファイルウォッチャーの問題はなく、新しい設定の影響も受けません。

WSL での Git の改行問題の解決 (多くの変更されたファイルが発生する場合)

Windows と Linux ではデフォルトの改行が異なるため、Git は改行以外の違いがない多数の変更されたファイルを報告する場合があります。これを防ぐには、.gitattributes ファイルを使用するか、Windows 側でグローバルに改行変換を無効にすることができます。

通常、リポジトリに .gitattributes ファイルを追加または変更することが、この問題を解決する最も信頼できる方法です。このファイルをソース管理にコミットすることで、他の人にも役立ち、必要に応じてリポジトリごとに動作を変更できます。たとえば、リポジトリのルートに次の .gitattributes ファイルを追加すると、Windows バッチファイルに必要な CRLF を除いて、すべてが LF に強制されます。

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

これは Git v2.10 以降 で機能することに注意してください。問題が発生している場合は、最新の Git クライアントがインストールされていることを確認してください。リポジトリ内の他のファイルタイプで CRLF を必要とするものをこの同じファイルに追加できます。

Unix スタイルの改行 (LF) を常にアップロードしたい場合は、代わりに input オプションを使用できます。

git config --global core.autocrlf input

改行変換を完全に無効にしたい場合は、代わりに次を実行します。

git config --global core.autocrlf false

最後に、これらの設定を有効にするには、リポジトリを再度クローンする必要がある場合があります。

Windows と WSL 間での Git 資格情報の共有

HTTPS を使用してリポジトリをクローンし、Windows で 資格情報ヘルパーを設定している 場合、これを WSL と共有して、入力したパスワードが両側で永続化されるようにすることができます。(これは SSH キーの使用には適用されないことに注意してください。)

以下の手順に従ってください。

  1. Windows コマンドプロンプトまたは PowerShell で次のコマンドを実行して、Windows で資格情報マネージャーを設定します。

     git config --global credential.helper wincred

  2. WSL ターミナルで次のコマンドを実行して、同じ資格情報ヘルパーを使用するように WSL を構成します。

     git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

Windows 側で Git を操作するときに入力したパスワードは、WSL でも利用できるようになり、その逆も同様です。

WSL から Git プッシュまたは同期を行う際のハングの解決

SSH を使用して Git リポジトリをクローンし、SSH キーにパスフレーズがある場合、VS Code のプルおよび同期機能は、リモートで実行されるとハングする可能性があります。

パスフレーズなしの SSH キーを使用するか、HTTPS を使用してクローンするか、またはコマンドラインから git push を実行して問題を回避します。

GitHub Codespaces のヒント

GitHub Codespaces に関するヒントや質問については、GitHub Codespaces ドキュメント を参照してください。また、Codespaces に影響を与える可能性のある 既知の Web の制限と適応 も確認できます。

拡張機能のヒント

多くの拡張機能は修正なしで動作しますが、特定の機能が期待どおりに動作しない原因となるいくつかの問題があります。場合によっては、別のコマンドを使用して問題を回避できますが、他の場合は、拡張機能を変更する必要がある場合があります。このセクションでは、一般的な問題とそれらを解決するためのヒントの簡単なリファレンスを提供します。リモート拡張機能ホストをサポートするために拡張機能を変更する方法の詳細なガイドについては、リモート開発のサポート に関する主要な拡張機能の記事も参照してください。

不足している依存関係に関するエラーの解決

一部の拡張機能は、特定の WSL Linux ディストリビューションの基本インストールに含まれていないライブラリに依存しています。パッケージマネージャーを使用して、追加のライブラリを Linux ディストリビューションに追加できます。Ubuntu および Debian ベースのディストリビューションの場合、sudo apt-get install を実行して必要なライブラリをインストールします。追加のインストール詳細については、拡張機能のドキュメントまたはエラーメッセージで言及されているランタイムを確認してください。

ローカル絶対パス設定がリモートで適用されると失敗する

VS Code のローカルユーザー設定は、リモートエンドポイントに接続するときに再利用されます。これによりユーザーエクスペリエンスの一貫性が保たれますが、ターゲットの場所が異なるため、ローカルマシンと各ホスト / コンテナ / WSL 間で絶対パス設定を変更する必要がある場合があります。

解決策: コマンドパレット (F1) から Preferences: Open Remote Settings コマンドを実行するか、設定エディターで Remote タブを選択して、リモートエンドポイントに接続した後にエンドポイント固有の設定を行うことができます。これらの設定は、接続するたびに既存のローカル設定を上書きします。

リモートエンドポイントにローカル VSIX をインストールする必要がある

開発中、または拡張機能の作者が修正を試すように求めたときに、ローカル VSIX をリモートマシンにインストールしたい場合があります。

解決策: SSH ホスト、コンテナ、または WSL に接続したら、ローカルと同様に VSIX をインストールできます。コマンドパレット (F1) から Extensions: Install from VSIX... コマンドを実行します。また、最新の Marketplace バージョンへの自動更新を防ぐために "extensions.autoUpdate": false を settings.json に追加することをお勧めします。リモート環境での拡張機能の開発とテストに関する詳細については、リモート開発のサポート を参照してください。

ブラウザがローカルで開かない

一部の拡張機能は、外部の Node モジュールまたはカスタムコードを使用してブラウザウィンドウを起動します。残念ながら、これにより拡張機能がブラウザをローカルではなくリモートで起動する可能性があります。

解決策: 拡張機能は、この問題を解決するために vscode.env.openExternal API を使用できます。詳細については、拡張機能の作成者向けガイド を参照してください。

クリップボードが機能しない

一部の拡張機能は、clipboardy などの Node モジュールを使用してクリップボードと統合します。残念ながら、これにより拡張機能がリモート側でクリップボードと誤って統合される可能性があります。

解決策: 拡張機能は、この問題を解決するために VS Code のクリップボード API に切り替えることができます。詳細については、拡張機能の作成者向けガイド を参照してください。

ブラウザまたはアプリケーションからローカル Web サーバーにアクセスできない

コンテナ内、SSH ホスト、または GitHub Codespaces を介して作業している場合、ブラウザが接続しようとしているポートがブロックされている可能性があります。

解決策: 拡張機能は vscode.env.openExternal または vscode.env.asExternalUri API (localhost ポートを自動的に転送します) を使用して、この問題を解決できます。詳細については、拡張機能の作成者向けガイド を参照してください。回避策として、[ポートを転送] コマンドを使用して手動で転送します。

Web ビューのコンテンツが表示されない

拡張機能の Web ビューコンテンツが iframe を使用してローカル Web サーバーに接続している場合、Web ビューが接続しているポートがブロックされている可能性があります。さらに、拡張機能が asWebviewUri を使用せずに vscode-resource:// URI をハードコードしている場合、Codespaces ブラウザエディターにコンテンツが表示されないことがあります。

解決策: 拡張機能は webview.asWebviewUri を使用して、vscode-resource:// URI の問題を解決できます。

ポートがブロックされている場合、最善のアプローチは、代わりに webview メッセージング API を使用することです。回避策として、vscode.env.asExternalUri を使用して、Web ビューが VS Code から生成された localhost Web サーバーに接続できるようにすることができます。ただし、これは現在、MicrosoftDocs/vscodespaces#11 によって Codespaces のブラウザベースのエディター (のみ) でブロックされています。回避策の詳細については、拡張機能の作成者向けガイド を参照してください。

ブロックされた localhost ポート

外部アプリケーションから localhost ポートに接続しようとすると、ポートがブロックされる場合があります。

解決策: VS Code 1.40 で、拡張機能が任意のポートをプログラムで転送するための新しい vscode.env.asExternalUri API が導入されました。詳細については、拡張機能の作成者向けガイド を参照してください。回避策として、[ポートを転送] コマンドを使用して手動で転送できます。

拡張機能データの保存エラー

拡張機能は、Linux の ~/.config/Code フォルダーを探してグローバルデータを永続化しようとする場合があります。このフォルダーが存在しない場合、拡張機能が ENOENT: no such file or directory, open '/root/.config/Code/User/filename-goes-here のようなエラーをスローする可能性があります。

解決策: 拡張機能は、この問題を解決するために context.globalStorageUri または context.storageUri プロパティを使用できます。詳細については、拡張機能の作成者向けガイド を参照してください。

サインインできない / 新しいエンドポイントに接続するたびにサインインが必要

サインインが必要な拡張機能は、独自のコードを使用して秘密を永続化する場合があります。このコードは、依存関係の不足が原因で失敗する可能性があります。成功した場合でも、秘密はリモートに保存されるため、新しいエンドポイントごとにサインインする必要があります。

解決策: 拡張機能は SecretStorage API を使用してこの問題を解決できます。詳細については、拡張機能の作成者向けガイド を参照してください。

互換性のない拡張機能が VS Code の接続を妨げる

互換性のない拡張機能がリモートホスト、コンテナ、または WSL にインストールされている場合、VS Code Server が互換性のためにハングまたはクラッシュするケースがありました。拡張機能がすぐにアクティブ化すると、接続できなくなり、拡張機能をアンインストールできなくなる可能性があります。

解決策: 次の手順に従って、リモート拡張機能フォルダーを手動で削除します。

  1. コンテナの場合、devcontainer.json に誤った拡張機能への参照が含まれていないことを確認してください。

  2. 次に、別のターミナル / コマンドプロンプトを使用して、リモートホスト、コンテナ、または WSL に接続します。

    • SSH または WSL の場合は、それに応じて環境に接続します (ssh を実行してサーバーに接続するか、WSL ターミナルを開きます)。
    • コンテナを使用している場合、docker ps -a を呼び出し、リストから正しい名前のイメージを探してコンテナ ID を特定します。コンテナが停止している場合、docker run -it /bin/sh を実行します。実行中の場合、docker exec -it /bin/sh を実行します。

  3. 接続したら、VS Code 安定版の場合は rm -rf ~/.vscode-server/extensions を、VS Code Insiders の場合は rm -rf ~/.vscode-server-insiders/extensions を実行して、すべての拡張機能を削除します。

ビルド済みのネイティブモジュールを同梱または取得する拡張機能が失敗する

VS Code 拡張機能にバンドルされている (または動的に取得される) ネイティブモジュールは、Electron の electron-rebuild を使用して 再コンパイルする必要があります。しかし、VS Code Server は標準の (Electron ではない) Node.js バージョンを実行するため、リモートで使用するとバイナリが失敗する可能性があります。

解決策: この問題を解決するには、拡張機能を変更する必要があります。拡張機能は、VS Code が出荷する Node.js の「モジュール」バージョンに対して、両方のバイナリセット (Electron および標準 Node.js) を含める (または動的に取得する) 必要があり、その後、アクティベーション関数で context.executionContext === vscode.ExtensionExecutionContext.Remote をチェックして、正しいバイナリを設定する必要があります。詳細については、拡張機能の作成者向けガイド を参照してください。

拡張機能が x86_64 以外のホストまたは Alpine Linux でのみ失敗する

拡張機能が Debian 9 以降、Ubuntu 16.04 以降、または RHEL / CentOS 7 以降のリモート SSH ホスト、コンテナ、または WSL で動作するものの、サポートされている x86_64 以外のホスト (例: ARMv7l) または Alpine Linux コンテナで失敗する場合、拡張機能はこれらのプラットフォームをサポートしないネイティブコードまたはランタイムのみを含んでいる可能性があります。たとえば、拡張機能にはネイティブモジュールまたはランタイムの x86_64 コンパイルバージョンのみが含まれている場合があります。Alpine Linux の場合、含まれているネイティブコードまたはランタイムは、Alpine Linux (musl) と他のディストリビューション (glibc) で libc が実装されている方法の 根本的な違い のために動作しない可能性があります。

解決策: 拡張機能は、これらの追加ターゲット用のバイナリをコンパイル/含めることで、これらのプラットフォームのサポートをオプトインする必要があります。一部のサードパーティの npm モジュールもこの問題を引き起こす可能性のあるネイティブコードを含んでいる可能性があることに注意することが重要です。したがって、場合によっては、npm モジュール作成者と協力して追加のコンパイルターゲットを追加する必要がある場合があります。詳細については、拡張機能の作成者向けガイド を参照してください。

モジュール不足により拡張機能が失敗する

Electron または VS Code の基本モジュール (拡張 API で公開されていない) に依存し、フォールバックを提供しない拡張機能は、リモートで実行されると失敗する可能性があります。開発者ツールのコンソールで original-fs が見つからないなどのエラーが表示される場合があります。

解決策: Electron モジュールへの依存関係を削除するか、フォールバックを提供します。詳細については、拡張機能の作成者向けガイド を参照してください。

リモートワークスペースファイルをローカルマシンにアクセス/転送できない

ワークスペースファイルを外部アプリケーションで開く拡張機能は、外部アプリケーションがリモートファイルに直接アクセスできないため、エラーが発生する可能性があります。

解決策: ローカルで実行するように設計された「UI」拡張機能を作成する場合、vscode.workspace.fs API を使用してリモートワークスペースファイルシステムと対話できます。その後、これを「ワークスペース」拡張機能の依存関係として作成し、必要に応じてコマンドを使用して呼び出すことができます。さまざまな種類の拡張機能と、コマンドを使用して拡張機能間で通信する方法の詳細については、拡張機能作成者向けガイド を参照してください。

拡張機能から接続されているデバイスにアクセスできない

ローカルに接続されているデバイスにアクセスする拡張機能は、リモートで実行されているときにそれらに接続できません。

解決策: 現在はありません。この問題を解決するための最善のアプローチを調査中です。

質問とフィードバック

問題の報告

いずれかのリモート開発拡張機能で問題が発生した場合は、適切なログを収集することが重要です。これにより、問題を 診断する ことができます。

各リモート拡張機能には、ログを表示するコマンドがあります。

Remote - SSH 拡張機能のログは、コマンドパレット (F1) から Remote-SSH: Show Log で取得できます。Remote - SSH の問題を報告する際は、外部ターミナル (Remote - SSH を使用しない) からマシンに SSH 接続できるかどうかも確認してください。

同様に、Dev Containers 拡張機能のログは Dev Containers: Show Container Log で取得できます。

上記2つと同様に、WSL拡張機能のログはWSL: Show Logで取得できます。また、問題がWSLリポジトリで追跡されているか（WSL拡張機能によるものではないか）も確認してください。

リモートで他の拡張機能を使用する際に問題が発生している場合 (たとえば、リモートコンテキストで他の拡張機能が適切にロードまたはインストールされない場合) は、リモート拡張機能ホスト の出力チャネルからログを取得し (出力: 出力ビューにフォーカス)、ドロップダウンから ログ (リモート拡張機能ホスト) を選択すると役立ちます。

注: ログ (拡張機能ホスト) のみが表示される場合、これはローカル拡張機能ホストであり、リモート拡張機能ホストは起動していません。これは、ログファイルが作成された後にのみログチャネルが作成されるため、リモート拡張機能ホストが起動しない場合、リモート拡張機能ホストログファイルは作成されず、出力ビューには表示されないためです。これは依然として、問題に含めるのに役立つ情報です。

リモートに関する質問とフィードバックのリソース

他にも様々なリモートリソースがあります。

08/07/2025