サービスServices制作実績Works自社ツールToolsブログBlogチームTeam会社概要Company
お問い合わせ
OpenAI製コーディングエージェント「Codex CLI」のサンドボックス検証を解説する記事のサムネイル
← ブログ一覧
AI8分

Codex CLIとは？OpenAI製コーディングエージェントのサンドボックスを実際に動かして検証した

  • #Codex CLI
  • #OpenAI
  • #サンドボックス

AIコーディングエージェントのCLIはここ数年で急速に増えており、本ブログでもQwen Code、Cline、Goose、OpenCode、Pi、Crush（Charm製）などをこのクラウド環境で実際に動かして検証してきました。今回取り上げる「Codex CLI」（https://github.com/openai/codex ）は、OpenAIが公開しているローカル実行型のコーディングエージェントです。

この記事では公式GitHubリポジトリのREADME・CHANGELOG・Rustソースコード（codex-rs配下）を一次情報としつつ、実際にnpmでインストールし、バージョン確認・サブコマンド構成、そして`codex sandbox`サブコマンドを使ったファイルシステム／ネットワークサンドボックスの挙動をこのクラウド環境の中で試した結果をまとめます。公式ドキュメントサイト（developers.openai.com/codex）は今回の検証環境のネットワークポリシー上アクセスできなかったため、そちらの記載内容は参照していません。対話セッションを動かすにはChatGPTアカウントまたはAPIキーでの認証が必要で、この検証環境にはどちらも用意されておらず、OpenAIのAPIエンドポイントへの到達性自体も`codex doctor`でブロックされていることが確認できたため、そこから先は公式READMEの記述として明確に書き分けています。

  • この記事でわかること：Codex CLIが何をするツールで、どんなライセンス・導入経路を持つか。
  • 実際にインストールして `codex --version` `codex --help` `codex doctor` を動かした結果。
  • `codex sandbox` コマンドでファイルの書き込みとネットワーク接続を実際にブロック／許可させて確認した挙動。
  • ソースコード（codex-rs/linux-sandbox）から確認した、Linux版サンドボックスの実装方式（bubblewrap・seccomp・レガシーLandlock）。
  • ChatGPTサインインとAPIキーという2つの認証方式、そして今回の検証環境で試せなかった範囲。

Codex CLIとは：OpenAIが公開するローカル実行型コーディングエージェント

公式リポジトリのREADMEには「Codex CLI is a coding agent from OpenAI that runs locally on your computer」と明記されています。ライセンスはApache License 2.0で、ソースコードはRustで書かれた`codex-rs`と、npm配布用のラッパーを含む`codex-cli`のディレクトリで構成されるモノレポになっていました。

READMEによれば、同じCodexという名前の体験は複数あり、ターミナルで動く今回のCLI以外に、VS Code／Cursor／Windsurf向けのIDE拡張、`codex app`コマンドで起動するデスクトップアプリ、そしてブラウザから使うクラウド版「Codex Web」（chatgpt.com/codex）が用意されていると案内されています。本記事で検証したのはターミナルで動くCLI版のみです。

認証はChatGPTアカウントでのサインイン（Plus・Pro・Business・Edu・Enterprise）、またはAPIキーのいずれかを使う設計です。インストーラーはmac/Linux向けのシェルスクリプト、Windows向けのPowerShellスクリプト、Homebrew、npm（`npm install -g @openai/codex`）など複数の経路が公式に案内されています。

実際にインストールしてみる

今回はnpm経路でインストールしました。

  • コマンド: `npm install -g @openai/codex`
  • 結果: エラーなく完了し、`codex --version` は `codex-cli 0.162.1` を返した
  • `codex --help` のトップレベルサブコマンドは `exec` `review` `login` `logout` `mcp` `plugin` `app-server` `sandbox` `resume` `fork` `queue` `archive` `delete` `cloud` `features` `doctor` `update` `completion` など20種類以上に及んだ

サブコマンドの多さは単なる見かけではありません。`mcp`は外部MCPサーバーの管理、`plugin`はCodexプラグインの管理、`app-server`はIDE統合などが使う常駐プロセス、`cloud`はクラウド版Codexで実行したタスクをローカルに取り込むための実験的機能、`resume`/`fork`/`queue`/`archive`/`delete`はローカルに保存された対話セッションの管理コマンドでした。単発の質問応答ツールというより、長期間のセッション管理を前提にした設計であることが、コマンド一覧だけからも伝わってきます。

`codex doctor`で見えた、この検証環境の実情

`codex doctor`は、インストール状態・認証・ネットワーク到達性などをまとめて診断してくれるコマンドです。このクラウド環境で実行すると、次のような結果が返ってきました。

  • auth: 「no Codex credentials were found」— ChatGPTサインインもAPIキーも未設定
  • reachability: 「one or more required provider endpoints are unreachable over HTTP」— OpenAIのAPIエンドポイントへの到達性チェックが失敗
  • websocket: 「Responses WebSocket failed; HTTPS fallback may still work」という警告
  • install: npm経由でインストールされたことを正しく検出し、実行ファイルのパスまで正確に報告

つまりこの検証環境では、インストール自体は正常に完了したものの、認証情報が無いことに加えて、ネットワークポリシー上OpenAIのAPIに到達できないことまで`codex doctor`が正確に検出していました。実際の対話セッション（認証した上でエージェントに質問や実装を頼む体験）はこの環境では試せなかったということを、ツール自身の診断結果として確認できた形です。

サンドボックスを実際に動かして確認する

Codex CLIの特徴としてよく語られるのが、エージェントが実行するシェルコマンドをOSレベルでサンドボックス化する仕組みです。対話セッションそのものは試せなかったものの、`codex sandbox`という単体のサブコマンドが用意されており、これは「エージェントが使うのと同じサンドボックスの中で任意のコマンドを1回実行する」ためのものです。認証なしでも動かせたので、実際に試してみました。

  • `codex sandbox -- echo hello` → 正常に `hello` が出力された
  • 追加設定なしで `codex sandbox -- sh -c 'echo test > ./file.txt'` → カレントディレクトリ内への書き込みでも「Read-only file system」でブロックされた
  • `codex sandbox -c sandbox_mode=workspace-write -- sh -c 'echo test > ./file.txt && cat ./file.txt'` → 書き込みが成功し、書いた内容も読み出せた
  • 同じ `workspace-write` 設定のまま `curl https://example.com` を実行 → ローカルのプロキシにすら到達できず接続エラーで失敗（ネットワークは遮断されたまま）

つまり`codex sandbox`は、追加設定をしない限りファイルシステムが丸ごと読み取り専用になる、かなり厳しいデフォルトになっています。`sandbox_mode=workspace-write`を指定するとカレントディレクトリへの書き込みは許可されますが、ネットワークは依然として遮断されたままでした。公式リポジトリのプロトコル定義（`codex-rs/protocol/src/protocol.rs`・`config_types.rs`）を確認すると、サンドボックスのポリシーは`read-only`／`workspace-write`／`danger-full-access`の3種類がシリアライズ名として定義されており、今回観察した挙動とも一致します。

実装方式についても`codex-rs/linux-sandbox`クレートのREADME（https://github.com/openai/codex/blob/main/codex-rs/linux-sandbox/README.md ）に詳しい記載がありました。Linux版はbubblewrap（`bwrap`）によるファイルシステム・名前空間の隔離を既定の方式としており、その上に`PR_SET_NO_NEW_PRIVS`とseccompフィルタによるシステムコール制限を重ねる構成です。以前使われていたLandlockベースの実装はコード上まだ残っているものの「レガシー」と明記され、`features.use_legacy_landlock`で無効化する方向に進んでいるようです。興味深いのは、このクラウド環境には`bwrap`コマンド自体が見つからなかった（`which bwrap`が何も返さなかった）にもかかわらず`codex sandbox`は問題なく動作した点です。READMEには「`bwrap`が見つからない場合は同梱の`codex-resources/bwrap`にフォールバックする」と記載されており、今回の挙動はその記述と一致していました。

なお、ソースコードを見るとmacOS向けの「seatbelt」対応やWindows向けの制限付きトークン実装を示すコード（`WindowsSandboxLevel`など）も確認できましたが、今回検証したのはこのLinux環境のみで、他OSでの動作は確認していません。

まとめ

実際にインストールして動かした範囲では、Codex CLIは「対話セッションを始める前の段階」からサンドボックスがかなり厳格に効いているツールという印象でした。認証情報もネットワーク到達性も無いこの検証環境でも`codex sandbox`単体のコマンドなら動かせて、デフォルトの読み取り専用設定から`workspace-write`への変化までを実際の挙動として確認できたのは収穫でした。

一方で、エージェントに実際にコードを書かせる本来の使い方は、ChatGPTアカウントでのサインインかAPIキーのいずれかが前提になります。この検証環境ではその両方が無く、加えてOpenAIのAPIエンドポイントへの到達性自体も`codex doctor`がブロックを検出していたため、今回はインストールからサンドボックス単体の挙動確認までにとどまりました。すでにChatGPTのPlus/Pro等のプランやAPIキーを持っている場合は、`codex`を起動してサインインするところから大きな障壁なく試せるはずです。

参考リンク

関連記事

まずは、やりたいことを聞かせてください

「何から手をつければいいか分からない」段階でも大丈夫です。 ご相談・お見積りは無料。碧南近郊なら直接伺います。

お問い合わせ090-1742-3456