OpenAI Codex 권한 설정: 샌드박스·승인 정책과 Full Access 차이

OpenAI Codex CLI를 실행하면 Read Only, Auto, Full Access 같은 권한 선택지를 만나게 됩니다. 이름만 보면 “자동으로 작업하려면 Full Access가 필요한가?”라는 생각이 들기 쉽습니다. 하지만 코덱스 권한 설정은 단순히 약한 권한과 강한 권한을 고르는 메뉴가 아닙니다.

Codex의 안전장치는 샌드박스 모드와 승인 정책이라는 두 층으로 나뉩니다. 코덱스 샌드박스 설정은 로컬 명령이 파일 시스템과 명령 네트워크에 닿는 범위를 제한합니다. 코덱스 승인 정책은 샌드박스 범위 확대뿐 아니라 execpolicy 규칙, MCP·앱의 부작용 작업, request_permissions, Skill 스크립트처럼 승인이 필요한 요청을 어떻게 처리할지 정합니다. 두 설정을 분리해서 이해해야 “승인 창이 없으니 안전하다”거나 “Auto는 컴퓨터 전체를 건드린다”는 오해를 피할 수 있습니다.

이 글은 2026년 8월 24일 기준 OpenAI 공식 문서와 Linux에서 실행한 Codex CLI 0.149.0을 바탕으로 정리합니다. 설치가 먼저라면 WSL에 OpenAI Codex CLI 설치하기부터 확인할 수 있습니다.

코덱스 권한 설정의 두 축

코덱스 권한 설정 화면을 읽을 때는 먼저 다음 질문을 나눠야 합니다.

1. Codex가 어디까지 실행할 수 있는가? → 샌드박스 모드
2. 어떤 상황에서 나에게 승인을 요청하는가? → 승인 정책

샌드박스 모드란? Codex가 만든 명령을 운영체제의 격리 장치 안에서 실행해 파일 읽기·쓰기와 명령 네트워크 범위를 제한하는 설정입니다. 예를 들어 Auto에서는 작업 폴더 안의 수정과 테스트는 허용하면서, 그 범위를 벗어나는 작업은 막거나 승인을 요청할 수 있습니다.

왜 기본으로 설정될까? Codex는 답변만 만드는 챗봇과 달리 모델이 만든 명령을 직접 실행합니다. 프롬프트를 잘못 이해하거나, 오류가 있는 스크립트 또는 신뢰하지 않는 저장소의 지시를 실행하면 의도하지 않은 파일 수정·삭제와 정보 전송으로 이어질 수 있습니다. 그래서 Codex는 처음부터 실행 범위를 제한해 실수의 영향을 줄입니다. 공식 문서는 버전 관리 중인 신뢰한 폴더에는 Auto를, 버전 관리가 없거나 아직 신뢰하지 않은 폴더에는 Read Only를 기본 출발점으로 안내합니다.

샌드박스가 울타리라면 승인 정책은 울타리의 출입 요청을 처리하는 방식에 가깝습니다. 승인 요청을 끈다고 울타리가 사라지는 것은 아니고, 반대로 Full Access처럼 울타리를 없애도 승인 정책에 따라 질문이 남을 수 있습니다.

샌드박스와 승인 정책은 대체 관계가 아니라 함께 작동하는 두 개의 안전장치입니다.

샌드박스 모드

현재 CLI의 --sandbox 옵션에서는 다음 세 값을 확인할 수 있습니다.

• read-only
• workspace-write
• danger-full-access

기본 workspace-write는 현재 작업 디렉터리와 추가된 workspace root, 시스템 임시 디렉터리를 쓰기 가능 범위로 둡니다. 명령 네트워크는 기본적으로 꺼져 있습니다. on-request 승인 정책과 함께 사용하면 이 쓰기 범위 밖의 수정이나 차단된 네트워크 접근을 시도할 때 승인을 요청할 수 있고, never에서는 해당 작업이 승인 없이 실패합니다.

승인 정책

Codex CLI 0.149.0의 --ask-for-approval 도움말에서는 다음 정책을 확인할 수 있습니다.

• on-request: Codex가 필요하다고 판단한 작업에서 승인을 요청
• never: 승인 요청을 표시하지 않고 허용된 범위 안에서만 최선을 다해 실행

Codex CLI 0.149.0의 --ask-for-approval 플래그는 on-request와 never만 받습니다. 반면 config.toml에서는 untrusted와 세분화된 granular 승인 정책을 사용할 수 있고, approvals_reviewer = "auto_review" 또는 --approve-for-me로 대상 승인 요청을 자동 검토에 보낼 수도 있습니다. 플래그의 허용 값과 설정 파일의 허용 형식은 구분해서 확인해야 합니다.

codex --version
codex --help

코덱스 샌드박스 설정: Read Only·Auto·Full Access 차이

아래 표는 승인 정책을 on-request로 둔 경우를 기준으로 비교한 것입니다. never에서는 ‘승인 요청’ 항목이 모두 실패로 바뀝니다.

모드	읽기	workspace·임시 경로 수정	그 밖의 경로 수정	명령 실행	명령 네트워크	어울리는 작업
Read Only (read-only)	가능	승인 필요	승인 필요	승인 필요	승인 필요	코드 설명, 구조 분석, 변경 계획
Auto (workspace-write + on-request)	가능	가능	승인 필요	허용 범위 안에서 가능	승인 필요	일반적인 코드 수정, 테스트, 빌드
Full Access (danger-full-access, 승인 정책 별도)	가능	가능	가능	가능	가능	외부에서 격리된 일회용 환경의 제한적 작업

Full Access 행은 샌드박스의 실행 범위만 나타냅니다. 승인 정책은 별도이므로 on-request를 유지할 수도 있고, never와 결합할 수도 있습니다.

이 표에서 가장 중요한 부분은 Auto가 곧 Full Access는 아니라는 점입니다.

권한은 작업에 필요한 만큼만 올립니다. 일반적인 프로젝트 수정은 Auto 범위에서 시작합니다.

OpenAI 공식 문서가 설명하는 Auto 프리셋은 일반적으로 다음 조합입니다.

codex --sandbox workspace-write --ask-for-approval on-request

Codex는 활성 workspace root와 시스템 임시 디렉터리 안에서 편집과 테스트를 이어 가고, on-request에서는 그 쓰기 범위 밖의 수정이나 차단된 명령 네트워크 접근에 승인을 요청할 수 있습니다.

Read Only (read-only): 분석과 계획

read-only는 프로젝트를 살펴보고 질문에 답하거나 변경 계획을 세우는 작업에 적합합니다.

codex --sandbox read-only --ask-for-approval on-request

처음 보는 저장소, 외부에서 내려받은 프로젝트, 변경 없이 원인만 찾고 싶은 상황이라면 이 모드부터 시작하는 편이 안전합니다. Codex가 제안한 변경이 괜찮은지 확인한 뒤 필요할 때만 workspace-write로 올릴 수 있습니다.

Auto (workspace-write): 일반 작업

실제 파일을 고치고 테스트까지 맡길 때의 기본 선택지는 workspace-write입니다.

codex --sandbox workspace-write --ask-for-approval on-request

이 모드에서는 현재 작업 폴더가 주된 쓰기 범위가 됩니다. 다만 “작업 폴더 안이니 무엇이든 수정할 수 있다”는 뜻은 아닙니다. 공식 문서에 따르면 기본 정책은 .git, .codex, .agents 같은 보호 경로를 재귀적으로 읽기 전용으로 다룹니다.

네트워크도 자동으로 열리지 않습니다. 패키지 다운로드나 외부 API 호출이 필요하면 현재 설정과 승인 화면을 확인해야 합니다. 웹 검색 도구, MCP 서버, 브라우저 기능은 명령 샌드박스와 별도의 통제 영역이라는 점도 구분해야 합니다.

Full Access (danger-full-access): 경계 해제

danger-full-access는 로컬 명령 실행에 적용되는 파일 시스템·명령 네트워크 샌드박스 제한을 제거합니다.

codex --sandbox danger-full-access --ask-for-approval on-request

--sandbox danger-full-access --ask-for-approval on-request처럼 두 축을 명시적으로 조합할 수는 있지만, 로컬 파일·명령 네트워크에는 더 이상 샌드박스 범위 확대를 묻는 경계가 없습니다. 앱·MCP 등 별도 승인 대상은 승인 정책의 영향을 받을 수 있습니다. 공식 문서가 ‘Dangerous full access’로 제시하는 프리셋은 샌드박스와 승인 요청을 모두 우회하는 다음 옵션입니다.

codex --dangerously-bypass-approvals-and-sandbox

CLI 도움말도 이 옵션을 EXTREMELY DANGEROUS라고 표시하며, 외부에서 이미 격리한 환경을 전제로 안내합니다. 일반 작업 PC에서 오류를 빨리 넘기기 위한 해결책으로 사용하면 안 됩니다.

코덱스 승인 정책: on-request와 never

on-request와 never의 차이는 “허용 범위”가 아니라 “질문 방식”입니다.

on-request

Codex가 샌드박스 밖의 파일을 수정하거나 차단된 네트워크가 필요한 상황에서 사용자에게 승인을 요청할 수 있습니다. 일반적인 대화형 작업에서는 사람이 경계를 확인할 기회를 남긴다는 장점이 있습니다.

승인 창이 뜨면 명령 한 줄만 보지 말고 다음 범위를 함께 확인합니다.

• 현재 작업 폴더 밖으로 나가는 경로가 있는가
• 홈 폴더 전체에 영향을 주는 와일드카드가 있는가
• rm, mv, 덮어쓰기 리다이렉션이 포함됐는가
• 패키지 설치나 네트워크 접근이 정말 필요한가
• Git push·배포·전송처럼 외부 상태를 바꾸는가

never

never는 Codex가 사용자에게 승인을 묻지 않게 합니다.

codex --sandbox workspace-write --ask-for-approval never

이 조합에서는 Codex가 활성 workspace root와 시스템 임시 디렉터리의 허용 범위에서 자동으로 진행합니다. 경계 밖 작업은 승인을 받아 실행하는 대신 실패하고, 오류 내용이 Codex에 전달됩니다. 따라서 never는 Full Access가 아니며, 승인 창이 없는 샌드박스 작업입니다.

CI나 반복 작업처럼 사람의 입력을 기다리면 곤란한 환경에서는 의미가 있지만, 실패 이유를 확인하지 않으면 Codex가 다른 우회 방법을 반복할 수 있습니다. 자동화에서는 실행 로그와 Git diff를 반드시 남겨야 합니다.

Full Access 전에 확인할 세 가지

Full Access가 필요한 것처럼 보일 때는 권한을 올리기 전에 아래 순서로 원인을 좁힙니다.

작업 폴더가 맞는지 확인

Codex는 시작한 폴더를 기준으로 작업 범위를 잡습니다. 엉뚱한 상위 폴더나 홈 디렉터리에서 실행하면 필요 이상으로 넓은 파일이 작업 대상에 들어옵니다.

pwd
git status --short --branch

작업할 저장소로 이동한 뒤 Codex를 실행하는 것만으로도 많은 권한 문제를 줄일 수 있습니다.

네트워크가 꼭 필요한지 확인

테스트와 빌드가 로컬 파일만으로 가능한데 패키지 설치부터 다시 시도하고 있지는 않은지 살펴봅니다. 필요한 패키지가 이미 설치돼 있다면 네트워크 권한을 열 이유가 없습니다.

반대로 의존성 설치가 필요하다면 전체 네트워크를 상시 허용하기보다 승인 요청을 한 번 검토하는 편이 낫습니다. 목적지 도메인까지 제한하려면 명령 네트워크 허용과 features.network_proxy를 함께 켜고 허용 규칙을 설정해야 합니다. 도메인 규칙만 적거나 네트워크만 켜면 목적지 제한이 적용되지 않을 수 있습니다.

외부 격리 경계가 있는지 확인

Full Access를 검토할 수 있는 대표적인 환경은 작업이 끝나면 폐기할 컨테이너나 가상 머신입니다. 그러나 “Docker 안에서 실행 중”이라는 문장만으로 안전이 보장되지는 않습니다.

• 민감한 홈 폴더가 볼륨으로 연결돼 있지 않은가
• SSH 키와 Codex 인증 정보가 컨테이너 안에 노출돼 있지 않은가
• Docker 소켓이 연결돼 있지 않은가
• 작업 결과를 Git diff로 검토하고 되돌릴 수 있는가

이 경계를 직접 확인하지 못했다면 Full Access로 전환하기 전에 격리 환경의 설정부터 바로잡는 편이 안전합니다.

현재 권한 모드 확인 방법

Codex를 실행한 상태에서는 /permissions와 /status를 함께 확인합니다.

/permissions
/status

/permissions는 현재 사용할 권한 구성을 확인하거나 바꾸는 화면이고, /status는 현재 모델·승인 정책·쓰기 가능한 경로·세션 상태를 확인할 때 유용합니다. Claude Code·Codex CLI 사용량과 status line 설정에서도 /status와 /usage의 차이를 확인할 수 있습니다.

CLI를 시작할 때 명시적으로 고정할 수도 있습니다.

codex --sandbox workspace-write --ask-for-approval on-request

전역 기본값은 ~/.codex/config.toml에 다음처럼 둘 수 있습니다.

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

Codex 0.149.0에는 파일 시스템과 네트워크 규칙을 함께 묶는 Permission profiles도 베타로 제공됩니다. 기본 프로필 이름은 :read-only, :workspace, :danger-full-access입니다. 다만 공식 문서는 새 프로필 설정과 기존 sandbox_mode 설정을 한 세션에서 섞지 말라고 안내합니다. 입문 단계에서는 /permissions 화면이나 기존 --sandbox 옵션 한 가지 방식으로 통일하는 편이 덜 헷갈립니다.

안전한 테스트 폴더에서 차이 확인

실제 프로젝트 대신 작은 Git 저장소를 만들어 모드 차이를 확인할 수 있습니다.

mkdir -p ~/codex-permission-lab
cd ~/codex-permission-lab
git init
printf 'before\n' > sample.txt
git add sample.txt
git commit -m "test baseline"

각 모드에서 Codex에게 다음 작업을 차례로 요청합니다.

1. sample.txt 읽기
2. 작업 폴더 안에 inside.txt 만들기
3. 작업 폴더 밖에 파일 만들기
4. 외부 주소에 curl 요청하기
5. 결과를 실행하지 말고 필요한 승인과 예상 영향부터 설명하기

예상 결과만 믿지 말고 실제 파일과 Git 상태를 확인합니다.

git status --short
find . -maxdepth 1 -type f -printf '%f\n'

테스트가 끝났다면 실험 폴더만 정확히 지정해 지웁니다. 경로를 변수나 와일드카드로 넓히지 않습니다.

bwrap 샌드박스 오류 원인과 확인 순서

Linux 환경의 Codex CLI 0.149.0에서 내장 샌드박스 명령을 직접 실행해 보니 read-only와 workspace 프로필은 다음 오류와 함께 시작 단계에서 멈췄습니다.

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

같은 환경에서 danger-full-access는 명령이 실행됐습니다. 이것은 Full Access가 더 정상적인 모드라는 뜻이 아닙니다. 이 로그는 bwrap이 loopback 인터페이스를 설정하는 RTM_NEWADDR 작업을 거부당해 샌드박스가 시작되지 않았음을 보여 줍니다. 다만 이 한 줄만으로 근본 원인을 특정할 수는 없으며 namespace·setuid bwrap·seccomp·커널 또는 컨테이너 정책을 함께 확인해야 합니다.

OpenAI 공식 문서도 Docker 같은 제한된 컨테이너에서는 호스트 설정이 사용자 네임스페이스, setuid bwrap, seccomp 동작을 막아 샌드박스가 실패할 수 있다고 설명합니다. 이런 오류를 만났을 때는 다음 순서로 확인합니다.

codex --version
command -v bwrap
unshare --user --map-root-user true

WSL·Linux 커널과 컨테이너 정책에 따라 결과가 다를 수 있습니다. 외부 컨테이너가 충분히 격리됐다는 사실을 확인하지 못했다면, 오류를 없애려고 danger-full-access를 기본값으로 바꾸지 않습니다.

Windows 네이티브 샌드박스 설정 구분

Windows에서 Codex를 PowerShell 기반으로 직접 실행한다면 샌드박스 구현 이름이 하나 더 나옵니다.

[windows]
sandbox = "elevated"

OpenAI는 전용 저권한 샌드박스 사용자, 파일 시스템 권한 경계, 방화벽 규칙을 사용하는 elevated를 권장합니다. unelevated는 현재 사용자에서 파생한 제한 토큰과 ACL, 환경 수준의 오프라인 제어를 사용하는 fallback입니다. 네트워크 격리가 더 약하고 일부 분리된 읽기·쓰기 정책을 집행하지 못할 수 있습니다. 이 두 값은 Windows에서 샌드박스를 어떻게 구현할지 정하는 값입니다. read-only, workspace-write, danger-full-access처럼 작업 권한 범위를 고르는 값과 같은 축으로 보면 안 됩니다.

WSL에서 Linux 도구 체인을 쓰고 있다면 Linux 샌드박스 전제조건을, Windows 앱과 PowerShell을 쓰고 있다면 Windows 네이티브 샌드박스 상태를 확인합니다.

코덱스 권한 설정 체크리스트

Codex에 코드를 맡기는 목적은 매번 승인 버튼을 누르는 데 있지 않습니다. 그렇다고 가장 넓은 권한을 기본값으로 두는 것도 답은 아닙니다. 분석은 Read Only, 일반 편집은 Auto 또는 workspace-write, Full Access는 외부 격리가 확인된 예외 환경으로 구분하면 선택이 단순해집니다.

마지막에는 AI가 생성한 코드를 실행하기 전 검토 방법처럼 Git diff와 테스트 결과를 확인해야 합니다. 샌드박스는 실수의 범위를 줄이는 장치이지, 코드의 정확성까지 대신 검증해 주는 장치는 아닙니다.

OpenAI Codex 권한 설정 공식 문서

• OpenAI Codex: Agent approvals & security
• OpenAI Codex: Permissions
• OpenAI Codex: Config basics
• OpenAI Codex: Windows sandbox