MENU
シニアが日々の課題をAIを使って解決しようとするサイト
  1. ホーム
  2. ツール
  3. Codex CLIのv0.44.0変更内容

Codex CLIのv0.44.0変更内容

ツール プログラミング ＡＩ

Codex CLIのv0.44.0の変更内容で、バグ修正を除いて、新規な機能、改良した機能のみを分かりやすく説明してください

（注）本記事の内容は正確性を保証するものではない。

GPT 5 Thinking の回答

了解です。Codex CLI 0.44.0で「不具合修正を除いた」新機能・改良点だけを分かりやすくまとめました。
（公開：2025-10-03 UTC）。主要ソースは公式リリースノートです。(GitHub)

新機能

  • UI刷新（TUI）
    チャットコンポーザー、下部ペイン、モデルピッカー、アップグレード案内を全面的に更新。
    操作系と視認性が改善され、モデル切替や入力が分かりやすくなりました。(GitHub)
  • カスタムプロンプトの引数対応強化
    /prompts: で定義するカスタムプロンプトに名前付き引数・位置指定引数の両方が使えるようになり、再利用可能なテンプレート化がしやすくなりました。(GitHub)
  • HTTP MCPサーバーのストリーミング対応
    STDIOだけでなくHTTP/SSE系のMCPサーバーからのストリーム応答を扱えるように。
    外部ツール連携のリアルタイム性が向上します。(GitHub)
  • （実験）Windowsの承認頻度低減
    読み取り専用コマンドについて、Windowsでの反復承認を抑制。
    安全性を保ちつつ操作の手間を減らします。(GitHub)
  • （非常に実験）codex cloud の導入
    CLIからクラウドタスク管理を行う試験的機能。
    ローカル↔クラウドのワークフロー分担に向けた布石です。(GitHub)

改良点（抜粋）

  • ショートカットヘルプの復活
    「？」でコマンド一覧を素早く参照可能に（操作発見性の改善）。(GitHub)
  • codex exec の表示品質向上
    端末のカラー対応を自動検出してANSI色表示を最適化、ログの読みやすさが向上。(GitHub)
  • ファジー検索の結果強化
    一致ファイル名を応答に含めるようになり、候補選択の精度と速度が上がります。(GitHub)
  • /review を主要コマンドへ昇格
    変更提案やPRスタイルのレビューを一等席のコマンドに配置し直し、レビュー中心の運用がしやすく。(GitHub)
  • 安全性の強化（承認ポリシー）
    AskForApproval::Never 設定でも危険コマンドを拒否するガードを追加（誤操作防止）。(GitHub)
  • イベント／可観測性の拡充
    turn started/completed などのイベント追加、OpenTelemetryイベント整備で、実行の可視化・追跡性が上がりました。(GitHub)
  • MCP連携の使い勝手向上
    MCPでファジー検索を公開、MCPツール呼び出しイベントを codex exec に追加し、統合度を高めています。(GitHub)
  • SDKまわりの拡充（TypeScript/Rust）
    型やテスト、作業ディレクトリ指定、サンドボックス指定など開発者向けの足場を強化。ツール連携や自動化がしやすくなりました。(GitHub)

追加質問し、新機能や改良点についてGPT 5 Thinkingから得た回答は下記の通り（抜粋）

UI刷新（TUI） チャットコンポーザー／下部ペインの新スタイル（抜粋）

プロンプト、背景色帯、ワーキング・シマーなどのスタイルが選べる。

UI刷新（TUI） モデルピッカー

上記画像はモデルピッカー（/model）を呼び出して、使用するモデルを選ぶ画面です。

見えているポイント：

  • 画面中央の「Select Model」配下に
    1. gpt-5（current）、2. gpt-5-codex の候補が並び、説明文（得意分野）が表示されています。
  • 上部ログに
    “Model changed to gpt-5-codex with high reasoning” → “…with minimal reasoning”
    と出ているのは、0.44系で導入された二段階化の挙動を示唆しています。
    ① モデル（gpt-5 / gpt-5-codex など）を選択 →
    ② Reasoning 努力度（minimal / standard / high）を続けて選ぶ、という流れです。
  • /model to change とある通り、/model コマンドでこのピッカーを呼び出します。

要するに、添付のUIは「どのモデルを使うか（＋必要なら推論強度）をその場で切り替えるための選択画面」です。

UI刷新（TUI） アップグレード案内

上記画像の「Update available! …」と書かれた枠（バナー）が、アップデート案内（Update nudge）の視認性強化にあたる部分です。
改善点は次のとおり：

  • サイズ拡大 & 余白増：カード全体が大きく、上下左右のパディングも広くなり、周囲のUIから視覚的に分離。
  • 見出しの強調：✨ Update available! とバージョン差分（0.0.0 → 0.11.0）を太字で明示。
    ひと目で「更新あり」と判別できます。
  • 公式リリースへの直リンク：releases/latest へのクリック可能なURLを追加し、詳細確認までの導線を短縮。
  • 即時実行コマンドの提示：npm install -g @openai/codex@latest をそのままコピー＆ペーストできる形で表示（操作手順が明快）。
  • コントラスト/枠線：濃色テーマでも読める高コントラストの枠線と文字色で、通知として埋もれにくい。
  • レイアウトの一貫性：下に続く「OpenAI Codex (v0.0.0)」の情報パネルと明確に区切り、通知と通常ステータスの役割が分かりやすい。

要するに、「見つけやすく・理解しやすく・すぐ更新できる」ように、カードの大きさ・情報量・導線が強化された、ということです。

カスタムプロンプトの引数対応強化


カスタムプロンプトの引数対応強化（位置指定＋名前付き）によって、テンプレ化したコマンドを変数だけ差し替えて即実行できるようになり、再現性・スピード・一貫性が上がります。
実際に「何ができるか」を、使い方→効果が一目で分かる形で例示します。

例1：Conventional Commitsを一発生成

使い方
/commit TYPE="feat" SCOPE="auth" SUBJECT="passwordless login"
効果

  • ルール準拠の件名＋本文（理由・影響・BREAKING CHANGE）を自動生成
  • TYPE/SCOPE/SUBJECT を差し替えるだけで統一品質のコミット文

例2：差分ファイルのピンポイントレビュー

使い方
/review target=@src/login.ts severity="high" style="actionable"
効果

  • 指定ファイルだけをレビューし、重大度(severity)とレビュー方針(style)を切替
  • コメントの粒度やトーンをプロジェクト標準に合わせて統一

例3：バグ修正のパッチ雛形を生成

使い方
/hotfix file=@server/routes/user.ts lines="120-168" reason="null pointer on optional field"
効果

  • 該当行だけを対象に原因→再現→修正案→テスト追加の雛形パッチを出力
  • file と lines を変えるだけで、同じ書式の修正提案を量産

例4：ドキュメント生成（対象・読者・形式を切替）

使い方
/docgen src=@README.md audience="beginner" format="md"
効果

  • 既存READMEから入門者向け概要を再構成
  • audience を "ops" や "exec" に変えると、運用向け／経営向けの要約に切替

例5：テストコードの雛形

使い方
/testgen module=@lib/math.ts framework="vitest" cases="edge: negative, zero, big"
効果

  • 指定モジュール用のテストスケルトンを生成
  • フレームワークやケース指示を引数で差し替えて、書式を共通化

例6：多言語翻訳＋語調指定

使い方
/translate lang="ja" tone="polite" domain="legal" target=@contracts/terms.en.md
効果

  • 語調(tone) と 専門領域(domain) を明示して訳質を安定化
  • 対象ファイル（@でパス指定）を切り替えるだけで再利用

使い勝手が上がるポイント（要約）

  • 位置指定：/commit “feat” “auth” “passwordless login” のように短く打てる
  • 名前付き：順番を気にせず、必須だけ明示し、任意は省略可（デフォルト適用）
  • @パス連携：@file や @glob/*.md で対象を素早く差し替え
  • チーム共通化：同じプロンプト名と引数名を使うことで、合意済みの出力品質を保てる

添付画像の /elegant COMMIT="" ARG2="" … は、まさに名前付き引数でテンプレを呼び出している例です。今後は同じタスクを「引数だけ差し替えて」反復できるため、毎回の長い指示文が不要になります。

HTTP MCPサーバーのストリーミング対応

これは何？

HTTP MCPサーバーのストリーミング対応は、Codex CLIがMCP（Model Context Protocol）をHTTP経由で“逐次（ストリーム）”受け取れるようになった機能です。
MCPサーバー側はHTTP（多くはSSE=Server-Sent Events）で部分結果や進捗を小刻みに送信し、Codex側は到着次第表示・処理します。 (GitHub)

何が嬉しい？

  • リアルタイム性：長い処理でも途中経過（ログ・部分回答）を即座にTUIへ表示。待ち時間の体感が大きく改善。 (Model Context Protocol)
  • 双方向の拡張性：HTTPなのでローカル/リモート問わずツール群に繋ぎやすい（認証ヘッダなども扱いやすい）。 (Model Context Protocol)
  • 既存MCP実装との互換：SSE/“Streamable HTTP”に対応したMCPサーバーで、そのまま流し込み可能。 (OpenAI GitHub)

どうやって有効化する？

0.44.0では、設定ファイルにURL型のMCP定義を足します（必要に応じて実験フラグ）。 (GitHub)

# ~/.codex/config.toml （例）
experimental_use_rmcp_client = true  # 必要に応じて

[mcp_servers.figma]
url = "http://127.0.0.1:3845/mcp"   # HTTPのMCPエンドポイント
# 任意: ベアラートークンでの認可
bearer_token = "YOUR_TOKEN"
  • url を書く＝HTTPストリーミングMCPを使う指定。
  • bearer_token を入れるとAuthorization: Bearerヘッダで送信（OAuthフローは未対応）。 (GitHub)

使うと何が起きる？

  • CodexがMCPツールを呼ぶと、サーバーから届くイベント/チャンクを逐次描画（進捗バーやログが刻んで出るイメージ）。
  • “一括応答”ではなく段階的に結果が見えるため、途中でキャンセル・条件変更なども判断しやすい。 (Model Context Protocol)

他の方式との違い（ざっくり）

  • STDIO MCP：Codexと外部プロセスをローカル接続。シンプルだがリモート配備しづらい。
  • HTTP（Streamable）MCP：ネットワーク越しに複数クライアントから利用可。SSE等で段階配信。
    クラウドの業務APIやSaaS連携に向く。 (Model Context Protocol)

代表的なユースケース

  • 長時間の外部処理（検索クローラ、ビルド、テスト、データ変換）の途中経過の可視化。
  • SaaS連携（例：Figma MCPなど）でクラウド側の進捗/イベントをライブ反映。 (GitHub)

既知メモ & トラブルシュート

  • 設定にurlを使う場合、command等のローカル実行系フィールドと混在させない（エラーに）。 (GitHub)
  • 一部Windows環境で設定読み込みのフィールド不一致エラー報告あり（例：missing field 'command'）。
    URL型とコマンド型のどちらか一方に寄せて記述を。 (GitHub)
  • プロキシ側のデフォルトタイムアウト30秒は削除され、長めのストリーミングにも対応しやすくなった。 (GitHub)

参考

  • Codex 0.44.0 リリース（“streamable HTTP MCP servers”を追加） (GitHub)
  • Streamable HTTP MCP対応の実装詳細と設定例（bearer_token 等） (GitHub)
  • MCP公式ドキュメント：HTTP/Streamable輸送の説明（SSEによる複数メッセージ配信など） (Model Context Protocol)
  • OpenAI Agents SDKドキュメント：Streamable HTTP MCP クライアントの案内 (OpenAI GitHub)

（非常に実験）codex cloud の導入

画面①：既存クラウドタスクの一覧と詳細

画面②：新規タスク作成時の「並列試行」選択

2枚のスクリーンショットは、試験的な「codex cloud」UI（CLI からクラウド上のタスクを管理・適用・作成する画面）を示しています。画像から読み取れる内容ベースで説明します。

画面①：既存クラウドタスクの一覧と詳細

  • 上部バー：Cloud Tasks · openai/codex · 0%
    → クラウド側のタスクボード。対象スペース（例：openai/codex）と進捗率が表示。
  • 左ペイン（キュー／履歴）：
    READY / ERROR ラベル付きで、タスクのタイトル・実行者・経過時間・差分数（例：+195/-1 · 1 files）が並びます。
    → ここでタスクを選ぶと、右側の詳細が切り替わる。
  • 右ペイン（詳細）：
    • ヘッダ：タスク名（例：Fix TUI freeze on launch）と「Attempt 1/4」など試行番号が表示。
      Tab/Shift-Tab や [ ] で試行（attempt）を切替。
    • [Prompt] Diff（↔で表示切替）：ユーザープロンプト、アシスタント応答の要約（Summary）、提案パッチ（Diff）を確認可能。
    • Testing チェックリスト：just fmt / cargo test -p codex-tui など、実行・検証手順を緑チェックで可視化。
    • その下に、モデルの思考ログ風メモ（調査方針や見つけた論点）が並ぶ。
  • フッター（キー操作ガイド）：
    ↑/↓ Move, r Refresh, Enter: Open, a: Apply (disabled), Tab: Next attempt, [ ]: Cycle attempts, o: Set Env, Ctrl+N: Attempts, n: New Task, q: Quit
    → ローカルからの適用（Apply）や環境変数セット（Set Env）、試行切替が可能。

要点：
クラウド側で生成された複数の候補（attempts）を一覧から選び、差分・要約・テスト結果までTUI一画面で確認し、必要に応じてApplyで反映する、という運用が想定されています。

画面②：新規タスク作成時の「並列試行」選択

  • タイトル：New Task · openai/codex · 1 attempt
  • ダイアログ：Parallel Attempts（Use ↑/↓, 1–4, Enter, Esc）
    → 1〜4回の並列試行（best-of）を選択できます。
    例：
    • 1 attempt · 1x parallel（現在値）
    • 2 attempts · 2x parallel
    • 3 attempts · 3x parallel
    • 4 attempts · 4x parallel
  • フッター：send / Shift+↵ newline / Ctrl+L+O env / Ctrl+L+N attempts / Ctrl+C quit
    → 入力送信、改行、環境の設定、試行数の再設定など。

要点：
新規タスクを投げる前に並列試行の数を決め、複数案を同時生成 → 後でベスト案を採択するワークフローが可能です。

これで何ができる？（画像から分かる機能の整理）

  1. クラウド実行・管理
    ローカルではなくクラウドでタスク（修正・生成・調査）を走らせ、CLI/TUIで進捗・ログ・成果物を閲覧できる。
  2. 複数試行（best-of）
    1〜4並列の候補生成 → 良い案を選んで適用。品質と安定性が上がる。
  3. 検証手順の可視化
    just fmt や cargo test などテスト／ビルドの通過状況がチェックで表示され、適用前に安全性を判断できる。
  4. Attemptの横断比較
    Tab や [ ] で異なる試行の要約・差分を素早く見比べ、最良案を選択。
  5. 環境の切替
    o: Set Env で環境変数／設定をタスク単位で付与し、同じプロンプトでも条件違いで再実行できる。
  6. 適用（Apply）
    条件を満たしたら a: Apply（状況により有効化）でローカルやリポジトリに反映する導線。

使いどころ（実務イメージ）

  • 長時間処理や重い生成をクラウドに委譲し、途中経過と成果を安全にレビューしてから取り込む。
  • 修正案のA/B/C比較（並列試行）→ テスト合格案を適用。
  • ノートPCの電源や環境に依らず、チームで同じボードを見て合意形成（要約・チェック項目が共有可能）。

注意（画像から読み取れない一般的ポイント）

  • まだ実験的機能で、環境によっては Apply が無効（権限や設定不足）になることがあります。
  • 実際の有効化手順（codex cloudのスイッチや設定項目）はバージョンで変わり得るため、手元の --help とリリースノートに従ってください。

必要なら、あなたのワークフロー向けに「best-of=3で並列生成→テスト→採択→適用」までの操作チートシート（キー操作一覧＋想定トラブル対処）を作ります。

ショートカットヘルプの復活

一番下の帯は、チャットコンポーザー直下に表示されるキーボード・ショートカットのヘルプバーです。

写っている内容の例（画像から読み取れる範囲）：

  • / … コマンド入力ヘルプ
  • @ … ファイルパス補助
  • ctrl + v … 画像貼り付け
  • ctrl + c … 終了
  • ? … ショートカットの表示/非表示切替
  • esc … 直前メッセージの編集
  • ctrl + j … 改行
  • ctrl + t … トランスクリプト表示

ポイント：

  • 「？」を押すとこのヘルプバーを表示/隠すトグルになっています。
  • 入力欄の状態に応じて（コマンド先頭かどうか等）内容がコンテキストで変わる場合があります。

ファジー検索の結果強化

変更前は、あいまい検索（ファジー検索）の候補は主にコマンド名／カスタムプロンプト名／拡張（extension）のアクション等にほぼ限定され、ファイル名（パス）自体は候補に出てきませんでした。
（ファイルは @ でのパス補完など“別の経路”でしか出せない状態）。

変更後（添付の例）は、同じファジー検索の候補リストに前方一致・部分一致したファイル名も並ぶため、

  • 「コマンドやプロンプト名」と「ファイル名」を同じ一覧で素早く選べる
  • @ を打たなくてもファイルへ即ジャンプ／参照できる
    ようになった、というのが差分です。

/review を主要コマンドへ昇格

上記画像のように起動画面の主要コマンド行に /review が常設されたことを指します。
「レビュー中心の運用がしやすくなった」というのは、以前はレビューを始めるまでに発生していた“余計な段取り”が減ったという意味です。代表的な手間は次のとおり。

これまでの面倒だった点

  • コマンドが隠れていた／覚えにくい
    /review が初期ヘルプに出ず、毎回ドキュメントを見たり、自然言語で「差分レビューして」と書いたりして呼び出していた。
  • レビュー対象の指定が冗長
    git diff を自分で流して貼る、または「このファイル群だけ見て」と長い説明を書いて誘導していた。
  • 運用フローが分断
    レビュー→修正提案→適用→再チェックの呼び分けを手動で行い、途中で /status や別のサブコマンドに行ったり来たり。
  • チームでの共通化が難しい
    人によって呼び方・書き方がバラバラで、再現性のある“同じレビュー”を回すのが難しかった。

0.44.0 で楽になった点

  • 入口が固定：起動画面に /review が見えている＝迷わず一手で開始できる。
    新メンバーにも教えやすい。
  • 標準動線化：/init /status /approvals /model と並列の“一等席”に配置されたことで、レビュー→適用までの定型運用を組みやすい。
  • 指示の省力化：/review 前提の挙動（作業ツリーや直近変更の走査、要点抽出、問題指摘）がテンプレ化され、毎回の長文プロンプトが不要。
  • チームでの再現性：コマンド名が共通語彙になり、スクリプトやカスタムプロンプトからも同じ入口で呼べる。

ミニ例（前→後）

  • 前：「git diff src/ を見て、重大度高めに指摘、修正案とテスト案も…」と毎回説明
  • 後：/review（必要なら severity="high" target=@src など軽い引数を添えるだけ）

要するに、“まず /review”という定番の始め方が確立し、余計な説明や手作業（差分貼り・モード切替）が要らなくなった、という改善です。

イベント／可観測性の拡充

0.44系ではイベント／可観測性が拡充され、CLI実行中に以下のような機械可読イベントが順次発火します。
添付の例はその一部です。

  • session.created：セッション開始（session_id付与）
  • turn.started：1ターンの処理開始
  • turn.completed：ターン完了（usage 内に input_tokens / cached_input_tokens / output_tokens を含む）
  • （失敗時）プロセスの終了コード=1でリターン

これにより：

  • コスト・トークン使用量の可視化（ターン単位・セッション単位）
  • 進捗トレース（開始→完了のライフサイクル把握）
  • 失敗検知の自動化（終了コードによるジョブ監視連携）

がしやすくなりました。

要するに、「どれだけ使って、どこで終わり／失敗したか」をイベントで外部ツールから追えるようになった、という強化です。

MCP連携の使い勝手向上

「MCP であいまい（ファジー）ファイル検索を標準機能として扱えるようにする拡張」の要点だけ、分かりやすくまとめます。

何が追加された？

  1. 新しいプロトコルメッセージ
  • クライアント → サーバーに送る ClientRequest::FuzzyFileSearch（検索語や件数などのパラメータ付き）
  • サーバー → クライアントは候補ファイルの一覧（パス・スコア等）で応答
  1. TypeScript の型エクスポート
  • 上記の新リクエスト／レスポンス型が TS でも利用可能に。
  • MCP クライアント／ツールを TS で書くときに型安全に実装できる。
  1. サーバー実装（codex-file-search の採用）
  • MCP サーバー側で codex-file-search ライブラリを使い、複数のルート（ルートディレクトリ）を横断してファジー検索を実行。
  • つまり、MCP 経由で“速いファイル候補出し”が標準化される。

👉 これにより、Codex CLI 側（MCPクライアント）はコマンドやプロンプト候補に加えて“ファイル名のあいまい候補”を同じUIで提示でき、ファイルへ即ジャンプしやすくなります。

どんな使い勝手の向上？

  • 検索一発で目的のファイルへ
    例）「find-todo」と叩く → find-todos.test.ts / find-todos.ts などが前方・部分一致で候補に並ぶ（添付のスクショの挙動）。
  • MCP ツールからも統一的に呼べる
    MCP クライアントは同じプロトコルでどの MCP サーバーにもファイル検索を依頼可能。
  • IDE拡張・CLI・クラウドのどこでも同じ操作感
    TS 型が用意されたので、拡張やツールが同じ型でやり取りでき、実装がブレにくい。

PR のレビューメモ（改善提案の意図）

  • Arc::new(...) の書き方統一：既に Arc を import 済みなら std::sync::Arc::new ではなく Arc::new を使う（可読性・一貫性）。
  • 決定論的な出力：複数ルートから集めた結果はソートして返すと、クライアント側の表示順が安定。
  • ハードコード値の回避：limit_per_root = 50 や threads = 2 は、CPU などから導出して可搬性・性能バランスを改善。
  • 依存関係のアルファベット順：Cargo.toml の 整頓（将来の差分が見やすい）。
  • serde のリネーム一貫性：#[serde(rename = "id")] などの命名規約を統一し、TS 側と齟齬をなくす。
  • PR 本文に動機・制限を書く：
    • 動機：「クライアントの素早いファイルナビゲーションをサーバー側検索で実現」
    • 制限・性能：大規模リポジトリでの最大候補数・スレッド数・応答時間などを明記

ざっくり擬似例（イメージ）

リクエスト（クライアント→サーバー）

{
  "type": "fuzzy_file_search",
  "params": { "query": "find-todo", "max_results": 50, "roots": ["src", "tests"] }
}

レスポンス（サーバー→クライアント）

{
  "type": "fuzzy_file_search.result",
  "files": [
    { "path": "src/extension/find-todos.ts", "score": 0.91 },
    { "path": "src/extension/find-todos.test.ts", "score": 0.88 }
  ]
}

実務インパクト（まとめ）

  • 探す→開くの時間が短縮（@ でのパス入力や長い手打ちが不要に）
  • MCP 経由なのでローカル・リモート問わず同じ手順で検索できる
  • TS 型とプロトコルが用意され、ツール作者も実装しやすい（バグ減・保守性UP）

必要なら、あなたの環境でMCP サーバーに codex-file-search を組み込む最小例（設定ファイルと起動スクリプト）を作ってお渡しします。

SDKまわりの拡充（TypeScript/Rust）

SDKまわりの拡充（TypeScript / Rust）とは？

開発者が“道具として使いやすくなった”アップデートです。ざっくり言うと—

  • 型が手厚く：リクエスト／イベント／使用量（usage）などの型が整理され、補完が効く・コンパイルで落ちるので安心。
  • 作業ディレクトリ指定：実行時に「どのフォルダをベースに動かすか」を明示でき、相対パスやツール呼び出しが安定。
  • サンドボックス指定：危険コマンドを隔離・制限する実行モードを選べて、PoC→本番で切替が楽。
  • Gitリポジトリ前提の緩和（例：skipGitRepoCheck）：素のフォルダでも試しやすく、スクリプト実行が軽快。
  • イベント・計測の整備：開始/完了やusageがイベントで取れるため、ログ基盤（例：OTel）に載せやすい。
  • MCP連携が素直に：HTTPストリーミングMCPなど新I/Fに型が追随。クライアント/サーバの実装が揃いやすい。

使い心地のイメージ

TypeScript（例）

import { CodexClient } from "@openai/codex";

const codex = new CodexClient({
  workdir: "/Users/you/projects/foo",  // 作業ディレクトリ
  sandbox: "restricted",               // サンドボックスモード
  skipGitRepoCheck: true               // Git前提をスキップ
});

const res = await codex.exec({
  command: "npm test",
  onEvent: (e) => {
    if (e.type === "turn.completed") {
      console.log("usage:", e.usage);  // input/output/cached tokens
    }
  }
});

Rust（例）

use codex_sdk::{Client, Sandbox, Events};

let mut cli = Client::new()
    .workdir("/home/you/foo")
    .sandbox(Sandbox::Restricted)
    .skip_git_repo_check(true);

cli.on_event(|ev| {
    if let Events::TurnCompleted { usage, .. } = ev {
        println!("usage: {:?}", usage);
    }
});

cli.exec("cargo test")?;

どちらも「どこで動かすか（workdir）／どれくらい縛るか（sandbox）／Git要件を外すか」をコードから即指定できる、という使い勝手の向上がキモです。
さらに、イベントで使用量を受け取りダッシュボードへ送る、といった運用が簡単になります。

ツール プログラミング ＡＩ
ChatGPT Codex Codex CLI Codex cloud GPT-5 GPT5 MCP
目次