Codex CLI 0.152.0｜Windowsの使い方と長時間作業の確認

Codex CLI 0.152.0で公式に確認できる変更

OpenAIのCodex公式リリースページでは、0.152.0が2026年9月1日に公開されています。今回の更新は、利用枠を確認する導線、MCPツールごとの出力上限、長いシェル操作の待ち時間といった新機能と、承認レビュー、会話履歴、Windows端末の修正に分けて読むと整理しやすくなります。公式ページの記載を根拠にし、版番号から性能・速度・互換性まで広げて判断しないことが出発点です（出典: https://github.com/openai/codex/releases/tag/rust-v0.152.0）。

新機能と修正を同じ効果と見なさない

利用枠バナーや output_token_limit、待ち時間の設定は、利用者が確認できる入口や条件を増やす新機能です。一方、Windowsのサンドボックスやターミナル照会、会話履歴の保持は、特定の場面で起きていた不整合を直す修正として記載されています。新機能が表示されたことと、修正対象の不具合が手元で再現しないことは、別の観察結果です。

たとえば、利用枠バナーを開けても短い作業が成功するとは限りません。逆に、短い読み取りが成功しても、長い出力の切り詰めやスレッド再開後の作業場所まで確認できたことにはなりません。確認項目を分けるほど、更新した理由と更新後に分かった範囲を正確に説明できます。

0.152.0の数字から言い過ぎない

リリース番号は、実行しているCodex CLIの版を特定するための情報です。数字が上がったことだけから、すべての処理が速くなった、Windowsの全端末が同じように動く、利用枠が増えた、と結論づけることはできません。利用しているモデル、接続先、作業場所、端末の種類が異なれば、観察結果も変わります。

公式ページで確認できる事実、手元で確認した表示、まだ試していない項目を別の欄に置きます。今回のリリース内容を自分の環境へ当てはめるときも、まず版番号と条件をそろえ、結果が出た範囲だけを採用します。

Windowsで最初に確認する順番

Windowsでの確認は、更新後の画面を眺めるだけでは足りません。更新前の版番号、実行ファイルの場所、PowerShellの種類を先に記録し、同じ確認を0.152.0で取り直します。公式リリースがMicrosoft Store版PowerShellや古いJediTermを名指ししているため、Windowsという一語で環境をまとめないことが重要です。

1. 更新前の版番号と実行場所を残す

まず、普段使うPowerShellで次の結果を保存します。Get-Command codex は、入力した codex がどの実行ファイルへ解決されたかを確認するためのものです。

codex --version
Get-Command codex
$PSVersionTable.PSEdition
$PSVersionTable.PSVersion

版番号は 0.152.0 のように省略せず、実行場所の表示も残します。複数の導入経路がある場合、同じ端末で入力しても別の実体が呼ばれることがあります。codex --version の値だけが変わり、Get-Command codex の場所が想定外なら、更新そのものより先に実行場所を確認します。

PSEdition と PSVersion は、Windows PowerShellとPowerShellの違いを記録する手がかりです。リリースページが示す「Microsoft Store版PowerShell」に該当するかは、これらの値だけで決めつけず、起動したアプリや導入元も記録します。確認した出典は https://github.com/openai/codex/releases/tag/rust-v0.152.0 です。

2. 更新後に同じ値を取り直す

更新後は、同じPowerShell、同じプロジェクト場所で4つの確認を繰り返します。版番号が0.152.0になっているか、実行ファイルの場所が意図したものか、PowerShellの種類が変わっていないかを見比べます。表示が変わらないときは、更新が失敗したと急いで決めず、別の codex が先に解決されていないかを調べます。

ここで確認するのは、版番号が表示されたという事実です。リリースに書かれたWindows修正がすべての端末で確認できた、という意味にはしません。版番号、端末、結果を同じ記録に残せば、後から別のPowerShellで試した結果とも比較できます。

3. 短い読み取りで実行を確認する

いきなり長い変更を依頼せず、戻しやすい練習用の場所で、ファイル名の確認や短い読み取りを行います。目的は、Codexが起動するか、対象場所を正しく見ているか、返答が終わるかを確かめることです。短い作業の成功は、長い作業の成功を保証しませんが、版番号や作業場所の取り違えを早く見つけられます。

ターミナル照会の停止を確認したい場合は、結果がすぐ返る読み取りを一つだけ選び、入力後に処理が戻るかを見ます。通信の遅延や別のプロセスの停止まで0.152.0の修正と決めつけないよう、実行したコマンド、開始時刻、終了時刻、表示された内容を残します。公式ページが示すのは修正項目であり、特定の端末での実測結果ではありません。

4. 古い端末表示は該当者だけを見る

古いJediTerm端末を使っていないなら、この項目は「対象外」と記録します。該当する端末では、下書き、カーソル、入力位置など、普段表示が崩れやすかった場面を短い入力で確認します。別の端末で表示が正常だったことを、古いJediTermの修正確認へ置き換えないことが大切です。

長時間の作業は4つの成功に分ける

長い作業では、「返答が表示された」「コマンドが終了した」「会話を再開できた」「正しい場所で結果を確認できた」が一つの出来事に見えます。しかし、0.152.0の公式記載は、ツール出力、待ち時間、会話履歴、作業ディレクトリを別々に扱っています。1時間を超える作業を本番の場所で無理に試す必要はありません。短い確認と設定の記録を組み合わせます。

output_token_limit は出力の上限として見る

0.152.0では、個別のMCPツールに output_token_limit を設定でき、スレッド再開後も出力の切り詰め方を一貫させる変更が入っています。これは、ツールが返せる内容の上限をツール単位で扱うための項目です。上限があることと、すべての出力が最後まで表示されることは同じではありません。

確認するときは、対象ツール名、設定された上限、実際に返った範囲、スレッド再開後の結果を分けて記録します。手元の設定画面や利用しているクライアントに項目が見えない場合は、推測で設定場所を補わず「未確認」とします。出力が短くなったときも、上限による切り詰めなのか、ツール側の結果なのか、通信途中の問題なのかを一つずつ切り分けます（出典: https://github.com/openai/codex/releases/tag/rust-v0.152.0）。

1時間を超える待ち時間は設定と実績を分ける

アプリサーバーのクライアントは、thread/shellCommand の待ち時間を設定でき、1時間を超える期限も扱えると公式ページに記載されています。ここから分かるのは、長い処理を待つための期限を設定できる範囲です。実際に処理がその時間内に終わること、端末や通信が待ち続けること、結果が正しいことまで保証する記載ではありません。

確認は、設定上の期限と実際の終了時刻を別の列に置きます。長時間の実測をする前に、短いシェル操作で開始と終了が記録できる状態を作り、長い作業は重要なファイルを避けた場所で試します。期限を延ばしたことで、処理の完了条件や内容の確認を省略しないようにします。

会話履歴と作業場所の復元を分ける

承認レビューについては、長いメッセージや大きな会話記録を保持する修正、履歴を整理した後も利用者の指示・回答・有効な許可情報を保つ修正が記載されています。これを確認するときは、会話の要点が残ったかと、ファイルの状態が残ったかを分けて見ます。履歴が見えることだけで、対象ファイルが更新されたとは判断しません。

また、再開したスレッドで作業場所を指定しなければ、保存済みの作業ディレクトリを復元する修正があります。再開後は、復元された場所の表示、対象ファイル名、作業前後の差分を順に確認します。意図した場所へ戻ったように見えても、別のファイルを対象にしていないかを読み直すことが必要です。

確認結果は、次のように4項目へ分けると明確です。

1. 出力: output_token_limit の範囲と切り詰めの有無。
2. 待ち時間: 設定された期限と実際の終了時刻。
3. 会話: 再開後に指示・回答・許可情報が必要な範囲で残ったか。
4. 作業場所: 復元されたディレクトリと対象ファイルが一致したか。

利用枠の表示は作業成功と別に読む

0.152.0では、利用枠に達したときなどに表示されるバナーから、使用状況、クレジット、リセット、プランを確認する操作が案内されます。確認しやすくなったのは情報への入口であり、表示された残量が次の作業の完了を保証するわけではありません。利用枠の表示と、実際の作業結果を同じ判定欄へ入れないようにします。

4つの欄だけ先に記録する

更新前後で、次の4つを同じ形式で残します。

• 確認日時: 2026年9月2日（日本時間）など、読んだ時点。
• 表示: 利用状況、クレジット、リセット、プランに何が表示されたか。
• 作業: 同じ短い読み取りが完了したか、どんな結果だったか。
• 判断: 利用枠、版、端末、作業結果のどこまで確認できたか。

「残量があるから長い作業も成功する」「バナーが出ないから利用枠に問題はない」といった読み方は避けます。表示が出たかどうか、数字が読めたかどうか、短い作業が完了したかどうかを別にすると、表示の遅れや別の原因を切り分けやすくなります。詳細は公式リリース https://github.com/openai/codex/releases/tag/rust-v0.152.0 で確認できます。

使っていない項目は未確認のまま残す

利用枠の全項目が表示されない、契約や利用入口によって表示が異なる、作業中にリセット時刻が変わるといった場合は、見えた範囲だけを記録します。契約条件や利用可能量を、0.152.0の版番号から推測しません。画面の表示、公式ページの記載、手元の作業結果の3種類を混ぜないことが重要です。

Copilot・Cursor・AiderをCodexへ読み替えない

同じ時期にAIコーディング製品の更新が続いていても、製品ごとの機能は別に確認します。今回の主題では、Codex 0.152.0のWindows・長時間作業の確認を中心にし、周辺情報は製品固有の案内として短く扱います。

Copilotの承認プレビューは別製品の機能

GitHub Copilotのコードレビューには、プルリクエストが承認できる状態かどうかを概要コメントに表示する評価と、管理者が許可した場合にCopilotが承認を提出できる公開プレビューが案内されています。承認提出は初期状態で無効です。評価だけでは必須承認数に算入されず、有効にした承認が条件へ算入される点も分けて読みます。

管理者はエンタープライズ、組織、リポジトリの単位で設定でき、リポジトリではCopilotが承認できるファイルパスも選べます。新しいコミットが入った後は、Copilotの承認が人による承認と同じように無効になり、改めてレビューを依頼する必要があります。これはCodex CLIの承認や会話再開の仕様ではありません（出典: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/）。

CursorとAiderは公式更新欄を別に見る

Cursorの公式Changelogでは、2026年8月27日付の更新として、リポジトリを接続せずに始めるCloud Agentsやブラウザーでのプレビューなどが案内されています。一方、今回の記事で扱う0.152.0のWindows修正やMCP出力上限へ直接つなげる情報ではありません。Cursorの更新は https://cursor.com/changelog で製品固有の条件を確認します。

Aiderについても、公式リリース欄の版情報をCodexの変更と混ぜません。今回の主題へ追加する新規内容は採用せず、必要な場合は https://github.com/Aider-AI/aider/releases を直接確認します。別製品の更新が見つかったことと、CodexのWindows動作が変わったことは、別の事実として扱います。

更新後の確認表を作る

確認結果は、版番号だけを残すより、入口、端末、表示、作業結果を一行で結び付けると役立ちます。次の表をコピーし、公式情報、手元で見たこと、まだ試していないことを分けて埋めます。作業を実施していない項目は、成功や失敗ではなく「未確認」と書きます。

公式記載・手元結果・未確認を分ける

表の「手元の判定」は、次の3種類で書くと誤解が減ります。

1. 公式記載: リリースページに明記された変更。自分の端末で試していない場合も含めます。
2. 手元結果: 版番号、PowerShell、端末、表示、短い作業、再開結果を実際に確認した内容。
3. 未確認: 設定場所が分からない、該当端末を使っていない、長い作業をまだ試していない項目。

「公式記載あり」と「手元で成功」は同じ欄へまとめません。更新直後に確認できない項目があっても、未確認として残せば、次に同じ条件で試すときの出発点になります。

採用判断は最小の確認から始める

日常利用へ戻すかを決めるときは、まず版番号と実行場所、次に短い読み取り、最後に必要な長い作業の順で確認します。MCPツールを使わない人は output_token_limit を無理に検証せず、該当なしと記録します。古いJediTermを使わない人も同じです。対象のない項目を成功扱いにしないことが、表の精度を保ちます。

長い作業を試す場合は、作業場所、対象ファイル、戻し方を先に決め、出力・待ち時間・会話・作業場所の4項目を別々に判定します。どれか一つだけ確認できた場合は、確認できた項目だけを採用し、残りは未確認として次へ送ります。

既存のWindows記事と今回の違い

Codexer Naviには、WindowsへCLI・アプリ・WSL2を導入する手順をまとめた CodexインストールWindows版の記事 と、WindowsでCodexが動く入口を整理した CodexはWindowsで動くかの記事 があります。これらは導入経路や初回起動を知りたいときの資料です。

今回の記事は、0.152.0へ更新した後に、すでに使えているWindows環境をどう確認するかに焦点を置きます。PowerShellの種類、実行ファイルの場所、ターミナル表示、利用枠、MCPツールの出力、長い待ち時間、会話再開、作業場所を一つの成功にまとめません。一般的な更新手順を知りたい場合は Codexのバージョン更新方法 も参照できますが、今回の版固有の修正は公式リリースページで確認してください。

導入記事に書かれたコマンドが使えたことは、0.152.0の修正を検証したこととは別です。既存記事から導入の前提を確認し、このページでは更新前後の差分と、手元の確認結果を記録する、と役割を分けると同じ説明を繰り返さずに済みます。

まとめ

Codex CLI 0.152.0の公式リリースには、利用枠バナー、個別MCPツールの output_token_limit、1時間を超える期限を含む thread/shellCommand の待ち時間設定が記載されています。承認レビューの長いメッセージや履歴の保持、履歴整理後の指示・回答・有効な許可情報の保持、再開時の作業ディレクトリ復元も修正項目です。Windowsでは、Microsoft Store版PowerShell、ターミナル照会、古いJediTerm端末に関する修正が示されています（出典: https://github.com/openai/codex/releases/tag/rust-v0.152.0）。

確認するときは、更新前の版番号と実行場所を残し、0.152.0で同じ情報を取り直します。短い読み取りを挟んだうえで、必要な人だけが長い作業を試し、出力、待ち時間、会話、作業場所を別々に判定します。利用枠の表示が読めたことや、返答が表示されたことだけで作業成功とはしません。

Copilotの承認プレビュー、Cursor、Aiderの更新情報は、それぞれの公式ページで確認する製品固有の情報です。Codexへ読み替えず、公式記載、手元結果、未確認の3欄を保ったまま、日常利用へ戻すか追加確認するかを判断してください。