코덱스는 WSL에서 프로젝트를 읽지 않으니 서두르지 마세요. 가장 흔한 이유는 Windows 경로, WSL 경로, 코덱스 샌드박스 범위를 번갈아 가면서 작업 디렉터리가 당신이 생각하는 프로젝트 디렉터리와 다르게 보이기 때문입니다.
먼저 어떤 디렉토리를 시작하는지 확인하세요
터미널에서 'pwd'를 실행한 후 'ls'를 실행하세요. 경로가 '/mnt/c/Users/...'라면, WSL에서 윈도우 디스크에 접근하는 것입니다; 만약 '/home/xxx/project'라면, WSL 리눅스 파일 시스템입니다. 이 두 경로 하에서는 많은 의존성, 권한, 청취 동작이 다르게 동작합니다.
변경하고 싶은 프로젝트를 WSL의 '/home/username/' 아래에 넣고 프로젝트 루트에서 Codex를 시작하는 것이 좋습니다. 한 터미널에서 윈도우 프로젝트를 열고 Codex가 다른 WSL 프로젝트를 읽게 하지 마세요.
다시 샌드박스 스코프를 봐
코덱스의 로컬 편집과 명령 실행은 현재 디렉터리, 권한 패턴, 샌드박스 제약 조건에 의해 영향을 받습니다. '/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'만 보고, 전체 저장소를 스캔하지 마세요"라고 할 수 있습니다. 이렇게 하면 맥락을 절약하고 관련 없는 디렉터리에 동그라미 끼우는 것을 방지할 수 있습니다.
가장 안정적인 결론
코덱스는 WSL에서 사용되며, 세 가지를 일관되게 유지하는 것이 가장 좋습니다: 프로젝트는 WSL 파일 시스템에 배치되고, 터미널은 프로젝트 루트 디렉터리에서 시작되며, 수정 범위는 현재 저장소로 제한됩니다. 이렇게 하면 시간을 절약할 수 있고, '파일이 있는데 찾을 수 없다'는 문제가 생길 가능성도 줄어듭니다.
