コンテンツにスキップ

Codex Remoteで新規チャットだけ作れない：Project Trustエラーを確認

確認できた範囲

Remote接続と既存セッションの継続は成功し、新規チャットだけがProject Trust確認で停止した。 Issue #40002では同じ処理段階の失敗が報告されているが、今回のWSL環境で同じパス照合問題が原因かは未確認である。

開始経路先に確認すること断定しないこと
既存セッションそのまま継続できるかRemote全体の接続障害
既存プロジェクトの新規チャット表示パスと保存済みTrustキーWSLでも大文字小文字が原因
「No project」またはWorktree生成された表示パスを記録する推測したTrustキーの追加
書き込み不要の作業読み取り専用で開始できるか読み取り専用で書き込めること

Codex RemoteのProject TrustエラーをWindowsの大文字小文字、パス区切り、WSLの別表記に分けて確認する図

既存セッションは使えるが新規チャットだけ停止した

確認した構成は、ChatGPT Androidアプリ、Codex Remote、Windows版Codex Desktop、WSL、Ubuntu、WSL内のGitリポジトリである。 Windows側からは、対象リポジトリを次のUNCパスで参照していた。

\\wsl$\Ubuntu-26.04\home\<user>\<project>

AndroidからWindows PCへの接続とプロジェクト選択は成功した。 PC側にすでに存在するセッションにはスマートフォンからアクセスでき、継続もできた。 しかし、スマートフォンから新規チャットを開始すると次のエラーが表示され、スレッドは作成されなかった。

プロジェクトの信頼設定を確認できません。リモートコンピューター上のCodexでリポジトリを開き、信頼するかどうかを選択してください。その後、そのリポジトリの元のディレクトリを選択して、もう一度試してください。読み取り専用モードで開始することもできます。問題が解決しない場合は、リモートコンピューター上のCodexを更新してください。

これは今回の環境で確認した観察結果であり、Remote全体の接続障害ではない。 サーバー側ログまたはCodex内部のTrust照合処理までは確認していない。 したがって、エラー文が似ているという理由だけで、公開Issueのどれかと同じ不具合だとは断定できない。

Issue #40002も外部から見える同じ境界で停止する

openai/codex Issue #40002は、Trustedとして登録済みのWindowsプロジェクトでも、Android Remoteから新規チャットを開始できない事象を報告している。1 GitHub API上の作成時刻は2026年8月21日20時05分（UTC）で、日本時間では8月22日5時05分に当たる。

Issue報告者の診断ログでは、WindowsホストへのRemote接続は正常で、既存スレッドのthread/resumeとTrust確認前のconfig/readは成功した。 一方、Trust確認に失敗すると、新規スレッドを作るthread/startは送信されなかった。

#40002の処理結果
Windowsホストへ接続成功
接続後のconfig/read成功
既存スレッドのthread/resume成功
Trustエラー直前のconfig/read成功
新規チャットのTrust確認失敗
thread/start送信されない

Issue #40002では、config/readとthread/resumeが新規作成前に完了し、処理はProject Trust確認で停止した。 今回の観察と一致するのは、既存セッションは使えて新規作成だけ止まるという外部から見える境界であり、今回の環境では内部リクエストを観測していない。

同Issueで再現した直接の条件は、Windowsパスの大文字と小文字である。

報告された設定では、Codex側に小文字のパスが保存されていた。

[projects.'c:\users\<user>\example-project']
trust_level = "trusted"

一方、Android Remoteは大文字と小文字が混ざったパスを参照した。

C:\Users\<user>\Example-Project

Windowsでは同じ場所を指す二つの表記だが、Issueの報告者は、Remote側に表示されたパスと大文字と小文字まで一致するTrustエントリを追加すると新規チャットを開始できたとしている。 別の利用者も、別プロジェクトで同じ失敗と回避結果をコメントしている。2

この結果は、大文字と小文字を区別したキー照合と整合する。 ただし、これは報告者による診断と回避例であり、OpenAI保守者が根本原因または恒久修正として確定した回答ではない。

Issue #39855は生成パスから区切り文字が欠ける

Issue #39855は、Windowsホストで新しいprojectless Remoteチャットを作ると、存在しないパスに対してTrust確認が行われる事象を報告している。3 表示されたパスでは、日付ディレクトリとチャット名の間の区切り文字が欠けていた。

表示: C:\Users\<user>\Documents\Codex\2026-08-20hello-3
実体: C:\Users\<user>\Documents\Codex\2026-08-20\hello-3

報告者は、実体側のディレクトリは存在し、空で、Gitリポジトリでも再解析ポイントでもないと説明している。 前の生成先をデスクトップで開いても、次の新規チャットでは別ディレクトリが生成されるため、失敗を繰り返した。

このIssueは既存のTrustedプロジェクトではなく、自動生成されるprojectlessチャットの分類とパス生成を対象にしている。 Issue #40002の大文字と小文字の問題と、同じProject Trustエラーが出ても条件は異なる。

Issue #39678はmacOSの「No project」とWorktreeにも広がる

Issue #39678は、AndroidからmacOSへ接続し、「No project」で新規Remoteチャットを開始するとTrust確認で停止する事象を報告している。4 既存のTrustedプロジェクトは選択できたため、報告者は、projectlessフローが作る一時ディレクトリをRemoteが明示的なTrust判断済みの既存ローカルリポジトリのように直ちに検証し、初期化がTrustを保存する前に失敗する「trust-routing regression」の可能性を挙げている。

同じIssueには、既存のTrusted GitプロジェクトでもWorktreeモードを選ぶと、生成予定のworktreeパスに対するTrust確認で停止するという別利用者の報告がある。5 生成先は失敗後に残らず、元のリポジトリをデスクトップで信頼しても回避できなかったとされている。

この報告は、Project TrustエラーがWindows固有または大文字と小文字だけの問題ではないことを示す。 一方で、「No project」、Worktree、既存プロジェクトは異なる開始経路であり、単一の原因へまとめることはできない。

WSLでは同じ場所に複数のパス表現がある

今回のWSL環境では、同じリポジトリを少なくとも次の形式で表現できる。

/home/<user>/<project>
\\wsl$\Ubuntu-26.04\home\<user>\<project>
\\wsl.localhost\Ubuntu-26.04\home\<user>\<project>

Issue #40002が直接確認したのは、通常のWindowsパスで大文字と小文字が異なる場合である。 公開された3件のIssueだけでは、Codex RemoteがLinuxパス、wsl$、wsl.localhostをどの段階で正規化し、どの文字列をTrustキーに使うかは分からない。

したがって、「WSLのUNC表記が違うために今回のエラーが起きた」は未確認の仮説である。 今回確認できたのは、WindowsホストとAndroid Remoteの接続後、WSL内の既存Gitリポジトリを選んだ新規チャットがTrust確認で止まったことまでである。

同じエラーでは開始経路とパスを分けて確認する

同じメッセージが出た場合は、設定を書き換える前に開始経路で条件を分ける。

  1. 利用者が、既存プロジェクト、「No project」、Worktreeのどの開始経路で失敗したかを記録する
  2. 既存プロジェクトの利用者が、Remote側の表示パスと保存済みTrustキーを伏せ字にして比較し、ドライブ名、大文字と小文字、末尾区切りを確認する
  3. 「No project」またはWorktreeの利用者が、生成された表示パスを記録し、推測したTrustエントリは追加しない
  4. WSLの既存プロジェクト利用者が、Linuxパス、wsl$、wsl.localhostのどの表記で開き、Remoteがどの表記を示したかを記録する
  5. 既存プロジェクトの利用者が、ホスト側のCodexで元のリポジトリを開き、Trust選択とアプリ更新を確認する
  6. 利用者が、書き込みを必要としないタスクなら読み取り専用モードで開始できるか確認する

Issue #40002の完全一致エントリは、通常のWindowsパスで再現した利用者の暫定回避策である。 設定ファイルを編集する場合はバックアップを取り、Remoteに表示されたパス以外を推測で追加しない。 WSLでも同じ方法が有効だとは確認されていない。

再現報告には、Android版ChatGPTとWindows版Codexのバージョン、開始経路、伏せ字にした表示パス、保存済みTrustキー、既存スレッドを再開できるか、読み取り専用で開始できるかを含めると条件を区別しやすい。 ユーザー名、リポジトリ名、認証情報、設定全体は公開しない。

公開IssueはいずれもOpenで原因の統合はされていない

2026年8月22日の確認時点で、Issue #40002、#39855、#39678はいずれもOpenである。 3件にはProject Trustという共通の失敗地点があるが、対象は既存Windowsプロジェクト、Windowsのprojectlessチャット、macOSのprojectlessチャットとWorktreeに分かれる。

現時点の判断は、開始経路を分け、既存プロジェクトの場合だけ表示パスとTrustキーを照合することだ。 WSL環境の根本原因は、同じ構成の再現情報またはOpenAI側の診断が公開されるまで未確定として扱う。

この記事をポスト リンクをコピー

関連記事

出典

  1. openai/codex Issue #40002「Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup」（2026年8月22日確認）。既存WindowsプロジェクトのTrustキー、大文字と小文字の差、再現手順、暫定回避策、Open状態を確認した。 ↩

  2. Issue #40002の別利用者による再現コメント（2026年8月22日確認）。別プロジェクトでも完全一致するTrustエントリにより開始できたという報告を確認した。 ↩

  3. openai/codex Issue #39855「Windows Remote: every new projectless chat fails trust verification with malformed path」（2026年8月22日確認）。Windowsのprojectlessチャットで区切り文字が欠けた生成パス、再現条件、Open状態を確認した。 ↩

  4. openai/codex Issue #39678「[Remote][Android to macOS] “No project” chat fails with project trust error」（2026年8月22日確認）。macOSの「No project」での再現条件、既存プロジェクトとの対照、Open状態を確認した。 ↩

  5. Issue #39678のWorktreeモード再現コメント（2026年8月22日確認）。既存TrustedプロジェクトのWorktreeモードで生成予定パスのTrust確認に失敗したという報告を確認した。 ↩