OpenAI Codex 0.160.0、エージェントの主機能を信頼性に置く

OpenAI Codex 0.160.0は4つの新機能と6群の修正を伴って登場したが、真の変化は見た目ではなく運用面にある。2026年10月1日にリリースされたこのアップデートにより、継続中のエージェントセッションを見つけ、再開し、監督し、中断後に復旧することが容易になる。

この焦点は示唆的な対比を生む。コーディングエージェントはしばしば、単一のタスク中に生成したコードで評価される。OpenAIは現在、履歴、権限、引き継ぎ、接続復旧、環境設定を含め、そのタスクを取り巻くあらゆる要素に重点的に投資している。

主な競争は、もはやCodexとClaude Code、GitHub Copilot、あるいは別のコーディング支援ツールの間だけではない。すべてのセッションが白紙から始まり、失敗が孤立したままの使い捨てチャットモデルに対する、永続的なエージェント運用との競争である。バージョン0.160.0は、OpenAIが開発者にエージェント作業を永続する運用状態として扱ってほしいと考えていることを示している。

OpenAI Codex 0.160.0で実際に変わること

このアップデートは、これまで見えにくかった障害点のいくつかを、Codexワークフローで管理できる要素へと変える。

公式の0.160.0リリースでは、変更点が新機能、バグ修正、ドキュメント、保守作業に分けられている。主な追加項目は、タスク履歴、Linuxでのターミナル操作、プロジェクト不要のセッション、オプションのGuardianレビューコンテキストだ。

タスク履歴には、特に目立つ変更が加えられた。エージェントのコマンドセンターでは以前、最近のセッションが10件しか読み込まれず、過去の作業へ直接たどる手段はなかった。新たにキーボード操作可能な「Show more」行が加わり、リクエストごとに最大10件の追加タスクを見つけられるようになった。

これは単なるリストへのページネーション追加ではない。Codexは異なる履歴ソースごとにカーソルとバッファ済み結果を保持し、インタラクティブと非インタラクティブのセッションを新しい順に統合する。

また、後続のリクエストが失敗しても、インターフェースは既存の結果を保持する。タスクがアーカイブまたは削除された後には空いた位置を補充し、削除済みタスクを復元してしまう古い更新を防ぐ。履歴が便利なメニューではなく運用記録になると、こうした詳細が重要になる。

Linuxユーザーには、別の操作修正も提供される。対応するローカルX11ターミナルのフルスクリーンモードでは、ユーザーはトランスクリプトのテキストを選択し、中クリックでプライマリ選択から貼り付けられる。この動作により、Codexは確立されたターミナルの慣習に近づく。

プロジェクト不要のセッションには、より重要な更新が加わる。ローカル設定と管理ポリシーが許可する場合に限り、Codexは認識済みプロジェクトの外でもワークスペースの既定値を使って作業を開始できる。

再開したタスクは、ユーザーが明示的に上書きしない限り、保存済みの権限プロファイルを復元できる。通常のターンでサーバーに保存されたプロファイルを書き換えるべきではない。明示的な承認レビューの選択は、復元されたタスク権限とは別に維持される。

このリリースでは、提案されたエージェント操作を評価する自動レビュー層Guardianも拡張された。2つのオプション機能により、Guardianは過去のユーザー指示を取得し、エージェントの引き継ぎから選択されたコンテキストを受け取れる。

Guardianへの追加はいずれもデフォルトで無効だ。この区別は重要である。なぜなら変更によって、操作レビュー時に利用できるコンテキストが拡張されるためだ。OpenAIはこれらを、すべてのセッションにひそかに適用される普遍的な挙動ではなく、制御可能な安全機能として提示している。

バグ修正も同じテーマを補強する。Codexは、確実ではない送信を無条件に再送することなく、再接続後にキュー済みメッセージを再開できる。より多くのターミナル設定を保持し、複数のWindowsサンドボックスパスを修復し、サブエージェントの環境継承を改善した。

OpenAIは、SQLiteの停止、誤解を招く初期化タイムアウト、古いプロバイダーカタログ、繰り返されるプラグイン解析、未使用のログデータベース領域にも対応した。これらの変更はモデルの見かけの知性を変えるものではない。エージェントワークフローが混乱したり、一貫性を失ったりする経路を減らすものだ。

このリリースが重要なのはそのためである。エージェントを取り巻くシステムを、ユーザーが我慢すべき配管ではなく、製品の一部として扱っている。

古いタスクがコマンドセンターを運用記録に変える

検索可能で拡張できる履歴により、Codexは一連のプロンプトから記憶を持つワークスペースへと変わる。

このアップデート以前、コマンドセンターが読み込む最近のセッションは10件だった。ユーザーはインターフェースが読み込んだ範囲内で検索できたが、さらに古いタスク履歴へ遡り続ける直接的な方法はなかった。

新しいタスクページネーションの設計では、選択可能な「Show more」行が追加される。検索中も利用でき、キーボード操作向けに設計された読み込み状態と再試行状態も含まれる。

10件ずつの増分は小さく聞こえる。重要なのは、OpenAIが増え続ける履歴のために、その周辺の状態管理を設計した点だ。

Codexはソースごとにカーソルを保存し、リクエスト間で結果をバッファリングする。単一の統合ソースを前提とせず、異なるセッション種別を新しい順に統合する。リクエストが失敗した場合でも、すでに読み込まれたタスクは表示されたままになる。

この挙動は一般的な開発状況を支える。新たなバグによって関連する症状が明らかになった後、ユーザーは数日前の調査に戻る必要があるかもしれない。更新失敗時に過去の行が消えてしまえば、履歴は信頼できない索引になってしまう。

このアップデートでは、通常の詳細更新を、最近のスレッド、読み込まれたスレッド、または明示的に要求されたスレッドに限定している。この選択は、表示対象のタスク集合が拡大した際のバックグラウンド作業を抑制する。OpenAIが履歴コレクションの規模が実質的に大きくなることを見込んでいることを示す。

永続的な履歴は、より単純なアシスタントで使われる使い捨てセッションモデルに負荷をかける。短命なアシスタントは、現在のプロンプトに答えるだけでよい。永続的なエージェントは、時間をまたいでアイデンティティ、順序、設定、権限を維持しなければならない。

この違いは、ユーザーの期待を変える。タスクがコマンドセンターに表示されると、それはチャットのトランスクリプトというより作業項目に似始める。ユーザーはそれを見つけ、再開し、フォークし、現在の状態を理解できることを期待する。

チームにとっても、推論と実装コンテキストを回復するための道筋がより明確になる。タスクは後から加えられた修正を含め、パッチを生み出した一連の流れを保持できる。これは、仕様、意思決定、ローカルの技術文書を収めた検索可能なナレッジベースを補完できる。

履歴には依然として限界がある。ページネーションは、セマンティック検索、プロジェクトレポーティング、正式な監査ログと同じものではない。このリリースは、それらのシステムを提供すると主張してはいない。

また、コマンドセンターは、誤った同一視を生まない形で混在するタスクソースを表現する必要がある。インタラクティブなローカルセッションには、リモート実行タスクとは異なる前提がありうる。まとめて並べ替えることは発見を助けるが、そうした違いを消すわけではない。

OpenAIの実装は、ソースごとのカーソルと統合された順序付けによって、この複雑さを認識している。また、古いリクエストによって削除済みタスクが戻されないようにもしており、これは微妙だが重要な一貫性のルールだ。

これにより、セッション履歴は共有インフラとして位置付けられる。再開、フォーク、検索、削除、アーカイブはすべて、同じ記録が予測可能に振る舞うことに依存する。

Claude CodeとGitHub Copilotも、インターフェースが異なる場合であっても、同じ幅広い製品上の圧力に直面している。コーディング支援ツールがより長い割り当てを担うようになれば、ユーザーは孤立した会話ウィンドウではなく、永続的な履歴を求めるだろう。

したがって競争上の問いは、最も長いリストを表示できるのは誰かではない。古いエージェント作業を再利用できるほど信頼できるものにできる製品はどれか、である。

OpenAIにとって、「Show more」は目に見える操作だ。より大きな動きは、エージェント履歴にも他の開発者システムと同じ慎重な状態管理が必要であると受け入れたことにある。

再接続の修正が最も高コストな曖昧さに対処する

コーディングエージェントは、失敗した作業と、状態が単に不明な作業を区別しなければならない。

ネットワークの中断は、状態を持つあらゆるエージェントにとって難しい問題を生む。クライアントはメッセージ送信後、確認を受け取る前に接続を失う可能性がある。そのメッセージを再送すれば操作が重複するかもしれず、破棄すれば依頼された作業を放棄することになるかもしれない。

OpenAIの再接続修正は、未送信メッセージと、配信確認なしに送信されたメッセージを分ける。Codexは、復元された履歴、バッファ済みイベント、後から届く受領情報に含まれる正確なクライアントメッセージ識別子を用いて、プロンプトと操作指示メッセージを照合する。

確認済みの送信は、復旧したキューから取り除かれる。一度も送られていないメッセージは、リプレイ後に再開できる。不確実な送信は、再送されるのではなく停止状態のままになる。

インターフェースは、配信確認できなかったメッセージも示す。これによりユーザーは、一般的な接続警告ではなく、解決すべき具体的な曖昧さを把握できる。

この区別が重要なのは、エージェントのプロンプトが副作用を引き起こしうるためだ。繰り返された依頼は、同じファイルを二度編集したり、外部操作を再び呼び出したり、最初の処理が成功した後に二つ目の結果を作ったりする可能性がある。

従来のチャットクライアントは、重複するテキストを許容できることが多い。エージェントシステムは、反復が無害だと仮定できない。そのメッセージは、会話だけでなく操作に対応する可能性がある。

OpenAIは、利用できない会話、保留中のコンパクションまたはレビューリクエスト、既存の復旧失敗については停止を維持した。言い換えれば、自動再開はクライアントが安全な状態を確立できる場合にのみ適用される。

これは、冪等性に関する圧力の実践例だ。冪等性とは、操作を繰り返しても一度だけ実行した場合と同じ効果になることを意味する。多くのエージェント操作は自然には冪等ではないため、クライアントは不用意なリプレイを避けなければならない。

このリリースは、あらゆる障害条件下で完璧な復旧を実現すると主張してはいない。履歴の欠落や確認の遅延によって、送信が不確実なままになることは依然としてある。より安全な挙動は、その不確実性を表に出すことだ。

この選択は、永続的なエージェントにおける中心的なトレードオフを示している。自動化を増やせば摩擦は減るかもしれないが、システムに十分な証拠がない場合、自動復旧はリスクを生む。

OpenAIはこの特定のトレードオフを、送信済みではなく、送信されていないと判明している入力だけを再開することで解決している。曖昧なケースは停止し、ユーザーに確認を求める。これは無条件のリプレイより滑らかではないが、重複実行を防ぐ。

同じ原則は、OpenAI Codex 0.160.0の他の箇所にも現れる。プロジェクト不要のセッションがワークスペース既定値を受け取るのは、ポリシーが許可する場合だけだ。Guardianが追加コンテキストを受け取るのも、オプション機能を通じてのみである。サブエージェントは、環境が準備済みであるかのように扱うのではなく、保留中の環境を保持する。

これらの変更は、楽観的な仮定よりも明示的な状態を優先する。このアプローチは保守的に感じられるかもしれないが、エージェントがより長い連続操作と、より重大なツールを扱うようになるほど価値を増す。

ターミナルUIでは、サーバープロバイダー、推論要約、詳細度の設定も保持される。再開とフォークの履歴では、正しいモデルプロバイダー検索が使われるようになった。これらの修正により、復旧したセッションが異なる設定をひそかに使用しながら、同等であるかのように見えることを防ぐ。

個々の開発者にとっての利点は継続性だ。接続の中断によって、キュー済みの作業が消えたり、依頼が重複したりするべきではない。

エンタープライズユーザーにとって、その重要性はさらに大きい。特にエージェントがリポジトリを変更したり、接続済みサービスと連携したりできる場合、不確実な送信は説明責任を複雑にする。復旧可能な状態は、意図と証拠の両方を保持しなければならない。

ここで、永続的なエージェント運用が使い捨てのチャットに対して優位性を得る。使い捨てのセッションは、単に失敗すればよい。耐久性のあるシステムには、何が起きたのかを説明し、有効なものを保持し、確実性が尽きる地点で停止することが求められる。

Guardianはコンテキストを得るが、コンテキストの増加が自動的に安全性を意味するわけではない

Guardianはユーザーの意図をより多く確認できるようになったが、レビューの品質は依然としてコンテキストの選択と現在のポリシーに左右される。

自動レビューアーが評価できるのは、受け取った証拠だけである。エージェントが長い会話の後に操作を提案する場合、最新のトランスクリプト断片には、その操作を当初許可した指示が含まれていない可能性がある。

新たに追加された任意の履歴取得機能は、この隔たりに対処する。Appsと併用して有効にすると、Guardianは親セッションのライブ接続と会話IDを通じ、過去のユーザーメッセージを検索・読み取りできる。

想定されているケースは明確だ。切り詰められたトランスクリプトでは、以前の指示、制約、または取り消された権限が欠落する可能性がある。副作用を伴う操作を承認する前に、Guardianは関連する履歴を必要とする。

実装では、呼び出しのたびに親の現在のAppsおよびツールのポリシーを再確認する。無効化されたツールは引き続き利用できず、承認が必要な呼び出しは拒否される。過去のコンテキストによって、以前利用できたツールが恒久的に許可されることはない。

OpenAIはまた、ユーザーによる許可とアシスタントが生成したコンテキストを区別するようレビューアーに指示している。これにより、以前のアシスタントの発言がユーザーの許可と同等に扱われることを防ぐ。

後からの撤回も重要だ。ユーザーが以前に操作を許可した後でその許可を取り消した場合、レビューでは最新の指示が優先されるべきである。取得設計では、不完全な結果と変化する許可の両方を明示的に考慮している。

履歴レスポンスの推定デフォルト上限は4,000トークンである。管理者はこの上限を設定できるが、より厳しい親またはレビューアー側の上限は引き続き適用される。

2つ目の任意機能は、エージェントの引き継ぎに関するルートコンテキストを選択する。関連する各引き継ぎについて、Guardianは直前のルートメッセージ3件を受け取れる。また、直近のキャンセルが見えるよう、最新のルートメッセージ3件も受け取れる。

これは、親エージェントがサブエージェントに作業を委任する場合に役立つ。子エージェントのローカルなトランスクリプトには割り当てられた作業は説明されていても、その作業を許容できるものにした、より広範な許可が省かれている可能性がある。

ただし、追加のコンテキストは完全な理解と同義ではない。取得によって関連する文言を見落とすことがあり、選択された引き継ぎウィンドウでは、その境界の外にある指示が除外される可能性がある。より大きなトランスクリプトには、相反する要求が含まれることもある。

この機能はデフォルトで無効のままであり、直ちに露出が広がることを抑えている。この状態は同時に、ユーザーがすべてのGuardianレビューで会話履歴全体が参照されると想定すべきではないことも意味する。

プライバシーとデータの取り扱いには注意が必要だ。オプションを有効にすると、実装は親のライブApps接続と会話IDを利用する。組織は、どのメッセージがレビュー経路で利用可能になるのかを理解しておくべきである。

レビューシステムは、許可とタスクのコンテキストの区別も維持する。この境界は不可欠だ。エージェントがタスクを受け取った理由を知ることは、エージェントが選択し得るあらゆる操作を自動的に許可するものではない。

これが今回のリリースにおける中心的なトレードオフである。永続的なエージェントには危険な誤解を避けるためにより多くのコンテキストが必要だが、広範なコンテキストはレビューアーが正しく扱うべき情報を増やす。

OpenAIの安全策は、いくつかの明白な失敗モードに対処している。ライブのポリシーチェック、メッセージ上限、無効がデフォルトであること、撤回への対応、明示的な拡張レジストリを持つセッションに関する分離ルールなどが含まれる。

それでも、公開プルリクエストが示すのは実装の説明とテスト範囲であり、実運用でのレビュー精度に関する独立した証拠ではない。ユーザーはGuardianを、範囲を限定した権限設定や人による確認の代替として扱うべきではない。

この機能は、多層防御として理解するのが最適である。レビューアーが関連する証拠を見つける助けにはなるが、曖昧な許可すべてが正しく解釈されることを保証するものではない。

この不確実性は導入方針に反映されるべきだ。チームは制御されたワークフローでこの機能を有効にし、レビューの挙動を検証し、重要な操作については明示的な承認の背後に置き続けられる。

プロジェクトなしのセッションは、ポリシーを捨てずにアクセスを拡張する

Codexは正式なプロジェクトの外でもより簡単に開始できるようになったが、権限チェックは引き続き制御境界として維持される。

コーディング作業は、常にリポジトリ内で始まるわけではない。開発者は設定ディレクトリ、一時エクスポート、ログ、生成ファイル、まだプロジェクト化されていないフォルダを調査する。

こうした状況では、従来のプロジェクト前提が摩擦を生むことがあった。OpenAI Codex 0.160.0では、ローカル実行、設定、管理ポリシーが許可する場合にワークスペースのデフォルトを使用する、プロジェクトなしのターミナルセッションが導入された。

実装では、保存済みの信頼判断がないローカル検出のプロジェクトなしディレクトリについて、フォルダ信頼の確認を省略できる。ワークスペース書き込み権限と詳細な承認デフォルトは、関連ポリシーが許可する場合にのみ適用される。

Windowsには追加の安全策が導入される。Codexは、暗黙的なワークスペース書き込み権限を有効にする前に、必要に応じてサンドボックスのセットアップを促す。

この更新では、ユーザーが明示的に上書きしない限り、再開時に保存済みのタスク権限も復元する。これにより、再開したタスクが異なる権限プロファイルでひそかに戻ることを防ぐ。

通常の会話ターンでサーバーの保存済みプロファイルが上書きされるべきではない。承認レビューアーを通じて行われた明示的な選択は、引き続き別途追跡される。この分離により、永続的なタスクポリシーが意図せず変更されるリスクを抑える。

ディレクトリ変更も同様に扱われる。/cdコマンドはフォルダ信頼を求め、「現在のディレクトリを維持」という選択肢を提示できる。Codexは場所を切り替える前に、タスクの活動状況とバックグラウンドターミナルを再確認する。

また、移動先に対する権限要件も適用する。そのため、ディレクトリ変更は単なるパス更新ではなく、ポリシー遷移であり続ける。

直接的な利点は柔軟性だ。開発者は、認識されるプロジェクト構造にまず整理しなくても、まとまりのないファイル群を起点に調査を開始できる。

より広い意味合いは、ワークスペースのアイデンティティに関わる。エージェントがリポジトリ外で動作できるなら、プロジェクト境界だけで信頼、保存、権限に関するすべての前提を担うことはできない。

その結果、明示的なポリシーへの依存が高まる。ワークスペースのデフォルト、保存済みタスクプロファイル、ディレクトリ信頼、サンドボックスの準備状況が、許可された振る舞いを定義する仕組みになる。

この更新は同意をなくすものではない。同意がどこで表現されるか、そしてCodexがいつ安全なデフォルトを推論できるかを変えるものだ。

この違いは、OpenAI CodexをClaude CodeやGitHub Copilotのワークフローと比較するユーザーにとって重要である。再開、ディレクトリ切り替え、権限復元が予測可能な結果を生む場合に限り、柔軟な開始点は有用となる。

プロジェクトなしの運用は、より多くのナレッジワークにエージェント利用を広げる可能性もある。技術調査では、ソースコードと仕様、ログ、会議メモ、生成レポートを組み合わせることが多い。

開発者はknowledge blendingを通じてそのコンテキストを統合し、得られた証拠全体にまたがる作業をエージェントに依頼できる。これらのソースに機密資料が含まれる場合、権限境界は明確に保たれなければならない。

懐疑的な見方は単純である。デフォルトは摩擦を減らす一方で、権限の変更を見えにくくする可能性がある。ユーザーは「ポリシーで許可されていること」と「この特定のタスクにとって安全であること」を混同するかもしれない。

OpenAIは、保存済み権限と明示的なレビューアー選択を分離することで、このリスクに部分的に対処している。また、移動先に別の信頼判断が必要な場合は、ディレクトリに関する同意も維持する。

リリースノートには、導入データやエンタープライズでのインシデント結果は示されていない。すべての環境で、プロジェクトなしのセッションがリポジトリに紐付いたセッションより安全だと主張する根拠はない。

意味のある変化は、より限定的である。Codexはポリシーモデルを放棄せず、より多くの場所で作業を開始できるようになった。組織がこのバランスを受け入れるかどうかは、管理設定と監査要件に依存する。

信頼性戦略が機能しているかを示す3つのシグナル

次の試金石は、これらの状態管理の改善が実際のワークロードの下でも理解しやすいままであるかどうかだ。

最初のシグナルは、Guardianの任意コンテキスト機能の導入状況である。OpenAIは、ユーザーが会話履歴の取得と引き継ぎを考慮したレビューを継続的なワークフローで有効にするかを注視すべきだ。

混乱を招く承認の増加を伴わずに導入が進めば、コンテキスト戦略の信頼性は高まる。チームがオプションを無効のままにするなら、追加機能の統制が難しすぎる可能性がある。

最も有用な証拠は、誤った承認、不必要なブロック、見逃された撤回、レビューアーの遅延を示すものだろう。機能フラグだけでは、Guardianが取得した指示を正しく解釈しているかは分からない。

2つ目のシグナルは、不安定な接続中の復旧動作である。新しいキューロジックは、未送信メッセージと状態が不確かな送信済みリクエストを区別する。実際のセッションでは、長時間タスク、複数デバイス、遅延したサーバー受信確認を通じて、その区別が試される。

重複操作が減れば、OpenAIの永続的ワークスペースという主張は強まる。停止が自動再送より安全であるとしても、不確実性に関する通知が頻発すれば、その主張は弱まる。

ユーザーは、今後のリリースが同じ照合モデルをより多くのイベント種別に適用するかも確認すべきだ。エージェントシステムは、通常のプロンプトを超えて、ツール呼び出し、レビュー、引き継ぎ、環境変更、ターミナル出力を生み出す。

3つ目のシグナルは、コマンドセンターの履歴がより広範なタスク管理の基盤になるかどうかだ。ページネーションは古いセッションへのアクセスを解決するが、長期的な導入は、より強力な検索と整理への需要を生む。

有用な次の段階には、より充実したフィルター、明確なタスク状態、永続的なラベル、セッションと結果としてのコード変更を結ぶより良いリンクなどが含まれ得る。これらは発表済みの機能ではないため、約束ではなく観測点にとどまる。

同じシグナルは競合他社にも当てはまる。他のコーディングエージェントが再開可能なタスク、権限の継続性、回復可能な状態を重視するなら、市場は永続的な運用を中核的な製品カテゴリーとして評価していることになる。

OpenAIの次のリリースでは、このアーキテクチャがサブエージェントにどこまで広がるかも明らかになるはずだ。バージョン0.160.0では、子エージェントの起動時にまだ開始中の環境がすでに保持される。

子エージェントは、その環境を失うのではなく、元の環境に後から加わった設定または失敗を受け取る。保留中の設定待機も、executorの再試行をまたいで存続できる。

これにより、タイミングによって操作の結果が変わる競合状態が減少する。準備が完了していないというだけで、少し早く開始した子エージェントが異なる環境を受け取るべきではない。

この方向性はリリース全体で一貫している。古いセッションは引き続き見つけられる。キュー内のメッセージは再接続後も残る。再開したタスクには権限が戻る。Guardianは関連する許可コンテキストを回復できる。サブエージェントは、まだ準備中の環境を保持する。

これらの変更はいずれも、生成されるコードの品質向上を保証するものではない。しかし総合すると、ユーザーがコード生成を取り巻くプロセスを信頼できるかどうかに対処している。

そのプロセスが競争の舞台になりつつある。モデル品質は依然として重要だが、持続的なエージェント作業は、復旧、権限境界、コンテキストの来歴、可視化された不確実性にも依存する。

したがって、OpenAI Codex 0.160.0は劇的な能力リリースではない。エージェントを使い捨てのプロンプト応答者ではなく、永続的な協働者として振る舞わせることを目指すインフラストラクチャリリースである。

開発者は、このアップデートを最も整理されていないワークフローで試すべきだ。古いタスクを再開し、接続を中断し、リポジトリ外で開始して、どの権限が復元されるかを確認する。

コーディングエージェントを評価するチームは、率直に問うべきである。中断後に、何が維持され、何が変わり、何がなお不確実なのかをシステムは説明できるのか。

実際の作業環境でも答えが明確なら、OpenAIの信頼性戦略は成功している。ユーザーが状態を手作業で再構築しなければならないなら、コマンドセンターは脆弱なセッションを洗練された形で表示しているにすぎない。