Codex メール通知の使い方｜公式設定と受信を分けて確認

Codexのメール通知は三つの結果に分けて読む

「Codexからメールが来るか」を一つの質問にすると、公式設定の説明、画面に出た通知、実際に受け取ったメールが混ざります。今回の検索意図では、まず公式ページに該当する記載があるかを見て、次に手元のCodexがどこへ表示したかを確認し、最後に受信箱の結果を記録する順番が重要です。三つを別欄に置けば、どこまで確認できたのかを後から説明できます。

2026年8月9日（JST）の公式情報には、Cline v4.1.7とAider v0.86.0の更新がありました。Clineでは完了カードから変更内容を見る入口や最終応答のコピー、中断後に指示とセッション状態を保つ変更が案内されています。AiderではGPT-5系を含むモデル対応や履歴表示の更新が紹介されていますが、いずれもCodexのメール配信を発表した情報ではありません（出典: https://github.com/cline/cline/releases/tag/v4.1.7、https://github.com/Aider-AI/aider/releases/tag/v0.86.0）。

この切り分けを先に行うと、「通知」という語を見つけただけでメール機能があると判断する誤りを避けられます。公式記載が見つからないときも、今回確認できた範囲に専用の記載がないと書くにとどめ、未確認の機能を存在しないと断定しません。検索結果や別製品の案内も、Codexの設定を裏付ける出典とは別に扱います。

Codex公式設定で確認できる通知の範囲

OpenAIの設定リファレンスは、Codexの設定ファイルにあるキーを一覧化しています。通知に関係する項目は、TUI（ターミナル画面）の通知を制御する[tui]配下のキーと、通知時にコマンドを呼び出すnotifyです。ここで示されるのは「どのイベントを、どの経路で知らせるか」であり、メールサービスのアカウントや受信箱をCodex内で登録する手順ではありません（出典: https://developers.openai.com/codex/config-reference）。

設定を読むときは、キー名、値、通知が発生する場所を一行ずつ対応させます。tui.notificationsを有効にしても、ターミナルが選択中かどうか、利用している端末が通知方式に対応しているかで見え方は変わります。notifyを見つけても、そこから先の外部プログラムがどこへ情報を届けるかは別の確認対象です。

Codexの版番号は設定ページと公式リリース一覧を別に見ます。設定ページは通知キーの意味を確認する場所、リリース一覧は手元の版がいつ公開されたものかを照合する場所です。版番号だけでメール機能の有無を判断せず、両方のURLを記録してください（出典: https://github.com/openai/codex/releases）。

tui.notificationsはターミナル内の通知

tui.notificationsは、CodexのTUIから端末の通知機能へ合図を出すための設定です。公式リファレンスでは、真偽値で有効化でき、配列を指定すれば対象イベントを絞り込めると説明されています。応答完了や承認要求など、画面を見ていない間に気づきたい出来事を指定するための項目です（出典: https://developers.openai.com/codex/config-reference）。

通知方式はtui.notification_methodで確認します。値はauto、osc9、belで、autoでは対応する端末へのOSC 9通知を優先し、利用できない場合はBELへ切り替える説明です。Windowsで音やタブの変化だけを見てメールが届いたと判断せず、通知がどの方式で表示されたのかも記録しておくと、再現条件が明確になります（出典: https://developers.openai.com/codex/config-advanced）。

通知のタイミングはtui.notification_conditionで見ます。unfocusedなら端末がフォーカスを失っているとき、alwaysならフォーカス中も対象になります。画面を見ながら短い確認をしたときに通知が出ない場合、まずメール配信の問題と決めず、設定値と端末のフォーカス状態を照合してください。

設定の読み方を確かめるための最小例は次のとおりです。これは端末通知の確認用で、メールの宛先を指定する記述ではありません。

[tui]
notifications = true
notification_method = "auto"
notification_condition = "unfocused"

notifyは外部プログラムへイベントを渡す

notifyは、対応するイベントが起きたときに外部プログラムを呼び出す設定です。公式の高度な設定では、現在対応するイベントはagent-turn-completeで、コマンドにはJSONを単一の引数として渡すと説明されています。代表的な項目はイベント種別、セッション識別子、ターン識別子、作業場所、入力メッセージ、最後の応答です（出典: https://developers.openai.com/codex/config-advanced）。

この仕組みは、画面以外の受け口へ情報を渡せる点が特徴です。デスクトップ表示、記録用のファイル、チャットへの通知など、外部プログラム側で処理の行き先を決められます。ただし、Codexの公式設定リファレンスがメールアドレス宛の配信設定を示しているわけではないため、notifyの存在だけをメール機能の根拠にしません。

メールを確認したい場合は、Codexがイベントを渡したか、外部の受け口が処理したか、受信箱に届いたかを分けて見ます。受け口まで情報が届いた証拠があっても、メールサービス側で処理が止まる可能性があります。逆に受信箱にメールがないだけで、Codexがイベントを出していないと判断することもできません。

設定場所とメール配信の境界

設定リファレンスでは、ユーザー設定は~/.codex/config.tomlに置き、信頼したプロジェクトではプロジェクト側の設定も読み込めると説明されています。一方、通知に関するキーはプロジェクト側で上書きできないものがあるため、メール通知を調べるときはプロジェクトのフォルダーだけでなく、ユーザー側の設定場所も確認します（出典: https://developers.openai.com/codex/config-reference）。

Windowsではユーザーフォルダー配下の.codex\config.tomlを開き、[tui]の設定とトップレベルのnotifyを別の欄として読みます。設定ファイルに項目がない場合は「未設定」と記録し、画面や受信箱の結果を推測で補いません。設定の変更を行う場合も、変更前の値と変更した時刻を先に残しておくと観測結果を比較しやすくなります。

公式記載・画面表示・メール受信を同じ欄に書かない

確認表の目的は、製品を順位付けすることではありません。どの情報が公式ページに書かれ、どの表示を手元で見て、どのメールを受け取ったかを一つの記録にまとめ、確認できた事実とまだ見ていない事実を区別することです。特に「公式に書かれていない」「今回の画面に出なかった」「メールが届かなかった」は意味が違うため、同じ「なし」で埋めないようにします。

先に固定する確認項目

製品名や版番号は、手元で表示された値と公式ページに掲載された値を別々に書きます。確認日を2026年8月10日と固定し、対象となる公式情報が8月9日（JST）のものか、後日の更新かも添えます。出典URLは判定の直後に置き、後からページを開き直したときに同じ記載へたどれるようにします。

この表では、Codexの欄だけを詳しく埋めれば十分という意味ではありません。Copilot CLIとCursorは公式の確認先を残し、AiderとClineは今回参照した版の変更を記録します。別製品の欄が「要確認」のままでも、Codexのメール受信結果を補う材料にはしません。

判定語を使い分ける

「確認できた」は、公式記載または手元の表示、受信箱の結果が、どの欄について確認できたか明確な場合に使います。「確認できない」は、決めた条件で対象を見たが該当する結果がなかった場合です。「要確認」は、公式ページの対象期間が不明、端末の条件が揃っていない、受け口の記録が足りない場合に使います。

たとえば、notifyの設定項目が公式ページにあることは「公式記載を確認できた」です。しかし、メールが受信箱に届いたことまでは同じ行から導けません。端末に完了通知が出たことも、メール配信が成功した証拠ではありません。事実の範囲を越えない判定にすると、再確認時に誤った前提を持ち越さずに済みます。

観測の順番をそろえる

最初にCodexの版番号、確認日、設定ファイルの場所を記録します。次に設定を読み、tui.notifications、通知方式、フォーカス条件、notifyの有無を欄ごとに写します。ここでは設定を変えず、現在の状態を観測した結果として残すことがポイントです。

次に、短い確認用の指示を一つだけ出し、端末をフォーカス中と非フォーカスの状態で分けて表示を見ます。表示された文言、表示時刻、音やタブの変化、外部受け口に残った情報を別々に記録します。条件を一度に変えないことで、通知が出なかった理由を追いやすくなります。

最後に受信箱を確認し、送信者、件名、受信時刻、迷惑メール側での扱いを記録します。メールが届かないときは「受信確認なし」と書き、Codexのイベント発生や外部受け口の処理まで否定しません。反対にメールを受け取ったときも、どの設定とどの表示に対応する通知かを表で照合します。

ClineとAiderの更新は周辺情報として記録する

周辺ツールの更新を確認する理由は、結果の表示や履歴の残り方を観測するときの視点を増やすためです。ClineとAiderに「通知」や「履歴」に関する変更があっても、それは各製品の機能です。Codexの設定項目やメール受信の根拠として引用する場合は、製品ごとの公式ページを分けて示します。

Cline v4.1.7で見る完了結果と中断後の状態

Cline v4.1.7では、完了行から変更内容を確認する「View Changes」が戻り、ターン最終応答のコピー操作も追加されています。作業が終わったあとに何が変わったか、画面に見えた結果をもう一度取り出せる更新です。完了カードを見られたことはClineの画面表示の確認であり、Codexのメール受信を示すものではありません（出典: https://github.com/cline/cline/releases/tag/v4.1.7）。

同じリリースでは、中断中にキューへ残った指示を保持し、中断後に処理する変更や、セッションの状態を中断・再起動後も保つ修正が案内されています。確認表に書くなら「完了カード」「最終応答」「中断後の指示」「再開後の状態」を別の観測項目にします。これらを一つの「通知」欄にまとめないことが、製品間の読み替えを防ぎます。

Aider v0.86.0で見るモデルと履歴表示

Aider v0.86.0では、GPT-5系を含むモデルへの対応、/clear実行時に履歴を消したことを表示する変更、/undoの出力をコミットメッセージの先頭行だけに整理する変更が掲載されています。既存モデルの設定が新しい値へ置き換わらない問題の修正も記載されています（出典: https://github.com/Aider-AI/aider/releases/tag/v0.86.0）。

ここで記録すべきなのは、履歴操作の結果が画面にどう出たかです。Aiderの/clearや/undoが確認できても、Codexのtui.notificationsやnotifyが動いたことにはなりません。製品名、版番号、表示された文言、確認した公式URLを分けて残し、メール欄は実際に受信を確認した場合だけ埋めます。

GitHub Copilot CLIとCursorは公式確認先を残す

GitHub Copilot CLIとCursorについては、対象日に新しい掲載がなかったことと、その製品に該当機能が存在しないことを同じ意味にしません。前者は特定の期間に公式ページで新着を見なかったという記録で、後者を述べるには対象機能を説明するページや更新履歴をさらに確認する必要があります。

GitHub Copilot CLIは公式リリース一覧を確認先にします。掲載日、版番号、変更本文を見て、メール、画面通知、履歴表示のどれが説明されているかを製品欄に写します。2026年8月9日（JST）の今回の対象期間に新着が見当たらなかったとしても、「対象期間の新着なし」と記録するにとどめ、メール機能の不存在とは書きません（出典: https://github.com/github/copilot-cli/releases）。

Cursorは公式Changelogを確認先にします。たとえば2026年8月3日の掲載には、Google Workspace向けのプラグインとしてGmailの検索・読取・下書き・送信などが説明されています。これはCursor側の機能であり、Codexのnotifyがメールを送る設定を示すものではありません。別製品のメール連携を見つけたときほど、製品名と出典URLを明示して欄を分けます（出典: https://cursor.com/en-US/changelog）。

Windowsでの再確認と記録方法

Windowsでは、端末のフォーカス状態、設定ファイルの場所、表示された通知、外部受け口の記録、受信箱の結果が別々の場所に現れます。確認作業を一つの画面だけで完結させようとせず、同じ版番号と同じ条件で各観測点を確認し、時刻を添えて表へ戻します。これが「画面には出たがメールは未確認」という状態を正しく残す方法です。

設定を読み、フォーカス状態を記録する

まずユーザーフォルダー配下の.codex\config.tomlを読み、[tui]の通知設定とトップレベルのnotifyを確認します。notification_conditionがunfocusedなら、端末を別のウィンドウへ移したときだけ表示される可能性があります。画面を見たまま通知が出ないときは、設定と条件を先に照合してください（出典: https://developers.openai.com/codex/config-reference）。

次に、Windowsの端末をフォーカス中、非フォーカス、最小化に分けて観測します。端末ごとにOSC 9やBELの扱いが異なるため、表示、音、タブの変化を具体的に書きます。autoの結果が分からない場合は、端末名と設定値を一緒に記録し、メール受信の判定と混ぜません（出典: https://developers.openai.com/codex/config-advanced）。

受け口と受信箱を時刻で照合する

notifyを使っている場合は、外部プログラムが起動したか、JSONを受け取ったか、最後の応答や作業場所を記録できたかを確認します。ここで確認できるのは、Codexから外部受け口までの経路です。受け口側に記録が残ってもメールが届くとは限らず、メールがないことだけでCodexのイベントを否定できません。

受信箱では、確認した時刻、送信者、件名、受信フォルダー、迷惑メール側の結果を残します。必要なら同じ短い確認用の指示を時間を空けて再度試しますが、設定値、端末の状態、確認時刻を変えた場合はその変更も書きます。受信結果が一度だけなら、判定を「要確認」として次回の条件を残す方が正確です。

設定変更と観測結果を分ける

設定を変更する場合は、変更前の内容、変更した項目、変更時刻、変更後に見た画面を順に記録します。変更後にメールが届かなくても、設定の読み込み、端末表示、外部受け口、メールサービスのどこで止まったかは別途確認が必要です。変更したこと自体を、機能が使える証拠や使えない証拠として扱いません。

今回の目的はメールを送る仕組みを新しく作ることではなく、Codexの公式設定と手元の結果を正確に照合することです。公式ページに専用の記載がないときは、確認できた通知の範囲、未確認のメール配信、次に開くURLを残します。これなら製品や版が更新されても、前回の観測と今回の観測を同じ尺度で比べられます。

まとめ

Codexの公式設定には、TUI通知を有効にするtui.notifications、通知方式とフォーカス条件、外部プログラムへJSONを渡すnotifyがあります。これらはメールアドレス宛の配信を直接設定する項目として説明されていないため、メールの有無を先に断定せず、公式記載と手元の観測を分けて確認します（出典: https://developers.openai.com/codex/config-reference、https://developers.openai.com/codex/config-advanced）。

Cline v4.1.7とAider v0.86.0は、完了結果、履歴、中断後の状態を記録する補助例です。GitHub Copilot CLIは公式リリース一覧、Cursorは公式Changelogを確認先として残し、対象日に新着がないことと機能の不存在を混同しません。別製品のメール連携を見つけても、Codexの根拠には読み替えないことが大切です。

Windowsで再確認するときは、版番号、設定場所、フォーカス状態、端末表示、外部受け口、受信箱、確認時刻を一つの表に残します。判定は「確認できた」「確認できない」「要確認」を使い分け、メールが届かなかった一回の結果だけで結論を固定しないことが、次の確認につながります。