Codex ne lit pas le projet dans WSL, donc ne vous précipitez pas pour le réinstaller. La raison la plus courante est que vous basculez entre le chemin Windows, le chemin WSL et le scope du bac à sable Codex, ce qui fait qu’il voit un répertoire fonctionnel qui n’est pas le même que celui du projet que vous pensez.
Confirmez en premier quel annuaire vous lancez
Exécutez 'pwd' dans le terminal puis 'ls'. Si le chemin est '/mnt/c/Users/...', vous accédez au disque Windows dans WSL ; Si c’est '/home/xxx/project', c’est le système de fichiers Linux WSL. De nombreuses dépendances, permissions et comportements d’écoute se comportent différemment sous ces deux voies.
Il est recommandé de placer le projet que vous souhaitez modifier sous « /home/username/ » dans WSL et de commencer Codex depuis la racine du projet. N’ouvrez pas un projet Windows dans un seul terminal et laissez Codex lire un autre projet WSL.
Regarde encore la lunette du bac à sable
L’édition locale et l’exécution des commandes du Codex sont affectées par le répertoire actuel, les patrons de permissions et les contraintes du bac à sable. Tu le changes en '/mnt/d/other-project', mais le répertoire de démarrage est dans '/home/me/app', il se peut qu’il ne soit pas directement accessible ou ne devrait pas être consulté.
Une approche plus stable consiste à entrer dans le répertoire racine du projet avant de le lancer : d’abord 'cd ~/projects/my-app', s’assurer que 'git status' peut voir le dépôt, puis laisser Codex analyser la structure du répertoire.
Comment dépanner si le document est toujours illisible
La première étape consiste à laisser Codex lister d’abord le répertoire, pas seulement à modifier le code. La deuxième étape consiste à vérifier si le fichier est bloqué par '.gitignore', les règles de l’outil ou les permissions. La troisième étape consiste à s’assurer que vous n’utilisez pas Node pour Windows et npm pour exécuter les dépendances de projets WSL.
Si c’est un grand dépôt, vous pouvez d’abord spécifier le chemin : par exemple, « ne regardez que 'src/api' et 'package.json', ne scannez pas tout le dépôt ». Cela sauve le contexte et évite de tourner autour de répertoires sans importance.
La conclusion la plus stable
Codex est utilisé dans WSL, et il est préférable de garder trois éléments cohérents : le projet est placé dans le système de fichiers WSL, le terminal est lancé depuis le répertoire racine du projet, et le périmètre de modification est limité au dépôt actuel. Cela fait gagner du temps et est moins susceptible de causer le problème « il y a un fichier mais il est indiqué qu’il ne peut pas être trouvé ».
