Codex を使っていると、次に迷うのは「どこで動かすか」です。手元の Mac で続けるのか、常時起動の作業機に逃がすのか、SSH 先の開発環境で動かすのか、外出中にスマホから承認だけ返すのか。ここを曖昧にしたまま Remote を有効にすると、便利さより先に、秘密情報、権限、作業場所、レビュー範囲が混ざります。
この記事では、2026年7月2日時点の OpenAI 公式ドキュメントを前提に、Codex Remote を実務でどう設計するかを整理します。Codex cloud の setup script や secrets は Codex cloud environment 設計ガイド、sandbox と approval の基本は Codex sandbox / approvals 設計ガイド、定期実行は Codex Automations 実践ガイド、成果物を受け入れる前の確認は Codex レビュー完了ゲート設計ガイド に分けています。
今回扱うのは、Codex の実行場所と操作端末を分けるときの境界設計です。
先に結論: Remote は「どこから操作するか」ではなく「どこで副作用が起きるか」で決める
Codex Remote を、スマホから見られて便利、SSH 先に入れて便利、という UI の話だけで考えると弱いです。実務で重要なのは、どのホストのファイル、資格情報、MCP server、ブラウザ、shell、sandbox 設定が使われるかです。
OpenAI の Remote connections docs では、remote access は接続先ホストの projects、threads、files、credentials、permissions、plugins、Computer Use、browser setup、local tools を使うと説明されています。つまり、スマホや別端末は操作面であって、実際の副作用は host 側で起きます。
私なら最初に次の4種類へ分けます。
| 選択肢 | 向く作業 | 注意点 |
|---|---|---|
| 手元PC | 短い実装、レビュー、画面確認 | sleep やネット断で止まる |
| 常時起動ホスト | 長めの調査、承認待ちの作業 | 置く資格情報を絞る |
| SSH開発環境 | 依存関係や社内ネットワークが remote にある作業 | SSH account と PATH を設計する |
| Codex cloud | GitHub 連携で完結する background task | local credentials や desktop state は使わない |
Remote の本質は「離れた場所から操作できること」ではありません。実行環境を明示して、そこにある権限だけを使わせることです。
手元PCを host にする場合
最初は手元PCを host にするのが一番楽です。Codex App で普段使っている project、thread、plugin、MCP server、ブラウザ状態をそのまま使えます。外出中に進捗を見たり、approval に返事したり、簡単な方向転換をするだけなら十分です。
ただし、手元PCは運用環境としては不安定です。
- sleep すると remote access が止まる
- ネットワークが切れると作業が止まる
- 個人用の credentials が載りやすい
- desktop app や browser session が作業に混ざりやすい
私なら、手元PC host は次に限定します。
- 30分から1時間で終わる作業
- 外部 write をしない調査
- 人間がすぐ review できる小さな diff
- secrets や production credential を使わない作業
長時間の automation や夜間の作業を手元PCに置くなら、最初から常時起動ホストへ分けた方が安定します。
常時起動ホストは「便利な自分のPC」ではなく、専用の作業環境として作る
Remote を本格運用するなら、常時起動の Mac / Windows / remote workstation を1台用意する方が扱いやすいです。ここに project、依存関係、MCP server、必要なブラウザ拡張、検証コマンドをそろえます。
ただし、常時起動ホストに何でも置くと危険です。便利な host は、同時に「agent が触れるものが多い host」でもあります。
私なら、常時起動ホストには次のルールを置きます。
host: codex-remote-dev-01
purpose: repo work and PR preparation only
credentials:
allowed:
- GitHub fine-grained token for selected repos
- package registry read token
forbidden:
- production database credentials
- personal browser sessions for unrelated services
- broad cloud admin tokens
permissions:
default_sandbox: workspace-write
approval_policy: on-request
external_write: approval required特に browser や desktop app を使う場合は、どのアカウントでログインしているかを分けます。個人の普段使いブラウザをそのまま host にするより、Codex 用の profile を作る方が事故が少ないです。
SSH host は PATH と account を先に検証する
Codex App は SSH host を remote project として追加できます。公式 docs では、~/.ssh/config の host alias を使い、remote host 上に Codex を install / authenticate し、Codex App の Settings > Connections から remote project folder を選ぶ流れが説明されています。remote project thread は、その SSH host の filesystem と shell に対して読み書きや command 実行を行います。
ここで詰まりやすいのは、SSH できるかではなく、Codex が起動する login shell で codex が PATH にいるかです。人間の interactive shell では動くのに、remote app server 起動時だけ見つからない、という状態は珍しくありません。
最初に確認するチェックはこれで十分です。
ssh devbox 'whoami; pwd; command -v codex; codex --version'
ssh devbox 'git --version; node --version; pnpm --version'
ssh devbox 'test -d ~/work/project && echo ok'SSH host では、account も分けます。個人の万能 account ではなく、repo 作業に必要な権限だけを持つ account にします。GitHub token、package registry、cloud credentials、MCP server credentials も、その host で本当に必要なものだけに絞ります。
Remote Control は承認端末を増やす機能として扱う
Remote Control は、スマホや別の Codex App から host を操作する入口です。2026年6月以降の OpenAI changelog では、iOS / Android device と host の間で authenticated one-to-one QR pairing を使うこと、古い inactive connection は再ペアリングが必要になることが示されています。
ここで大事なのは、スマホが「軽い閲覧端末」ではなく、approval を返せる端末になる点です。外出中に approve できるのは便利ですが、承認判断を雑にすると Remote の意味が崩れます。
私なら、モバイルから許す操作を次のように制限します。
| 操作 | モバイルで許すか |
|---|---|
| 進捗確認 | 許す |
| 方向修正 | 許す |
| build / test の再実行 | 条件付きで許す |
| repo 内の小さな edit | 条件付きで許す |
| package 追加 | 原則あとでPC確認 |
| 外部 write / deploy / credential 操作 | モバイル承認だけでは通さない |
approval は「今すぐ返せる」ほど危険です。モバイルでは画面が狭く、diff、terminal output、対象 host、対象 repo を見落としやすい。だから high-risk 操作は、Remote Control で通知を受けても PC で確認する運用にします。
sandbox は remote でも消えないが、信頼境界は host ごとに変わる
Codex の sandbox docs では、default permissions は workspace-write と on-request で、workspace 内の編集や routine command は通し、internet や workspace 外へ出るときに確認する形が説明されています。この考え方は Remote でも重要です。
ただし、同じ workspace-write でも、host が変わると意味が変わります。
- 手元PCの workspace: 個人の未コミット変更が混ざる可能性がある
- 常時起動ホストの workspace: 複数 task の worktree が残る可能性がある
- SSH host の workspace: 社内ネットワークや private dependency に届く可能性がある
だから、Remote では permission mode だけで安心しません。host ごとに writable roots、network、credentials、MCP server、browser profile を棚卸しします。
remote_host_policy:
host: devbox
writable_roots:
- /home/codex/work/project
network:
default: deny
allow:
- github.com
- registry.npmjs.org
mcp:
allowed:
- github-readonly
forbidden:
- production-admin
approval:
package_install: required
external_write: required
deploy: forbiddenこの程度の表を作るだけでも、「どの host なら何を任せてよいか」がかなり明確になります。
thread handoff は Git state の移動として見る
Remote connections には、thread と Git state を local computer と remote host の間で handoff する考え方があります。これは便利ですが、単なる会話の引っ越しではありません。branch、worktree、未完了の作業状態が移ります。
handoff 前に見るべき項目は次です。
- 移動先 host に同じ repository / subdirectory が保存されているか
- branch 名が task と合っているか
- 未コミット変更が誰のものか分かるか
- 移動先 host で build / test が走るか
- 移動先 host の credentials が作業に対して過剰ではないか
特に、local で始めた作業を SSH host に渡すときは、依存関係や生成ファイルの差で diff が増えることがあります。handoff は「続きから作業できる」機能ですが、review では移動前後の差分を必ず確認します。
最小導入手順
私なら、Codex Remote は次の順で導入します。
- 手元PCを host にして、スマホから進捗確認だけ試す
- approval を返す前に、対象 host / repo / command を必ず読む習慣を作る
- 常時起動 host を1台作り、Codex 用の account と browser profile を分ける
- SSH host は
command -v codexと project path を先に検証する - host ごとに allowed credentials / MCP / network / writable roots を表にする
- high-risk 操作は mobile approval だけで通さない
- PR 化したら、実行 host と検証コマンドを PR body に残す
Remote の導入初日にやらない方がよいのは、すべての repo、すべての credentials、すべての MCP server を常時起動 host に集めることです。便利に見えますが、後から「この agent は何に触れたのか」を説明しづらくなります。
まとめ
Codex Remote は、単なるリモート操作機能ではありません。Codex の実行場所、操作端末、承認者、資格情報、MCP server、sandbox 境界を分けるための機能です。
手元PC、常時起動ホスト、SSH開発環境、Codex cloud は、それぞれ向く仕事が違います。Remote を有効にする前に、「どこで副作用が起きるか」「どの host の credentials を使うか」「モバイル承認だけで通してよい操作か」を決めてください。
私なら、最初は手元PCで小さく試し、常時起動 host は repo 作業専用にし、SSH host は PATH と account を検証してから使います。外部 write、deploy、credential 操作は、Remote Control の便利さに流されず、PC で diff と log を見てから承認します。