Claude Code / Codex / Cursor、スマホから作業の続きができないのはどれか──リモート操舵はエージェントループの置き場所で決まる

この記事について
Claude（Anthropic）との共同編集により作成されました。

要約

Claude Code・Codex・Cursor の3つをリモート接続の観点で試して、自分が重視しているのはローカルで Agent CLI を立てて、その同じセッションをスマホから続けることだと気づいた

この軸（既存セッションの操舵）で比べると、Claude Code > Codex > Cursor になる。2026年9月時点の各社公式ドキュメントとも整合している

差を作っているのは機能の数ではなく、エージェントループがどのマシンで回っているか。Claude Code は実行マシン上に残り、Codex は起きている Desktop ホストが要り、Cursor の IDE Remote SSH はクライアント側で回るので切断で落ちる

Claude Code は Remote Control をデフォルトで有効にできるのが大きい。remoteControlAtStartup を立てておけば、ローカルで claude と打つだけでスマホから再開できる状態になる

Codex はホストの ChatGPT Desktop が立ち上がっていないと接続できず、自分も繋がらないことが何度かあった。今どのセッションがアクティブなのかも分かりにくい

Cursor の Remote Control は別経路で、こちらはループをクラウド側へ渡す設計。IDE SSH の評判と同一視すべきではないが、「今のセッションがそのまま切断に耐える」形にはまだなっていない

クラウドの隔離環境で新規タスクを走らせる軸なら順位は変わりうる。そこは Cursor が厚い。ただ Claude も弱くはないので、今回は軸を分けて置いておく

手元のマシンで claude や codex を立てて作業していて、そのまま出かけたい。電車の中でスマホを開いて、さっきの続きをそのまま操舵したい。

自分がリモート接続まわりに求めているのは、突き詰めるとこれだけだった。3つとも試してみて、ようやく自分のユースケースが言語化できた感じがある。クラウドに新しい環境を立てて走らせる話でもないし、GPU 箱に SSH する話でもない。いま動いているこのセッションを、別のデバイスから覗いて続けるという一点である。

その軸で比べると、順位はかなりはっきり分かれた。Claude Code、Codex、Cursor の順になる。決め手になったのは機能の数ではなく、エージェントループがどのマシンで回っているかと、リモート接続をデフォルトの状態にできるかどうかだった。

以前 Claude Code の --remote-control を試した記事を書いたが、あれは Claude Code 単体の話だった。今回は3つ横に並べて、なぜこの順位になるのかを構造から整理する。

まず「リモートコネクト」を3層に分ける#

各社とも Remote / Remote Control / Remote SSH という名前を使っていて、しかも指しているものが違う。ここを分けないと比較が成立しない。

層	何を指すか	典型的なユースケース
A. セッション操舵	自分のマシンで動いているエージェントを、スマホ・ブラウザ・別PCから続ける	デスクで始めた作業を、ソファや外出先から操舵する
B. リモート実行環境	コードとツールが既にある SSH ホストや開発 VM 上でエージェントを動かす	GPU 箱、社内 devbox、依存関係がローカルに無いリポジトリ
C. クラウド隔離環境	ベンダーが用意した VM / コンテナで新規タスクを走らせる	PR を切る、CI 相当の作業を投げて待つ

自分が欲しかったのは A である。B は「A をリモートの箱でもやりたい」という派生なので今回の比較では補助扱い、C は別の話として最後に触れる。

この分け方を外して読むと、Cursor が不当に低く見える。Cursor が強いのは C だからだ。

結論：A 軸での順位表#

評価軸	Claude Code	Codex	Cursor
A. セッション操舵の完成度	高い	高い（Desktop 前提）	中（前提条件が多い）
エージェントループの置き場所	実行マシン上に残る	実行ホスト / app-server 上	IDE SSH はクライアント側、Remote Control はクラウド側
切断・スリープ耐性	自動再接続とキューイングあり	ホストが起きている必要あり	IDE SSH は切断でセッション喪失（公式に既知）
セットアップの軽さ	CLI 一発。既定で自動接続にもできる	Desktop ペアリングが主経路	経路が分裂している
今どれが生きているかの分かりやすさ	端末のインジケータとセッション一覧で分かる	分かりにくい	一覧はある（クラウド側）
モバイル到達性	iOS / Android / 任意のブラウザ	iOS / Android（ChatGPT アプリ）	iOS のみ（Android は予定）
B. SSH 先での実行	高い	高い（Desktop 経由）	低い〜中
C. クラウド隔離環境	あり（別機能）	あり（Codex cloud）	強い（Cloud Agents が本流）

A と B を主軸にすると Claude Code が抜ける。C を主軸にすると順位は入れ替わる。この記事は前者の話をしている。

差を作っているのはエージェントループの置き場所#

機能表を眺めていても順位の理由は出てこなかった。効いていたのは、エージェントのループがどのマシンで回っているかという一点である。

1
Claude Code Remote Control
2
  [スマホ / ブラウザ] ──relay──> [実行マシン上の claude プロセス]
3
                                   ↑ ファイル・シェル・MCP はここ
4

5
Codex Remote
6
  [スマホ] ──relay──> [ChatGPT Desktop ホスト] ──SSH──> [リモート app-server]
7
                      （ホストが落ちると全体が止まる）
8

9
Cursor IDE Remote SSH
10
  [ローカル Cursor クライアント] ──SSH──> [リモート editor/server]
11
         ↑ エージェントループはここ（クライアント側）
12
         切断・スリープ・ウィンドウ閉鎖で作業が止まる
13

14
Cursor Remote Control / My Machines
15
  [スマホ / Web] ──> [Cursor クラウドのエージェントループ] ──outbound──> [自マシンの worker]

表にするとこうなる。

製品	ループの場所	ツール実行の場所	切断したときの意味
Claude Code Remote Control	実行マシン	実行マシン	UI は窓。プロセスが生きていれば作業は残る
Codex Remote	Desktop ホスト（必要なら SSH 先）	ホスト / SSH 先	Desktop が落ちると操舵できない
Cursor IDE Remote SSH	ローカルクライアント	リモート	クライアント切断でエージェント停止
Cursor Remote Control / My Machines	Cursor クラウド	自マシン	自マシンは起きている必要あり。会話状態はクラウド側へ移る

Claude Code だけが、既存セッションそのものを別デバイスから覗く設計になっている。Codex は Desktop をハブにする。Cursor の IDE SSH はエディタ接続であって、エージェントの耐久実行ではない。Cursor の Remote Control はセッションをクラウド側へ渡す。

自分の欲しかったものが A だったので、この構造の違いがそのまま順位になった。

Claude Code#

セッション操舵#

Remote Control は、ローカル（または SSH 先）で動いている Claude Code を claude.ai/code と Claude モバイルアプリから操舵する機能である¹。

起動経路が3つある。

起動方法	用途
`claude remote-control`	サーバモード。接続待ち専用で、QR とセッション URL を出す
`claude --remote-control`（`--rc`）	普段の対話セッションを、同時にリモート公開する
`/remote-control`（`/rc`）	既に動いている CLI / VS Code セッションを、あとから公開する

効いてくるのは3番目である。作業を始めたあとで出かけることになる、という順番のほうが普通なので、走っているセッションにあとから窓を開けられるのは大きい。

さらに言えば、その3番目の手間すら省ける。/config の Enable Remote Control for all sessions を true にするか、~/.claude/settings.json に remoteControlAtStartup を true で書いておくと、対話セッションの起動時に自動で接続する¹ ²。Desktop アプリなら Settings > Claude Code > Enable remote control by default、VS Code 拡張なら同名のトグルが同じ役割を持つ¹。

自分の運用ではここがいちばん大きかった。ローカルのターミナルで普段どおり claude と打つだけで、そのセッションはもうスマホから再開できる状態になっている。「リモートで続けたい」と思った時点で何かを設定する必要がない。リモート接続が特別な操作ではなく、ただのデフォルトになる。

自動接続を有効にすると、対話セッションのプロセス1つにつきリモートセッションが1つ登録される。複数インスタンスを立てれば、それぞれ別のセッションになる¹。1プロセスで複数セッションを捌きたいときはサーバモードを使う¹。

公式が明記している性質は次のとおり。

実行とファイルアクセスはマシン上に残る。Web とモバイルは窓である¹
端末・ブラウザ・スマホを同時に使え、会話とサブエージェントの進行が同期する¹
スリープやネットワーク断のあと、復帰時に自動再接続する。再接続中はメッセージ・権限プロンプト・サブエージェント更新をキューする¹
アウトバウンド HTTPS のみで、インバウンドポートは開かない¹
iOS / Android / 任意のブラウザから接続できる。QR コードかセッション URL で入る¹
サーバを止めたあとも、同じディレクトリなら約4時間は claude remote-control -c や --session-id で復帰できる¹

リモート実行環境#

Desktop アプリの環境セレクタから SSH 接続を追加できる。user@hostname（または ~/.ssh/config の Host）、ポート、秘密鍵を入れると、初回接続時にリモートへ Claude Code を自動インストールする。リモート側の OS は Linux か macOS。接続後は権限モード、コネクタ、プラグイン、MCP が使える³。

CLI 経路なら、リモートに Claude を入れて tmux や screen で常駐させ、その上に Remote Control を足す。この使い方は公式の制限事項にも書かれている。プロセスを止めればセッションはオフラインになる¹。

弱い点#

いいことばかりではない。

claude.ai へのログインが必須。API キー、setup-token / CLAUDE_CODE_OAUTH_TOKEN、Bedrock / Agent Platform / Foundry、カスタム ANTHROPIC_BASE_URL では使えない¹
DISABLE_TELEMETRY などフラグ評価を無効化する設定でも Remote Control が落ちる¹
Team / Enterprise は管理者トグルがオフだと使えない。Zero Data Retention 環境では有効化できない¹
ローカルプロセスが生きている必要がある。長時間のサーバモードでネットワークが切れると、約10分でプロセスが終了する¹
Desktop の SSH 先は Linux / macOS で、Windows リモートは対象外³

独自ゲートウェイや Bedrock 前提の環境だと、そもそも土俵に乗らない。ここは事前に確認したほうがいい。

Codex#

セッション操舵#

ChatGPT の Remote は、接続済みの Mac / Windows 上で動く ChatGPT Desktop を、モバイル（iOS / Android）や別の Desktop から操舵する機能である⁴。ホストのプロジェクト、チャット、ファイル、資格情報、権限、プラグイン、Computer Use、ブラウザ設定、ローカルツールが使える。

セットアップは Desktop 起点になる。

ホストで Settings > Connections > Control this Mac or PC
QR をモバイルで読む
同一アカウント / ワークスペースでペアリングを完了する

ここが Claude Code との一番の違いで、公式も「モバイルのセットアップはアプリから始める。Codex CLI や IDE 拡張からはセットアップできない」とはっきり書いている⁴。セットアップを CLI 側から始められないのが効いてくる。CLI 側にも codex remote-control（フォアグラウンド）、start / stop、pair（短命ペアリングコード）はあるが、これは管理クライアントと SSH リモート向けで、codex app-server --listen の代替ではない⁵。

リモート実行環境#

Desktop の Connections > SSH から、~/.ssh/config の具体的な Host エイリアスを読み、リモートの Codex app-server を SSH 経由で起動する。リモートの login shell の PATH に codex がある必要がある⁴。

チャットの Hand off は、ローカルと接続済みリモートのあいだで会話と Git 状態を移す機能で、先方に同じリポジトリ（同じサブディレクトリ）の保存済みプロジェクトが必要になる。Codex cloud 環境への handoff は非対応⁴。

CLI の codex --remote ws://... はリモート app-server に TUI を接続する。対象は codex / resume / fork だが、WebSocket 輸送は公式に experimental / unsupported 扱いで、ループバック＋SSH ポートフォワードが推奨されている⁶ ⁵。

強い点と弱い点#

強いのは、ChatGPT モバイルが iOS / Android 両方あること、Connections UI が「この Mac を制御 / 他デバイスを制御 / SSH」と分かれていて分かりやすいこと、ホスト間の chat handoff があること。公開リスナを晒さず VPN / mesh を前提にする、という注意書きが公式にあるのも良い⁴。

弱いのは、ほぼ一点に集約される。日常のリモート操舵が Desktop ハブ前提なので、ホストのスリープ・ネットワーク断・アプリ終了で止まる⁴。Mac は蓋を閉じてスリープすると落ちるため、蓋閉じ運用は外部ディスプレイ接続が条件だと公式が書いている⁴。

実際、自分も繋がらないことが何度かあった。ホスト側の ChatGPT Desktop が立ち上がっていないと、スマホからはそもそも接続できない。公式の要件も、最新の ChatGPT デスクトップアプリが、起きていてオンラインで、同じアカウントとワークスペースにサインインしたホスト上で動いていること、となっている⁴。トラブルシューティングの先頭も「ホストがスマホに出てこないときは、デスクトップアプリが起動しているか確認せよ」だ⁴。ホストが寝る・回線が切れる・アプリを閉じる、のいずれかが起きるとリモートアクセスは止まり、復帰するまで戻らない⁴。

要件としては何もおかしくない。ただ、出先でスマホを開いた瞬間に、その要件が満たされているかどうかが分からないのが、運用上はつらい。Claude Code のように「ターミナルで立ち上げた時点でもう繋がっている」ものと比べると、接続できるかどうかを毎回ホスト側の状態に賭けている感覚になる。

他にも、2026-06-08 以降使っていない既存接続は再ペアリングが必要⁴、ワークスペース管理者の Remote Control 許可が要る場合がある⁴、ロールアウト差で機能が見えないことがある⁴、といった前提が乗る。

Claude Code より一段落ちる主因は機能不足ではなく、操舵の対象が、今の CLI セッションではなく、起きている Desktop ホストであることだと思っている。機能集合は近い。ハブ依存とセットアップの摩擦が効いてくる。

Cursor#

Cursor はリモートらしい機能が複数あって、名前が重なる。ここが評価を下げやすい。

機能	層	実体
IDE Remote SSH	B	VS Code 系のリモートエディタ。エージェントの耐久実行ではない
Agents Window の Remote Control	A	ローカル / Remote SSH ワークスペースのセッションをクラウドループへ渡し、スマホから操舵する⁸
My Machines	A / B	`agent worker start`。ツール実行だけ自マシン、ループはクラウド⁹
Cloud Agents	C	Cursor 管理の VM。モバイル体験の本流⁸

Agents Window の Remote Control#

Cursor 3.9.8 以降の機能で、/remote-control のあと次のメッセージを送ると、セッションを自マシン上の worker に渡し、他デバイスから操舵できるようになる。エージェントループはクラウドへ移り、ターミナル・編集・テスト・git は自マシンで走る⁸。

前提条件が多い。

Agents Window 専用で、クラシック IDE だけでは設定もコマンドも出ない⁸
Pro / Pro+ / Ultra / Teams / Enterprise で Cloud Agents が使えるアカウントが必要⁸
クラウドへのデータ保存を許可する必要があり、Privacy Mode (Legacy) では使えない⁸
Teams / Enterprise は管理者が Dashboard → Cloud Agents → Self-Hosted で有効化する⁸
自マシンは起きてオンラインである必要がある（Keep this computer awake がある）⁸
モバイルアプリは iOS 26+ / iPadOS 26+ で、Android は予定⁸

My Machines は個人向けの常駐 worker で、agent worker start がアウトバウンド HTTPS を張り、cursor.com/agents の環境ドロップダウンからそのマシンを選ぶ⁹。リポジトリと worker-dir の対応が要るので、Git を正とする運用が前提に近い。

IDE Remote SSH がいちばん弱い#

ここが構造的な弱点になる。IDE Remote SSH では、エージェントループがクライアント側にある。Cursor のスタッフが公式フォーラムで、恒久的な切断（ノート PC のスリープ、ウィンドウ閉鎖）ではエージェントセッションが失われる、これは既知の制限である、と回答している¹⁰。

ユーザー側の要求は「Claude や Codex を tmux で常駐させるのと同じことを Remote SSH でやりたい」なのだが、Cursor はその形を IDE SSH では提供していない。公式側が挙げる回避策は、リモート上の Cursor CLI を tmux で回すか、Cloud Agents / My Machines に逃げることである¹⁰。つまり IDE の Remote SSH をリモート操舵の本命にしてはいけない。

これとは別に、フォーラムには不安定さの報告も繰り返し出ている。Agents Window の Remote SSH でターミナルが出ない¹¹、SSH 瞬断後に No Connect transport provider registered. でエージェントが黙って死ぬ¹²、エディタは動くが cursor-agent-exec がリモートで起動せずタイムアウトする¹³、といったものだ。

ただしこの手の不具合はバージョン依存で、改善も再発もするので、製品の仕様として書くべきではない。順位の根拠にしているのは、あくまでスタッフが認めているクライアント側ループのほうである。ここは分けて見てほしい。

Cursor の名誉のために#

Cursor がこの軸で最下位になるのは、機能が無いからではない。既存マシン上の耐久セッションという一点で、IDE 本流が構造的に不利というだけだ。

Cloud Agents は製品の本流として厚く、モバイルから PR レビューやマージまで届く⁸。My Machines と Team Pools は「自前マシンでツール実行、ループはクラウド」という形でエンタープライズ向けに整理されている⁹ ¹⁴。Remote Control は worker を自動管理してくれるので、別途 agent worker start しなくていい⁸。

問題は、A と B が一つの体験に統合されていないことだ。経路が4つあって、どれが「今のセッションを続ける」ものなのか分かりにくい。

切断とスリープで何が起きるか#

A 軸の実用性は、結局この表に落ちる。

事象	Claude Code	Codex	Cursor IDE SSH	Cursor Remote Control
ノート PC のスリープ	復帰後に再接続。キューあり¹	ホストが寝ると操舵停止⁴	セッション喪失¹⁰	ツール実行不可⁸
短時間のネットワーク断	再接続とキュー¹	ホスト依存⁴	黙死や Reload が報告されている¹²	worker のアウトバウンド次第⁹
UI を閉じる	プロセスを止めればオフライン¹	Desktop 終了で停止⁴	ウィンドウ閉鎖で停止¹⁰	自マシンの worker が生きていればクラウド側は続きうる⁸

「出かける前にノート PC を閉じる」という日常動作に、いちばん素直に耐える設計になっているのは Claude Code である。もっとも Claude Code もマシンが寝れば作業は進まないので、離れているあいだも働かせたいなら別の工夫が要る。そのあたりは前の記事で書いた。

セットアップ摩擦#

差がいちばんはっきり出るのはここだ。

Claude Code — プロジェクトディレクトリで claude --remote-control。出てきた URL か QR を開く。以上。自動接続をオンにしてあるなら、普段どおり claude と打つだけで何もしなくていい
Codex — Desktop をインストールし、Connections を設定し、QR でペアリング。必要なら SSH config とリモートの codex
Cursor — Agents Window、Cloud Agents 権限、クラウド保存の許可、管理者トグル、iOS アプリ。IDE SSH に行くと別の失敗モードに入る

Claude Code は公開するだけ、Codex はホストをペアする、Cursor はセッションをクラウドに移す。求めているモデルとの距離が、そのまま手数の差になっている。

今どれが生きているのか分かるか#

事前に評価軸として立てていなかったが、使っていると効いてくるのがこれだった。

Claude Code は、ターミナル側に /rc active のインジケータが出る¹。接続したセッションは claude.ai/code と Claude アプリのセッション一覧に並び、オンラインのものにはコンピュータのアイコンと緑のドットが付く¹。名前は --name や /rename で付けられ、指定しなければ myhost-graceful-unicorn のようにホスト名を接頭辞にした名前が自動で入る¹。どのマシンのどのセッションを触っているのかが、一覧の時点で分かる。

Codex はここが分かりにくい。今ホスト上でどれがアクティブなのかが掴みづらく、これも自分の中で評価を下げる要因になった。公式ドキュメントを見ても、モバイルから現在のアクティブセッションを一覧するインターフェースについての記述は見当たらない⁴。

Cursor は cursor.com/agents にエージェントの一覧があるが、これはクラウド側から見た一覧である⁸。「今この手元のマシンで何が動いているか」とは、見ている対象が少しずれる。

地味な差に見えて、セッションを立てっぱなしにして出かける運用ほど効いてくる。戻ってきて開いたときに、どれが今の作業なのかを一覧で判別できないと、そもそも続きから始められない。

モバイルとデータ境界#

	Claude Code	Codex	Cursor
iOS	あり	あり（ChatGPT）	あり（iOS 26+）
Android	あり	あり	予定⁸
任意のブラウザ	`claude.ai/code`	Desktop / ChatGPT 経路	`cursor.com/agents`
通知	`/config` の push 設定¹	タスク完了・承認待ち⁴	ターン完了 push、Live Activities（最大8）⁸

Android ユーザーだと、この時点で Cursor は候補から外れる。

データ境界も見ておく価値がある。3つともインバウンドポートは開かない（リレー方式）が、クラウドに残るものが違う。Claude Code は同期用のトランスクリプト¹、Codex はリレー経由の会話⁴、Cursor の Remote Control は続行に必要な会話状態とモデルコンテキストをクラウドへ送ると公式に書いてある⁸ ¹⁴。

「コードを自マシンから出したくない」という要件があるなら、ループも実行もマシン上に残る Claude Code がいちばん説明しやすい。

クラウド隔離環境の軸は、今回は置いておく#

ここまでの順位は A + B という前提の上に乗っている。C（クラウドの隔離環境で新規タスクを走らせる）を主軸にすると、話は変わりうる。

	Claude Code	Codex	Cursor
製品名	Claude Code on the web / Cloud セッション	Codex cloud environments⁷	Cloud Agents⁸
モバイルからの新規タスク	あり	あり	本流
既存ローカル状態の再利用	Remote Control 側¹	Remote 側。cloud への handoff は不可⁴	Move to Cloud / My Machines⁹
備考	Remote Control とは別物、と公式が対比している¹	setup script と internet access 制御が厚い⁷	PR レビューまでモバイルで完結する⁸

この軸だと Cursor の Cloud Agents は明確に厚い。ただ Claude 側も普通に戦えそうな感触があったので、ちゃんと比べるにはもう一回まとまった試用が要る。今回は軸を混ぜないために置いておく。

逆転しうる条件を明示しておくと、こうなる。

主用途が C（クラウドでの新規タスク、PR、モバイルレビュー）なら Cursor が上がる
ChatGPT Desktop を常時起動する運用が既にあるなら、Codex と Claude Code の差は縮む
iOS のみで、かつ Cloud Agents 前提の組織なら Cursor のモバイル体験は厚い
Bedrock や独自ゲートウェイが必須なら、Claude Code の Remote Control はそもそも使えない¹

使い分け#

最後に、やりたいこと別の第一選択をまとめておく。

やりたいこと	第一選択	理由
今の CLI セッションをスマホから続ける	Claude Code	既定で自動接続にでき、実行場所も動かない
常時起動の Desktop を別デバイスから触る	Codex	ChatGPT Remote のペアリングが製品として整っている
社内 SSH の Linux / macOS 箱でコーディングする	Claude Code Desktop SSH、または Codex SSH	エージェントがリモート側で走る
ノート PC を閉じても SSH 先のエージェントを生かしたい	Claude Code / Codex + tmux	Cursor IDE SSH はクライアント側ループが公式の既知制限¹⁰
外出先から PR を切ってレビューする	Cursor Cloud Agents、または各社の cloud	C 層は Cursor が厚い
自前 GPU や社内ネットのままクラウド UI から投げる	Cursor My Machines、Codex self-hosted exec-server	ループはベンダー、実行は自前

3つ触ってみて得た一番の収穫は、順位そのものより自分が A を欲しがっていたと気づけたことのほうだった。同じ「リモート」という言葉でも、A が欲しい人と C が欲しい人では最適解が違う。比較記事を読むときは、書き手がどの層の話をしているかを先に確認したほうがいい。この記事は A の話をしている。

なお各社とも Remote まわりの更新が速い。ここに書いたのは2026年9月時点の公式ドキュメントに基づく整理なので、導入前に一次情報を見てほしい。

参考文献#

Claude Code Remote Control https://code.claude.com/docs/en/remote-control
Claude Code settings reference（remoteControlAtStartup） https://code.claude.com/docs/en/settings-reference#remotecontrolatstartup
Claude Code Desktop application（SSH sessions） https://code.claude.com/docs/en/desktop
Codex Remote connections https://learn.chatgpt.com/docs/remote-connections
Codex developer commands（--remote, codex remote-control） https://learn.chatgpt.com/docs/developer-commands?surface=cli
Codex App Server https://learn.chatgpt.com/docs/app-server
Codex Cloud environments https://learn.chatgpt.com/docs/environments/cloud-environment
Cursor for iOS / Remote Control https://cursor.com/docs/cloud-agent/mobile
Cursor My Machines https://cursor.com/docs/cloud-agent/self-hosted/my-machines
Cursor Forum — Durable agent runtime on Remote SSH/Cloud-workstations（スタッフ回答: エージェントループはクライアント側） https://forum.cursor.com/t/durable-agent-runtime-on-remote-ssh-cloud-workstations/159513
Cursor Forum — SSH remote connection in agents window not working https://forum.cursor.com/t/ssh-remote-connection-in-agents-window-not-working/160784
Cursor Forum — Agents Window: after Remote SSH disconnect, agent dies silently https://forum.cursor.com/t/agents-window-after-remote-ssh-disconnect-agent-dies-silently-with-no-reload-reconnect-option/167027
Cursor Forum — Remote SSH agents fail with ERROR_EXTENSION_HOST_TIMEOUT https://forum.cursor.com/t/remote-ssh-agents-fail-with-error-extension-host-timeout-cursor-agent-exec-is-installed-but-never-activates/166253
Cursor Self-Hosted Machines https://cursor.com/docs/cloud-agent/self-hosted