CodexはWSLではプロジェクトを読み取らないので、急いで再インストールしないでください。 最も一般的な理由は、Windowsパス、WSLパス、Codexサンドボックススコープを行き来し、作業ディレクトリがプロジェクトディレクトリとは異なるものを表示してしまうことです。
どのディレクトリを最初に起動するか確認してください
ターミナルで「pwd」を実行し、その後「ls」を実行します。 パスが「/mnt/c/Users/...」の場合、WindowsディスクにWSLでアクセスしています。 もし「/home/xxx/project」なら、それはWSL Linuxのファイルシステムです。 多くの依存関係、権限、リスニングの挙動はこれら二つの経路の下で異なる挙動を示します。
変更したいプロジェクトはWSLの「/home/username/」に置き、Codexはプロジェクトのルートから起動するのが推奨されます。 あるターミナルでWindowsプロジェクトを開いて、Codexに別のWSLプロジェクトを読み込ませないでください。
もう一度サンドボックスのスコープを見てください
Codexのローカル編集およびコマンド実行は、現在のディレクトリ、権限パターン、サンドボックス制約の影響を受けます。 「/mnt/d/other-project」に変更しますが、起動ディレクトリは「/home/me/app」にあり、直接アクセスできないか、アクセスすべきでない場合があります。
より安定した方法は、プロジェクト開始前にルートディレクトリに入ることです。まず「cd ~/projects/my-app」を入力し、「git status」がリポジトリを認識できるようにし、その後Codexにディレクトリ構造を解析させます。
ドキュメントがまだ読み取れない場合のトラブルシューティング方法
最初のステップは、Codexが単にコードを変更させるのではなく、ディレクトリを最初にリストアップさせることです。 次のステップは、ファイルが「.gitignore」やツールのルール、または権限によってブロックされているかどうかを確認することです。 三つ目のステップは、Node for Windowsやnpmを使ってWSLプロジェクトの依存関係を実行しないようにすることです。
大規模なリポジトリの場合は、まずパスを指定することができます。例えば「src/api」と「package.json」だけを見て、リポジトリ全体をスキャンしない。 これにより文脈を節約し、無関係なディレクトリに丸をつくのを避けられます。
最も安定した結論
CodexはWSLで使用されており、3つの点を一貫させるのが最善です。プロジェクトはWSLファイルシステムに配置され、ターミナルはプロジェクトのルートディレクトリから起動される、そして修正範囲は現在のリポジトリに限定されます。 これにより時間が節約でき、「ファイルがあるが見つからない」という問題が起きにくいです。
