Codex公式資料では、コマンド実行の範囲を制御する主要な仕組みとしてサンドボックスと承認ポリシーが説明されています。公式のサンドボックス説明を踏まえると、共有された高権限アカウントにCodex CLIを置いたまま、複数リポジトリへアクセスさせてはいけません。今週は、独立したシステムアカウント、リポジトリ単位の作業領域、最小権限の認証情報を準備し、ファイル、ネットワーク、認証情報、Xcode、復旧性の順に検収してください。

この検収で対象になるのは、リモートMac上でCodex CLIに複数のリポジトリを変更、ビルド、テストさせる開発者です。長時間稼働するMacノードを管理するDevOps担当者、Agentのアクセス範囲を承認するセキュリティ・プラットフォーム責任者にも適しています。

利用開始と隔離試行の判断

まず、次の判定リストで利用段階を決めます。すべてにチェックを付けられない場合は、複数リポジトリの常時運用へ進めないでください。

上線前の判定リスト

  • [ ] Codex CLIを共有の高権限アカウントではなく、専用の独立システムアカウントで実行できる
  • [ ] リポジトリごとの作業ディレクトリと書き込み可能な範囲を記録できる
  • [ ] サンドボックス、承認ポリシー、ネットワーク許可を別々に設定し、変更履歴を残せる
  • [ ] SSH Agent、環境変数、ログインキーチェーン、Xcode署名資産の可視範囲を確認できる
  • [ ] Xcodeの派生データ、キャッシュ、Simulator、ログをリポジトリ間で分離できる
  • [ ] SSH切断、プロセス終了、Mac再起動後に、作業領域と資格情報を回収できる

6項目すべてにチェックできる場合は、非本番リポジトリで複数対象の限定運用へ進みます。4項目または5項目だけの場合は、単一リポジトリを順番に処理する方式へ戻します。3項目以下、または認証情報の範囲を確認できない場合は、ノードを再構築するか、Agentをレビュー専用に制限してください。

VMSPINの日本語サービス案内を検討する場合も、最初から本番の署名資産を置くのではなく、回収可能な検証用リポジトリでこの判定を先に行ってください。

ファイル境界とリポジトリ分離

Codex CLIが何を読めるか、何を書き換えられるかは、プロンプトよりも実行時の権限と作業領域で決まります。検収対象は現在のリポジトリだけではありません。親ディレクトリ、隣接するリポジトリ、Gitメタデータ、プロジェクト設定、テンポラリ領域まで確認します。

Codex CLIを現在のコードリポジトリだけに変更させるには、どう制限しますか。
専用アカウントでリポジトリごとに作業ディレクトリを分け、書き込み可能な場所を必要な範囲に限定します。検証用の別リポジトリに識別用ファイルを置き、現在の作業対象から読み取り、変更、削除を試みます。実際の秘密情報や本番コードは使わないでください。

確認する項目は次の順番です。

  1. 対象リポジトリの絶対パスと現在の作業ディレクトリを記録します。
  2. 隣接リポジトリ、親ディレクトリ、.git、生成物、テンポラリ領域に対する読み取りと書き込みを分けて試します。
  3. リポジトリ切り替え後に、前の作業内容や一時ファイルが残っていないか確認します。
  4. 変更前後のファイル一覧、Git差分、プロセスの実行記録を保存します。
  5. 意図しない読み取り、別リポジトリへの変更、残留ファイルがあれば、その時点で停止します。

合格条件は「対象外の場所へアクセスできない」ことを証拠付きで示せることです。単に変更が起きなかっただけでは不十分です。アクセス拒否の記録と権限状態を保存してください。

ネットワークと外部実行経路

モデルとの通信、依存関係の取得、Git操作、外部API、スクリプト、MCPなどは、同じ「ネットワーク利用」としてまとめないでください。Codexの公式資料でも、サンドボックス、承認、ネットワーク設定は別の制御として扱われています。公式リポジトリのネットワーク説明を確認し、現在の設定名と挙動を再確認してください。

承認を無効にすれば、ネットワークも利用可能になりますか。
なりません。承認の扱いは実行許可の確認方法であり、通信先やネットワーク経路の許可を意味しません。外部通信が必要なタスクでは、許可する宛先、目的、ログの保存場所を別々に定義します。

検収では、次の順に分離します。

  • 依存関係の取得先を許可済みのドメインへ限定し、未知の宛先を拒否できるか確認します。
  • Gitの読み取り、Gitのプッシュ、外部API呼び出しを別の操作として検証します。
  • 承認画面や監査ログに、実行コマンド、宛先、失敗理由が残るか確認します。
  • MCPサーバーや外部ツール実行器が、ローカルのサンドボックスを経由せずにファイルやネットワークへ到達しないか調べます。

Codexの設定項目は、利用している時点の公式仕様と照合してください。Codexの設定ソースには権限関連の実装情報がありますが、ソース上の項目名だけを見て、実行環境での許可範囲を推測してはいけません。

MCPや権限伝播については、CodexのGitHub Issueにあるコミュニティ報告も確認できます。ただし、個別Issueは再現条件が限定された報告であり、一般的な脆弱性と断定しないでください。自分のノードで再現性、影響範囲、修正版の有無を確認できない限り、待機中のリスクとして扱います。

アカウントと認証情報の露出

リモートMacでのmacOS Agent隔離は、Codex CLIのサンドボックスだけでは完結しません。OSユーザー、環境変数、SSH Agent、ログインキーチェーン、Xcodeの署名ID、配布用資格情報を個別に調べる必要があります。

リモートMac上のCodex CLIはSSHキーやmacOS Keychainを読めますか。
OSアカウントと実行経路に権限があれば、見える可能性があります。特にSSH Agentが転送されている状態や、ログイン中のキーチェーンを利用できる状態は、作業領域の隔離とは別の問題です。キーチェーンの認証とアクセス制御については、AppleのKeychain Accessガイドを基準に確認してください。

検収は、次の三段階に分けると判断しやすくなります。

  • 認証情報なし：コードの読み取り、編集、ローカルビルドだけを確認します。
  • 読み取り専用の認証情報：依存関係取得やリポジトリ読み取りを試し、書き込みや公開操作が拒否されることを確認します。
  • 期限付きの実行用認証情報：期限、対象サービス、失効方法、監査ログを確認します。

本番用のSSH秘密鍵、配布証明書、署名秘密鍵、長期トークンを既定のAgentセッションへ直接公開してはいけません。Xcodeの署名が必要な場合も、ビルド用と公開用の資格情報を分離し、アップロード操作は別の承認段階にします。

Xcode実行と並行処理の境界

Xcodeが起動し、xcodebuildが終了コードを返すことだけでは、長期運用できる証拠になりません。検証用プロジェクトで、派生データ、キャッシュ、Simulator、ビルドスクリプト、成果物の保存場所を分けて確認します。

複数リポジトリを同時に処理しても、同じMacなら問題ありませんか。
問題が起きる可能性があります。ワークスペースだけでなく、ポート、キャッシュ、派生データ、環境変数、ログ、Simulatorの状態が共有されると、別タスクの結果が混ざるためです。

次の手順で検証します。

  1. 識別可能なテストプロジェクトを用意し、各タスクに異なる作業ディレクトリを割り当てます。
  2. xcodebuild、テストスクリプト、Simulator操作を個別に実行します。
  3. ビルド成果物、派生データ、ログ、キャッシュが別のタスクへ混入しないか確認します。
  4. 同じポート番号や同名の一時ファイルを使う処理を重ね、競合時の停止と復旧を記録します。
  5. 変更差分、成果物の識別子、ログの対応関係を照合します。

ここで合格しない場合は、単一リポジトリを順番に処理する方式へ戻します。並行処理を続けるなら、リポジトリごとの独立ノード、独立ユーザー、独立キャッシュを用意できるかを再評価してください。

清掃と再起動復旧

長時間稼働するMacノードでは、正常終了より異常終了後の状態が重要です。SSH切断、Codex CLIの終了、タスク中断、Macの再起動、リポジトリ切り替えを順番に再現し、残ったプロセス、テンポラリファイル、ログ、認証情報、作業差分を確認します。

最低限、次の証拠を保存します。

  • 実行前後のプロセス一覧と対象ユーザー
  • 作業ディレクトリおよびGit差分の状態
  • 一時ファイル、DerivedData、キャッシュの削除記録
  • 承認履歴、ネットワーク拒否、外部ツールの実行ログ
  • 再起動後に再開された処理と、再利用された認証情報
  • 失敗したタスクを再実行したときの重複ビルドや二重アップロードの有無

注意：SSH接続が切れたあとに処理が残ること自体より、誰の権限で残り、どのリポジトリと認証情報へ到達できるかを確認してください。プロセスを止めるだけで、残留したトークンや作業差分が消えるとは限りません。

今週の検収マイルストーン

今週は、最初に判定リストを保存し、次に非本番リポジトリでファイルと認証情報の境界を確認します。その後にXcodeの並行処理、異常終了、Mac再起動を試し、各段階の証拠を一つの検収記録へまとめてください。

最終判断は、次の条件分岐で行います。

  • 6項目すべてにチェックがあり、ファイル境界、ネットワーク許可、認証情報の非露出、Xcodeの成果物分離、再起動後の清掃を証拠付きで確認できる場合：非本番の複数リポジトリで限定運用を開始します。
  • ファイルとアカウントは分離できるが、並行処理または復旧清掃を証明できない場合：単一リポジトリの順番処理に限定します。
  • SSH Agent、Keychain、署名資産の範囲を特定できない場合：Agentによるビルドや公開操作を止め、レビュー用途だけにします。
  • 共有高権限アカウントから変更できない場合：ノードを再構築するか、独立したMacノードへ分離します。
  • 検証用ログや差分を保存できない場合：安全性を承認せず、実行を延期します。

既存のLinuxまたはWindows環境だけでこの分離を補おうとすると、macOS固有のXcode、Simulator、Keychain、署名処理を同じ条件で再現できません。一方で、既存環境の共有アカウントや長期SSH接続は、リポジトリ境界、認証情報、キャッシュが混ざりやすく、復旧時の証拠も不足しがちです。

そのため、短期の隔離試行や検証用のMacが必要なら、VMSPINの料金案内を確認し、非本番リポジトリで権限と復旧を先に再測定する方法が現実的です。長期の高負荷処理や物理機器への接続が必要なら、自社保有のMacや専用ノードのほうが適する場合もあります。まずはMac利用の申込み案内を入口に、独立アカウント、作業領域、資格情報の回収方法を確認してから、複数リポジトリ運用へ進んでください。