Codex AppとClaude Desktopから入る｜Docker Sandboxes

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

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

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

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

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

準備は一度だけです。

sbx setup ssh

sbx setupは0.39.0では experimental 表示のコマンドです。このコマンドは~/.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側でport forwardingを足し、non-loopback addressへbindすれば、別の公開経路が作れてしまうからです。SSH設定が安全だからと油断せず、第2回で書いたとおり開発サーバーのhost bindはloopbackへ寄せておきます。安全なのはsbx setup sshが作る経路であって、その上にこちらが足す設定までは面倒を見てくれません。

Codex Appから接続する

先に2つ確認します。ターミナルで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の公式ドキュメントは警告として明記しています。

Connecting Claude Desktop to a sandbox over SSH transmits Anthropic credentials into the Claude Code process within the sandbox, reducing isolation guarantees.

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回で構成の比較として扱います。並列作業をOrca ADEから仕切る実践は第7回です。

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

Kitの変更は、すべてが既存サンドボックスへ即時反映されるわけではありません。mixinの内容によってはsbx kit addで既存Sandboxへ足せますが（第7回）、次の変更は作り直しが要る場合が多いです。

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で確認してから人が打ちます。