Codexエージェントモード｜サンドボックスの設定と確認項目

Codexのエージェントモードでサンドボックスを有効にするなら、alpha版の番号だけで利用可否を決めず、設定の読み込み、作業場所、読み取り結果を順に確認する必要があります。2026年8月8日（JST）に公開されたCodex CLI 0.148.0-alpha.4／.5を入口に、MCP接続と端末入力を別の項目として記録し、Copilot CLIの更新をCodexへ読み替えない確認方法をまとめます。

Codex CLI 0.148.0-alpha.4 / .5の公開事実を分ける

今回の時事フックは、2026年8月8日（JST）にOpenAIの公式リリース欄でCodex CLIの0.148.0-alpha.4と0.148.0-alpha.5が相次いで公開されたことです。両ページにはPre-releaseの表示、版番号、公開時刻、配布アセットが示されていますが、alpha.4からalpha.5へ何が変わったかを一覧にした詳しい説明は確認できません。したがって、タグ名や公開順だけからエージェントモード、サンドボックス、MCP、端末入力の改善を推測することはできません（出典: Codex CLI 0.148.0-alpha.4、Codex CLI 0.148.0-alpha.5）。

公開ページの情報と、実際に手元で起動して得た結果は記録欄を分けます。たとえば版番号は公式ページで確認できても、現在の端末に同じ版が入っているとは限りません。設定が読まれたことを画面で確認できても、許可される作業範囲が想定どおりかは別に確かめる必要があります。公開事実を基準にし、未掲載の項目は未掲載のまま残すことが、alpha版を扱う最初の境界です。

エージェントモードとサンドボックスを確認する順番

「サンドボックスを有効にする」という検索語は、設定項目が表示されることと、その設定の範囲で実際の操作が止まることを一つにまとめがちです。Codexでは、まずどの版を起動したかを記録し、次にエージェントモードの入口と表示を確認します。その後でサンドボックスの設定、現在の作業場所、読み取り結果を分けて確かめます。版番号と挙動が同じ欄に入ると、alpha.4とalpha.5の差なのか、端末や設定の差なのかを後から判別しにくくなるためです。

版番号と起動入口を先に記録する

検証を始める前に、画面に表示されたCodex CLIの版番号、確認日、使用した入口をメモします。コマンド名やショートカットが同じでも、導入経路や実行場所が違えば別の版が選ばれることがあります。最初の記録は次のような短い確認で十分です。結果に出た文字列を、公式ページのタグ名と照合します。

codex --version

0.148.0-alpha.4または0.148.0-alpha.5と表示された場合でも、そこで機能差分まで確定したとは扱いません。表示された版番号、実行した場所、確認日を一組にして残し、二つのalpha版を比べるときは同じ入力と同じ順番で確認します。表示が安定版だった場合は、alpha版の結果と混ぜず、別の行へ記録してください。

設定の読み込みとエージェントモードの表示を見る

次に、Codexがどの設定を読み込んだか、エージェントモードが画面上でどのように示されているかを確認します。設定名だけを先に決めて探すのではなく、実際の表示に出た項目名、値、読み込み元を記録します。表示がない項目は「無効」と断言せず、「確認できない」とします。公式リリースページに説明がない機能を、版番号の存在だけで追加されたと書かないためです。

サンドボックスの設定も同じ扱いにします。設定画面や起動時の案内で有効・無効の表示を確認したら、設定の値だけでなく対象になる作業場所を併記します。設定を読めたことと、範囲外の場所へ書き込めることは別の事実です。とくにalpha版では、表示された設定の意味が環境ごとに異なる可能性を残し、分からない項目を「要確認」のまま次のテストへ渡します。

作業場所と読み取り範囲を小さく試す

最初の対象は、重要な成果物ではなく、複製した小さな確認用フォルダーにします。開始前にフォルダー内のファイル名を控え、読み取ってよいファイルと対象外の場所を決めます。Codexに短い依頼を渡し、指定したファイルの内容を説明できるか、指定していないファイルへ触れていないかを確認します。読み取り確認は、書き込みの許可を調べる操作とは分けてください。

Windowsでは、作業場所のパス、ドライブの種類、端末、起動方法を記録します。Windows Dev Driveでのサンドボックス動作は今回のCopilot CLI 1.0.79-7に記載された別製品の修正であり、Codexにも同じ結果が出る根拠ではありません。Codex側は、実際に選んだ場所で確認できた結果だけを残します。パスが表示されない、読み取り範囲が説明できない、想定外のファイルが変わった場合は、利用範囲を広げず「要確認」と判定します。

MCP接続と端末入力を別々に確認する

エージェントモードを試すときは、MCP接続と端末入力を一つの成功条件にまとめないことが重要です。接続先が一覧に表示されたこと、短い読み取りが返ったこと、端末から入力を受け付けたことは、それぞれ異なる確認結果です。どれか一つが成功しても、他の二つが使えるとは限りません。alpha.4とalpha.5を比べる場合も、同じ接続先、同じ短い入力、同じ終了条件で繰り返します。接続、読み取り、入力の境界を分けて記録すると、原因を追いやすくなります。

MCPは接続表示と読み取り結果を分ける

まず接続先の名称、接続状態、確認日を記録します。次に、許可された範囲の小さな読み取りを一つだけ行い、返ってきた結果と対象をメモします。接続先が見えていても読み取りが返らない場合は「接続は確認できたが、読み取りは要確認」と分けます。逆に一度読み取りが返っても、書き込みや外部サービスへの操作まで成功したと解釈してはいけません。

MCPの結果をCodexのサンドボックス全体の判定に使うことも避けます。MCP側の接続範囲、Codex側の作業場所、端末側の入力処理は別の境界です。接続を切ったあとに同じ読み取りを行い、結果が変わるかまで確認する必要がある場合は、追加の確認項目として残します。公式リリースページに記載がない場合は、実測結果に出典URLを付けず、版番号と確認記録を根拠として示します。

端末入力は短い依頼で結果を残す

端末入力の確認は、長い作業をいきなり依頼せず、「指定ファイルの先頭を説明する」のような短い依頼から始めます。入力が受け付けられたか、応答が返ったか、途中で表示が止まらなかったか、終了後に端末が通常の入力へ戻ったかを別々に記録します。Windows TerminalやVS Codeの統合端末を使う場合は、端末名とキー入力も添えます。

短い入力が通ったあとに、複数ファイルの変更や外部接続を追加する場合は、別の確認として扱います。サンドボックスが有効に見えること、読み取りができること、端末が戻ることがそろっても、書き込みの範囲や外部操作の可否が確定したわけではありません。最初の判定は「基本入力を確認できた」にとどめ、次の操作へ進む条件を明示します。

GitHub Copilot CLI 1.0.79-7〜-9は別製品として確認する

同じ2026年8月8日（JST）の話題として、GitHub Copilot CLIでは1.0.79-7、1.0.79-8、1.0.79-9が公開されました。ただし、ここに書かれた/sandbox、/worktree、Agent Plugins、モデル選択、Windows Dev Driveの内容はCopilot CLIのリリースノートです。Codexのサンドボックスに同じ画面や設定があることを示す資料ではありません。記事の確認表では、製品名と版を必ず列に残し、Copilot CLIの観察をCodexの判定へ流用しないようにします（出典: 1.0.79-7、1.0.79-8、1.0.79-9）。

1.0.79-7では、Agent Pluginsの拡張をcom.github.copilot/extensions/へ配置できること、Kimi K3モデルへの対応、--planと--mode autopilotを組み合わせる入口が記載されています。また、/appが現在のセッションをGitHub Copilotのデスクトップアプリで開くようになり、Windows Dev Drive上の作業場所でもサンドボックス化されたコマンドが動く修正が示されています。これらはCopilot CLIを更新した場合に確認する項目です。

1.0.79-8では、/sandboxの設定画面に認証関連の項目をまとめる変更、worktreeBaseRefで/worktreeの開始点を制御する変更、モデル選択画面の分類、作業場所内のPATH上にあるツール用フォルダーの扱いが記載されています。/worktreeなどの開始点が既定でHEADになったことも、Copilot CLI側の設定として記録します。Codexで同名の入口が使えるかどうかは、別の製品確認が必要です。

1.0.79-9の変更は、/sandbox設定画面に設定の保存先をsettings.jsonとして表示するものです。これは設定の所在を確認しやすくするCopilot CLIの画面変更であり、Codexの設定ファイル名や保存先を決める情報ではありません。三つのリリースを一つの更新としてまとめず、版ごとに「確認できた」「確認できない」「要確認」を残します。

CursorとAiderは確認先を残し、未発表を機能の不存在にしない

CursorとAiderを併用している場合でも、対象日に新着を採用しなかったことと、その製品に機能が存在しないことは別です。Cursorは公式Changelog、Aiderは公式Releasesを確認先として残します。2026年8月8日（JST）のCodex CLI alpha版を判断する際に、CursorやAiderの更新が見当たらないからといって、エージェントモードやサンドボックスの対応状況を推測しないでください。

確認表には、製品名、確認したページ、対象日、採用した発表の有無を別々に置きます。「対象日の新着なし」はニュースの選択結果であって、機能の有無を調査した結論ではありません。Cursorの表示やAiderのコマンドをCodexの確認手順へ混ぜる場合は、まず製品側の公式説明を読み、同じ名称が同じ意味かを別途確かめます。互換性が確認できない状態は、機能がないという結論ではなく「要確認」と書きます。

Vercel AI Gatewayの話題はサンドボックスと切り分ける

周辺情報として、VercelではGrok Imagine Image 2.0 PreviewをAI Gatewayから利用できるようになったと案内されています。文字を含む画像や既存画像の編集を試す場合の選択肢としては参考になりますが、画像生成の提供先が増えたことは、Codex CLIのエージェントモードやサンドボックスの設定を説明する根拠ではありません。今回の記事では、画像生成の機能評価を広げず、Codexの作業範囲確認とは別の話題として短く記録します（出典: Grok Imagine Image 2.0 Preview — Vercel AI Gateway）。

確認表で「確認できた」「確認できない」「要確認」を分ける

最後に、製品、版、入口、設定表示、作業場所、読み取り結果、MCP接続、端末入力、確認日、出典URLを一つの表へまとめます。表の目的は、未確認の項目を空欄のまま隠さないことです。公式ページで版番号を確認できた場合は「確認できた」、説明が掲載されていない場合は「確認できない」、手元の環境を試していない場合や互換性が不明な場合は「要確認」とします。三つの判定を混ぜないことで、alpha版の公開と利用判断の間にある距離が見えるようになります。

「確認できた」は観察した範囲だけに使う

「確認できた」は、画面表示や読み取り結果を実際に見て、同じ条件を記録できる場合に使います。alpha.4で表示された結果をalpha.5にもそのまま移さず、版番号、作業場所、端末、入力をそろえて別々に確認します。公式ページに版番号があっても、手元の起動結果を見ていない場合は、手元の動作を「確認できた」とはしません。

「確認できない」と「要確認」を使い分ける

公式ページに詳細差分が掲載されていない場合は「確認できない」です。環境をまだ試していない、結果が再現しない、設定の意味を説明できない場合は「要確認」です。どちらも失敗の断定ではなく、次に行う確認を残すための判定です。確認日と出典URLを添え、版が変わったときに同じ作業をやり直せる状態にします。

まとめ

Codex CLI 0.148.0-alpha.4とalpha.5が公開されたことは公式リリースページで確認できますが、詳しい変更一覧がない以上、版番号からエージェントモードやサンドボックスの差分を決めることはできません。公開事実、手元の表示、読み取り結果を分けて記録し、まず小さな確認用の場所から始めます。

確認の順番は、版番号、エージェントモードの表示、サンドボックス設定、作業場所、短い読み取り、MCP接続、端末入力です。読み取りの成功を、書き込みや外部サービス操作の許可と同じに扱わず、判定を三つに分けます。Windows Dev Driveや/worktree、/sandboxに関するCopilot CLIの更新は、Codexの機能へ読み替えません。

CursorのChangelogとAiderのReleasesは確認先として残し、対象日に新着がないことと機能がないことを混同しないようにします。確認日、製品、版、出典URL、未確認事項を表へ残せば、次のalpha版が公開されたときも同じ条件で再確認できます。