コンテンツにスキップ
17.3k

Remote Workspace

SSH のマシンリンクについては、リモートリンク を参照してください。

Remote Workspace では、OpenCodex Hub でコーディングエージェントを実行し、別のコンピューターからプロジェクトファイル、コマンド、テスト、ビルド用の計算資源を提供できます。スマートフォンや 3 台目のコンピューターから、Hub のダッシュボードを通じてセッションを操作できます。

Phone browser -> Computer 1 OCX Hub -> encrypted channel -> Computer 2 OCX Executor
Codex / Claude / Pi project and commands
logins and sessions no coding CLI login

Executor に必要なのは OpenCodex だけです。Codex、Claude Code、Pi、ChatGPT ログイン、プロバイダー API キーは不要です。Hub への外向き WebSocket 接続を開くため、Executor に公開ポートやルーターのポート転送は必要ありません。

コンピューター 1 がすべてのコーディングエージェントのログインとモデルセッションを所有します。使いたいエージェントをそこにインストールしてログインし、OpenCodex を Hub として実行します。

Terminal window
ocx config set runtimeRole hub
OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
ocx gui

OCX_REMOTE_WORKSPACE_ENABLED=1 は Hub のプロセス自体に設定してください。ダッシュボード用コマンドにだけ設定しても、実行中のサービスは有効になりません。明示的に有効化されていない Hub は、ワークスペースキーの作成やコーディングエージェントのランタイム検査をせず、無効状態を返します。

スマートフォンや別のコンピューターからダッシュボードを開く場合は、認証付き HTTPS デプロイを使います。対応する管理アクセスと Tailscale の構成は Remote Hub Deployment を参照してください。認証のないローカルダッシュボードのポートを公開しないでください。

Codex Remote Workspace は現行の App Server 権限プロファイルを使います。Hub で選択された Codex 設定に旧式の sandbox_mode または sandbox_workspace_write が残っていると、弱い境界で起動する代わりに、ダッシュボードは Codex を利用不可と報告します。この機能を使う前に Codex プロファイルを移行してください。旧式のサンドボックスと権限プロファイルを併用しないでください。

  1. Hub ダッシュボードで Remote Workspace を開きます。
  2. Create pairing code を選びます。
  3. コンピューター 2 で、公開したいプロジェクトのディレクトリへ移動します。
  4. そのコンピューター用に生成された Linux / macOS terminal または Windows PowerShell コマンドをコピーします。現在のディレクトリをペアリングし、その端末で ocx remote-workspace agent の接続を維持します。

手動での同等の手順は次のとおりです。

Terminal window
cd /path/to/project
printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
--pairing-code-stdin --root "$PWD"
ocx remote-workspace agent

Windows PowerShell ではダッシュボードに表示されたコマンドを使います。同等の手動操作は次のとおりです。

Terminal window
$pairingCode = 'ONE-TIME-CODE'
$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
--pairing-code-stdin --root (Get-Location).Path
if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }

現在の OCX Bun 実行ファイルは、Linux サンドボックスに読み取り専用のファイル 1 件として自動追加されます。プロジェクトでシステムパス外のユーザーインストール済みツールチェーンが必要なら、ホームディレクトリ全体を公開せず、明示的にペアリングします。

Terminal window
printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
--pairing-code-stdin --root "$PWD" \
--toolchain-root "$HOME/.nvm/versions/node/v24/bin"

ネイティブヘルパーのソースはレビュー用に同梱されています。ビルドしても、この段階では Windows や macOS のコマンドは有効になりません。--executor-helper はレビュー済みヘルパーを選ぶための指定のままであり、バイナリの存在やパスの設定だけではコマンド対応の証明になりません。

ワンタイムコードはコマンドライン引数ではなく標準入力から読み取ります。ペアリングでローカルのデバイス署名鍵とデバイス単位のベアラーが作られます。Hub はそのハッシュのみを保存し、Executor の実際のパスは受け取りません。前面で動くエージェントは Ctrl+C で停止します。再実行すると同じデバイスとして再接続します。

秘密情報を表示せずにローカルの登録状態を確認できます。

Terminal window
ocx remote-workspace status

リモートコーディングセッションを開始する

Section titled “リモートコーディングセッションを開始する”

ダッシュボードで次を選びます。

  1. オンラインのコンピューター。
  2. ローカルで承認済みのワークスペースフォルダー 1 件。
  3. Hub 上の Codex、Claude Code、Pi のいずれか。
  4. アクセスモード。

既定の Read only では、ディレクトリ一覧とファイルの読み取りができます。書き込みオプションは、Executor がコマンドサンドボックスのプローブに合格した場合だけ Edit files and run commands と表示されます。それ以外では Edit files only です。ダッシュボードは 2 つの場所を別々に示し、モデルとログインは Hub にあり、ワークスペース操作は選択したコンピューターで行うことを明確にします。

プロンプトはコンピューター 1、コンピューター 3、スマートフォンから Hub ダッシュボードを通じて送れます。セッションが別のコンピューターやフォルダーへ黙って切り替わることはありません。Executor が切断されると Executor offline となり、Hub のファイルシステムに切り替わることもありません。

プロンプト送信は受け付けを直ちに通知し、ダッシュボードがセッションをポーリングして進行状況と完了を確認します。通知が失われた場合、下書きは送信状態不明の表示とともに残ります。再送信前にセッションの進行状況を確認してください。ダッシュボードが自動再試行することはありません。

プロンプトの実行中も Stop を使えます。Hub のコーディングエージェントのターンを中断し、実行中の Executor コマンドをキャンセルし、遅れて届いた応答が停止済みセッションを再開しないようにします。

Hub は、容量を制限したセッションメタデータと最近のイベントの小さなスナップショットを保存します。Hub の再起動後、未完了セッションは元の Executor を待ちます。そのデバイスが再接続すると、次のプロンプトは元の Codex スレッド、Claude Code セッション、または Pi セッション ID を再開します。

Claude Code は、最初のプロンプトが完了した時点で永続履歴を作ります。新しい Claude セッションでプロンプトが一度も完了しないまま Hub が停止した場合、再開する会話がないため、新しいセッションを開始してください。

機能一覧の変更によって既存セッションの保護が黙って弱まることはありません。Executor がコマンドの封じ込め機能を失った場合や、利用可能なツールが変わった場合は新しいセッションを開始します。コンピューターの登録を取り消すと、そのソケットは閉じられ、紐付くセッションは停止します。

  • プロバイダーの認証情報とコーディングエージェントの履歴は Hub に残ります。
  • Executor の秘密鍵、デバイスベアラー、実際のルートパスは、所有者のみがアクセスできる OCX 状態に残ります。
  • ペアリングコードの失敗は、すべてのリスナーでカーネルが観測した接続元ごとに制限されます。10 分間に 10 回失敗すると、一般的な 429 と Retry-After が返ります。Hub が保持するのは、それらの接続元 ID の期限付きで容量を制限したハッシュだけです。直接のローカル呼び出し元が識別ヘッダーを偽装できるため、Tailscale Serve の利用者は管理リスナーのループバック用の制限枠を共有します。
  • 各作業セッションでは、Ed25519 で署名した一時的な P-256 ECDH ハンドシェイクと、順序付き AES-256-GCM メッセージを使います。
  • 双方が現在の機能一覧に合意するまで、ソケットはオンラインとして表示されません。
  • 再接続時、ローカルサンドボックスが利用できなければ機能を減らせますが、ペアリング時の許可範囲外の機能は追加できません。
  • 各リクエストは、1 つのモデルスレッド、デバイス、ルート、アクセスモード、機能セットに結び付けられます。
  • パスは相対化、正規化、範囲制限され、シンボリックリンク、ジャンクション、親ディレクトリ経由の脱出は拒否されます。Windows のデバイス名、代替データストリーム、末尾のドットや空白を使う別名も拒否されます。
  • Executor の操作は直列化され、開いたファイルの ID を再確認します。アトミックな置き換えの直前にも書き込みハッシュを確認します。承認済みルートの変更には再ペアリングが必要で、ツールチェーンルートは各コマンドの前に再検証されます。
  • ハードリンクされたファイルの読み書きは拒否されます。コマンド実行前にはワークスペース内を最大 250,000 件走査し、ディレクトリ以外の項目に複数のリンクがあればコマンド経路を無効にします。パスのサンドボックスだけでは、その inode の別名が承認済みルート外にあるか確認できないためです。
  • Linux のコマンドは bubblewrap を通じて実行されます。書き込み可能なワークスペースは 1 つで、環境は消去され、プロセス名前空間は分離されます。現在の OCX Bun 実行ファイルは読み取り専用ファイル 1 件として渡され、出力と時間には上限があり、ネットワークは既定で無効です。専用の封じ込めテストには明示的に設定したホスト環境が必要です。一般的なテストスイートの成功だけでは実行の証拠になりません。
  • macOS が公開するのはファイルツールだけです。子孫プロセスが setsid() を呼ぶと、プロセスグループでは封じ込められません。また、コマンド起動のために広い Apple Seatbelt システムプロファイルを取り込むと、無関係なホストサービスへの権限が与えられます。そのため、狭い範囲で取り消し可能な子孫プロセス管理主体が用意されるまで、ネイティブヘルパーはプローブと直接コマンドの両方を拒否します。
  • Windows と macOS のネイティブコマンド要求は安全側で失敗します。ヘルパーが直接拒否するテストと、コマンド封じ込めが機能する証拠は区別が必要です。Windows でのコマンド受け入れは未対応です。
  • 固定されたネイティブヘルパーは、承認されたすべての書き込み可能ワークスペースの外に置く必要があります。OCX はコマンド対応の公開前と各コマンドの直前の両方で確認し、ワークスペース内のコードが次のサンドボックスを実施するバイナリを置き換えられないようにします。
  • セッション停止時は実行中の Executor コマンドをキャンセルし、Hub のモデルプロセスとループバックツールブリッジを掃除します。Windows は npm ラッパーが所有するプロセスツリーを停止し、Node の子プロセスを残しません。Linux と macOS は、CLI が正常停止の猶予期間を無視した場合だけ強制停止します。

Hub はコーディングエージェントを実行するため、意図的にプロンプトとモデル出力を参照できます。エンドツーエンド暗号化で保護されるのは Executor RPC のペイロードです。ペアリング済み Hub は、認証された WSS 経由で承認済みルートを選ぶ信頼対象であり、自身のモデルとの会話から遮断されるわけではありません。

Remote Workspace は認証情報をほかのコンピューターにコピーも同期もしません。Remote Hub のプロバイダールーティングや、将来のホスト計算資源または Super Sync 製品とは別の機能です。実運用向けリリースには、署名済み Windows ヘルパーのパッケージ化、対象バイナリそのものについてのネイティブ CI 証拠、独立したメンテナーレビュー、実際の 3 台構成での受け入れ確認がなお必要です。

POST /api/remote-workspace/sessions/:id/prompt は、受け付けたセッションのスナップショットと HTTP 202 を返します。セッション ID と単調増加するイベント番号は受け付け時点のスナップショットを識別します。202 はモデルのターン完了を意味しません。以後のイベントと最終状態は GET /api/remote-workspace/sessions をポーリングしてください。そのターンが実行中の間、再接続とランタイム再開はビジー状態のままです。受け付け通知が失われると受け付けの有無は不明になるため、クライアントは再送信するか決める前にポーリングする必要があります。