Quick Comparison
Windows 앱은 PowerShell과 native Windows sandbox로 WSL이나 VM 없이도 실행할 수 있다. Linux-native workflow가 이미 WSL2에 있거나 native sandbox가 맞지 않을 때만 WSL2로 옮긴다.
| 실행 위치 | 먼저 고를 상황 | 핵심 제약 |
|---|---|---|
| Windows native PowerShell | Visual Studio, MSBuild, .ps1, Windows path 중심 | sandbox 구현과 Windows 정책이 준비돼야 한다. |
| WSL2 | Linux CI, Bash, symlink·권한·Linux toolchain 중심 | native Windows sandbox가 아니라 Linux 환경에서 실행된다. |
unelevated native sandbox | elevated 설정이 조직 정책에 막힌 임시 경우 | 더 약한 filesystem·network 격리이므로 장기 기본값으로 삼지 않는다. |
Windows native sandbox 설정
native Windows sandbox는 project folder 밖의 filesystem write와 승인 없는 network access를 막는다. elevated는 별도 저권한 sandbox user, firewall rule, local policy를 사용하므로 권장되는 구현이다. unelevated는 현재 user에서 파생한 제한 token과 ACL 경계로 동작하는 fallback이며, 강도는 더 낮지만 조직 정책 때문에 elevated를 준비하지 못한 경우 계속 작업할 수 있다.
# config.toml
[windows]
sandbox = "elevated" # 또는 임시 fallback인 "unelevated"elevated가 실패하면 먼저 UAC 또는 administrator prompt, local user·group 생성, firewall rule, sandbox user logon right를 막는 enterprise policy를 확인한다. full access로 바꿔 문제를 덮으면 project directory 밖까지 의도치 않은 수정이 가능해진다. 필요한 외부 directory는 현재 session에서만 read access를 추가한다.
/sandbox-add-read-dir C:\absolute\directory\pathWSL2를 고르는 기준
WSL2에서는 Codex가 native Windows sandbox 대신 Linux environment에서 실행된다. Linux toolchain과 Bash script가 기준이거나 repository와 개발 흐름이 이미 WSL2 안에 있을 때 적합하다. WSL1은 Codex 0.115부터 지원되지 않으므로 WSL2를 사용한다.
# WSL shell
cd ~/code/your-project
codexrepository는 /mnt/c/...보다 ~/code/...처럼 Linux home 아래에 둔다. Windows-mounted path는 I/O가 느리고 symlink·permission 문제가 섞일 수 있다. 한 repository를 PowerShell과 WSL에서 번갈아 실행해야 한다면 AGENTS.md에 기준 shell과 build·test 명령을 적고, lockfile·line ending·path 문제가 어느 환경에서 생겼는지 함께 기록한다.
Windows native와 WSL2는 같은 shell만 다른 환경이 아닙니다. sandbox 구현, 경로, 권한, filesystem 성능이 달라집니다. 팀에서 한 repository의 기준 환경을 정하지 않으면 재현 가능한 검증 명령을 유지하기 어렵습니다.
참고 링크
2 sources