Codex右側パネルでPRレビューを確認する手順と差分の見方

Codex右側パネルとは何か

「Codex 右側」と検索すると、画面の右端にあるボタン、サイドバー、レビュー欄のどれを指しているのかが曖昧になりがちです。Codexには、作業を始める入口、会話や作業を選ぶ履歴欄、差分を確認する領域、レビューの指摘を読む領域があります。これらは同じ画面に並ぶことがありますが、役割は同一ではありません。右側パネルを理解するには、画面の位置よりも、そこに何の情報が出ているかを先に見るのが近道です。

OpenAIの公式発表で使われている表現は「side panel」で、プルリクエストレビューを表示する場所として説明されています。したがって、すべての画面で常に同じ幅や同じ名称の欄が出ると決めつけるのは適切ではありません。アプリの更新、表示している作業、選択したプロジェクトによって、入口やラベルが変わることがあります。この記事では、公式に案内された役割を日本語で「右側パネル」と呼び、場所の細部ではなく確認の考え方を扱います。

右側パネルと履歴欄を分けて考える

履歴欄は、過去のCodexチャットや作業を探し、続きから開くための場所です。一方、右側パネルは、いま開いているレビューや差分の内容を読むための場所として理解すると混乱しません。チャットをアーカイブすると履歴欄から隠せますが、レビュー中の差分そのものを承認したり、修正を取り込んだりする操作とは別です。履歴が見えない問題と、レビュー欄が出ない問題を同じ原因として扱わないことが大切です。

OpenAIヘルプでは、Codexチャットを履歴のサイドバーからアーカイブでき、削除する場合はアーカイブ済みのチャットを設定画面から選ぶ流れが案内されています。削除したチャットは復元できないと説明されているため、整理操作をする前に、必要な会話がアーカイブ状態なのか、いま開いている作業とは別の履歴なのかを確かめます。参照先は https://help.openai.com/en/articles/20001333-how-to-archive-and-delete-codex-chats-in-the-chatgpt-app です。

差分内編集がレビューと相性よい理由

レビューで重要なのは、指摘を読んだあとに、どの行のどの変更が問題なのかを確かめることです。文章だけの指摘を別画面で読み、リポジトリへ戻って変更を探すと、対象を取り違えたり、修正前の状態を見たりしやすくなります。差分の中で編集できる導線があると、指摘、変更箇所、修正後の表示を同じ文脈で追いやすくなります。

ただし、差分内で編集できることは、その変更が正しいと保証するものではありません。編集は提案を反映する一手段であり、レビューの根拠を読んだり、テスト結果を確かめたり、変更範囲を見直したりする作業は残ります。右側パネルを便利な編集欄としてだけ使わず、「なぜ直すのか」と「直した結果を何で確認するのか」をセットで扱うと、見た目だけの修正を取り込みにくくなります。

2026年7月のデスクトップ統合で何が変わったか

2026年7月9日のOpenAI発表では、新しいChatGPTデスクトップアプリにCodexアプリが統合され、Codexは開発者や技術職向けのコーディングエージェントとして引き続き提供されると説明されています。そのうえで、差分内編集、サイドパネルでのプルリクエストレビュー、GPT-5.6を使ったコンピューター操作の高速化、ひとつのプロジェクトで複数リポジトリを扱う対応が更新点として挙げられました。出典URLは https://openai.com/index/chatgpt-for-your-most-ambitious-work/ です。

この発表を読むときは、Codexの役割が別製品に置き換わったと考えるのではなく、デスクトップの入口と確認画面がまとまったと読むのが分かりやすいでしょう。既存の作業を開く場所、差分を読む場所、プルリクエストのレビューを見る場所が同じデスクトップアプリ内で近づいたため、画面を往復する負担が減る可能性があります。一方、利用できる機能や表示は契約、地域、アプリ版、作業の種類に左右されるため、公式発表の内容と自分の画面を分けて確認します。

デスクトップ統合が意味すること

Codexアプリの利用者が新しいChatGPTデスクトップアプリへ移行する場合、以前のCodexだけを起動するという感覚から、ChatGPT、Work、Codexの入口を同じアプリで選ぶ感覚へ変わります。ここで大事なのは、名前が一つにまとまったことと、すべての作業が同じ場所で処理されることは別だという点です。ローカルのファイルを扱う作業、GitHub上のプルリクエストを読む作業、過去のチャットを探す作業には、対象と権限の違いがあります。

右側パネルを使うときは、最初に画面上部やプロジェクト名を確認し、今どの入口を開いているのかを固定します。別の作業を開いたまま指摘を読むと、似たファイル名や同じブランチ名を取り違えることがあります。発表内容を機能一覧として覚えるより、入口、対象、差分、確認結果を一つの記録に残すほうが、更新後の画面を安全に読みやすくなります。

サイドパネルはレビューの入口として読む

OpenAIの公式ユースケースは、CodexのGitHubコードレビューについて、プルリクエスト上で回帰、テスト不足、文書の問題を見つける用途を示しています。レビュー結果は、あくまで人が確認するための追加の視点です。右側パネルに表示された指摘は、変更箇所と関連づけて読むための入口であり、承認ボタンの代わりになる最終判断ではありません。公式ページは https://developers.openai.com/codex/use-cases/github-code-reviews です。

レビュー欄に指摘が表示されたら、指摘文だけを読み飛ばさず、対象行の前後、変更前の内容、呼び出し元、関連するテストを順番に確認します。とくに「回帰の可能性」と書かれた場合は、現在の差分が既存の振る舞いをどう変えるのかを見ます。右側パネルの価値は、レビューを人の確認から切り離すことではなく、指摘と根拠を近い距離で読めることにあります。

複数リポジトリと編集機能を混同しない

同じプロジェクトで複数のリポジトリを扱えるようになると、関連するコードを一つの作業で参照しやすくなります。しかし、参照できることと編集してよいことは違います。レビュー対象のリポジトリ、変更を受け入れるリポジトリ、単に関連情報として読むリポジトリを分けて指定しないと、差分の意味を誤って説明する危険があります。

右側パネルで差分内編集を行うときも、どのリポジトリのどのブランチに変更を返すのかを先に確認します。複数の対象が見える場合は、ファイルの先頭にあるパス、プロジェクト名、ブランチ、差分の件数を照合します。便利な入口が増えたほど、作業の対象を一つずつ言葉にして固定することが重要になります。

Codex右側パネルでPRレビューを読む手順

ここからは、右側パネルを開いたあとに、指摘をそのまま受け入れず、変更の根拠を確かめる順番を説明します。画面のボタン名は更新で変わる可能性があるため、特定のラベルを暗記するより、「対象を固定する」「指摘と差分を照合する」「修正後に確認する」という三つの役割で覚えるのが実用的です。

右側パネルが表示されること自体を完了条件にしないことも大切です。レビューで確認したいのは、変更が目的に沿っているか、問題の指摘が再現するか、修正後に別の箇所を壊していないかです。次の手順は、Codexアプリやデスクトップで表示が少し違っても応用できます。

Step 1: 対象のPRと差分を固定する

最初にプルリクエストの番号、タイトル、対象リポジトリ、ブランチを確認します。右側パネルにレビュー結果が出ていても、現在開いている作業が別のPRなら、その指摘は判断材料になりません。ファイル一覧の先頭にあるリポジトリ名と、画面に表示された変更件数を照合し、レビューしたい差分が開いていることを確認します。

表示が曖昧な場合は、短いメモに「対象PR」「変更の目的」「触れる範囲」を書いてからレビューを始めます。複数リポジトリを一つのプロジェクトで扱う場合は、関連資料として読む場所と変更を返す場所を分けて記録します。対象が固定できないまま指摘だけを読み進めると、もっともらしい説明でも別の変更へのコメントになるおそれがあります。

Step 2: 指摘から該当行へ移動する

指摘文を読んだら、右側パネルからリンクされたファイルや差分の行へ移動し、変更前と変更後を並べて見ます。行だけを見て判断せず、その関数を呼び出す側、戻り値を受ける側、例外時の分岐まで確認します。レビューの指摘が正しくても、修正箇所を一行だけ変えると別の条件を取りこぼすことがあります。

指摘が「テスト不足」に関するものなら、テストが存在するかだけでなく、変更した条件を実際に通るかを読みます。「文書の問題」なら、説明を足す場所が公開仕様なのか内部メモなのかを確かめます。右側パネルは読む順番を示してくれますが、指摘の意味を自分のコードへ翻訳する作業は利用者が担います。

Step 3: 差分内編集の内容を読む

修正案を右側パネルの差分内編集で反映する場合は、変更された行だけでなく、その前後の文脈を読み直します。括弧や条件式の位置、型、関数名、コメントの意味が保たれているかを確認し、見た目が整ったことだけで完了にしません。元の指摘を解消する変更と、ついでに入った変更が混ざっていないかも見ます。

小さな修正なら、変更前の期待される振る舞いを一文で言い直してから編集します。たとえば「空の入力では既存の表示を保ち、値がある場合だけ新しい分岐を通す」のように条件を言葉にすると、画面上の色や行数に引っ張られにくくなります。編集を保存する前に、差分全体で意図しないファイルが増えていないかを確認しましょう。

Step 4: テストとレビュー結果を照合する

編集後は、レビューで問題になった条件を再現できるテストを先に確認します。既存テストが通ったとしても、指摘された境界条件を通っていなければ十分ではありません。逆に、テストが失敗した場合は、修正が間違いだと即断せず、テストの前提と変更の目的が一致しているかを読みます。

右側パネルに出るレビュー結果、実行したテストの結果、利用者が追加した手直しは別々に記録します。これらを一つの「問題なし」にまとめると、あとからどの根拠で受け入れたのか分からなくなります。Codexの指摘が消えたことではなく、目的、差分、確認結果が対応していることを完了の条件にします。

レビュー結果を過信しない読み方

AIコーディングエージェントのレビューは、変更を読む視点を増やすのに役立ちますが、プロジェクト固有の判断をすべて置き換えるものではありません。右側パネルに表示された指摘が少ないことは、問題が少ない可能性を示すだけで、変更が完全に安全だと証明するものではありません。反対に、指摘が多い場合も、すべてを同じ強さで直すのではなく、再現条件と影響範囲を分けて読みます。

Codexの公式コードレビュー案内は、人がレビューを行う前に回帰、テスト不足、文書不足を見つける用途を示しています。つまり右側パネルは、人が読むべき材料を整理する場所です。レビュー担当者は、指摘の根拠と変更後の挙動を確認し、必要なら作業を差し戻したり、依頼の範囲を狭めたりします。人の判断を残すことが、便利な表示と安全な受け入れを両立する前提です。

指摘の重要度と確度を分ける

「重要そうに見える」ことと「実際に再現する」ことは別です。たとえば入力値の検証を指摘された場合、公開経路からその値が入るのか、呼び出し元ですでに制限されているのか、失敗時の表示が仕様なのかを確認します。指摘の文面に納得しても、実際のデータの流れと結び付かなければ、不要な修正を加えることになります。

重要度を見るときは、利用者への影響、発生条件、修正の広さ、戻しやすさを分けて考えます。影響が大きくても発生条件が存在しないなら、確認を先に行うべきです。影響が小さく見えても、共通処理に広がる変更なら、関連箇所を追加で読む必要があります。右側パネルは指摘を近づけますが、優先順位の決定はプロジェクトの文脈で行います。

差分内編集後に変更範囲を再確認する

一つの指摘を直したつもりでも、編集によって整形、import、型定義、テストデータなど別の行が変わることがあります。変更されたファイル数と行数を修正前後で見比べ、依頼した範囲を超えていないか確認します。大きな差分になった場合は、修正を小さく分けるか、理由をコメントに残してから次へ進むと、レビューの根拠を追いやすくなります。

差分内編集は、画面の中で変更を作れるため、作業の速度を上げる可能性があります。その一方で、入力欄の近くにある行だけを直して全体を見落とす危険もあります。右側パネルの編集を終えたら、ファイル単位の差分、関連する呼び出し、テストの三つを必ず戻って確認し、表示上の完了とコード上の完了を分けます。

テストと実行結果を別に記録する

レビュー指摘が解消されたこと、テストが通ったこと、手元で期待した画面になったことは、それぞれ異なる事実です。右側パネルの表示だけでなく、実行したテスト名、結果、未確認の範囲を短く残します。テストがない場合は「問題なし」ではなく「この条件は未確認」と書くほうが、次の確認者にとって正確です。

同じ修正を別の入口で確認した場合も、どの入口で何を見たかを分けます。Codexアプリのレビュー結果と、GitHubに表示された指摘が同じ内容でも、表示場所が違うため、片方だけを見て両方を確認したと決めないようにします。レビューの記録は、結果のよさを飾るためではなく、後から判断を再現するために使います。

右側パネルが見えないときの切り分け

右側パネルが表示されない場合、すぐに故障と判断する必要はありません。現在の画面がレビュー対象か、Codexを選んでいるか、対象プロジェクトに差分があるか、アプリが更新済みかの順に確認します。OpenAIの発表に書かれた機能が、すべての利用者のすべての画面に同じタイミングで出るとは限らないため、公式情報と手元の状態を分けて記録することが重要です。

切り分けでは、一度に複数の設定を変えないようにします。アプリの更新、サインアウト、プロジェクトの入れ替えを同時に行うと、何が効いたのか分からなくなります。まず画面名と版番号を残し、次に別の小さなPRまたは短い差分で同じ表示が出るかを確かめます。表示だけの問題なのか、レビュー対象の問題なのかを分けることで、不要な再設定を避けられます。

Step 5: 入口とアカウントを確認する

デスクトップアプリでChatGPTや別の画面を開いていると、Codexのレビュー欄を探しても見つかりません。画面上部でCodexの入口を選び、対象プロジェクトとPRを開いているかを確認します。組織やワークスペースを切り替えた直後は、同じリポジトリ名でも参照できる対象が変わる場合があるため、アカウントだけでなくワークスペース名も記録します。

履歴のサイドバーが空に見える場合は、アーカイブ済みのチャットを設定から確認します。OpenAIヘルプが説明するように、アーカイブは履歴から隠す操作で、削除とは異なります。右側パネルの不表示と履歴の不表示は別の問題なので、チャットを削除して作り直す前に、アーカイブ、サインイン先、表示中の入口を順番に確認してください。

Step 6: 安定版と先行版を分けて確認する

Codex CLIやデスクトップの更新直後は、版番号を記録します。安定版で確認した表示と、先行版で見えた表示を同じ結果として扱わないことが大切です。先行版を試す場合は、試す理由、元の版、確認した操作、戻す判断を残し、右側パネルが出たことだけで導入を決めないようにします。

版番号の確認先は、手元の画面だけではなく、OpenAI Codexの公式リリース一覧です。公開ページの説明にない変更を見つけた場合は、公式に発表された事実ではなく、自分の環境で観察した結果として記録します。こうすると、表示の違いを機能の確定仕様と誤って説明しにくくなります。

Step 7: 対象差分と権限を確認する

レビュー対象のPRに差分がない、対象リポジトリが接続されていない、現在のアカウントに閲覧権限がない場合は、右側パネルが空になったり、レビューの入口が出なかったりします。まずGitHub側でPRの状態と差分を確認し、次にCodex側で同じリポジトリを選んでいるかを見ます。接続をやり直す前に、閲覧できる範囲と編集できる範囲を分けて確認しましょう。

公式のGitHub連携案内は、CodexをGitHubのプルリクエストレビューに使う入口を説明しています。参照先は https://developers.openai.com/codex/integrations/github です。ここで示される連携の条件と、自分のワークスペースで許可されている機能が一致するかを確認し、権限のない対象を無理に開こうとしないことが安全です。

2026年9月10日に確認したいCodexの版

この記事の対象日である2026年9月10日に公式リリース一覧を確認すると、安定版として0.153.4がLatest表示になり、その後に0.154.0-alpha.6、alpha.7、alpha.8、alpha.10.2、alpha.11、alpha.6.1などの先行版が並んでいます。先行版の公開日は9月8日から9月9日に集中しており、右側パネルの表示やレビューの入口を調べるときに、どの版を使ったかを残す価値があります。出典は https://github.com/openai/codex/releases です。

0.153.4のリリース本文では、Astraを組み込みモデル選択画面に表示し、明示的な指定がない場合の扱いを修正したこと、非同期の質問を利用可能な道具がある場合に限るよう案内を整えたことが説明されています。これは右側パネルそのものの機能追加ではありませんが、画面に出るモデルや質問の挙動が版によって変わる可能性を示します。レビュー表示の差を調べるときは、モデルの変更と画面の変更を別々に扱います。

0.153.4を基準に表示を比べる

日常の確認では、安定版を基準にして、同じPR、同じアカウント、同じプロジェクトで右側パネルの表示を比べます。確認するのは、PRを開けるか、指摘から該当行へ移動できるか、差分内編集の入口が見えるか、修正後の差分を再表示できるかです。版を変えたうえでPRも変えると、表示の違いが更新由来か対象由来か判断できません。

比べた結果を記録するときは、「表示された」「表示されない」だけではなく、画面の入口、版番号、PRの状態、利用したモデル、操作の順序を書きます。表示のない機能を探して設定を広げる前に、公式発表でその機能が現在の入口に含まれるかを確認します。小さな差分で比べるほうが、更新後の挙動を読みやすくなります。

先行版を試すときの線引き

0.154.0系の先行版は、最新の変更を早く確かめたい人には参考になりますが、安定版と同じ説明や安定性を期待するものではありません。レビュー中の重要なPRを先行版だけで判断せず、安定版での表示と結果を基準に置きます。先行版で見つけた表示を紹介する場合も、公開された事実、画面での観察、まだ確認できない点を分けて書きます。

右側パネルのような画面機能は、本体の更新だけでなくデスクトップアプリ側の配信やアカウント条件にも影響されます。先行版に変えて表示が出たとしても、それがすべての利用者に広がったとは限りません。利用者向けの記事では、版番号をタイトルの主役にせず、どの入口で何が見えたかを記録するほうが、後から情報を更新しやすくなります。

更新後に照合する四つの項目

更新後は、まず画面の入口、次に対象PR、続いてレビュー指摘と差分、最後に編集後の確認結果を照合します。入口が違えば同じCodexでも表示が変わり、PRが違えば指摘の内容が変わり、差分が違えば編集結果の評価も変わります。この四つを同じ記録に置くと、レビュー欄が消えたときに、版の問題か対象の問題かを切り分けやすくなります。

特に、版番号の更新とモデルの更新を一つの「性能向上」としてまとめないようにします。CLIやアプリの版は画面や操作を変え、モデルは応答内容や推論の傾向を変えます。レビューの正しさを確かめたい場合は、同じモデルと同じ差分で入口だけを比べるなど、変える条件を一つに絞ると結果を説明しやすくなります。

右側パネルに渡すレビュー依頼の作り方

右側パネルを活用するには、画面の使い方だけでなく、レビューしてほしい範囲を短く伝えることも大切です。「見て」とだけ依頼すると、どの差分を重く見るか、どこまで確認すればよいかが曖昧になります。目的、対象、気になる条件、確認してほしい結果を一つの依頼にまとめ、レビューの出力を読みやすくします。

たとえば「このPRの認証周辺の変更について、既存の失敗時表示が変わっていないか、関連テストが条件を通っているかを確認し、問題があればファイルと理由を示してください」と書けば、レビューの焦点が見えます。ここで重要なのは、結論を先に決めて誘導することではなく、何を確認したかを後から照合できる依頼にすることです。

Step 8: 目的と対象を一文ずつ伝える

最初の一文でPRの目的を示し、次の一文で対象範囲を示します。「一覧画面の検索条件を変える」が目的なら、対象は検索処理、入力欄、結果表示、関連テストのように書きます。触れてほしくない範囲があるなら、「データ構造と公開インターフェースは評価対象に含めるが、変更案は出さない」のように明示します。

目的と対象が分かれていると、右側パネルの指摘を読んだときに、依頼した範囲の中の問題か、周辺への追加提案かを判断できます。レビューが広がりすぎる場合は、対象ファイルや条件を狭めてもう一度確認します。短い依頼でも範囲が明確なら、指摘と差分の対応が崩れにくくなります。

Step 9: 完了条件と未確認を指定する

レビューの終わりを「コメントがなくなること」にしないで、確認したい条件を書きます。たとえば「空の入力、通常値、上限値、失敗時の四つを見て、実行したテスト名と未確認の条件を報告する」とすれば、右側パネルの指摘が少ない場合でも、読むべき範囲が残ります。完了条件は、修正を依頼するときにもそのまま使えます。

未確認の条件を報告してもらうことは、レビューを弱くするためではありません。どこまで見たかを明らかにすると、人が追加で確認する場所を選べます。Codexが「問題なし」と返した場合でも、未確認の範囲があればそこを人が読む必要があります。右側パネルを判断の終点ではなく、確認事項を整理する場所として扱いましょう。

Step 10: 修正依頼と受け入れ判断を分ける

レビュー結果を読んだ直後に、すべての指摘を同じ依頼で修正させると、元の問題と追加された変更の関係が見えにくくなります。まず指摘の妥当性を確認し、修正する項目を選び、変更後に同じ右側パネルで差分を読み直します。修正しない指摘がある場合は、理由を短く残しておくと、後のレビューで同じ議論を繰り返さずに済みます。

修正を受け入れる判断では、指摘の解消、変更範囲、テスト、公開仕様との整合を別々に見ます。差分内編集で直せる小さな問題でも、共通処理に影響するなら関連箇所を読みます。修正を行った事実と、修正を受け入れた判断は同じではありません。右側パネルはこの二つを分けて確認するための画面として使うと、作業の流れが安定します。

既存のCodex機能との使い分け

Codexには、GitHub上のPRレビュー、手元の差分レビュー、チャット履歴の整理など、似て見えて役割の異なる機能があります。右側パネルを説明するときに、これらを一つの機能としてまとめると、どの画面で何が起きるのかが曖昧になります。まず対象がGitHubのPRなのか、ローカルの未確定差分なのか、過去の会話なのかを分けてから入口を選びます。

GitHubの公式連携ページは、プルリクエストをCodexでレビューする入口を案内しています。対して、デスクトップの右側パネルは、そのレビューを読む、差分と照合する、編集後の状態を確認するという画面上の導線です。機能の設定場所、指摘が置かれる場所、変更を返す場所が異なる場合があるため、案内文では「どこから始めるか」を具体的に書きます。

GitHubのPRレビューを読む場合

GitHub上でレビューを依頼した場合は、PRのタイトル、対象ブランチ、指摘の行、関連するテストをGitHub側でも確認します。右側パネルに同じ指摘が出ていても、表示の同期や読み込みのタイミングで見え方が異なることがあります。最終的な変更を受け入れる前に、PRの差分そのものと、必要なテスト結果を基準にします。

公式のユースケースは、Codexのコードレビューを人のレビュー前に追加する確認信号として位置づけています。これはレビューを一つ増やす考え方であり、人の判断をなくす説明ではありません。指摘がない場合も、変更の目的と影響範囲を人が確認し、必要なら別の観点で読み直します。

手元の差分を読む場合

ローカルの作業場所で未確定の差分を確認する場合は、PR番号が存在しないことがあります。このときはブランチ名、変更ファイル、実行したテストを記録し、GitHubのPRレビュー結果と混ぜないようにします。右側パネルで編集した内容が手元の作業場所に返るのか、別の作業として保存されるのかは、利用している入口の説明を確認してください。

手元の差分では、未保存の変更、別の作業から持ち込んだ変更、今回のレビューで加えた変更が一つに見えることがあります。レビューを始める前に現在の差分を保存し、修正後にどこが増えたかを照合します。変更の出どころを分けておくと、右側パネルの指摘がどの差分に向けられたものかを追いやすくなります。

履歴を整理する場合

右側パネルでレビューを終えたあと、履歴を短くしたくなっても、すぐに削除へ進まないでください。OpenAIヘルプが説明するように、アーカイブは履歴から隠す操作で、削除したチャットは復元できません。次のレビューで参照する可能性があるなら、対象PR、確認結果、未確認の条件を別の記録へ残してから、履歴の整理方法を選びます。

履歴を整理する目的は、画面を見やすくすることです。レビューの判断を消すことではありません。会話を残す必要があるか、差分を別の場所に保存したか、後から同じPRを開けるかを確認し、アーカイブと削除を使い分けます。右側パネルの不表示を直す目的で履歴を削除するのは、原因を隠すだけになる可能性があるため避けましょう。

まとめ

Codexの右側パネルは、プルリクエストレビューの指摘と差分を近い場所で読み、必要な編集を行ったあとに変更を確認するための導線です。2026年7月9日のOpenAI発表で、Codexアプリのデスクトップ統合、差分内編集、サイドパネルでのPRレビューが案内され、画面上の確認方法が変わりました。現在の表示を読むときは、公式発表と手元の画面を分けて扱います。

実際に使うときは、まず入口、アカウント、プロジェクト、対象PRを固定します。次に指摘と該当行を照合し、差分内編集を使った場合は変更範囲とテストを読み直します。右側パネルが見えないときは、履歴の問題、対象差分の問題、権限の問題、版の違いを一度に直さず、順番に切り分けてください。

2026年9月10日時点では、安定版0.153.4と0.154.0系の先行版が並んでいます。版番号、モデル、入口、対象差分を記録し、表示された機能だけを根拠に判断することが、更新後のレビューを安定させます。Codexの指摘は確認を助ける材料であり、最終的な変更の受け入れは、差分とテストを読んだ人が決めるものです。