Windows에서 Codex를 활성화하기 위한 안전하고 효과적인 샌드박스 구축

제가 2025년 9월 Codex 엔지니어링 팀에 합류했을 때, Windows용 Codex는 샌드박스 (sandbox) 구현이 되어 있지 않았습니다. 이는 Windows 사용자들이 OpenAI의 코딩 에이전트 (coding agents)를 사용할 때 두 가지 미흡한 옵션 중 하나를 강제로 선택해야 함을 의미했습니다.

• 코딩 에이전트가 실행하고자 하는 거의 모든 명령(읽기 작업 포함)을 승인하는 것인데, 이는 비효율적이고 번거롭습니다. Codex를 사용하는 주요 이점은 모든 지루한 작업을 직접 할 필요가 없다는 점입니다.
• 전체 액세스 (Full Access) 모드를 활성화하는 것인데, 이는 승인이나 제한 없이 Codex가 모든 명령을 실행하도록 허용하여 감독을 희생하는 대신 마찰을 제거합니다.

우리의 코딩 에이전트인 __Codex__는 CLI, IDE 확장 프로그램 또는 데스크톱 앱을 통해 개발자의 노트북에서 실행됩니다. Codex는 키보드 앞의 인간과 추론 (inference)을 처리하기 위해 클라우드에서 실행되는 모델 사이의 대화를 관리합니다.

Codex는 기본적으로 실제 사용자의 권한으로 실행되므로, 사용자가 할 수 있는 모든 것을 할 수 있음을 의미합니다. 이는 강력하지만 잠재적으로 위험할 수 있습니다. 코딩 모델은 테스트 실행부터 파일 읽기 또는 편집, Git 브랜치 생성에 이르기까지 로컬에서 명령을 실행하도록 하네스 (harness)에 지시할 수 있으므로, Codex의 기본 모드는 효과성과 안전성 사이의 적절한 균형을 찾으려고 시도합니다. 이 기본 모드를 통해 Codex는 거의 모든 곳의 파일을 읽을 수 있고, 사용자가 명시적으로 요청하지 않는 한 인터넷 접속 없이 워크스페이스(즉, Codex를 실행 중인 디렉토리) 내에서 파일을 작성할 수 있습니다. 파일 작성 및 네트워크 액세스를 안전한 범위 내로 자동 제한하기 위해서는, 이러한 제약 사항을 실제로 강제하는 샌드박스 (sandbox) 환경이 필요합니다.

*샌드박스 (sandbox)*는 제한된 실행 환경입니다. 개발자가 Codex를 사용할 때, 컴퓨터의 운영 체제 (OS)는 권한이 축소된 명령을 실행하며, 이러한 제약 사항은 프로세스 트리 (process tree)를 따라 전파됩니다. 모든 Codex 명령은 시작부터 샌드박스 처리되며, 모든 하위 프로세스는 동일한 경계 내에 머무릅니다.

Codex가 효과적인 샌드박스 (sandbox)를 구현하기 위해서는 컴퓨터의 운영체제 (operating system)에 의해 강제되는 격리 기능이 필요합니다. 일부 운영체제는 이를 잘 수행하는 유틸리티를 제공합니다 (예: macOS의 Seatbelt, Linux의 seccomp 또는 bubblewrap). 하지만 Windows는 현재 이러한 유형의 기능을 기본적으로 (out of the box) 제공하지 않습니다.

Codex를 다른 모든 곳에서와 마찬가지로 Windows에서도 안전하고 즐겁게 사용할 수 있도록 만들기 위해, 우리는 자체적인 샌드박스를 구현해야 했습니다.

Windows는 격리를 위한 몇 가지 도구와 프리미티브 (primitives)를 제공합니다. 그 중 어느 것도 우리의 요구사항을 완전히 충족하지는 못했지만, 우리는 여러 잠재적인 솔루션, 즉 AppContainer, Windows Sandbox, 그리고 강제 무결성 제어 (Mandatory Integrity Control) 레이블링을 검토했습니다.

AppContainer

무엇인가 (What): AppContainer는 Windows의 네이티브 샌드박스로, 자신이 무엇에 접근해야 하는지 사전에 정확히 알고 있는 앱들을 위해 구축된 기능 기반 (capability-based) 격리 모델입니다.
왜 매력적인가 (Why): 최선(best-effort)을 다하는 제한 방식이 아닌, 실제 OS 경계를 제공하기 때문에 매력적입니다.
왜 아닌가 (Why not): Codex는 하나의 엄격하게 범위가 제한된 앱이 아닙니다. Codex는 셸 (shells), Git, Python, 패키지 매니저 (package managers), 빌드 도구 (build tools), 그리고 에이전트가 필요하다고 판단하는 기타 바이너리 (binaries) 등 개방형 개발자 워크플로 (workflows)를 구동합니다. 실제로 이러한 특성 때문에 AppContainer는 이 문제에 적합한 형태가 아니었습니다. 강력한 격리였지만, "에이전트가 개발자처럼 작동하도록 허용한다"는 목적보다는 훨씬 더 좁은 범위의 워크로드 (workloads)를 위한 것이었습니다.

Windows Sandbox

무엇인가 (What): Windows Sandbox는 Microsoft의 일회용 경량 가상 머신 (VM)입니다. 강력한 격리 경계가 있는 새로운 Windows 데스크톱을 사용할 수 있으며, 그 안에서 수행하는 모든 작업은 세션이 종료되면 사라집니다.
왜 매력적인가 (Why): 분명한 이유로 흥미롭습니다. AppContainer보다 임의의 소프트웨어와 훨씬 더 호환성이 높으며, 보안 관점에서도 훨씬 더 강력한 상자입니다.
왜 아닌가 (Why not): Codex는 설정과 호스트/게스트 브릿징 (host/guest bridging)이 필요한 별도의 일회용 데스크톱 내부가 아니라, 사용자의 실제 체크아웃 (checkout), 도구 및 환경에서 직접 작동해야 합니다. 또한 근본적인 제품 문제도 있었습니다. Windows Sandbox는 Windows Home SKU에서는 사용할 수조차 없습니다.

Mandatory Integrity Control (MIC) 무결성 레이블링 (integrity labeling)

무엇인가 (What): Windows에는 시스템이 객체와 프로세스를 얼마나 신뢰할지를 결정하는 low, medium, high와 같은 "무결성 수준 (integrity levels)"이라는 개념이 있습니다. 기본 규칙은 낮은 무결성 프로세스가 일반적인 ACL (Access Control List)에서 허용하더라도, 더 높은 무결성 수준을 가진 객체에는 쓸 수 없다는 것입니다. 예를 들어, low-integrity 프로세스는 신뢰도가 낮은 것으로 간주되므로, 해당 객체들이 이를 허용하도록 명시적으로 레이블이 다시 지정되지 않는 한 Windows는 해당 프로세스가 일반적인 medium-integrity 객체에 쓰는 것을 차단합니다.

이유 (Why): MIC는 이론적으로는 우아해 보였습니다. Codex를 low integrity로 실행하고, 쓰기가 가능한 루트(roots)들을 low integrity로 레이블을 다시 지정한 뒤, Windows가 그 외의 모든 곳에 대해 쓰기를 방지하도록 강제하는 방식입니다. 그렇게 했다면 실제 OS 메커니즘을 기반으로 한 관리자 권한이 필요 없는 경로를 확보할 수 있었을 것입니다.

안 되는 이유 (Why not): ACL과 마찬가지로, 무결성 레이블은 실제 호스트 파일 시스템을 수정하며, 이 경우에는 의미론적(semantic) 변화가 특히 광범위합니다. 워크스페이스를 low integrity로 표시하는 것은 단순히 "Codex가 여기에 쓸 수 있다"는 것만을 의미하지 않습니다. 이는 일반적인 low-integrity 프로세스들이 그곳에 쓸 수 있음을 의미합니다. 실제 개발자 머신에서 이는 사용자의 실제 체크아웃(checkout) 디렉토리를 호스트를 위한 low-integrity 싱크(sink)로 만들어 버리며, 이는 하나의 샌드박스 설계를 위해 신중하게 타겟팅된 ACL을 부여하는 것보다 훨씬 더 위험합니다. 설령 medium-integrity 개발 도구들이 계속 작동하더라도, 워크스페이스의 근본적인 신뢰 모델이 통제하기 어렵고 정당화하기 더 어려운 방식으로 변하게 됩니다.

모든 옵션을 실행 불가능한 것으로 평가한 후, 우리는 Windows 사용자들에게 좋은 Codex 경험을 제공하기 위해 우리만의 솔루션을 설계하기 시작했습니다.

우리의 첫 번째 작동 가능한 프로토타입은 필요한 격리(isolation)를 구현하기 위해 Windows의 개념과 도구들을 조합하여 사용했습니다. 처음부터 하나의 목표는 권한 상승 (elevation) 없이 이를 작동하게 만드는 것이었습니다. 즉, Codex가 샌드박스를 설정하거나 실행하기 위해 사용자에게 관리자 권한을 요청할 필요가 없어야 한다는 의미였습니다. 이는 파일 쓰기와 네트워크 액세스라는 두 가지 요소에 대해 어떻게 합리적인 제한을 둘 것인지 찾아내는 것을 의미했습니다.

만약 파일 쓰기를 전혀 제한하지 않는다면 보안 문제가 발생할 것입니다. 반대로 파일 쓰기를 너무 많이 제한한다면, 지속적인 승인을 요청해야 하므로 샌드박스가 사용자의 생산성을 저해할 것입니다. 이 문제를 해결하기 위해 우리는 Windows의 두 가지 중요한 구성 요소인 SID와 쓰기 제한 토큰 (write-restricted tokens)에 의존했습니다.

SID, 즉 보안 식별자 (Security Identifier)는 Windows가 권한과 연결하는 신원입니다. 각 사용자에게는 SID가 있고, 그룹에도 SID가 있으며, 심지어 단일 로그인 세션조차 고유한 SID를 가집니다. 예를 들어, 현재 로그인된 세션은 S-1-5-5-X-Y와 같은 SID를 가질 수 있습니다. 로컬 관리자 (local administrators) 그룹에 할당된 SID는 S-1-5-32-544일 수 있습니다.

Windows는 또한 실제 사용자와 일치하지는 않지만, 특정 파일이나 디렉토리를 누가 읽기/쓰기/실행할 수 있는지를 정의하는 ACL (Access Control Lists, 액세스 제어 목록)에 나타날 수 있는 합성 SID (synthetic SIDs)를 생성할 수 있게 해줍니다. 이는 SID를 우리 샌드박스를 위한 유용한 기본 요소 (primitive)로 만들어 줍니다. 즉, 머신의 다른 어떤 것과도 간섭하지 않고 Codex 샌드박스 전용으로 사용할 SID를 생성할 수 있습니다.

프로세스 토큰 (Process tokens)은 실행 중인 프로세스의 신원과 권한을 정의하는 Windows의 보안 객체입니다. 이는 프로세스가 수행할 수 있는 작업을 결정합니다. *쓰기 제한 토큰 (write-restricted token)*은 Windows가 쓰기 작업에 대해 추가적인 액세스 확인을 수행하도록 만드는 특수한 유형의 프로세스 토큰입니다.

쓰기 작업이 성공하려면 다음 두 가지 확인을 통과해야 합니다:

• 일반 사용자 신원 (토큰의 "소유자")이 해당 작업을 수행할 수 있도록 허용되어야 함
• 토큰의 제한된 SID 목록 (restricted SID list)에 있는 최소 하나 이상의 SID가 액세스 권한을 부여받아야 함

실제로 이러한 확인 절차를 통해 우리는 ACL을 사용하여 샌드박스가 파일 시스템의 정확히 어느 부분을 수정할 수 있는지 정의할 수 있었으며, 이는 쓰기 작업에 대해 우리에게 필요한 세밀함 (granularity)을 제공했습니다.

SID와 쓰기 제한 토큰을 사용하여, 우리의 권한 상승되지 않은 (unelevated) 샌드박스는 다음과 같이 작동했습니다:

• 샌드박스 설정 시 sandbox-write라고 불리는 합성 SID를 생성했습니다.

• sandbox-write SID에 현재 작업 디렉토리 (current working directory)에 대한 쓰기, 실행 및 삭제 권한을 부여했습니다.

• config.toml에 구성된 모든 추가적인 writable_roots에 대해서도 권한을 부여했습니다.

• 샌드박스 설정은 다음과 같은 "쓰기 가능 범위 내 읽기 전용" 위치에 대해 동일한 SID 쓰기 권한을 명시적으로 거부했습니다:
  <cwd>/.git

<cwd>/.codex

<cwd>/.agents

• Codex는 쓰기 제한이 있는 토큰 (write-restricted token) 하에서 명령을 실행했으며, 이 제한된 SID 목록에는 다음이 포함됩니다:
  Everyone

현재 로그인된 세션의 SID, 그리고 sandbox-write 합성 SID (synthetic SID).

이 흐름은 파일 쓰기를 제한하는 문제를 효과적으로 해결했으며 유망해 보였습니다. 이제 우리는 샌드박스의 네트워크 액세스 (network access)를 제한하기 위한 솔루션이 필요했습니다.

네트워크 액세스를 제한하는 것은 샌드박스의 중요한 부분입니다. 그렇지 않으면 악성 코드가 기기에서 인터넷으로 데이터를 유출 (exfiltrate)할 수 있기 때문입니다. 권한 상승 (elevation) 요구 사항을 피하고 싶었기 때문에, 네트워크 트래픽을 강력하게 차단할 수 있는 옵션은 제한적이었습니다. Windows Firewall과 같이 우리가 사용하고자 했던 도구들은 일반적으로 관리자 권한 없이는 설치할 수 없었습니다.

Windows Firewall을 옵션으로 사용할 수 없게 되자, 우리는 제어할 수 있는 범위를 제한했습니다. 우리는 개발자들이 실제로 사용하는 네트워크 도구들에 대해 자식 환경 (child environment)이 '실패 시 차단 (fail-closed)'되도록 시도했습니다. 이를 통해 Git 명령, 패키지 설치 도구 등이 샌드박스 내에서 실패하게 만들고, 사용자가 인터넷 연결 작업에 대해 승인해야 하도록 했습니다. 아이디어는 명백한 탈출구 (escape hatches)를 오염시키는 것이었습니다. 즉, 프록시를 인식하는 트래픽을 죽은 엔드포인트 (dead endpoint)로 보내고, Git의 HTTP(S) 전송 (transport)도 동일하게 작동하게 하며, SSH를 통한 Git이 즉시 실패하도록 만드는 것이었습니다. 이에 더해, 우리는 PATH에 작은 denybin 디렉토리를 추가하고 PATHEXT를 재정렬하여, 스텁 (stub) SSH 및 SCP 스크립트가 실제 바이너리보다 먼저 해석되도록 했습니다.

예를 들어, 네트워크 액세스를 제한하기 위해 사용한 구체적인 환경 변수 재정의 (environment overrides)는 다음과 같습니다:

HTTPS_PROXY=http://127.0.0.1:9

ALL_PROXY=http://127.0.0.1:9

GIT_HTTPS_PROXY=http://127.0.0.1:9

NO_PROXY=localhost,127.0.0.1,::1

GIT_SSH_COMMAND=cmd /c exit 1

이 방법은 일반적인 도구 기반 트래픽의 상당수를 차단했지만, 여전히 권고 수준에 불과했습니다. 프로세스가 환경 변수를 무시하거나, PATH를 우회하거나, 단순히 소켓을 직접 열 수도 있었기 때문입니다. 이는 너무 위험했습니다.

흥미로운 소프트웨어 구현체들이 그렇듯, 첫 번째 프로토타입(prototype)에도 장단점이 있었습니다. 몇 가지 표준 Windows 기능만으로 목적을 달성했고, 매우 명시적이고 세밀한 파일 시스템 쓰기(filesystem writes)를 허용했으며, 권한 상승 없이(unelevated) 실행되어 사용자가 과도한 권한 상승 프롬프트를 수락하거나 로컬 머신의 관리자(admin)가 될 필요가 없다는 장점이 있었습니다. 하지만 몇 가지 실질적인 단점들이 있었으며, 그중 일부는 최종 설계로 채택되는 것을 불가능하게 만들었습니다.

• 설정 속도: 워크스페이스 디렉터리의 토폴로지(topology)에 따라 워크스페이스 ACL(Access Control List)을 적용하는 데 많은 비용이 들 수 있습니다.
• 흔적(Footprint): 개발자의 시스템에 실제 ACL을 적용했습니다. 비록 적용된 모든 ACL이 샌드박스(sandbox)에서만 사용되는 커스텀 생성 합성 SID(synthetic SID)에 귀속되므로 흔적이 특별히 침해적이지는 않지만, 흔적은 남습니다.
• 변경하기 어려운 의미론(semantics): 파일 기반 제한을 위해 ACL에 의존한다는 것은 샌드박스의 의미론을 변경하는 것이 비용이 많이 들고 복잡함을 의미합니다. macOS에서는 Seatbelt를 구성하는 데 사용되는 .sbpl 파일을 생성하는 방식을 동적으로 변경할 수 있는 반면, Windows 샌드박스는 ACL을 조정하기 위해 느리고 집중적인 작업이 필요할 수 있습니다.
• 약한 네트워크 보호: 앞서 언급했듯이, 이는 "권고(advisory)\

더 나은 네트워크 억제(network suppression)를 얻기 위해, 우리는 사용자 또는 프로그램의 아웃바운드 네트워크 트래픽을 차단할 수 있는 Windows Firewall을 사용하고자 했습니다. 불행하게도, 몇 가지 이유로 인해 Codex harness가 생성하는 명령어에만 적용되는 기능적인 방화벽 규칙을 효과적으로 만들 수 없었습니다:

• Windows는 제한된 토큰의 비(非)주체 식별자(non-principal identity)에 대한 방화벽 규칙 일치를 허용하지 않습니다. 이는 우리가 “우리의 합성 SID를 제한된 SID 목록에 포함하는 모든 토큰”에 방화벽 규칙을 적용할 수 없다는 것을 의미합니다.
• 특정 바이너리에 일치하는 방화벽 규칙을 만들 수는 있지만, 그것은 codex.exe의 네트워킹만 제한할 수 있게 합니다.