Codex doesn't read the project in WSL, so don't rush to reinstall it. The most common reason is that you switch back and forth between the Windows path, the WSL path, and the Codex sandbox scope, causing it to see a working directory that is not the same as the project directory you think.
Confirm which directory you are launching first
Execute 'pwd' in the terminal and then 'ls'. If the path is '/mnt/c/Users/...', you are accessing the Windows disk in WSL; If it's '/home/xxx/project', it's the WSL Linux file system. Many dependencies, permissions, and listening behaviors behave differently under these two paths.
It is recommended to place the project you want to change under '/home/username/' in WSL and start Codex from the project root. Don't open a Windows project in one terminal and let Codex read another WSL project.
Look at the sandbox scope again
Local editing and command execution of Codex is affected by current directory, permission patterns, and sandbox constraints. You change it to '/mnt/d/other-project', but the startup directory is in '/home/me/app', it may not be directly accessible or should not be accessed.
A more stable approach is to enter the root directory of the project before starting it: first 'cd ~/projects/my-app', make sure that 'git status' can see the repository, and then let Codex analyze the directory structure.
How to troubleshoot if the document is still unreadable
The first step is to let Codex list the directory first, not just let it change the code. The second step is to check if the file is blocked by '.gitignore', tool rules, or permissions. The third step is to make sure that you do not use Node for Windows and npm to run WSL project dependencies.
If it is a large repository, you can specify the path first: for example, "only look at 'src/api' and 'package.json', do not scan the entire repository". This saves context and avoids circling in irrelevant directories.
The most stable conclusion
Codex is used in WSL, and it is best to keep three things consistent: the project is placed in the WSL file system, the terminal is started from the project root directory, and the modification scope is limited to the current repository. This saves time and is less likely to cause the problem of "there is a file but it says it can't be found".
