빠른 비교
| 실행 위치 | 적합한 상황 |
|---|---|
| PowerShell 네이티브 | Windows 도구, .NET, Visual Studio, PowerShell 스크립트 중심 |
| WSL2 | Linux toolchain, bash script, Linux CI와 같은 환경 재현 |
| 둘 다 사용 | 저장소별로 기준을 문서화하고 섞어 쓰지 않기 |
선택 기준
PowerShell 네이티브는 Windows 프로젝트에 맞다
Windows 전용 도구, Visual Studio, MSBuild, PowerShell 스크립트, Windows 경로를 쓰는 프로젝트는 PowerShell에서 Codex를 실행하는 편이 자연스럽습니다. 이 경우 Codex는 Windows sandbox와 PowerShell 명령 체계를 기준으로 동작합니다. .ps1, .sln, .csproj, Windows batch 파일이 많은 저장소에서는 네이티브 실행이 검증 명령과 더 잘 맞습니다.
cd E:\Works\Project
codexWindows에서는 줄끝, 경로 구분자, quoting 규칙이 Linux와 다릅니다. 검증 명령을 AGENTS.md에 PowerShell 기준으로 명시해 두면 Codex가 잘못된 shell 문법을 시도하는 일을 줄일 수 있습니다.
WSL2는 Linux 배포 환경 재현에 맞다
프로덕션이나 CI가 Linux이고, npm/bash/python/ruby 같은 도구가 Linux 기준으로 동작한다면 WSL2가 더 안정적일 수 있습니다. 특히 shell script, symlink, executable bit, Linux path에 의존하는 프로젝트는 Windows 네이티브보다 WSL2에서 재현성이 높습니다.
cd ~/work/project
codex다만 WSL2 안에서 Windows 파일 시스템 경로를 직접 작업하면 파일 I/O가 느려지거나 권한·줄끝 문제가 섞일 수 있습니다. Linux 프로젝트는 가능하면 WSL 파일 시스템 안에 두고 작업하는 편이 낫습니다.
한 저장소에서 실행 기준을 섞으면 검증이 흔들린다
같은 저장소를 어떤 날은 PowerShell에서, 어떤 날은 WSL2에서 실행하면 lockfile, line ending, path, shell command가 흔들릴 수 있습니다. 팀 프로젝트에서는 AGENTS.md나 개발 문서에 "이 저장소의 Codex 기준 shell"을 적어 두는 것이 좋습니다.
AGENTS.md 예
Run and test
- Windows 기준: PowerShell에서 npm.cmd run build
- WSL 기준: bash에서 npm run build
- 두 환경을 섞어 실행하지 않는다Codex가 실패했을 때도 먼저 "현재 실행 위치가 PowerShell인가, WSL인가"를 확인해야 원인 진단이 빨라집니다.
운영 기준
| 상황 | 먼저 고를 실행 위치 |
|---|---|
| .NET/Visual Studio 중심 | PowerShell |
| Linux CI 재현 | WSL2 |
| bash script가 많음 | WSL2 |
| PowerShell script가 많음 | PowerShell |
| Windows GUI 도구 연동 | PowerShell |
| 경로/줄끝 오류 반복 | 실행 기준 문서화 |
주의할 점
Windows에서 Codex를 쓸 때 가장 흔한 문제는 Codex 자체보다 shell 기준이 섞이는 것입니다. PowerShell과 WSL2는 경로, quoting, 권한, 줄끝 처리가 다릅니다. 저장소별 기준 shell과 검증 명령을 AGENTS.md에 명시하는 편이 안전합니다.
권한 설정도 실행 환경마다 다르게 체감될 수 있습니다. 네트워크, writable root, 외부 명령 승인이 필요한 작업은 /status나 설정 파일로 현재 sandbox와 approval 상태를 확인한 뒤 진행합니다.
참고 링크
3 sources