Codexのサンドボックス設定｜Windows MXCとオートレビュー

Codexのサンドボックスは、Codexが実行するコマンドとその子プロセスについて、読み書きできるファイルとネットワークへの接続をOSの機能で制限する仕組みです。Windowsでは2026年10月9日、OpenAI DevelopersがMicrosoftのMXCを使う新しい方式を発表し、セットアップの速さ、ネットワーク制限の強さ、ファイルアクセスを細かく決められることを挙げました（OpenAI DevelopersのX投稿）。

この記事は、WindowsでCodexを使う開発者と、社内で許可するかを決める情シス・開発リーダー向けに、MXCの仕組み、対応端末の確かめ方、設定、オートレビューを整理します。内容は2026年10月12日時点で確認したOpenAIの公式ドキュメント、openai/codexのリポジトリ（コミット5ef96ab）、Microsoftの発表に基づき、手元で動かした結果は含みません。コマンドと設定はすべて公式の例です。Codexを入れるところから始める場合は、インストールの手順はこちらを先に見てください。

10月9日に何が変わったか｜Windows版CodexにMXCの方式が加わった

変わったのは、Windows上のCodexが使うサンドボックスの「実行方式」です。OpenAI Developersの投稿は、新しい方式の特徴に「より速いセットアップ」「より強いネットワークの制限」「きめ細かなファイルアクセスの制御」を挙げ、対応するWindows 11端末が必要だと書いています。

MXCは、Microsoftが2026年10月7日にWindows 11向けの一般提供を発表した仕組みです。Microsoftの解説では「信頼できないコードや動的に生成される処理のための、方針で動く実行の層」とされ、開発者やIT管理者が決めたファイルとネットワークの範囲を、実行時に強制します。方針はエージェントの手の外にあるため、エージェントや生成されたコードが自分で権限を広げることはできません。同じ発表で、対応済みのエージェントとしてCodex、GitHub Copilot、OpenClawなどが挙がっています。

Codexの公式ドキュメント（Windows sandbox）は、Windowsのサンドボックスを次の3方式で説明しています。

方式	位置づけ	仕組み	注意点
mxc（推奨）	対応するWindows端末での第一の選択	OSのプロセス隔離を使う。管理者の承認つきセットアップが要らず、追加のWindowsアカウントを作らない。ローカルのファイアウォール規則も使わない	対応するWindows 11のビルドとOS側の機能が必要
elevated（従来方式）	MXCが使えない時の第一の代替	権限の低い専用のサンドボックス用ユーザー、ファイルの権限の境界、ファイアウォール規則を使う。セットアップに管理者の承認が必要	コマンド自体は管理者権限なしで動く
unelevated（従来方式）	elevatedが使えず、組織が認める時の代替	今のユーザーから作った制限付きトークンとACL	elevatedよりネットワークの隔離が弱く、読み取り禁止のパスに対応しない

2026年10月12日時点の公式のChatGPT & Codex changelogにMXCの項目はなく、MXCの説明はX投稿とWindows sandboxのドキュメントで確認できます。同じ時期に、10月6日にはオートレビューの無料化、10月9日にはPro向けの「Composer predictions」（次に送るメッセージを提案する機能・ベータ）がX上で案内されました。後者は本記事では扱いません。Codexの全体像はOpenAI Codexとは｜CLI・クラウド・APIの使い方と料金で整理しています。

MXCは何を制限するか｜ファイル・ネットワーク・子プロセス

公式ドキュメントでは、Windowsのサンドボックスはコマンドとその子プロセスに、ファイルとネットワークの権限を強制します。中身はopenai/codexのcodex-rs/mxc-sandboxのREADMEにあります。この方式は、Codexが実行するコマンドをCodex自身の実行ファイル経由でMXCのBaseContainerRunnerに渡すもので、ホストのACLの書き換え、サンドボックス用ユーザーの作成、管理者権限の要求はしません。Microsoftの「エージェントは自分自身のセキュリティの権限者にはなれない」という考え方を、MXCの境界がOSの機能で受け持つ形です。

ファイル：権限プロファイルの範囲

• ファイルの権限はCodexの権限プロファイルから作られ、.gitなどの保護されたメタデータの扱いも含みます。
• 読み書きを禁止するパス（deny）には、OS側の機能（PSE_SUPPORT_FS_DENY）が要ります。使えない端末では、コマンドが起動前にエラーで止まります。
• 禁止のglobは起動前に、その時点のファイルとフォルダの具体的なパスへ展開されます。ドライブのルートへの許可は、ルートと直下の項目だけに効きます。

ネットワーク：ループバックとプロキシ経由

• 管理されたネットワークでは、IPv4・IPv6のループバック（同じ端末内）の通信と、Codexのプロキシの待ち受けを許します。
• ループバック以外への直接の外向き通信と、外からの一般的な着信は遮断されます。プロキシ経由の通信にはドメインの規則が効き、DNSへの直接の問い合わせは拒否されたままです。
• MXCではallow_local_bindingの既定がtrueになり、管理要件でfalseになる場合は設定エラーです。trueの時は、プロキシのプライベートネットワーク宛ての追加チェックが外れます。無効にしたネットワークが有効になることはありません。

子プロセス：コマンドが終わると止まる

• 前面のコマンドが終わると、残っている子孫のプロセスも終了します。従来方式の2つでは残っていたため、コマンドから裏で起動した開発サーバーはMXCでは止まります。
• クリップボード、入力の注入、デスクトップやシステムの操作の制限は残ります。

また、選んだ方式でコマンドが失敗しても、別の方式へ自動で切り替わることはありません（README）。サーバー側でエージェントを隔離する方式との違いはAIエージェント サンドボックス設計｜gVisor比較にまとめています。

対応端末の確かめ方と、MXCを優先・必須にする設定

MXCを使えるかどうかは、端末ごとに確かめます。進め方は、確認コマンドで動くことを見てからprefer_mxcで優先し、必須の指定は確かめた端末にだけ使う、という順です。組織として使わせない場合は、管理側の要件で止めます。

対応端末を確かめる

公式ドキュメントによると、MXCのプロセス隔離はWindows 11 24H2（ビルド26100.9278）と25H2（ビルド26200.9278）で導入され、Microsoftが順次展開しています。Codex CLI 0.162.0以降なら、保存済みの選択を変えずに1回だけMXCで動かす確認コマンドを、プロジェクトのフォルダで実行できます（公式の例）。

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

MXC_OKと終了コード0が返れば成功です。ワークスペースの権限プロファイルと組織の管理要件を当てた状態で起動できるかを見ています。READMEは、Windowsの更新を入れただけでは機能が有効な証拠と扱わず、端末の機能を実際に確かめると書いています。

MXCを優先して使う

デスクトップアプリは、個人向けアカウントで端末が対応していれば自動でMXCを優先します。企業の配備やCLI単体ではconfig.tomlに次を書きます（公式の「Enable MXC」と「Configure a legacy fallback」の例を1つにまとめたもの）。設定リファレンスでは、この機能はCLI単体では既定でオフです。

[features]
prefer_mxc = true

[windows]
sandbox = "elevated" # or "unelevated"

端末と方針が許せばMXC、許さなければwindows.sandboxの従来方式を使います。切り替えは次の起動から効き、MXCから戻す時は従来方式のセットアップが改めて要る場合があります（README）。まず優先、必須は確かめた端末から、の順が安全です。

MXCを必須にする

windows.sandboxにmxcを指定すると、MXCが使えない端末や、管理要件で禁止された端末では失敗します。READMEはこの指定を「厳格（strict）」としています。

[windows]
sandbox = "mxc"

組織で禁止する・従来方式を絞る

MXCを使わせない場合は、管理側のrequirements.tomlにallow_mxc = falseを書きます。自動の選択と明示的な指定の両方が止まります。従来方式を絞るallowed_sandbox_implementationsはMXCを制限しません（どちらも公式の例）。

[windows]
allow_mxc = false
allowed_sandbox_implementations = ["elevated"]

上は2つの例を並べたもので、片方だけでも使えます。Windowsのシステム用のrequirements.tomlは%ProgramData%\OpenAI\Codex\requirements.tomlに置きます。管理者権限のない社員の端末には、IT部門が先にelevatedを用意するcodex sandbox setup --elevatedの手順も公式にあります。

アクセス範囲・承認・通信の設定

windows.sandboxは実行方式を選ぶだけで、どこまで読み書きできるか（アクセス範囲）と、いつ人に確認するか（承認）は別に決めます。MXCでも、ファイルの権限は同じ権限プロファイルから作られます。

アクセス範囲：sandbox_modeか権限プロファイル

従来からのsandbox_modeはread-only・workspace-write・danger-full-accessの3つで、workspace-writeではsandbox_workspace_write.writable_rootsで書き込み先を足します。workspace-writeでも、書き込み先の.gitは読み取り専用で守られます。

パスごとに決めたい時は、権限プロファイル（2026年10月12日時点でベータ）を使います。組み込みは:read-only・:workspace・:danger-full-accessで、[permissions.<名前>]に自分のプロファイルを作り、default_permissionsで選びます。パスごとにread・write・denyを指定でき、同じパスではdenyが優先です。組み込みの:workspaceをextendsで土台にすると、.codexを読み取り専用にするような基本の保護も引き継がれます。次は、広い範囲をdenyにしたうえで、その中の一部だけ書き込みを開け直す公式の例です。

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

より具体的なパスの規則が優先されるため、Documentsは読み書きできず、その下のcodexフォルダだけ書き込めます。ワークスペース内の.envをglobで読めなくする例もドキュメントにあります。権限プロファイルとsandbox_modeは併用できず、sandbox_modeがどこかにあると古い設定が使われます。ネイティブのWindowsではドライブ文字のパスやUNCパスも書けますが、深さに上限のないdenyのglobにはglob_scan_max_depthを決めておきます。

承認：いつ人に確認するか

主な方針はon-request（サンドボックス内は自動、外に出る時に確認）とnever（確認しない）です。以前のuntrustedは選べなくなり、残っているとクライアントが起動しないことがあります。バージョン管理されたフォルダでの推奨は「Auto」（--sandbox workspace-write --ask-for-approval on-request）です。デスクトップアプリでは入力欄の下で「Ask for approval」「Approve for me」「Full access」などを選び、CLIでは/permissionsで変えます。

通信：ネットワークは既定でオフ

既定ではコマンドのネットワークはオフです。オンにして宛先を絞るにはnetwork_proxyを有効にしてドメインの規則を書きます。プロキシなしでオンにすると、宛先の制限なしで直接つながります。このプロキシが絞るのはコマンドの通信だけで、Web検索、MCPサーバー、アプリ、ブラウザ、Computer Useは別の設定です。効いている設定はCLIの/statusと/debug-configで見られ、codex sandbox windows [--permissions-profile <name>] [COMMAND]...でサンドボックスの下のコマンドを試せます。

オートレビューの仕組みと設定｜判断基準とプラン

オートレビューは、サンドボックスの境界での承認を、人の代わりに「レビュー用エージェント」が判断する機能です。Codex本体は同じサンドボックスと同じ制限の中で動き、変わるのは境界を越える承認要求を判断する役だけです。公式ドキュメントは「権限を与えるものではなく、判断者の入れ替え」と書いています。

何を自動で判断するか

対象は、ふだんなら人に確認が出る次の承認要求です。サンドボックス内で許された範囲内の操作は審査されず、Computer Useのアプリへのアクセス承認も本人が判断します。

• 権限を広げて実行したいシェルやexecの呼び出し
• 今の方針で止められたネットワークの要求
• 書き込みが許された範囲の外のファイル編集
• 承認が必要なMCPやアプリのツール呼び出し

許可されればそのまま実行され、拒否されると、Codex本体は明らかに安全な別の方法を探すか、止まって利用者に確認します。止める対象は、秘密情報を信頼できない宛先へ送る操作、認証情報の探索、広い範囲や長く残るセキュリティの弱体化、取り返しのつかない破壊的な操作です。レビューの失敗は止める側に倒れます。今のオープンソースの実装では、同じターンで3回続けて拒否されるか、直近50回中10回拒否されるとターンを中断します。

有効にする

デスクトップアプリでは権限の切り替えで「Approve for me」を選びます。CLIやローカルの設定では次を書きます（公式の例）。

approval_policy = "on-request"
approvals_reviewer = "auto_review"

承認の方針だけを変えてもレビュー役は選ばれず、approval_policy = "never"では承認要求が出ないため働きません。

判断基準を変える

既定の判断基準はopenai/codexのcodex-rs/prompts/templates/guardian/policy.mdにあり、「データの持ち出し」「認証情報の探索」「長く残るセキュリティの弱体化」「破壊的な操作」「低リスクの操作」の区分で規則が並びます。たとえば「持ち出しの許可には、送る中身と宛先の両方の指定が要る」とあります。なお、公式ドキュメントからのリンク先（codex-rs/core/src/guardian/policy.md）は2026年10月12日時点で開けません。

変え方は2つで、[auto_review]のpolicyは今の基準を置き換え、extra_policyは今の基準と一緒に読み込まれる追加の規則です。組織ではguardian_policy_configとguardian_extra_policyが利用者の設定より優先されます。置き換える時の書式は次のとおりで（公式の例）、公式ドキュメントは今の基準の全文をコピーしてから足し、全文を確かめられない場合は上書きしないよう求めています。

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

どのプランで使えるか

公式の料金ページの機能表では、「Auto-review for approval requests」はPlus・Pro・Business・Enterprise／Education・APIキーで利用可です。使用量の扱いは情報がそろっていません。

項目	確認できた内容	出どころ
無料化	ChatGPTアカウントでサインインする全ユーザー向けに無料と案内（10月6日）。gihyo.jpは、プランの利用枠も消費しないとの記述も伝えている	OpenAIのThibault Sottiaux氏のX投稿（gihyo.jpの報道）
使用量	追加のモデル呼び出しを使うため、使用量が増えることがある	公式ドキュメント（Agent approvals & security）
管理者の制御	allowed_approvals_reviewersで許可・必須を決める	公式ドキュメント（Managed configuration）

組織で使う場合は、記載がそろうまで使用量の推移を見て判断するのが安全です。人の承認をどこに残すかの設計はHuman-in-the-Loop完全ガイド｜エージェント承認設計も参考になります。

Copilot・Claude Codeのサンドボックスとの位置関係

同じ週にGitHubもMXCを使うローカルサンドボックスを一般提供し（10月7日）、Microsoftは今後MXCに対応するエージェントとしてClaude Codeを挙げています。各社の公式ドキュメントの範囲で並べると次のとおりです。

項目	Codex	GitHub Copilot	Claude Code
ネイティブのWindows	MXC（推奨）と従来方式	MXCを使うローカルサンドボックス（最近のWindows 11の更新が必要）	サンドボックスなしで実行。WSL2の中で使う
既定	自動で適用。ネットワークは既定でオフ	既定でオフ	既定でオフ（/sandboxで有効化）
囲む範囲	コマンドとその子プロセス	シェルコマンドと検索、既定でローカルのMCP・LSP。組み込みのファイル操作はソフトウェア上の確認	シェルコマンドとその子プロセス。ファイル操作のツール・MCPサーバー・フックは対象外
ドキュメントにある強み	境界を越える承認をオートレビューに任せられる	/sandbox policyで自動の許可も含めた実際の方針を一覧できる	sandbox.credentialsで認証情報をコマンドから隠せる

GitHubは、Windowsではプロキシの設定に従うプログラムを前提にしているため、直接の接続を防ぐ強さはmacOS・Linuxと同じではないとしています。Copilot CLIの守りはCopilot CLIのプロンプトインジェクション｜止め方、Claude Codeの認証情報の保護はClaude Code サンドボックスmaskモード解説で扱っています。

社内で許可する前に確かめること（情シス・開発リーダー向け）

社内の端末でCodexを許可する前に、公式ドキュメントで確かめられる範囲で次の7点を決めておきます。決めた内容は、全員に入れる前に数台で試します。

1. 端末：OSのビルドと、確認コマンドでMXC_OKが返るか。
2. 方式：requirements.tomlで、MXCを許すか（windows.allow_mxc）、従来方式をどこまで許すか、features.prefer_mxcを固定するかを決めます。
3. 権限：Codex 0.138.0以降なら、allowed_permission_profilesでプロファイルの許可リストを作り、":danger-full-access"を入れません（書かなかったものは拒否）。
4. 承認：allowed_approvals_reviewersでオートレビューを任意か必須（["auto_review"]）にし、組織の判断基準をguardian_policy_configかguardian_extra_policyで入れます。
5. 読み取り禁止：ネイティブのWindowsでは、管理側のdeny_readはCodexの組み込みのファイル操作には効きますが、シェルのサブプロセスの読み取りには使われません。.envや鍵は権限プロファイルのdenyでも守ります。
6. 通信：プロキシで管理する場合、MXCではループバックの通信（allow_local_binding = true）を許す必要があります。管理要件の[experimental_network]はWindowsでの対応が限られるため、検証してから使います。
7. 環境変数：既定では、名前にKEY・SECRET・TOKENを含む変数をコマンドに渡す前に自動では外しません（ignore_default_excludesの既定がtrue）。次の公式の例のようにfalseにすると、それらが先に自動で外れます。

[shell_environment_policy]
inherit = "core"
set = { MY_FLAG = "1" }
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"

入られた後に止める順番

サンドボックスとオートレビューは、何かあった時の影響の範囲を限る仕組みです。公式ドキュメントもオートレビューを「決定的なセキュリティの保証ではない」としています。不審な動きが見つかった時は、次の順で止めます。

1. 鍵を無効にする：Codexのセッションから読めた可能性のあるAPIキーやトークンを発行元で無効にします。JPCERT/CCは2026年10月8日公開の注意喚起で「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」ことを挙げています。
2. 外部連携を切る：MCPサーバーはmcp_servers.<id>.enabled = falseで、設定を消さずに無効にできます。組織では管理側のMCPサーバーの許可リストで止めます。
3. 記録を見る：オートレビューの記録は既定で~/.codex/sessionsに残り、OpenTelemetryを有効にしていればcodex.tool_decisionで承認と拒否を追えます。サンドボックスの記録はCODEX_HOME/.sandbox/sandbox.logです。診断をOpenAIに送る時も、CODEX_HOME/.sandbox-secrets/の中身は含めないよう公式ドキュメントは書いています。
4. 戻せるか確かめる：公式ドキュメントは、作業ブランチでgit statusをきれいにしてから任せ、こまめにコミットする運用を勧めています。workspace-writeでは.gitが読み取り専用なので、サンドボックス内のコマンドから履歴は書き換えられません。

よくある失敗パターン

失敗1：全員の設定でMXCを必須にする

❌ 推奨になったので、全社でwindows.sandbox = "mxc"を指定する。

⭕ features.prefer_mxc = trueと従来方式の組み合わせで始め、MXC_OKが返る端末から必須にする。必須の指定は未対応の端末でコマンドを実行せずに失敗し、別の方式にも切り替わりません。

失敗2：オートレビューがあるのでFull accessにする

❌ 承認が面倒なので、Full accessにしてオートレビューに任せる。

⭕ workspace-writeとon-requestのままapprovals_reviewer = "auto_review"を足す。approval_policy = "never"や:danger-full-access、--yoloでは、審査の対象になる承認要求そのものが作られないことがあります。

失敗3：数行だけでpolicyを上書きする

❌ 社内ルールを数行だけ[auto_review]のpolicyに書く。

⭕ 足すだけならextra_policyを使い、置き換えるなら全文をコピーしてから足す。policyは今の基準と混ざらないため、数行だけだと持ち出しや破壊的な操作の規則が使われなくなります。

失敗4：開発サーバーを裏で起動する手順のまま移る

❌ MXCに切り替えた後も、Codexのコマンドで開発サーバーを裏で起動してテストを続ける。

⭕ 切り替える前に、その手順がMXCで動くかを試す。MXCでは前面のコマンドが終わると子孫のプロセスも止まるため、サーバーをいつ誰が起動するかを決め直す必要があります。

よくある質問

Codexのサンドボックスとは何ですか？

Codexが実行するコマンドとその子プロセスの、ファイルの読み書きとネットワークへの接続をOSの機能で制限する仕組みです。macOSはSeatbelt、LinuxとWSL2はbwrapとseccomp、ネイティブのWindowsはMXC（従来方式はelevatedとunelevated）を使います。

CodexはWindowsとWSLのどちらで動かせばいいですか？

公式ドキュメントは、ネイティブのWindowsのサンドボックスを既定とし、Linux向けの道具が必要な時、作業がすでにWSL2にある時、ネイティブの方式で足りない時にWSLを選ぶよう書いています。WSL1はCodex 0.115以降では使えません。

Windows 10でもMXCは使えますか？

MXCのプロセス隔離はWindows 11 24H2と25H2の対象ビルドで導入されたものなので、Windows 10では従来方式で動かすことになります。Windows 10でのCodex自体もベストエフォートの扱いです。

オートレビューを有効にすると、Codexにできることは増えますか？

増えません。判断する役が人から別のエージェントに替わるだけで、書き込み先、ネットワーク、保護されたパスはそのままです。範囲を変える時は権限プロファイルかsandbox_modeを見直します。

サンドボックスの初期化でエラーが出たら、何を確かめればいいですか？

MXCなら確認コマンドをもう一度実行し、ネットワークの方針を見ます。elevatedならセットアップをやり直し、管理者の承認、ユーザーの作成、ファイアウォール規則の変更、ログオン権限が会社の方針で止められていないかをIT部門に確認します。どの場合も/status・/debug-configとsandbox.logを見てください。

まとめ

10月9日の発表で、Windows版Codexのサンドボックスは対応端末ではMXCが推奨になりました。MXCは専用アカウントやファイアウォール規則を作らずにコマンドと子プロセスを囲み、ファイルは権限プロファイルどおりに、通信はループバックとプロキシ経由だけに絞ります。オートレビューはその境界を越える承認を別のエージェントに任せる仕組みで、範囲は広げません。まず確認コマンドでMXC_OKを確かめ、prefer_mxcと従来方式の組み合わせで始め、on-requestのままオートレビューを試してください。組織ではrequirements.tomlで方式・権限・承認を先に決めてから広げます。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• Windows sandbox — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Auto-review — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Agent approvals & security — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Permissions（permission profiles） — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Configuration Reference — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Advanced Config — OpenAI公式ドキュメント（shell_environment_policy・参照日: 2026-10-12）
• Managed configuration — OpenAI公式ドキュメント（参照日: 2026-10-12）
• Pricing — OpenAI公式ドキュメント（機能表・参照日: 2026-10-12）
• codex-rs/mxc-sandbox/README.md — openai/codex（コミット5ef96ab・参照日: 2026-10-12）
• codex-rs/prompts/templates/guardian/policy.md — openai/codex（コミット5ef96ab・参照日: 2026-10-12）
• codex-rs/config/src/config_toml.rs — openai/codex（コミット5ef96ab・参照日: 2026-10-12）
• MXCを使うサンドボックスの方式の発表 — OpenAI DevelopersのX投稿（2026年10月9日）
• オートレビューの無料化の案内 — Thibault Sottiaux氏のX投稿（2026年10月6日）
• Microsoft Execution Containers: Policy-driven containment for AI agents — Microsoft（2026年10月7日・参照日: 2026-10-12）
• Building Windows for hybrid intelligence — Microsoft（2026年10月7日・参照日: 2026-10-12）
• About cloud and local sandboxes for GitHub Copilot — GitHub Docs（参照日: 2026-10-12）
• Understanding filesystem policies for local sandboxing in GitHub Copilot CLI — GitHub Docs（参照日: 2026-10-12）
• Local sandboxing for GitHub Copilot now generally available — GitHub Changelog（2026年10月7日）
• Configure the sandboxed Bash tool — Claude Code Docs（参照日: 2026-10-12）
• JPCERT-AT-2026-0030 — JPCERT/CC（2026年10月8日公開・10月9日更新）
• Windows版CodexがMXCに対応、セットアップを高速化 — gihyo.jp（2026年10月10日・報道）

このテーマの関連記事

• ▸ 【2026年10月】Rewriting Prime Agent in Rust｜14倍高速化の実像
• ▸ 【2026年10月】AIエージェントが社内Slackに銀行口座情報を投稿した
• ▸ 500B tokens later｜AI逆コンパイル5つの教訓
• ▸ Talorysとは？Cloudflare無料枠AIの検証点
• ▸ Show HN: Nokia 110のAIエージェント｜実務検証5項目