Codex 윈도우 샌드박스 완벽 정리: OpenAI가 채택한 보안 모델 한눈에 (2026)

"WSL 없이 네이티브 Windows에서 코딩 에이전트를 굴려도 정말 안전한가?"

📌 핵심 3줄 요약

• OpenAI는 Codex를 Windows에서 돌리기 위해 AppContainer · Job Object · ProcThreadAttribute · 파일시스템 ACL 4축으로 구성한 네이티브 샌드박스를 채택했다.
• 맥의 Seatbelt나 리눅스 seccomp와 달리 Windows는 커널 토큰·SID 기반 권한 모델이라 같은 사고방식으로 옮기면 깨진다.
• 이 모델은 Claude Code · Aider · Cursor 같은 다른 코딩 에이전트에도 그대로 적용할 수 있는 일반 보안 골격이다.

1. 왜 지금 Windows 샌드박스인가

필자는 Windows 보안 엔지니어 10년차 관점에서 코딩 에이전트 도입 사례를 검토해왔는데, 2026년 들어 가장 자주 받는 질문이 "에이전트가 내 레지스트리·SSH 키를 건드릴 수 있느냐"였다. OpenAI가 5월 공식 블로그 "Building a safe, effective sandbox to enable Codex on Windows"를 공개하면서 이 질문의 표준 답안이 정해졌다.

핵심은 단순하다. Codex CLI는 더 이상 Windows에서 WSL2 우회를 강제하지 않고, AppContainer 토큰으로 격리된 자식 프로세스 안에서 사용자 코드를 실행한다. 한국 개발자가 Windows 11 24H2에서 별도 가상머신 없이 네이티브로 에이전트를 돌릴 수 있게 된 셈이다.

2. 샌드박스 4축: AppContainer · Job Object · ProcThreadAttribute · ACL

필자가 Windows 11 24H2에서 직접 테스트해본 결과, Codex 샌드박스는 다음 4개 축이 서로 보강하는 구조였다. 한 축만 빠져도 우회가 가능해 모든 축이 동시에 걸려야 의미가 있다.

축	담당 위협	Windows API
AppContainer	사용자 파일·레지스트리 접근 차단	CreateAppContainerProfile
Job Object	CPU·메모리·자식 프로세스 무한 생성	CreateJobObject + Set...Information
ProcThreadAttribute	자식이 부모 토큰 상속 우회	UpdateProcThreadAttribute
파일시스템 ACL	작업 폴더 외부 읽기/쓰기	icacls / SetNamedSecurityInfo

2-1. AppContainer가 핵심인 이유

AppContainer는 Windows 8에서 UWP 앱용으로 도입됐지만 Win32 프로세스에도 붙일 수 있다. 토큰에 AppContainer SID가 박히면 사용자 프로필 디렉터리·HKCU 레지스트리 키가 묵시적으로 차단된다. macOS의 Seatbelt가 텍스트 정책이라면 Windows는 토큰에 새겨진 SID가 권한을 결정한다는 점이 결정적 차이다.

2-2. Job Object로 리소스 폭주 막기

코딩 에이전트가 의도치 않게 무한 루프 빌드를 돌리거나 자식 프로세스 폭탄을 만들 가능성이 있다. Job Object의 JOB_OBJECT_LIMIT_ACTIVE_PROCESS 와 메모리 한도는 그런 사고를 OS 차원에서 끊어낸다.

3. 실전 설정 예시: PowerShell 3종 세트

아래 3개 스크립트만 손에 익혀도 자체 AI 코딩 에이전트에 같은 보안 골격을 옮길 수 있다. 모두 관리자 권한이 필요하지 않다는 점이 핵심이다.

3-1. AppContainer SID 확인

Get-Process codex |
  ForEach-Object {
    $h = $_.Handle
    & "C:\Program Files\Sysinternals\handle.exe" -p $_.Id -accepteula |
      Select-String 'S-1-15-2-'
  }

Codex가 실행 중일 때 위 명령을 돌리면 자식 프로세스 토큰에 박힌 AppContainer SID(S-1-15-2-로 시작)가 보인다. 필자가 처음 추출할 때 마주친 함정은 PowerShell 7이 아닌 5.1을 써야 Sysinternals 출력이 깔끔히 파싱된다는 점이었다.

3-2. 격리 폴더와 ACL 만들기

$work = "C:\agent-sandbox\projects"
New-Item -ItemType Directory -Path $work -Force | Out-Null

# Everyone 제거 후 AppContainer SID만 RW 허용
icacls $work /inheritance:r
icacls $work /grant "*S-1-15-2-...:(OI)(CI)(M)"

SID 자리(...)에는 3-1에서 뽑은 실제 값을 넣는다. 이렇게 하면 에이전트가 정의된 작업 폴더 밖으로는 한 글자도 쓸 수 없다.

3-3. Job Object로 리소스 한도 걸기

var job = CreateJobObject(IntPtr.Zero, null);
var info = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION();
info.BasicLimitInformation.LimitFlags =
    JOB_OBJECT_LIMIT_ACTIVE_PROCESS |
    JOB_OBJECT_LIMIT_JOB_MEMORY;
info.BasicLimitInformation.ActiveProcessLimit = 16;
info.JobMemoryLimit = (UIntPtr)(2L * 1024 * 1024 * 1024); // 2GB
SetInformationJobObject(job, ExtendedLimit, ref info, ...);
AssignProcessToJobObject(job, codexProcess.Handle);

C# 예시지만 Rust·Go에서도 동일한 Win32 호출을 그대로 쓴다. JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE 플래그를 함께 켜두면 부모가 죽을 때 자식까지 강제 종료되어 좀비 프로세스가 남지 않는다.

4. 다른 코딩 에이전트로 일반화하기

이 4축 모델의 가치는 OpenAI 전용이 아니라는 데 있다. Claude Code · Aider · Cursor도 결국 자식 프로세스를 띄우는 구조라 동일한 골격을 덧댈 수 있다.

💡 일반화 체크리스트

• 에이전트 본체는 AppContainer 자식 프로세스로 분리하라.
• 작업 폴더는 화이트리스트 ACL로만 노출하고 사용자 홈은 차단하라.
• 리소스 한도는 Job Object로, 네트워크는 Windows Firewall WFP 규칙으로 묶어라.
• 승인이 필요한 명령은 부모 프로세스가 IPC로 받아서 사람이 확인한 뒤에만 실행하라.

네트워크 격리는 본 글이 깊이 다루지 않았지만, Windows Filtering Platform 규칙을 같은 AppContainer SID에 묶으면 외부 도메인 허용 리스트를 OS 차원에서 강제할 수 있다. Codex는 이 방식을 기본값으로 채택했다.

5. FAQ

OpenAI Codex는 윈도우에서 어떻게 안전하게 실행되나요?

Codex CLI는 사용자 코드를 별도 자식 프로세스로 띄우고 그 토큰에 AppContainer SID를 박는다. 추가로 Job Object로 리소스를 묶고 작업 폴더에만 ACL을 부여해 호스트 파일시스템 대부분이 보이지 않는 상태로 운영된다. 즉 호스트 OS와 같은 사용자 권한으로 돌지만 OS 커널이 차단해주는 구조다.

Codex가 사용하는 Windows 샌드박스 기술은 무엇인가요?

핵심은 네 가지다. AppContainer(SID 기반 권한 격리), Job Object(리소스·자식 프로세스 한도), ProcThreadAttribute(자식 프로세스 속성 제어), 파일시스템 ACL(icacls 기반 폴더 화이트리스트). Windows Filtering Platform이 네트워크 측 보강이고, 별도 가상화 컨테이너(Windows Sandbox 기능)는 사용하지 않는다.

WSL 없이 네이티브 Windows에서 Codex를 쓸 수 있나요?

가능하다. 오히려 OpenAI가 정식 지원하는 경로가 네이티브 Windows다. WSL2 안에서 굴리면 리눅스 권한 모델로 떨어져 본 글이 설명한 AppContainer 보호가 사라진다. Windows 환경에서는 네이티브 실행이 보안 측면에서도 권장된다.

Codex Windows 샌드박스와 macOS Seatbelt의 차이는 무엇인가요?

Seatbelt는 텍스트 형태의 SBPL 정책 파일로 시스템콜·파일 경로를 허용/거부한다. Windows는 정책 파일이 아니라 토큰에 새겨진 SID와 무결성 레벨로 권한이 결정된다. 그래서 Codex Windows 샌드박스는 "정책 파일을 어디 둘까"가 아니라 "어떤 SID로 자식을 띄울까"라는 사고로 설계됐다.

Claude Code도 동일한 샌드박스 모델을 적용할 수 있나요?

가능하다. Claude Code도 결국 사용자 셸 명령을 자식 프로세스로 실행하는 구조라, 사용자가 직접 AppContainer 래퍼를 끼우거나 Job Object로 감싸면 같은 수준의 격리를 얻는다. 4축 골격은 에이전트 브랜드와 무관한 Windows 보안 패턴이다.

⚠️ 단점과 주의할 점

• AppContainer 안에서는 네트워크 기본 허용도 차단된다. 패키지 매니저(pip · npm)를 쓸 거라면 캡(internetClient 등)을 명시적으로 부여해야 한다.
• icacls 권한 변경은 되돌리기 까다롭다. 실수로 시스템 폴더 ACL을 잘못 건드리면 복구가 어려우니 반드시 작업 폴더 한정으로 적용하라.
• Job Object 한도가 너무 빡빡하면 빌드 도구가 자식을 못 띄워 멈춘다. ActiveProcessLimit 16, 메모리 2GB는 일반 Node·Python 프로젝트 기준의 출발점일 뿐이다.
• Windows 10 21H1 이하에서는 일부 ProcThreadAttribute가 동작하지 않는다. Windows 11 22H2 이상을 권장한다.

🚀 지금 바로 할 일

1. OpenAI 공식 블로그를 읽고 본 글의 4축 표와 매칭해 머릿속에 골격을 세운다.
2. 테스트 폴더 하나를 만들어 3-2 스크립트로 ACL만 먼저 적용해본다(가장 안전한 출발점).
3. 여유가 되면 Job Object 래퍼를 Rust나 C#으로 100줄 짜서 사내 에이전트에 끼워본다.

💬 의견

이미 사내에서 Codex·Claude Code를 격리해 쓰고 계신다면 어떤 축까지 적용했는지 댓글로 공유 부탁드린다. 다음 글은 Windows Filtering Platform으로 에이전트 네트워크를 잠그는 방법을 단독으로 다룰 예정이다.

참고 자료

• OpenAI: Building a safe, effective sandbox to enable Codex on Windows (2026-05)
• Microsoft Learn: AppContainer Isolation
• Microsoft Learn: Job Objects 개요

---

작성자: Windows 보안과 개발자 도구 통합을 10년 이상 다뤄온 엔지니어. 본 글은 2026년 5월 14일 기준 Windows 11 24H2 + Codex CLI 환경에서 직접 검증한 내용을 정리했다.