対象読者: SSH・VS Code にある程度慣れたエンジニア向け（中〜上級）
狙い: Remote-SSH をまず試し、環境的に難しければ無理にこねくり回すより VS Code Server（code-server 等）を使う 運用方針を、具体手順・設定・トラブルシュートを含めて丁寧に解説します。対象拡張は Codex（CLI 含む） / Claude Code / GitHub Copilot に限定します。

TL;DR（要点まとめ）

まずは Remote-SSH を試す：操作感がローカルそのままで最も速く安全に導入できる。拡張は「Install in SSH: 」でリモートに入れる。
Remote-SSH が失敗したら VS Code Server（code-server 等）へ乗り換え：Web 経由で同等体験が得られるが、HTTPS + リバースプロキシによる保護は必須。
**最終手段としてフルGUI（X11/VNC）**は帯域・遅延・クリップボードの不安定さで実用性が低い。
重要な事前準備：SSH 鍵（Ed25519 推奨）、VSCODE_AGENT_FOLDER の指定、inotify の緩和、非対話シェル出力の抑制（.bashrc ガード）。
CentOS7 等の 古い glibc 環境では、ユーザー領域に新しい glibc を入れて Node をラップする等の追加対応が必要になることがある（手順例あり）。

目次

事前チェック・準備（SSH / サーバ）
推奨ワークフロー（手順） — Remote-SSH をまず試す
Remote-SSH の詳細設定例（SSH config・VSCode 側）
AI 拡張（Codex / Claude Code / Copilot）導入ポイント
Remote-SSH でよくあるトラブルと対処法（ログ確認コマンド含む）
Remote-SSH が無理なとき：VS Code Server（code-server）導入と注意点
CentOS7 / 古い glibc 対応（ユーザー領域で glibc を入れて Node をラップする手順）
比較表（Remote-SSH / VS Code Server / フルGUI）
セキュリティチェックリスト & 運用のコツ
付録: 便利スニペット（inotify 設定 / .bashrc ガード / node ラッパー / wget ラッパー / kill server）

1. 事前チェック・準備（最低限）

ローカル: 最新の VS Code Desktop。（拡張の UI / 認証はローカル側で発生することが多い）
サーバ: SSH でログイン可能。ssh user@host が最低限通ること。
推奨: 鍵認証（Ed25519 推奨）、~/.ssh/config でホスト管理（ProxyJump が必要なら設定）
サーバ側要件（一般）: 標準の Linux ユーザ環境（glibc, bash）。NFS にホームが乗っている場合は VSCODE_AGENT_FOLDER をローカルディスクに指すこと（/tmp や /var/tmp 等）。
ネットワーク: リモートから外向け HTTPS（api.github.com / api.anthropic.com / api.openai.com 等）へ行けること（AI 拡張がクラウドAPIを叩くため）。必要なら HTTPS_PROXY を設定。

2. 推奨ワークフロー（まずは Remote-SSH）

SSH キーを準備（未作成なら）

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

~/.ssh/config にホストを書く（ProxyJump がある場合は ProxyJump を使う）

Host bastion
  HostName bastion.example.com
  User your_user
  IdentityFile ~/.ssh/id_ed25519

Host dev-server
  HostName 10.0.0.50
  User your_user
  ProxyJump bastion
  IdentityFile ~/.ssh/id_ed25519

VS Code 側で Remote - SSH 拡張をインストールし、Connect to Host... で接続。接続時に自動的に VS Code Server がリモートへ展開される。
接続後、VS Code の拡張ビューで 「SSH: 」 タブを選び、Install in SSH: <host> を使って対象拡張（Copilot / Claude Code / Codex）をリモートにインストールする。
API キー等は VS Code Secret Storage（拡張の設定）か、最小権限で 環境変数（~/.bashrc）で設定する。

理由：Remote-SSH は「ローカル UI」＋「リモート実行環境」の最も自然な構成で、レスポンスが良く、拡張の動作も安定します。まずこれを試すのが運用コストを最小にする最短経路です。

3. Remote-SSH の詳細設定例・運用上の留意点

VSCODE_AGENT_FOLDER（NFS 上の問題回避）

NFS マウント上に VS Code Server が展開されるとファイル監視や I/O が遅く不安定になります。サーバ側でユーザに VSCODE_AGENT_FOLDER を設定してローカルディスクに置くのが常套手段。

# リモートで .bashrc へ追加
export VSCODE_AGENT_FOLDER=/tmp/$USER/.vscode-server

inotify（ファイル監視）を十分にする

大規模リポジトリでは fs.inotify.max_user_watches が不足すると問題。管理者権限で以下を設定してもらう（例）。

# /etc/sysctl.d/99-vscode-remote.conf
fs.inotify.max_user_watches=524288
fs.inotify.max_user_instances=1024
fs.inotify.max_queued_events=16384

# 反映
sudo sysctl --system

`.bashrc` やログインスクリプトの余計な出力は抑える

VS Code Server の起動は非対話シェルで行われるため、.bashrc 等が余計なメッセージを stdout に吐くと Failed to parse remote port from server output の原因になります。先頭に非対話ガードを入れる：

# ~/.bashrc の冒頭に追加
# 非対話シェル(Remote-SSH等)ではここで終了
case $- in
  *i*) ;;   # 対話シェルなら続行
  *) return ;; # 非対話なら何もしないで戻る
esac

または touch ~/.hushlogin でいくつかのログメッセージを抑えられます。

SSH 接続保持

~/.ssh/config に ServerAlive などを入れて接続安定化を図る：

Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3
  TCPKeepAlive yes
  ForwardAgent no

4. Codex / Claude Code / GitHub Copilot の導入ポイント

Codex（CLI を含む）

CLI の多くはマルチライン入力やクリップボード挙動に不具合があることが知られるため、長い指示はファイル経由で渡すのが確実：

# prompt.md に複数行の指示を書く
codex "$(cat prompt.md)"
# 画像添付
codex -i ~/screenshots/error.png "このエラーを説明して"

VS Code 拡張版（Codex – OpenAI’s coding agent）があるなら Remote: SSH の「Install in SSH: host」でリモートに入れる（WSL などと同様の扱い）。

Claude Code（Anthropic）

リモートにインストールすること（UI 側に入れると制約がある場合がある）を推奨。API キーは VS Code Secret Storage または ~/.bashrc の環境変数で指定。
確認コマンド例（リモートターミナルから）：

# リモート上で
echo $ANTHROPIC_API_KEY

GitHub Copilot

リモート側にインストールし、ブラウザで GitHub 認証（サインイン）を行う。Copilot はサブスクリプションが必要。
Copilot Chat を使う場合はキーボードショートカットを設定しておくと便利。

5. Remote-SSH でよくあるトラブル（具体例と対処）

1) 「Failed to parse remote port from server output」

症状: 接続後すぐエラーで接続が確立されない。
原因: .bashrc 等が標準出力に余計なメッセージを出している。
対処: .bashrc の非対話ガードを入れる or 管理者に /etc/profile.d/ の不要な echo を制限してもらう。~/.hushlogin でログインメッセージを抑える方法も有効。

2) 拡張が「Install in SSH: host」と表示されない

原因: Extension Host が落ちているか、リモートに拡張を置く元のローカル拡張キャッシュが壊れている。
対処:

Remote-SSH: Kill VS Code Server on Host... を実行して再接続。
ローカルの拡張を一度アンインストール → 再インストールしてから Install in SSH をやり直す。

3) 拡張が動かない（Copilot/Claude 反応無し）

原因: リモートから外向き通信ブロック、APIキー設定ミス、拡張が UI 側で動いている。
対処:

# リモートで通信確認
curl -I https://api.github.com
curl -I https://api.anthropic.com
curl -I https://api.openai.com

必要なら export HTTPS_PROXY="http://proxy:8080" を ~/.bashrc に追加。
拡張の remote.extensionKind 設定で "remote" を優先する（UI 実行は副作用あり）。

4) NFS 上でファイル操作が重い / inotify 足りない

対処: 前述の VSCODE_AGENT_FOLDER をローカルディスクに指定、fs.inotify の緩和、files.watcherExclude の設定で node_modules 等を除外。

6. Remote-SSH が無理な環境での代替：VS Code Server（code-server）導入

Remote-SSH が運用上（ファイアウォールや古い環境、PAM/shell の問題等）難しい場合、VS Code Server（例：code-server） をリモートで常駐させ、ブラウザまたは軽量クライアントで接続する方法が現実的な代替です。

注意：必ず HTTPS とリバースプロキシで保護する

code-server を直接パブリックに晒すのは危険です。実運用では Nginx / Caddy 等でリバースプロキシを立て、Let's Encrypt 等で TLS 化し、認証（Basic / OAuth / VPN）を導入してください。WebSocket を通す設定が必要です（WS/ WSS）。

code-server の導入（概略）

サーバに code-server をインストール（公式手順に従う）
systemd ユニット等で常駐させる
Nginx（例）で TLS 終端 & WebSocket をリバースプロキシ
code-server 内で拡張をインストール（GUI or CLI）

# code-server の CLI で拡張を入れる例
# PATH は実環境に合わせて変更
~/.local/bin/code-server --install-extension github.copilot --force
~/.local/bin/code-server --install-extension anthropic.claude-code --force
~/.local/bin/code-server --install-extension openai.codex-extension --force

利点と欠点

利点: ブラウザでどのマシンからでも同じ IDE を利用可能。ファイアウォール越しに HTTPS で運用できる。
欠点: HTTPS / プロキシ設定が必須で、運用・保守コストが上がる。API キーや Secret をどのように安全に置くかを設計する必要がある。

7. （上級向け）CentOS7 等・古い glibc 環境への対処例

問題: CentOS7 系のように glibc が古く（例: 2.17）、VS Code Server に含まれる Node が動かない（exit code 127 等）。
対策の方向性: ユーザー領域に新しい glibc をビルドして置き、VS Code Server の node をラップして新 glibc 経由で起動する。

警告：glibc のビルドは重く、失敗したときの影響が大きい。管理者と相談の上で行ってください。以下は「必要な場合の例」として示します。

大まかな手順（要約）

ユーザー領域に glibc をビルド・インストール（例: ~/.local/glibc-2.28）
VS Code Server の ~/.vscode-server/bin/<commit> 内の node を node.raw に退避し、node スクリプトで ld-linux-x86-64.so.2 --library-path に新 glibc を指定して実行するラッパーを作る。
同様に wget に --no-config などのオプション対応が問題を起こす場合は ~/bin/wget ラッパーを用意。

node ラッパー（抜粋例）

# ~/.vscode-server/bin/<commit>/node.real
#!/bin/bash
set -euo pipefail
GLIBC_HOME="$HOME/.local/glibc-2.28"
GCC_RUNTIME="/home/software/gcc-9.2.0/lib64"   # 利用可能なら
REAL_NODE="$(dirname "$0")/node.raw"
unset LD_PRELOAD
exec "$GLIBC_HOME/lib/ld-linux-x86-64.so.2" \
     --library-path "$GLIBC_HOME/lib:$GCC_RUNTIME:/lib64:/usr/lib64" \
     "$REAL_NODE" "$@"

成功したら ~/.vscode-server/bin/<commit>/node --version が実行できるはずです。
VS Code が更新されると新しい <commit> ディレクトリが作られて上書きされるので、ラッパーを自動で再適用するスクリプト (vscode-wrapper-repair.sh) を用意すると便利です。

8. 比較表（短縮）

特性	Remote-SSH（推奨）	VS Code Server（code-server）	フルGUI（X11/VNC）
操作感	ローカルと同等（速い）	ブラウザ経由でほぼ同等	GUI転送なので遅い
導入容易さ	高（最小設定で可）	中（HTTPS/リバプロ必要）	中〜高（X11/RDPの設定要）
セキュリティ	SSH 鍵で管理しやすい	HTTPS の鍵管理が必須	同上（さらに設定が大変）
対応環境	多くのLinuxでOK	Web公開できる環境が必要	帯域/遅延に非常に敏感
拡張の互換性	高（リモート拡張実行）	高（リモートで実行）	高（ローカルで実行）
トラブル要因	古い glibc / login scripts	TLS/Proxy 設定のミス	帯域・遅延・GPU/clipboard問題

9. セキュリティチェックリスト（必須）

SSH は**鍵認証（Ed25519）**のみ許可。PasswordAuthentication no。
ForwardAgent は必要最小限に。~/.ssh/config で ForwardAgent no。
VS Code Server を公開するなら 必ず HTTPS + リバースプロキシ（Nginx/Caddy） を導入し、認証を入れる。
API キー管理は VS Code Secret Storage 優先、次に環境変数（ファイルは chmod 600）。設定ファイルは .gitignore に登録。
Copilot/Claude の組織利用時は「学習に使用されないオプション（Business/Enterprise）」を検討。
~/.bashrc 等に API キーや平文パスワードを置かない（最小限で）。

10. 付録：便利スニペット・操作コマンド

Remote-SSH 接続確認

# SSH が通るか
ssh dev-server "echo 'Bastion connection: OK' && hostname"
# VS Code Server の場所確認
ssh dev-server "echo \$VSCODE_AGENT_FOLDER"

VS Code Server を kill（再展開）

VS Code -> コマンドパレット: Remote-SSH: Kill VS Code Server on Host...
またはリモートで手動削除:

ssh dev-server "rm -rf /tmp/\$USER/.vscode-server"

inotify 現状確認

ssh dev-server "cat /proc/sys/fs/inotify/max_user_watches"

`.bashrc` 非対話ガード（再掲）

case $- in
  *i*) ;; 
  *) return ;; 
esac

Codex CLI の安全な長文入力例

# prompt.md に複数行
codex "$(cat prompt.md)"
# 画像添付
codex -i ~/screenshots/err.png "このエラーを説明して"

node ラッパー自動修復スクリプト（概要）

（新しい VS Code Server commit ができたときに再適用する）

# ~/bin/vscode-wrapper-repair.sh (要実行権限)
COMMIT=$(basename $(readlink -f ~/.vscode-server/bin/*))
cd ~/.vscode-server/bin/$COMMIT
# ここで node の退避とラッパー生成処理を行う（前節の例参照）

最後に（運用の勧め）

まずは Remote-SSH：最速で導入でき、日常運用でもっともトラブルが少ない。
Remote-SSH で詰まる代表例は「古い glibc / ログ出力 / NFS 上の VS Code Server」「組織のファイアウォール」で、これらは対処可能だが手間が増える。
そうした手間をかけるより、VS Code Server を HTTPS で立てる（かつ安全に保護する）方が早く安定するケースも多い。
どちらを選ぶにせよ、拡張はリモート側にインストールし、API キーの管理とログインスクリプトの扱いには十分注意してください。