3行でいうと

  • 実行の場所は3種類。手元のプロジェクト（Local）、手元の別作業コピー（Worktree）、クラウドの専用環境（Cloud）。
  • 安全は2段。サンドボックスは「技術的にできること」、承認ポリシーは「いつ止まって確認するか」。手元で動かす場合は、初期は通信オフ。
  • 設定はconfig.toml。優先順位は、コマンドラインの指定、プロジェクト、プロファイル、ユーザー、の順。プロジェクト設定は信頼したときだけ読まれる。

この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書を読んでまとめたものです。Codexの文書は、2026年10月8日の時点で、URLの移転（developers.openai.comからlearn.chatgpt.comへ）や、古い設定の廃止がありました。内容は変わることがあります。今回（10月22日）は、出典の9ページのうち8ページを取り直しました（同じ題の「Agent approvals & security」のもう1つのURLだけは取り直していません）。

先に結論

前提：Codexとは

文書では、Codexは「ChatGPTの、本格的な作業とソフトウェア開発のための道具」と説明されています。使える入口として、ChatGPTのデスクトップ・モバイル・Web、Codex CLI（ターミナルで動くコマンド）、IDE拡張（エディタに入れる拡張）、Codex Cloud（クラウドの環境）が挙がっています。

用語です。

実行の場所：Local・Worktree・Cloud

デスクトップアプリの「環境モード」についての文書の説明は、次のとおりです。

モード 動く場所 内容
Local 手元のPC 今のプロジェクトのディレクトリで直接作業する
Worktree 手元のPC gitのワークツリー（同じリポジトリの別の作業コピー）に変更を分けて、今のチェックアウトから隔離する
Cloud クラウド 公開済みの再利用できる環境から、専用の作業場所でリモートのタスクを始める

文書が強調している違いがあります。Cloudのタスクは、クラウド環境の中のファイルとサービスだけを使います。手元のファイル、動いているプロセス、ブラウザのログイン、VPNは、自動では持ち込まれません。また、タスクの変更は、再利用する環境そのものを書き換えません。

クラウドの始め方（文書の手順）

  1. ChatGPTにサインインする。
  2. Webかデスクトップで「Work in > Cloud」を開き、環境を選ぶ。モバイルではCodexを開く。
  3. 既存の環境を選ぶか、リポジトリを選んで新しく作る。GitHubの接続を求められることがある。
  4. 新しい環境は、Codexがプロジェクトを調べて準備し、依存関係を入れ、動作を試す。その結果を見て、保存して「公開（Publish）」する。
  5. タスクを書いて送る。変更とテスト結果を確認し、追加の修正を頼み、準備ができたらコミットするかプルリクエストを開く。

文書には「各タスクに専用の作業場所があり、PCがスリープしていても進められる」とあります。ターミナルからクラウドのタスクを始めたり、最近のクラウドの会話の状況を一覧したりできる、とも書かれています。ただし、その具体的なコマンド名は、読んだページに書かれていません。

通信（インターネット）はどうなるか

ここは確認が必要です。読んだ文書のあいだで、次のように見えました。

この3つは、画面や世代が違う可能性があり、僕らは整合を確認できていません。クラウドの通信設定は、使う環境の画面で確かめてください。

安全の2つの鍵：サンドボックスと承認

サンドボックスモード（技術的にできること）

モード 内容
read-only ファイルを読み、隔離の中でコマンドを動かす。外へ出る操作は承認が要ることがある
workspace-write 作業ディレクトリでファイル編集とコマンド実行ができる。「Auto」プリセットが使う
danger-full-access 隔離なし。システム全体に制限なく作用できる

承認ポリシー（いつ止まって聞くか）

ポリシー 内容
on-request 隔離が許すコマンドは承認なしで走る。隔離の外に出る操作や通信は承認が要る
never 確認しない。ただしサンドボックスの制限は残る
granular 聞く場面の種類を選び、残りは自動で拒否する。隔離の承認、実行ルール、MCP、権限要求、スキルのスクリプトなどの区分がある
untrusted 廃止。設定、プロファイル、スクリプトから消すこと

10月22日のページには、approvals_reviewer = "auto_review"と設定すると、条件に合う承認の依頼を「レビュー役のエージェント」に回せる、という記述もありました。この記事では詳しく扱いません。

初期設定は、バージョン管理されたフォルダでAuto（workspace-writeとon-request）、バージョン管理されていないフォルダでread-onlyです。作業フォルダを信頼するまではread-onlyで始まることがあります。codexをフラグなしで実行すると、この初期設定になります。

untrustedからの移行は、sandbox_mode = "read-only"とapproval_policy = "on-request"の組み合わせにするか、approval_policyを省いてユーザー設定に[projects."/path"]のtrust_level = "untrusted"を書く、と案内されています。

守られる場所と、危ないスイッチ

workspace-writeでも、書き込める場所の中の.git、.agents、.codex、.awsは、読み取り専用に保たれます（下の階層も再帰的に）。10月8日の記事では.awsが挙がっていませんでした。通信を使うには、[sandbox_workspace_write]のnetwork_access = trueで有効にします。network_proxyという機能は、有効にした通信にドメインの規則をかけますが、通信そのものを許可するものではありません。

--dangerously-bypass-approvals-and-sandbox（別名--yolo）は、隔離も承認もなくします。文書は「推奨しない」と書いています。10月8日に読んだ文書には、--full-autoはcodex execでは非推奨で、古い書き方は警告つきで動き、代わりにcodex exec --sandbox workspace-writeを使うよう案内されている、とありました（10月22日に取り直した承認とセキュリティのページには--full-autoの記載が見つからず、Autoプリセットは--sandbox workspace-write --ask-for-approval on-requestと書かれていました）。

設定ファイル（config.toml）の置き場所と優先順位

設定は、ユーザー設定の~/.codex/config.tomlと、プロジェクトの.codex/config.tomlにあります。セキュリティのため、プロジェクトの.codex/の設定は、そのプロジェクトを信頼したときだけ読まれます。信頼していなければ、読み飛ばされますが、ユーザーとシステムの設定は読まれます。

優先順位は、強い順に次のとおりです（文書の記述）。

  1. コマンドラインのフラグと--configの上書き
  2. プロジェクトの設定（プロジェクトの根から現在地まで。近いものが優先。信頼したプロジェクトのみ）
  3. --profileで選んだプロファイルのファイル（~/.codex/プロファイル名.config.toml）
  4. ユーザー設定（~/.codex/config.toml）
  5. ワークスペースに配られたクラウド管理の既定値
  6. システム設定（Unixでは/etc/codex/config.toml）
  7. 組み込みの既定値

組織のrequirements.tomlの方針は、さらに動作を制約します。たとえば管理者はapproval_policy = "never"を禁止できます。

主な設定は、model（既定のモデル）、approval_policy、sandbox_modeです。公式文書の例です。この記事では、実行していません。

model = "gpt-6.1-sol"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

プロファイルは、共通の既定をconfig.tomlに置き、違う値だけを入れたファイルです。名前つきの権限プロファイルは、[permissions.<名前>]の表とdefault_permissionsで作る、と書かれています。

実行時に切り替える方法は、1回ごとに--sandboxと--ask-for-approval（短縮は-a）、設定ファイルのsandbox_modeとapproval_policy、保存したプロファイル（codex --profile）、セッション中の/permissionsです。動作を試すには、codex sandbox macos・linux・windowsで、隔離の下でのコマンドの挙動を見られる、とあります。

指示とサブエージェント

指示ファイルAGENTS.mdは、~/.codexから現在地まで順に連結され、合計の初期上限は32KiBです（AGENTS.mdのガイドの記述）。ここでは詳しく扱わず、Codexのサブエージェントだけ触れます。

文書によると、サブエージェントは、作業の一部を並行して担当し、結果を1つの回答にまとめる専門のエージェントです。ノイズの多い途中経過を本流のチャットから外せます。それぞれが自分のモデルとツール呼び出しを使うため、単独の実行より多くのトークンを使います。自分で作る場合は、~/.codex/agents/（個人）か.codex/agents/（プロジェクト）にTOMLファイルを置き、name、description、developer_instructionsが必須です。modelやmodel_reasoning_effortなどは任意です。10月8日に読んだときはsandbox_modeとmcp_serversも任意で、省くと親から引き継ぐと書きましたが、10月22日のページでは、この2つをカスタムエージェントのファイルに書いても親の設定は上書きされず、権限・提供元・MCPサーバーは親から引き継ぐ、と読めました。サンドボックスと承認は親のセッションで決める、とあります。全体の設定（enabledやmax_concurrent_threads_per_session）は、config.tomlの[agents]に書きます。enabledの初期値はtrueで、サブエージェントの流れは現行のリリースでは既定でオン、と書かれています。組み込みのエージェントはdefault、worker、explorerです。

使い分けの見立て

見立てです。文書の記述を、判断の軸に並べてみます。

状況 候補 文書から読める理由
手元のコードを、その場で直したい Local＋workspace-write＋on-request 初期設定。作業フォルダの外へ出るときだけ確認
実験的な変更を、今の作業と分けたい Worktree 別の作業コピーに隔離される
PCを閉じていても進めたい。手元の環境に依存したくない Cloud 専用の作業場所。スリープ中も進む
手元のVPNや、ログイン済みのブラウザが必要 Local Cloudには自動で持ち込まれない
書き込みを広げたくない read-onlyかworkspace-write danger-full-accessと--yoloは、文書が推奨しない

つまずきやすい点

気をつけること

出典

更新履歴