Codex 샌드박스와 승인 모드: 완벽 가이드 (2026)

- Codex의 샌드박스/승인 메커니즘(그리고 새로운 Permission Profiles 레이어)은 빠르게 바뀌며, 공식 문서는 현재 learn.chatgpt.com의 여러 경로에 나뉘어 있습니다. 아래 내용은 작성 시점(2026년 8월)의 공식 문서와 교차 확인했지만, 의존하기 전에 최신 문서를 확인하세요.

샌드박스 모드 대 승인 정책 - 두 가지 다른 질문

Codex는 무언가를 실행하기 전에 완전히 별개의 두 가지 질문을 스스로에게 던집니다. "내가 무엇을 해도 되는가?"(샌드박스 모드)와 "언제 먼저 물어봐야 하는가?"(승인 정책)입니다. 공식 learn.chatgpt.com/codex/sandboxing 문서에 따르면 두 레이어는 독립적으로 작동합니다. 샌드박스가 활짝 열려 있어도 Codex가 물어보기를 멈추는 것은 아니며, 승인 정책이 엄격해도 Codex가 건드릴 수 있는 범위가 자동으로 제한되는 것은 아닙니다.

Codex가 처음이신가요? 이 설정 심화 내용에 들어가기 전에 OpenAI Codex가 무엇인지를 읽어보세요. 혼동을 피하기 위해 한마디: 이것은 Codex 자체의 권한 시스템이며, 그 위에 AgentKit을 설치하는 것과는 아무 관련이 없습니다.

세 가지 샌드박스 모드

샌드박스 모드는 당신의 확인을 기다리지 않고 Codex가 당신의 컴퓨터에서 무엇을 건드릴 수 있는지를 결정합니다. 공식 샌드박스 문서(2026년 8월 접속)에 따르면 세 가지 수준이 있습니다.

workspace-write는 아무것도 지정하지 않을 때 Codex가 기본으로 선택하는 모드입니다. 컴퓨터 전체를 열어주지 않으면서도 실제 작업에 충분히 넓어서, 저도 대부분의 일상 코딩에 이것을 씁니다.

간단한 예: 이미 코딩 중인 저장소에서 Codex를 열고 아무것도 바꾸지 않으면 기본값은 workspace-write가 되어 저장소 안의 파일을 자유롭게 편집할 수 있습니다. 하지만 그 범위 밖에 쓰려고 하면(예를 들어 ~/.ssh/나 다른 시스템 디렉터리를 건드리는 경우) 그것은 샌드박스 밖 동작이 됩니다. 동시에 설정된 승인 정책에 따라, 그대로 완전히 차단되거나 별도의 확인 단계가 발생합니다.

세 가지 승인 정책

승인 정책은 Codex가 무엇을 해도 되는지와는 완전히 별개로, 언제 멈춰서 당신에게 물어봐야 하는지를 결정합니다. 공식 에이전트 승인 및 보안 문서(2026년 8월 접속)에 따르면 세 가지 수준이 있습니다.

대부분의 가이드가 놓치는 부분: 공식 문서는 on-request가 "버전 관리되는 폴더의" 기본값이라고 밝히고 있으며, 모든 폴더에 대한 무조건적인 기본값이 아닙니다. 제가 확인한 다른 거의 모든 가이드(두 언어 모두)는 이 조건을 건너뜁니다. git으로 추적되지 않는 디렉터리에서 Codex를 실행 중이라면 on-request가 활성화되어 있다고 단정하지 말고 실제 설정을 확인하세요.

모드 전환 방법 - /permissions, CLI 플래그, config.toml

샌드박스 모드와 승인 정책을 설정하는 일반적인 방법은 세 가지입니다.

• 세션 내(CLI): /permissions를 입력해 선택기를 열고 직접 고릅니다.
• IDE/데스크톱: 컴포저 안에 있는 권한 컨트롤을 사용합니다.
• 시작 플래그: --sandbox와 --ask-for-approval.
• 영구 설정: ~/.codex/config.toml 안의 sandbox_mode와 approval_policy 키.

CI 파이프라인을 위한 실제 예(프롬프트에 답할 사람이 아무도 없는 경우):

codex --sandbox read-only --ask-for-approval never

이 조합이 비대화형 실행에서 작동하는 이유는 Codex가 입력을 기다리며 멈추지 않고(never), 동시에 read-only가 예기치 않은 쓰기를 막기 때문입니다. 이 구성은 Codex용 AGENTS.md를 설정하는 방식과 곧바로 짝을 이룹니다. 둘을 하나의 워크플로로 결합하는 방법은 Codex용 AGENTS.md 가이드를 참고하세요.

Permission Profiles - 새로운 설정 레이어

위의 고전적인 sandbox_mode/approval_policy 짝 외에도 Codex에는 새로운 설정 레이어가 있습니다. 바로 Permission Profiles이며, learn.chatgpt.com/docs/permissions를 직접 가져와 확인했습니다(2026년 8월 접속). 작동 방식은 다음과 같습니다.

• default_permissions 키는 내장 또는 사용자 지정 프로필을 가리킵니다.
• 내장 프로필은 세 가지: :read-only, :workspace, :danger-full-access. 위의 세 샌드박스 모드와 대략 일치하며 이름만 다릅니다.
• [permissions.<name>] 테이블로 자신만의 프로필을 작성해, 어떤 경로가 읽기 가능·쓰기 가능·명시적으로 거부인지 선언할 수 있습니다.
• 네트워크 액세스는 분리되어 있습니다. network.enabled(네트워크 켜기/끄기)는 features.network_proxy(제어된 프록시를 통해 라우팅)와 별개입니다.

솔직히 말하면: 이 글을 조사하며 확인한 검색 결과에서는 이것을 다루는 곳이 거의 없습니다. 언급한 것은 한 기사뿐이고 그것도 단독으로였으며, 비교를 위해 sandbox_mode/approval_policy 짝 옆에 나란히 놓인 적은 한 번도 없었습니다. 그리고 공식 문서가 명시하지 않는 것이 하나 있습니다. default_permissions와 sandbox_mode/approval_policy를 동시에 설정했을 때의 우선순위입니다. 일부 비공식 출처는 sandbox_mode가 이긴다고 추측하지만, 그것을 직접 확인해 주는 일차 문서 페이지는 찾지 못했습니다. 그러니 사실로 여기지 마세요. 실무에서 안전한 선택은 하나의 시스템을 골라 일관되게 유지하는 것입니다. 완전한 레거시 짝이든 완전한 Permission Profiles이든 하나로 하고, 섞지 마세요.

이 레이어의 진짜 가치를 그려보기 위한 개념적 예입니다(공식 필드 구문으로 확인된 것은 아닙니다). 저장소 전체를 읽을 수는 있지만 쓰기는 logs/ 디렉터리로만 제한하고, 더 넓은 읽기 범위에는 원래 포함될 .env나 .ssh/ 같은 민감한 경로 몇 개를 명시적으로 거부하고 싶다고 합시다. 이것은 고전적인 sandbox_mode/approval_policy 짝(넓은 세 수준뿐)으로는 할 수 없는 경로별 제어입니다. 이것은 문서에 최근 추가된 부분이므로, 의존하기 전에 정확한 필드 구문을 최신 문서에서 확인하세요.

결정 표 - 어떤 작업에 어떤 모드

이것은 Codex를 열 때마다 다시 고민하는 대신, 1분 안에 결정하기 위해 제가 실제로 쓰는 표입니다.

기억할 한 줄: 일회용 환경이 아니라면 danger-full-access를 never/--yolo와 절대 함께 쓰지 마세요. 이 표에서 두 안전 레이어를 동시에 포기하는 유일한 행입니다.

프로덕션 안전성의 교훈 - 진짜 한 방

위의 표는 종이 위에서는 그럴듯하게 들리지만, 그것이 존재하는 이유는 이론적인 것이 아닙니다. 이 사이트의 /goal을 효과적으로 쓰는 방법 글은 "Slap #1"을 들려줍니다. 목표는 분명히 적혀 있었습니다 - 스테이징에만 배포 - 하지만 몇 번의 자동 컴팩트 후 에이전트는 컨텍스트에서 벗어나 경계를 잊었고, 컴팩트마다 작업을 상기시키는 훅이 있었는데도 곧장 프로덕션에 배포해 버렸습니다.

바로 이것이 이 결정 표가 막는 실패입니다. 안전선은 실제 sandbox_mode/approval_policy(Codex가 반드시 따라야 하는 기술적 제한)에 있어야 하며, 프롬프트나 목표 안의 메모(충분한 컨텍스트 컴팩션 후 에이전트가 잊을 수 있는 것)에 두어서는 안 됩니다. 프로덕션 환경이 Codex의 손이 닿는 범위 어딘가에 있다면, 그 범위에 대해 approval_policy = never를 설정하지 마세요. 하지 말라고 이미 말했다고 아무리 확신하더라도 말입니다.

다시 말해, 위의 결정 표는 벽에 걸어 둘 이론적 연습이 아닙니다. 그것은 Slap #1이 제기하는 바로 그 질문에 대한 기술적 답입니다. 컨텍스트에서 벗어나 표류한 지속형 에이전트가 건드려서는 안 될 것을 건드리는 것을 어떻게 막을 것인가. 프롬프트 알림은 잊힐 수 있지만, sandbox_mode/approval_policy에 설정된 제한은 잊히지 않습니다.

AgentKit은 당신이 선택한 모드 안에서 실행됩니다

경계에 대해 분명히 하자면: AgentKit은 Codex의 샌드박스나 승인 정책을 건드리거나 우회하지 않습니다. 그것은 현재 활성화된 모드 안에서 실행되는 스킬/워크플로 레이어일 뿐입니다. read-only + untrusted를 설정하면 AgentKit도 정확히 같은 제한에 묶이며, 자체적인 특권은 전혀 없습니다. Codex용 설치: ak kit init engineer --target codex, 그런 다음 새 Codex 세션에서 $ak:cook을 호출하세요. 전체 안내는 Codex에서 AgentKit 사용하는 방법을 참고하세요.

자주 묻는 질문(FAQ)

Codex의 기본 샌드박스 모드는 무엇인가요?

workspace-write입니다. Codex는 시스템 전체에 자유롭게 접근하지 않으면서 현재 워크스페이스 디렉터리 안에서 읽고 쓸 수 있습니다. 버전 관리되는 폴더에서는 기본 승인 정책인 on-request와 짝을 이룹니다.

on-request는 항상 모든 명령 전에 물어보나요?

아니요. on-request는 어떤 명령을 바로 실행해도 안전한지 Codex가 스스로 판단하게 하고, 명령이 위험하거나 현재 샌드박스 범위 밖이라고 판단할 때만 물어봅니다. 대부분의 명령 전에 물어보는 untrusted와는 다릅니다.

danger-full-access와 --yolo의 차이는 무엇인가요?

danger-full-access는 sandbox_mode의 한 값입니다(파일시스템 경계를 제거합니다). --yolo(둘 다 우회하는 플래그)는 더 나아가, 가장 넓은 샌드박스와 never 승인 정책을 하나의 플래그로 묶어 danger-full-access 단독보다 더 위험합니다. 이 영역은 자주 바뀌므로, 사용하기 전에 당신의 설치본에서 정확한 플래그 이름을 확인하세요.

Permission Profiles와 sandbox_mode를 함께 쓸 수 있나요?

기술적으로는 둘 다 선언할 수 있지만, 공식 문서는 충돌 시 어느 쪽이 이기는지 명시하지 않습니다. 어떤 우선순위 주장도 확인된 것으로 여기지 마세요. 안전한 접근은 하나의 시스템(레거시 또는 Permission Profiles)을 골라 일관되게 유지하는 것입니다.

CI/CD에는 어떤 모드를 써야 하나요?

read-only(또는 범위를 좁힌 workspace-write)를 never와 짝짓습니다. 파이프라인에서는 프롬프트에 답할 사람이 없으므로 승인은 never일 수밖에 없고, 그래서 그래도 작동하는 가장 좁은 샌드박스로 보완합니다.

/permissions는 config.toml을 영구적으로 바꾸나요?

이것은 의존하기 전에 실제로 확인해야 할 세부 사항입니다. 세션에만 적용되는 변경인지, 실제로 config.toml에 기록되는 것인지에 따라 동작이 다를 수 있습니다. 가장 확실한 확인 방법은 선택기로 전환한 후 config.toml을 열어 저장되었는지 직접 확인하는 것입니다.

결론

Codex의 안전 모델은 두 개의 독립된 레이어로 요약됩니다. 샌드박스 모드(무엇을 할 수 있는가)와 승인 정책(언제 물어봐야 하는가)입니다. 기본값인 workspace-write + on-request는 대부분의 일상 코딩에 맞습니다. 일회용 환경이 아니라면 danger-full-access를 never/--yolo와 절대 함께 쓰지 마세요. 추측하지 말고 위의 결정 표를 사용하고, Slap #1의 교훈을 기억하세요. 안전선은 프롬프트 메모가 아니라 설정에 속합니다.