Windows sandbox란 무엇일까요?

Codex에 작업 폴더 접근을 허용해도 Windows 전체에 접근할 수 있는 것은 아닙니다. Windows sandbox는 Codex 명령이 허용된 작업 영역을 벗어나지 못하도록 실행 범위를 제한합니다.

Windows용 Codex에서는 이 경계를 elevated와 unelevated 두 방식으로 적용합니다.

작업 범위와 sandbox 방식은 서로 다른 설정입니다

sandbox_mode와 elevated·unelevated는 역할이 다릅니다.

read-only, workspace-write, danger-full-access 같은 sandbox_mode는 Codex에 허용할 작업 범위를 정합니다. 파일을 읽기만 할 수 있는지, 작업 폴더 안에서 파일을 수정할 수 있는지를 이 설정으로 고릅니다.

반면 elevated와 unelevated는 Windows가 그 범위를 어떤 방식으로 적용할지 정합니다. sandbox_mode가 허용 범위를 정한다면, 두 방식은 그 범위를 지키는 방법을 정합니다.

elevated를 선택해도 workspace-write로 허용한 폴더 안에서는 Codex가 파일을 만들고 수정할 수 있습니다. sandbox는 작업 자체를 막는 장치가 아닙니다. 허용된 영역을 벗어난 변경을 제한하는 장치입니다.

elevated는 Codex용 Windows 계정을 따로 만듭니다

elevated를 처음 설정할 때는 관리자 승인이 필요합니다. 이 승인을 받아 CodexSandboxOffline과 CodexSandboxOnline이라는 Windows 사용자 계정을 만듭니다. 이후 실행 조건에 따라 둘 중 하나의 계정으로 Codex 명령을 실행합니다.

사용자가 이 계정으로 로그인하는 것은 아닙니다. Codex가 내부에서 명령을 실행할 때만 쓰는 계정입니다. 이렇게 현재 로그인한 사용자와 실행 주체를 분리한 뒤, 파일 권한과 firewall, Windows local policy를 함께 적용해 경계를 만듭니다.

elevated는 별도 계정만으로 경계를 만들지 않습니다. Windows에서 프로그램을 실행하면 실행 주체와 권한 정보가 담긴 access token이 함께 사용됩니다. 일종의 신분증입니다. elevated는 별도 계정의 token에서 불필요한 권한을 덜어낸 restricted token으로 명령을 실행합니다.

unelevated는 현재 사용자의 권한을 제한해 실행합니다

unelevated는 별도의 Windows 사용자 계정을 만들지 않습니다. 대신 현재 로그인한 사용자의 access token에서 권한을 제한해 restricted token을 만듭니다. Codex 명령은 이 token으로 실행됩니다.

ACL도 함께 작동합니다. token이 명령을 실행하는 쪽의 신분증이라면, ACL은 파일과 폴더에 붙은 출입 명단입니다. 누가 들어올 수 있고, 들어온 뒤 무엇을 할 수 있는지가 적혀 있습니다. restricted token과 ACL을 함께 적용하면 “이 폴더에는 쓸 수 있지만 저 폴더에는 쓸 수 없다”는 경계가 생깁니다.

unelevated도 sandbox입니다. 관리자 권한이 없거나 정책 때문에 별도 계정을 만들기 어려운 환경에서도 사용할 수 있도록 마련된 공식 fallback입니다.

실제로 파일을 써보면

Codex CLI 0.146.0에서 두 방식을 같은 조건으로 시험했습니다. Windows native codex sandbox와 PowerShell을 사용했고, permission profile은 :workspace로 맞췄습니다. sandbox 내부에서는 추가 승인을 허용하지 않았습니다.

방식명령을 실행한 사용자허용된 workspace 내부workspace 밖에 둔 같은 canary 폴더
elevatedCodexSandboxOffline파일 생성 성공쓰기 실패
unelevated현재 로그인한 사용자파일 생성 성공쓰기 실패

테스트에 사용한 canary 폴더에는 sandbox 밖에서 실행한 프로그램이 파일을 쓸 수 있었습니다. 폴더 자체가 원래 쓰기 금지였던 것은 아닙니다. 쓰기 실패는 두 sandbox가 적용된 경우에만 발생했습니다.

unelevated도 실제 filesystem 경계를 적용했습니다. 다만 어느 방식을 선택하든 workspace-write로 허용한 작업 폴더 안의 변경은 막지 않습니다.

둘 다 막았다면 무엇이 다를까

이번 관측에서는 두 방식이 같은 결과를 보였습니다. workspace 안에는 쓸 수 있었고, 바깥에는 쓰지 못했습니다. 하지만 이 결과만으로 격리 구조나 전체 보안 강도까지 같다고 볼 수는 없습니다.

elevated는 현재 사용자와 분리된 별도 계정으로 명령을 실행합니다. 파일 권한과 Windows local policy도 함께 적용합니다. network를 허용하지 않는 경우에는 offline 전용 사용자에 적용할 WFP filter를 설치합니다. WFP는 Windows가 network 통신을 걸러낼 때 사용하는 기능입니다.

unelevated는 현재 사용자의 token에서 권한을 제한합니다. network를 허용하지 않는 경우에는 loopback proxy를 두고 package manager를 offline mode로 바꿉니다. Git proxy와 SSH 차단 설정 등도 적용합니다.

두 방식은 구현부터 다릅니다. 다만 이번에 직접 확인한 범위는 filesystem 쓰기 경계뿐입니다. 실제 network 차단 효과와 공격 우회 난이도까지 비교하지는 않았습니다.

무엇을 선택하면 될까

OpenAI의 Windows sandbox 문서는 elevated를 우선 선택할 방식으로 안내합니다. 관리자 승인이 가능하고 특별한 호환성 문제가 없다면 elevated가 기본 선택입니다.

회사 정책이나 관리자 권한 문제로 초기 설정을 진행할 수 없다면 unelevated를 선택할 수 있습니다. 그렇다고 unelevated를 곧바로 위험한 방식으로 볼 필요는 없습니다. 제한된 token과 ACL로 경계를 만드는 sandbox이며, 직접 관측에서도 허용한 workspace 밖의 파일 쓰기를 막았습니다.

설정은 나중에도 바꿀 수 있습니다. 개인 설정 파일인 ~/.codex/config.toml에서 다음 값을 지정합니다.

[windows]
sandbox = "elevated"

필요하다면 값을 "unelevated"로 바꾸면 됩니다.

선택 기준은 간단합니다. 관리자 설정이 가능하면 별도 계정을 사용하는 elevated, 어렵다면 현재 사용자의 권한을 제한하는 unelevated를 선택하면 됩니다. 어느 쪽을 고르든 Codex에 허용할 작업 범위는 sandbox_mode에서 따로 정합니다.

참고한 문서