Codexローカル実行|WindowsとCursorの処理場所の違いを確認

Codexローカル実行|WindowsとCursorの処理場所の違いを確認

Codexの「ローカル実行」は、モデルを手元に置くこと、作業フォルダーをPCで開くこと、ツール処理を行う端末を選ぶことが同じ意味ではありません。Cursorが9月2日に自社ネットワーク内の端末で処理するself-hosted machinesを案内した今、WindowsでCodexを使う人は入口・版・作業場所・参照範囲・ネットワーク・承認を分けて確認します。記事では公式記載と確認項目を整理します。

結論powered by Claude

「ローカル実行」は三つに分けて考えると迷いにくい。モデルの接続先、Codexが読む作業フォルダー、ツール処理を置く端末は別の項目だ。Windows版はPowerShell上のサンドボックスでファイルとネットワークの境界を設けるが、ローカルモデルやオフライン利用を意味しない。根拠はWindowsサンドボックスの公式説明ローカル環境の公式説明にある。

確認表では、処理場所と参照範囲を別々に記録する。Cursorのself-hosted machinesは自社ネットワーク内の端末でツール処理を行うCursor固有の機能であり、Codexに同じ端末群や再接続の仕組みがあるとは書かない。Copilotの参照除外も、Copilotの文脈に入れない規則として扱い、別製品の境界へ読み替えない。

Copilotの組織設定とLinux通信制限、Cline v4.1.17のCodex接続修正、Aiderの対象期間内の版表示は、それぞれの製品の事実として補足する。公式記載・手元で表示された結果・未確認の項目を分けることが、更新後の判断を安定させる。まず入口と版を残し、小さな読み取り、範囲、接続、承認を順番に確認したい。

目次 (21)

「Codexローカル実行」を三つに分けて考える

「ローカル実行」と検索すると、手元のモデルを使う方法、PC上のフォルダーを対象にする方法、エージェントのツール処理を手元の端末で行う方法が一つに見えやすい。しかし、この三つは確認する場所も判断材料も違う。モデルの接続先は推論をどこへ依頼するかの話であり、作業フォルダーはどのファイルを読んだり変更候補にしたりするかの話だ。さらにツール処理の端末は、コマンドやファイル操作をどの実行環境で進めるかを表す。まず語を分解すると、ローカルという印象だけからデータの流れや安全性を断定せずに済む。

ローカルモデルとローカルの作業場所は別の項目

既存のcodex-local-llm.mdは、Ollamaなどを経由してgpt-ossのようなモデルを手元で動かす接続方法を扱っている。これは推論モデルの場所を変える話で、Codexがどのフォルダーを読み、どの端末でツールを実行し、ネットワークへ出られるかを同時に決める説明ではない。モデルをPCに置いても、承認やサンドボックスの設定は別に確認する必要がある。逆に、PC上の作業フォルダーを対象にしても、推論までローカルモデルで行っているとは限らない。

「ローカル」と書く前に対象を名詞で記録する

実際の確認では、「ローカルで動いた」と一行で済ませず、モデルの接続先、作業フォルダー、ツール処理の端末、参照したファイル、外部接続の可否を分けて残す。たとえばWindowsのPowerShellからローカルのリポジトリを開き、CodexがWindows側のサンドボックスでツールを扱っていても、利用しているモデルがどこにあるかは別の記録になる。この切り分けが、ローカルモデルの記事やインターネットアクセスの記事との重複を避ける出発点だ。

Windowsのサンドボックスは作業場所の境界を確認する機能

OpenAIのWindows向け公式説明では、CodexはPowerShell上でWindowsの仕組みを使って動かせ、WSLや仮想マシンを必須にしない構成が案内されている。エージェントモードでは、作業フォルダーの外へのファイル書き込みを抑え、明示的な許可なしのネットワーク接続を防ぐ境界が設けられる。ここで確認できるのは、Windows側の実行環境と権限の境界であって、モデルの推論場所そのものではない。公式ページはhttps://learn.chatgpt.com/docs/windows/windows-sandboxで参照できる。

elevatedとunelevatedは同じ強さではない

Windowsのネイティブサンドボックスには、より強いelevatedと、導入条件が合わない場合のunelevatedがある。公式説明では、前者は専用の低権限ユーザー、ファイル権限の境界、ファイアウォール規則などを使い、後者は制限付きトークンとACLを使う代替として説明される。表示されたモードを記録せずに「Windowsサンドボックス済み」とだけ書くと、実際の境界の強さを比較できない。Windows 11推奨、更新済みWindows 10はベストエフォートという対応表も、手元の版や管理状態と分けて読む。

ネットワークと承認は別々に判定する

ネットワークが遮断されたことは、ファイル範囲や承認表示まで確認できたことを意味しない。小さな読み取りが通った、限定した書き込みが止まった、外部接続が許可を求めた、という三つの結果を別の欄に記録する。サンドボックスのモードが同じでも、設定や入口が変われば表示が変わる可能性があるため、現在の版、使用した入口、作業フォルダーと一緒に残す。既存のcodex-security-settings.mdは境界の点検を詳しく扱うので、この記事では処理場所との関係に絞る。

ローカル環境とクラウド環境を混同しない

Codexの公式ページにある「ローカル環境」は、ChatGPTデスクトップアプリでプロジェクトの共通操作や作業用フォルダーの準備を設定する仕組みとして説明されている。設定はプロジェクト直下の.codexフォルダーに置ける。これは作業場所をそろえるための設定であり、モデルの推論やすべてのツール処理がPC内だけで完結するという意味ではない。ローカル環境という名称から、送信先や処理端末まで推測しないことが重要だ。

クラウド環境の公式説明では、依頼を受けるとクラウド側にコンテナを用意し、選択したブランチまたはコミットを取得し、環境準備とネットワーク設定を適用したうえで、エージェントが端末コマンド、編集、確認を進める流れが記載されている。準備段階とエージェントの接続条件が別に書かれており、クラウドという一語だけでネットワークの可否を決めてはいない。詳細はhttps://learn.chatgpt.com/docs/environments/cloud-environmentで確認できる。

ローカル環境で確認するファイル

ローカル環境を使うときは、プロジェクト直下の.codexが本当に対象プロジェクトのものかを確認する。リポジトリに複数のプロジェクトがある場合、共通の.codexを含むディレクトリを開くという説明になっている。ここで見るべきなのは、準備する依存関係や共通操作の設定、作業フォルダーの位置だ。設定ファイルを読めたことだけから、ファイル全体が参照対象になった、あるいはネットワークが使える、と結論づけてはいけない。

クラウド環境で確認する境界

クラウド側では、どのブランチやコミットを取得したか、どのコンテナでツール処理をしたか、準備段階と作業段階で接続条件がどう違うかを記録する。公式説明では、エージェントのインターネット接続は既定で無効だが、必要に応じて限定または無制限の設定を選べるとされている。したがって「クラウドだから接続できる」「ローカルだから接続できない」という二分法ではなく、入口、作業場所、設定、実際の結果をそろえて判定する。

入口・版・作業フォルダーを一枚の表で判定する

処理場所を確かめるための表は、製品名だけを並べる比較表では足りない。入口、版、作業フォルダー、ファイル範囲、ネットワーク、承認、短い確認結果を同じ行に置くと、公式発表と手元の再現を分離しやすい。下表の「要確認」は未確認を意味し、機能がないという断定ではない。Copilot、Cline、Aiderの行もCodexの仕様へ読み替えず、各製品の発表を記録するための欄として使う。

製品・入口 処理場所 作業フォルダー 参照範囲 ネットワーク 承認 短い確認の結果 判定 出典URL
Codex / Windows PowerShell 使用中の版を記録 Windows側のサンドボックスでツール処理 開始時に固定した作業フォルダー 作業フォルダーと追加読取先 権限と設定に応じて遮断・許可 表示された確認要求を記録 読み取り・書き込み・接続を個別に確認 推論場所は別確認 Windows説明
Codex / クラウド環境 使用中の版を記録 クラウド環境のコンテナ 取得したブランチまたはコミット 取得したリポジトリと設定した範囲 準備段階と作業段階を分けて記録 環境の権限表示を記録 コンテナ、取得元、接続条件を確認 クラウド側の処理 Cloud説明
Cursor / self-hosted machines 2026-09-02告知 自社ネットワーク内の端末・VM・worker 割り当てられたプロジェクト workerが扱うコードと成果物 自社ネットワークの条件 端末群とアカウントの管理 個人端末・team pool・再接続を確認 Cursor固有 Cursor告知
Copilot / app・CLI・VS Code 2026-09-02告知・CLI 1.0.83-2 今回の告知では処理場所を説明しない 製品・組織の設定に従う 除外ファイルは文脈に使わない CLI Linuxは設定proxyへの送信を制限 組織・リポジトリ管理を確認 既定モデルと参照除外を別に確認 Copilot固有 参照除外
Cline / v4.1.17 2026-09-02公開 Cline側の更新で処理場所は未記載 Clineの利用中プロジェクト Codexの範囲とは分けて確認 個別の接続条件を確認 製品側の表示を確認 Codex CLIモデルのtool calling修正を確認 Cline固有 Clineリリース
Aider / releases Latestはv0.86.0 対象期間の新規版なし Aiderの利用中プロジェクト Codexの範囲へ読み替えない 今回の確認対象外 今回の確認対象外 対象期間内の新規版表示なし Aider固有 Aiderリリース一覧

Cursor self-hosted machinesをCodexと比較するときの線引き

Cursorの2026年9月2日付Changelogは、self-hosted machinesによってツール処理を自社ネットワーク内に置けると説明している。コードベースやビルド成果物を内部の端末に残し、エージェントのツール呼び出しをその端末側で扱う構成だ。個人向けのMy Machinesでは一台のノートPCや仮想マシンをアカウントへ接続し、team poolでは複数のworkerを名前付きの待ち行列として扱える。リポジトリ一つに端末を固定しない点も、通常の作業フォルダーを開く場合との違いになる。

処理場所・ファイル・端末群を分けて読む

比較するときは、まず「ツール処理がどこに置かれるか」を見る。次にコードと生成物がどの端末に残るか、個人端末かteam poolか、切断した端末を再接続できるかを確認する。Cursorのページには、待機中の端末を休止させ、後続の依頼に合わせて再接続する仕組みや、self-hosted workerのcomputer useはLinuxとMacに対応するという記載がある。これはCursorの機能説明であり、CodexのWindowsサンドボックスに同じpoolや再接続があるという根拠にはならない。

Codexへ同じ機能を足して読まない

CodexのWindows公式ページが説明するのは、PowerShell上の実行、ファイル権限の境界、ネットワーク条件、elevatedとunelevatedの選択だ。一方、Cursorの告知は自社ネットワーク内の端末群と、そこへ処理を割り当てる仕組みを説明している。両者を同じ「ローカル」と呼んでも、端末群の管理、生成物の置き場所、再接続、対応OSの意味は同じではない。比較表には各製品の公式記載を残し、未記載の仕組みを補完しない。

Copilot・Cline・Aiderの周辺情報は製品別に読む

9月2日前後の更新には、処理場所と混同しやすい情報が複数ある。Copilotでは組織の既定モデルと参照除外、Copilot CLIではLinuxの通信制限が案内された。ClineではCodex CLIモデルのツール呼び出しに関する修正があり、Aiderのリリース一覧では対象期間に新しい版が追加された表示は確認できない。これらは同じ機能の比較材料ではなく、製品ごとの管理・参照・通信・接続の事実として扱う。

Copilotの既定モデルと参照除外

GitHubの公式Changelogでは、Copilot BusinessとCopilot Enterpriseで、組織が新しい会話の既定モデルを指定でき、teamごとに異なる既定値を割り当てられると案内している。Copilotアプリ、Copilot CLI、Visual Studio Codeが対象に含まれる。これはモデル選択を管理する話で、モデルがどの端末で推論するかを説明する発表ではない。出典は既定モデルに関する公式Changelogだ。

同じ日の参照除外の告知では、組織・Organization・リポジトリの管理者が設定した除外方針をCopilotアプリとCLIが尊重し、除外したファイルを文脈に使わないと説明している。これは参照範囲を狭める規則であり、PC内で処理することや外部接続がないことの証明ではない。詳細はCopilotの参照除外に関する公式Changelogで確認できる。

Copilot CLI 1.0.83-2のリリース本文には、Linuxサンドボックスの外向き通信を設定したproxyに制限し、その方式に必要なLinux側の条件を列挙した変更がある。WindowsのCodexで表示されるネットワーク境界を、このCopilot CLIのLinux向け変更から推測してはいけない。根拠はCopilot CLI 1.0.83-2の公式リリースに限定する。

ClineのCodex接続修正はClineの更新

Cline v4.1.17のリリース本文には、Codex CLIモデルなどでcatalogが能力なしと宣言した結果、ツール呼び出しが無効になる問題を修正したと記載されている。ここで確認できるのはClineがモデル情報の扱いを直したことだ。Codex自体のWindowsサンドボックス、作業フォルダー、ネットワーク条件が変わったという意味ではない。Clineの更新を読んだら、Clineの入口で表示と操作を確認し、Codexの環境記録へ混ぜない。

Aiderは対象期間の版表示だけを残す

Aiderの公式リリース一覧では、現時点のLatestとしてv0.86.0が表示され、ページ上の公開日は8月9日になっている。9月2日前後に新しい版が掲載されたという表示は確認できないため、対象期間内の更新なしという補足にとどめる。Aiderがどの端末で処理するか、Codexと同じ境界を持つかは、この一覧からは判断しない。出典はAider公式リリース一覧である。

更新後に利用者が残す確認記録

更新や入口の切り替え後は、結果だけでなく、どの条件で試したかを短く残す。最初に入口と版を記録し、次に作業フォルダーを一つに固定する。その後、読めるファイルと読めないファイル、書き込みが止まった場所、ネットワーク接続の表示、承認を求められた操作を別々に確認する。読み取りが成功したこと、書き込みが許可されたこと、外部接続ができたことは、それぞれ別の判定なので、一つの「成功」にまとめない。

入口: Windows PowerShell / Codex CLI / Desktop app
版: codex --version の表示
作業フォルダー: 確認した絶対パス
参照範囲: 読み取りできた場所と対象外
ネットワーク: 接続先・遮断表示・確認時刻
承認: 表示された確認内容と選択
結果: 読み取り / 書き込み / 接続を個別に記録

0.152.1と先行版を処理場所の変更と混ぜない

Codex 0.152.1の公式リリースに記載された変更は、モデルのメタデータから渡されるNode REPLの方針を承認レビューが尊重する不具合修正だ。これはNode REPLと確認経路の修正であり、Windowsの処理場所を変更したという説明ではない。0.153.0-alpha.5とalpha.6は先行版として公開されているが、ページの公開事実だけから新しい処理端末や性能を推測しない。出典は0.152.10.153.0-alpha.50.153.0-alpha.6の公式リリースである。

既存記事との役割を分ける

codex-local-llm.mdはローカルモデルへの接続、codex-internet-access.mdはネットワーク制限とWeb検索、codex-security-settings.mdは設定境界の点検、codex-news-2026-09-03.mdは0.152.1と先行版のニュースを扱っている。今回の記事はそれらを置き換えず、「ローカル実行」という語をモデル、作業場所、ツール処理の端末に分解し、CursorとCopilotの発表を製品別に照合する。入口・作業フォルダー・範囲・接続・承認を一つの記録へ並べる点が差分になる。

まとめ:ローカル実行は場所を一つずつ確認する

Codexのローカル実行を正しく読むには、ローカルモデル、ローカルの作業フォルダー、ツール処理を行う端末を分ける必要がある。Windowsのネイティブサンドボックスはファイルとネットワークの境界を確認する材料になるが、推論モデルの場所を単独で証明するものではない。ローカル環境の.codex設定も、クラウドコンテナも、それぞれ公式説明の範囲で読む。

Cursorのself-hosted machinesは自社ネットワーク内の端末群へ処理を置くCursor固有の機能で、Copilotの既定モデル・参照除外・Linux通信制限、Clineの接続修正、Aiderの版表示も各製品の情報だ。更新後は入口、版、作業フォルダー、参照範囲、ネットワーク、承認、短い結果を残し、公式記載と手元で確認できた事実を分けて判断しよう。

参考になったら ♡
Codexer Navi 編集部
@codexer_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。