Codex AppとClaude DesktopからSSHで入る｜常設運用の勘所

AIエージェントの開発をご検討中ですか？ AIエージェント開発サービスを見る →

連載「Docker Sandboxesでコーディングエージェントを隔離する」第5回／検証日: 2026年8月23日／sbx 0.39.0

ここまでで、共通Kit・CodexとClaudeが同居する永続Sandbox・ランチャー・credentialが揃いました。残りは入り口です。

ターミナルからsbx runで入っても開発はできます。それでもCodex AppとClaude Desktopからつないでいるのは、デスクトップ版が持つ実ブラウザやplugin連携と、microVM内のコード実行を1つのループへ入れられるからです。

SSHはdaemon socket経由で、外部にportを開かない

準備は一度だけです。

sbx setup ssh

このコマンドは~/.ssh/configへDocker Sandboxes管理のHost *.sbx設定を追加します。着目すべきは接続の経路です。22番portへは向かわず、ProxyCommand経由でローカルのsbx daemon socketへ流れます。

つまり、これを実行しただけでインターネットやLANからサンドボックスへSSHできるようになるわけではありません。サンドボックス内でSSH serverを公開しているわけでも、ホストの22番portをforwardしているわけでもない。ホスト上のプロセスからdaemon socketへ話しかけているだけです。

疎通確認はこれだけ。

ssh sampleapp.sbx -- echo connected

停止中のサンドボックスは、SSH接続時に自動起動します。止めておいても入り直せるので、使い終わったら遠慮なく落として構いません。

ただし、抜け道はあります。SSH client側でremote／local port forwardingを足してnon-loopback addressへbindすれば、別の公開経路を作れてしまいます。SSH設定が安全だからと油断せず、第2回で書いたとおり開発サーバーのhost bindはloopbackへ寄せておきます。安全なのはsbx setup sshが作る経路であって、その上にこちらが足す設定までは面倒を見てくれません。

Codex Appから接続する

接続前に、ターミナルでssh sampleapp.sbxが通ること、そしてサンドボックス内のlogin shellでcodexコマンドがPATHにあることを確認します（第2回でKitから入れたものです）。ここが通っていないと、アプリ側のエラーが接続の問題なのか環境の問題なのか判別できません。

手順は6段です。

Codex AppのSettings > Connectionsを開く
SSH connectionを追加する
Hostへsampleapp.sbxを入力する
接続後、remote folder pickerでプロジェクトのプライベートcloneを選ぶ
remote sessionを開始する
pwd、git status、node --versionで着地点を確かめる

folder pickerが最初に/home/agentを表示することがあります。ホストの絶対パスを保った場所へworkspaceが置かれる構成もあるので、見つからなければpwdやfindで実際のclone先を探してください。第1回で書いたclone modeの話がここで効いてきます。開いているのはホストのリポジトリではなく、microVM内のプライベートcloneです。

Codexのコマンド承認設定は、Docker Sandboxesの隔離とは別管理です。サンドボックスへ閉じ込めた前提で承認を緩めるなら、remote chatごとにpermissionを変えます。ここを緩められるのが、そもそも隔離した見返りです。

デスクトップ版から入る価値は、ブラウザとpluginにある

remote connectionでは、接続先hostのファイル・credential・permission・plugin・browser setup・local toolsがremote projectの実行環境として使われます。裏を返せば、デスクトップアプリ側が持っている機能を、サンドボックス内のコードに対して使えるということです。

UI修正のループはこうなります。

エージェントがサンドボックス内でnpm run devを起動する
ホスト側のブラウザ機能でlocalhost:3000を開く
screenshotとDOM／console／networkの状態を確認する
サンドボックス内のコードを直す
hot reload後の画面を再確認する
lintとbuildを回す

ブラウザはホスト、アプリはmicroVM。ターミナルだけで開発していると、2と3が人の手作業として分断されます。デスクトップ版から入ると、認証済みのブラウザsessionとscreenshotとコード修正が1つのループに入るので、UIの修正が目に見えて速くなりました。

注意点もあります。拡張機能やpluginがどのhostで動くか、remote sessionでも使えるかは製品ごとに違います。SSHで入れること自体が、すべての拡張へ権限を与えるわけではありません。機密ページを操作するなら、ブラウザ側の権限も別に確認してください。

Claude Desktopから接続する（credentialのtrade-off）

Claude DesktopはClaude agent typeのサンドボックス、つまり第1回で作ったsampleappへ接続します。Codex Appと同じhostです。

environmentのドロップダウンを開く
+ Add SSH connectionを選ぶ
Connection Nameを入力する
SSH Hostへsampleapp.sbxを入力する
SSH PortとIdentity Fileは空欄のまま保存する
作成したenvironmentを選ぶ
remote folder pickerでプライベートcloneを開く

ここで一点、明示的に受け入れる必要のあるtrade-offがあります。Dockerの公式ドキュメントには、Claude DesktopからSSH接続するとAnthropic credentialがサンドボックス内のClaude Codeプロセスへ渡るため、proxy-managed credentialより分離保証が弱くなると書かれています。

第3回・第4回でやってきたのは「実キーをホストに残し、サンドボックスにはsentinelだけ渡す」という設計でした。この接続だけはその形になりません。サンドボックス内から読める認証情報が存在する前提で運用します。だからこそ、GitHubのトークンとアプリのAPIキーは絞っておく価値があります。すべてのcredentialが同じ強度で守られるわけではないので、弱い経路が1つ混ざる前提で他を締める、という考え方になります。

Anthropicのtoken更新後に接続が切れることがあります。ホストから対象サンドボックスを起動してから、つなぎ直します。

sbx run --name sampleapp

同じcloneを共有するから、交代は速く、並列は危ない

一度作ってSSHを有効にすれば、Codex AppやClaude Desktopから何度でも、複数セッションで接続できます。毎回新しいサンドボックスを作る必要はありません。

Sandboxが1つなので、全セッションが同じプライベートcloneを共有します。

Codex App     ─┐
Claude Desktop ─┼─ sampleapp ─ one private clone / one working tree
CLI (SSH)      ─┘

これは狙った性質です。Codexで書きかけた作業をそのままClaudeへ渡せる——未コミット変更も、起動中の開発サーバーも、.nextのビルドキャッシュも共有されるので、交代のための引き継ぎcommitが要りません。CodexとClaudeを得意分野で使い分けたい場面では、これが一番効きました。

裏返しに、同じファイルを同時に触ったり、片方がbranchを切り替えたりすれば当然ぶつかります。セッションを増やすこと自体は並列開発になりません。並列で動かすなら選択肢は3つです。

作業ごとにmicroVM内でGit worktreeとbranchを分ける（worktreeごとにnpm ciが必要）
独立した大きな作業は、サンドボックス自体を分ける
同じworking treeを使うなら、編集担当をファイル単位で決める

この「交代は速いが並列は自分で仕切る」という置き方をなぜ選んだかは、第6回で構成の比較として扱います。

作り直しが要る変更と、削除前の確認

Kitの変更は、すべてが既存サンドボックスへ即時反映されるわけではありません。次の変更は作り直しが要る場合が多いです。

credential serviceや注入domainの追加・変更（第3回・第4回）
agent typeの変更
workspace modeの変更
install処理や基礎環境の変更（第1回）
port mappingの変更（第1回）
追加したCLI（Codex等）のバージョン変更（第2回）

第1回で書いたとおり、clone modeでは受け渡し境界がGitひとつです。削除すると、その中にしかないcommitと未コミット変更は戻りません。サンドボックス側とホスト側の両方から取りこぼしを確認します。

sbx exec sampleapp git status --short
sbx exec sampleapp git log --oneline --decorate -5
git fetch sandbox-sampleapp && git log --oneline sandbox-sampleapp/main -5

3行目のsandbox-sampleappは、Sandbox作成時にホストのリポジトリへ追加されるremoteです。Sandbox内でcommitした分はここからfetchできますが、未コミット変更はfetchできません。必要な変更をcommit／pushしてから、停止して削除します。

sbx stop sampleapp
sbx rm sampleapp

削除だけは人が承認する運用にしています。第1回の分担表で「サンドボックス削除前の最終確認」を人側に置いたのはこの理由です。プライベートclone・node_modules・未保存の作業に加えて、第2回でdevice loginしたCodexの認証情報も同時に消えます。エージェントは自分が壊した副作用を見積もれないので、対象名をsbx lsで確認してから人が打ちます。

連載のまとめ：残ったのは3つの判断

5回を通して残った判断を、最後にまとめます。

サンドボックスを使い捨てにしない。作り直せる常設環境として扱う。 普段は同じサンドボックスへ入り直し、Kitを環境のsource of truthにします。壊れたら消して作り直せますが、ソースコードは必ずGitへ逃がしておきます。

認証は用途ごとに分け、強度の違いを前提にする。 Codex用OAuth、Claude用credential、GitHub PAT、アプリのGemini／OpenAIキーは、用途も権限も守られ方も別です。service名と環境変数を分けるだけで、切り分けの手数と漏えい時の影響範囲が目に見えて変わりました。

一度に複数の問題を直さない。 credential・SDK・endpoint・アプリコードを同時に変えると、何が効いたのか分からなくなります。まず認証経路を証明してから、次の変更へ進みます。

Docker Sandboxesを入れて分かったのは、価値がmicroVMの起動コマンドより、その外側の境界設計にあることでした。エージェントに広い権限を渡す前提で開発するなら、渡す先をmicroVMにしておく意味は十分ありました。