VSCodeのSSHエージェント連携が神すぎる件について（2025年版）

VSCodeのSSHエージェント連携が非常に強力で便利になっています。開発体験が劇的に向上するこの機能について、ぜひ活用してみてください。

エージェントにSSHアクセス権を与えるときは、何をしているか完全に監視して理解できるようにしておきたい。基本的には、自分が打ち込めるコマンドだけをCLIに「入力」するようにして、動作内容を把握できて、結果に驚かされないようにしたい。今のところ、OpenCodeとスマートなLLM（qwen 3.8-flash-nextやdeepseek v4 0731以降など）を使えば、比較的うまく運用できてるよ。

(2025)が抜けてるね。ちなみにVSCodeのSSHエージェントはリモート開発において神ツールだよ。Flyが挙げている「デメリット」は、実際にはメリットの一部だ。チームでこの拡張機能をバリバリ使ってきたけど、問題になったことは一度もない。SSHアクセスを任意に制限すれば、必要なセキュリティやガードレールはいくらでも確保できるからね。

VSCodeのアーキテクチャのこの部分は自分としては許容範囲。ただ逆方向、つまり侵害されたリモート環境がこちらのローカルマシンに対してやりたい放題できるのはさすがにナシだ。

エージェントはリモートの開発用ボックスで動かすものだろ。目的はリモートマシンをローカル環境の拡張のように扱って、拡張機能の実行、コンテナ操作、パッケージのインストール、デプロイテスト、ポート転送なんかをすることにある。トンネリングはその機能の一部だよ。本番サーバーにインストールして挙動に驚いてるなら、それは自分の責任だな。

リモートマシン上でファイルを編集し、任意のコマンドを実行するために作られたプログラムが……実際にそれを行っているだけじゃないか。何がそんなにおかしいのか分からない。SSH/SFTPでバイナリを送るのが一見奇妙に見えるかもしれないけど、VSCodeはリモートマシンがインターネットにアクセスできるとは限らないことを考慮する必要があるし、リモート側でエージェントを確実にブートストラップさせる手段が必要なんだ。SSHトンネル経由で送り込むのは、ごく自然な解決策だよ。

自分が使ってるエージェントは、作業ディレクトリから外に出られないように設計してあるし、そのディレクトリのフルパスを推測することすらできないようにしている。VSCodeが完全に逆のアプローチを取っているのは興味深いね。

2026年がどうなったかを考えると、この2025年時点の批判記事はなんだか古臭く見えるな。

ちょっと待って、これってどっちのマシンについて言ってるのか誰か教えてくれない？著者のセットアップだと、VSCode（フロントエンド）を自分の開発用ラップトップで動かしていて、そこには直接LLMを触らせたくないんだよね。で、VSCodeはSSH経由で専用の「サンドボックス」マシンに接続して、LLMがそこで好き勝手に動けるようにしている。VSCodeはMicrosoft流に、SSH接続を使ってサンドボックス側にVSCode Server（バックエンド）をインストールし、WebSocketで通信する仕組みだ。じゃあ何が問題なの？もしWebSocket接続でフロントエンドがサンドボックス側のコマンドを実行できるとしても、そもそもフロントエンドはSSH接続を持ってるし、強力なサーバープロセスも動いてるんだから、今さら驚くようなことでもない。サンドボックスの目的自体が、信頼できないコマンドを安全に実行することなんだし。でも記事にはWebSocketが「実行中のVSCodeフロントエンドに戻る」と書いてある。もしかして、話が逆なのか？つまり、エージェントはサンドボックス上で動いているのに、なぜかそのWebSocket接続を通じて、開発用ラップトップ側でもコマンドを実行できちゃうってこと？だとしたら、完全に狂ってるんだけど！

VSCodeとSSHが何のためにあるかを考えれば、筋違いな投稿だと分かるはずだよ。

なんでsshfsを使わないの？VSCodeができるずっと前からずっと使ってるけど、急に使えなくなったの？