Codex작업 준비와 권한

샌드박스와 승인 정책

샌드박스는 무엇을 기술적으로 허용하는지, 승인 정책은 언제 물어보는지, 왜 둘을 따로 생각해야 하는지를 정리하는 보안 기본 카드입니다.

마지막 수정 2026년 3월 20일

기본 패턴

toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

설명

  • 샌드박스는 "어디까지 할 수 있는가"를 정합니다. 승인 정책은 "그 행동 전에 사용자에게 물어볼 것인가"를 정합니다.
  • 로컬 CLI와 IDE 기본값은 보수적이며, 공식 문서는 기본적으로 네트워크가 꺼져 있고 쓰기 권한도 작업 공간 안으로 제한된다고 설명합니다.
  • read-only는 읽기 중심 대화와 계획에 적합하고, workspace-write는 저장소 안 수정과 테스트에 적합하며, 전체 권한은 꼭 필요한 경우만 써야 합니다.
  • approval_policy = "on-request"는 실행 전 확인을 거치게 만들고, never는 승인 없이 계속 진행하게 만듭니다.
  • 세션 중에는 /permissions로 권한 수준을 바꿀 수 있으며, 공식 가이드는 보통 가장 좁은 권한에서 시작해 점진적으로 넓히는 방식을 권합니다.

짧은 예제

text
상황별 선택
- 코드 설명만 듣고 싶다 -> read-only
- 저장소 안 파일 수정과 테스트는 필요하다 -> workspace-write
- 네트워크 접근도 필요하다 -> workspace-write + 명시적 network_access
- 무인 자동화라 승인 대화가 없어야 한다 -> 정책 검토 후 never

빠른 정리

항목의미
sandbox_mode기술적으로 허용된 파일/명령/네트워크 범위
approval_policy실행 전에 사용자 승인 여부
read-only수정 없이 읽기와 계획 중심
workspace-write작업 공간 안 수정과 검증 가능
/permissions세션 중 권한 프리셋 전환

주의할 점

승인 정책만 좁히고 샌드박스를 넓게 열면 생각보다 강한 권한이 남을 수 있습니다. 반대로 샌드박스만 좁히고 승인 정책을 풀어도 필요한 작업이 계속 실패합니다. 두 축을 항상 같이 봐야 안전합니다.

참고 링크

3 sources