OpenAI Codex · 샌드박스

샌드박스 매니저: 권한 프로필을 명령 한 줄로 컴파일해요

워크스페이스는 쓰기 가능, 네트워크는 조여요. 같은 git status인데 Mac은 sandbox-exec, Linux는 helper, Windows는 그대로 나갈 수 있어요. 차이는 컴파일러에 있어요.

강의 목표읽고 나면 말할 수 있어요. 권한 프로필이 어떻게 샌드박스 타입으로 골라지고 명령 한 줄로 컴파일되는지. 샌드박스를 켤지, 이 기계에 백엔드가 있는지는 질문 두 개예요. 같은 프로필은 모델이 보는 environment_context에도 렌더링돼요.

먼저 한 번 써 보세요 · 같은 명령, 껍질 세 겹

같은 프로필: 기계 세 대가 각각 어떤 껍질을 쓰는지 보세요

Windows 단계

꺼져 있으면 구현을 내줄 수 없어요. 켜야 Windows가 두 번째 박자에 들어가요.

도구 선호

Forbid는 필요 없음을 못 박아요. Require는 필요함을 못 박지, 기계에 백엔드가 있는지는 못 박지 못해요.

관리 네트워크

켜면 Auto는 샌드박스를 켜야 해요. Windows가 여전히 꺼져 있으면 타입은 여전히 None이에요.

모델이 보는 프로필

아직 렌더링되지 않았어요.

시작 대기. 재생을 눌러, 같은 명령이 기계 세 대에서 각각 어떤 껍질을 쓰는지 보세요.

논리 궤적 · 애니메이션 각 단계가 소스 어디에 대응하는지

PermissionProfile 세 상태를 읽어요models.rs L411
additional permissions를 겹쳐요policy_transforms.rs L525
Auto면 should_require_platform_sandbox를 달려요policy_transforms.rs L541
select_initial이 이어서 get_platform_sandbox를 물어요manager.rs L62
None이면 argv를 그대로 전해요manager.rs L366
macOS는 /usr/bin/sandbox-exec를 앞에 붙여요manager.rs L401
Linux는 프로필을 helper에 직렬화해요landlock.rs L23
Windows 첫 박자는 argv를 안 바꿔요manager.rs L447
같은 프로필이 environment_context에 렌더링돼요environment_context.rs L96

재생을 눌러, 같은 git status가 기계 세 대에서 각각 어떤 껍질을 쓰는지 보세요.

명령 세 줄

필요와 제공

모델 쪽

수업용 스케치: 명령은 git status로 고정이고 실제 셸은 부르지 않아요. 바깥 래핑은 플랫폼 계약으로 단순화했어요. 논리 궤적 오른쪽 행 번호는 openai/codex 저장소 commit 4f39251a01에 대응해요.

아이디어 1 · 필요한지와 있는지는 질문 두 개예요

어떤 문제를 푸는가

같은 저장소, 기계 세 대, 모델이 같은 git status를 내요. 설정에 적힌 것은 같은 권한 프로필이에요. 워크스페이스 쓰기 가능, 네트워크 조임.

디버깅하는 사람은 샌드박스가 안 먹었다고 생각해요. 로그에 프로필이 있고 모델 컨텍스트의 environment_context도 있어요. 플랫폼 층이 프로필을 래핑 명령으로 컴파일하지 않았을 뿐이에요. Windows에서 스위치가 꺼져 있으면 컴파일러가 원 argv를 내주고 정책 층은 그대로예요.

아이디어는 무엇인가

SandboxManager는 먼저 필요한지를 묻고 그다음 있는지를 물어요. should_sandbox는 불리언 하나만 돌려줘요. Forbid는 항상 거짓, Require는 항상 참, Auto는 프로필 모양을 봐요. 관리 네트워크 요구가 있으면 켜야 해요. 네트워크가 조여 있으면 호출 쪽이 파일시스템을 맡는 경우를 빼면 켜요. 네트워크가 열려 있고 파일시스템이 제한 없을 때만 건너뛰어요.

출처: codex-rs/sandboxing/src/manager.rs 310–329행 · codex-rs/sandboxing/src/policy_transforms.rs 541–561행

그다음 get_platform_sandbox가 OS별로 타입을 줘요. macOS는 Seatbelt, Linux는 seccomp helper. Windows는 스위치가 하나 더 있어 꺼져 있으면 빈 값이에요. 빈 값은 이 호스트에 보낼 구현이 없다는 뜻이에요.

출처: codex-rs/sandboxing/src/manager.rs 62–76행

select_initial은 앞을 먼저 묻고, 뒤의 빈 값을 SandboxType::None으로 접어요. 프로필은 필요하다고 하는데 호스트가 못 주면 타입은 여전히 None이에요.

출처: codex-rs/sandboxing/src/manager.rs 293–306행

수업용 구조도: 질문 두 개를 따로 물어야 컴파일 산물이 플랫폼별로 갈라져요.

왜 오래가는가

설정의 의도와 호스트의 백엔드는 원래 갈라져요. 제품 문구, 상태 바, 모델 설명이 모두 설정에서 켜고 싶은 쪽만 읽으면 디버깅이 여기서부터 삐뚤어져요. 함수 둘. 하나는 불리언, 하나는 선택적 백엔드 이름. 다른 언어로 다시 써도 필요해요.

아이디어 2 · 프로필 하나, 출구 둘

어떤 문제를 푸는가

권한을 두 벌로 쓰면 한쪽만 고치고 다른 쪽을 잊어, 모델이 낡은 경계로 다음을 계획해요. 모델이 바깥 샌드박스가 없다고 보는 것과 Windows에서 샌드박스를 끄면 None이 되는 것은 같은 의도의 출구 둘이어야 해요.

아이디어는 무엇인가

PermissionProfile 변형 셋은 누가 바깥 샌드박스를 만드는지 적어요. Managed는 Codex가 래핑 명령을 짜요. Disabled는 바깥 층이 없어요. External은 파일시스템을 호출 쪽이 맡고 네트워크는 여전히 Codex 몫일 수 있어요.

출처: codex-rs/protocol/src/models.rs 411–425행

transform은 타입으로 나눠요. None은 사용자 argv를 그대로 전하고 로컬 cwd도 안 준비해요. 샌드박스 없는 요청이 원격 경로를 들고 있을 수 있어서예요. macOS는 /usr/bin/sandbox-exec만 믿고, 정책은 -p, 경로는 -D, 사용자 명령은 -- 뒤예요. Linux는 프로필 전체를 --permission-profile에 직렬화하고 helper가 없으면 바로 오류이며 샌드박스 없음으로 내려가지 않아요. Windows 첫 박자는 검증만 하고 argv는 안 움직여요. 래퍼는 현재 exe이고 껍질은 transform_for_direct_spawn으로 미뤄요.

출처: codex-rs/sandboxing/src/manager.rs 365–459행 · codex-rs/sandboxing/src/seatbelt.rs 52–56행 · codex-rs/sandboxing/src/landlock.rs 15–23행 · codex-rs/sandboxing/src/manager.rs 484–518행

같은 프로필을 FileSystemContext가 내부 열거형으로 접어 environment_context에 렌더링해요. Disabled는 type="disabled"에 unrestricted 파일시스템이에요. 모델이 보는 텍스트는 월권을 막지 못하고 헛된 시도만 줄여요.

출처: codex-rs/core/src/context/environment_context.rs 96–116행

수업용 구조도: 런타임 값 하나, 출구 둘.

플랫폼이 구현을 못 주면 XML은 말을 바꾸지 않아요.

왜 오래가는가

런타임 사실은 하나여야 해요. 격리는 자식 프로세스 입구에서 일어나고, 오케스트레이션 층은 경로와 프로필을 계속 들고 실행 경계에서야 내려앉아요해요. 플랫폼 방언은 바뀌어도, 래핑 명령과 모델에 동시에 먹이는 이 프로필 모양은 쓸모 있어요.

아이디어 3 · 열 때는 합집합, 승인할 때는 교집합

어떤 문제를 푸는가

명령 하나에 overlay를 더 달 수 있어요. 사람이 승인할 때 합집합을 쓰면, 한 번 잘못 승인해 요청에 없던 경로가 세션 권한에 들어가요.

아이디어는 무엇인가

병합은 합집합이에요. 한쪽이 네트워크를 열면 결과는 열린 네트워크고, 파일시스템 항목은 이어 붙인 뒤 중복을 빼요. 교집합은 다른 세트예요. 네트워크는 양쪽이 열려야 남고, 파일시스템은 요청 범위 안의 이미 승인된 항목만 남겨요. 교집합이 비면 세션에 기장하지 않고 베이스 프로필이 계속 유효해요. 공집합은 이번 추가 개구가 넓힌 것이 없다는 뜻이에요. 명령이 달릴 수 있는지는 뒤의 정책과 샌드박스를 봐요.

출처: codex-rs/sandboxing/src/policy_transforms.rs 90–142행 · codex-rs/sandboxing/src/policy_transforms.rs 144–214행 · codex-rs/core/src/session/mod.rs 2833–2846행

왜 오래가는가

넓히기와 승인은 다른 일이에요. 합집합은 “이 명령이 경로를 하나 더 열었다”를 말할 수 있게 해요. 교집합은 사람이 승인한 것이 요청보다 넓지 않게 해요. 공집합은 개구 실패예요. 가장 엄격으로 바꿨다고 읽지 말고, 명령 전체를 금지했다고 읽지 마세요.

가로 비교 · 어느 층을 자르고, 실패가 어느 쪽으로 기울는지

DeepSeek Harness: 백엔드가 없으면 실행을 거절해요

DSH도 자식 프로세스 입구에서 잘라요. confine이 현재 호스트로 runner를 고르고 정책을 runner 인자로 짜며 사용자 명령은 -- 뒤예요. 프로필 어휘는 파일 모드 셋뿐이고 danger-full-access는 래핑에 안 들어가요.

백엔드가 없으면 fail closed이고 원 argv로 돌아가지 않아요. 문구는 refusing to run the command unconfined예요. Codex도 Unix helper가 없으면 안 달려요. Windows에서 샌드박스를 끄면 구현을 못 주는 것을 None으로 접어 뒤의 정책 층에 넘겨요.

양쪽 소스 확인 · 2026-08-22 · DSH · 샌드박스

Grok: apply 한 번으로 현재 프로세스를 잠가요

Grok에도 SandboxManager라는 타입이 있고 역할은 apply() 다음 install()이에요. 주석은 대상이 현재 프로세스이며 되돌릴 수 없다고 적어요. 컴파일 산물은 CapabilitySet이고 명령마다 argv를 씌우지 않아요.

플랫폼이 안 받거나 apply가 실패하면 경고를 치고 apply_failed를 적은 뒤 계속 달려요. 뒤의 도구 호출은 같은 capability를 공유해요. Grok은 명령마다 argv를 다시 짜지 않고, 같은 프로세스에서 명령 둘에 경계 두 세트를 줄 수도 없어요.

양쪽 소스 확인 · 2026-08-22 · Grok · 샌드박스 Profile 다섯 가지

출처: packages/sandbox/sandbox-local/src/index.ts 316–333행 · crates/codegen/xai-grok-sandbox/src/lib.rs 117–136행

수업 실습

반환 네 개, 입력 세 묶음

should_require_platform_sandbox를 열고 종이로 반환 네 개를 그리세요. 아래 세 묶음에 예측을 내요. Disabled 프로필 더하기 관리 네트워크; 루트 쓰기 가능에 deny 하나, 네트워크 Enabled; External 프로필, 네트워크 Restricted.

심화 질문: 같은 Disabled 프로필에 도구가 Require를 선언하고 Windows 단계가 여전히 꺼져 있어요. 타입은 무엇이고, 모델이 보는 XML은 말을 바꿀까요.

Takeaway: 격리가 필요한지와 이 기계가 무엇을 줄 수 있는지를 함수 둘로 쓰세요. 권한 프로필 하나를 래핑 명령과 모델에 동시에 먹여요. Windows는 두 박자고, 꺼져 있으면 원 argv를 내주며 정책 층은 그대로예요.