Windows에서 Codex가 PowerShell과 충돌하는 문제 — 대신 Linux 컨테이너에서 실행하세요

코딩 에이전트의 셸 명령어 실패 원인: Windows와 PowerShell의 차이점

만약 코딩 에이전트를 Windows에서 충분히 오래 실행해 본다면, 하나의 패턴을 발견할 수 있습니다. 에이전트는 셸 명령어를 작성하고, 실패하며, 명령어를 재작성하고, 다시 실패하는 과정을 세네 번 반복한 후에야 비로소 작동하는 것을 찾아냅니다. 반면 macOS나 Linux에서는 같은 작업이 보통 첫 시도에 성공합니다.

모델을 탓하기 쉽지만, 대개 문제는 모델 자체가 아닙니다. 바로 그 아래의 셸 계층(shell layer) 때문입니다.

실제 발생하는 문제점

Windows 네이티브 환경에서 Codex는 사용자가 입력한 명령어를 OS에 단순한 argv 리스트로 전달하지 않습니다. 외부 CLI 명령어들은 PowerShell을 통해 감싸져 실행됩니다. 이는 직접적인 호출 방식보다는 pwsh.exe -Command "your-command ..." 형태에 가깝습니다 (#15294).

이러한 단일 설계 결정은 여러 문제로 이어집니다:

• 따옴표 처리 및 이스케이프(Quoting and escaping). PowerShell은 자체적인 따옴표 규칙을 가지고 있습니다. bash에서는 완벽하게 유효한 명령이라도 여기서는 다른 형태의 이스케이프 처리가 필요할 수 있으며, 모델은 어떤 방언(dialect)으로 작성해야 할지 추측해야 합니다.
• 권한 규칙 불일치. 모든 명령어가 PowerShell 래퍼로 재작성되기 때문에, "dotnet으로 시작하는 모든 것"과 같은 허용 규칙(allow-rules)이 신뢰성 있게 일치하지 않습니다 (#8537). 이것이 많은 Windows 사용자들이 모든 명령어를 승인하게 되는 이유입니다 (#2860, 77개의 댓글).
• 기본 파일 작업도 셸을 거칩니다. 읽기(read)/쓰기(write)/검색 같은 기본적인 작업조차 내부 도구로 처리되기보다는 PowerShell 작업으로 보고되었습니다 (#3800).
• 환경 변수 누출(Environment leaks). 자식 프로세스로 실행되는 powershell.exe는 PowerShell 7의 PSModulePath를 상속받을 수 있으며, 이는 모듈 검색을 방해하여 심지어 Get-FileHash조차 사용할 수 없게 만듭니다 (#27117).
• 샌드박싱(Sandboxing)이 불안정합니다. 샌드박스된 PowerShell 명령어는 명령어가 실행되기 전에도 간헐적으로 실패하는 경우가 있습니다 (#25497).

• 노이즈가 심합니다. 모든 명령을 실행할 때마다 콘솔 창이 깜빡입니다 (#48074, #48422).

요청은 계속해서 들어옵니다. 사람들은 구성 가능한 Windows 셸을 반복적으로 요청해 왔습니다 (#16717, #31548, #16579). 이는 커뮤니티가 이미 명백한 결론에 도달했음을 보여줍니다: 문제가 있는 것은 셸 계층이지, 작업 자체가 아닙니다.

재시도 루프가 실제로 비용을 발생시킵니다

실패한 명령은 단순히 낭비된 몇 초가 아닙니다. 에이전트는 왜 실패했는지 추론하고, 다른 명령을 생성하며, 다시 시도해야 합니다. 각 왕복 과정에는 전체 컨텍스트가 포함됩니다. Windows 환경에서는 이 일이 작업당 여러 번 발생할 수 있으며, 그 모든 것이 토큰과 사용자의 주의력으로 비용 청구됩니다.

일반적인 해결책들과 그 비용

• WSL. 작동은 하지만, 이제 두 개의 환경을 유지해야 하며, 에이전트가 프로젝트가 실제로 존재하는 곳에서 실행될지 아닐지 알 수 없습니다.
• 기본 셸로 Git Bash 사용으로 전환. Codex는 Git Bash → PowerShell을 혼란스러운 방식으로 연결하는 것으로 보고되었습니다 (#7298).
• 모든 것을 승인하기. 빠르지만, 들리는 것만큼이나 나쁜 생각입니다.
• 설정 옵션이 나올 때까지 기다리기. 합리적이지만, 다른 사람의 로드맵에 막혀 있습니다.

다른 접근 방식: Windows에서 에이전트 실행 중단

TaskHandoff는 로컬 및 원격 머신 전반에 걸쳐 AI/Codex 작업 공간을 실행하고 관리하기 위한 오픈 소스 제어 평면(Apache-2.0)입니다. 호스트 셸과 싸우는 대신, 각 세션은 관리되는 Linux Docker 워크스페이스 내부에서 실행되며, 사용자는 단일 콘솔에서 이를 구동합니다.

구체적으로 이는 다음을 의미합니다:

• 에이전트는 하부 머신이 Windows, macOS, 또는 Linux 중 무엇이든 항상 동일한 bash 환경을 보게 됩니다.
• Docker 워크스페이스는 일급 객체(first-class objects)처럼 생성되고, 시작되며, 중지되고, 복원됩니다. 더 이상 '내 다른 컴퓨터에서는 됐는데'라는 문제가 없습니다.
• **환경 템플릿(Environment templates)**을 사용하면 컨테이너의 툴체인(toolchain)을 스냅샷하고 재사용할 수 있어, 작동하는 설정이 프로젝트마다 다시 발견될 필요가 없습니다.
• **멀티 노드 관리(Multi-node management)**는 로컬 및 원격 머신들을 하나의 보드에 배치합니다. Linux 박스에서 무거운 작업을 실행하면서도 Windows 노트북으로 제어할 수 있습니다.
• **AI 세션 센터(AI session center)**는 WebSocket을 통해 세션 상태를 실시간으로 스트리밍합니다.

모델에게 PowerShell을 가르칠 필요가 없습니다. 그냥 묻지 않으면 됩니다.

빠른 시작

curl -fsSL https://github.com/edgestorage/task-handoff/releases/latest/download/install-server.sh | sudo sh

데스크톱 앱과 서버(Debian/Ubuntu의 systemd) 형태로 배포되며, 영어/중국어 UI를 지원합니다.

• 레포지토리: https://github.com/edgestorage/task-handoff
• 문서: https://docs.thandoff.com/

솔직한 주의사항

워크스페이스를 컨테이너에서 실행한다고 해서 모든 Windows 문제를 마법처럼 해결해 주는 것은 아닙니다. 만약 프로젝트가 진정으로 Windows 전용 툴링(tooling)을 필요로 한다면, Windows 노드가 필요할 것입니다. 하지만 에이전트가 셸 구문 및 권한에 대해 루프를 돌리는 대규모 작업의 경우, 호스트 셸(host shell)을 방정식에서 제거하는 것이 오늘날 이용 가능한 가장 저렴한 해결책입니다.