Codex 샌드박스와 승인 모드, 윈도우에서 설정 읽는 법

2026.10.18 · 밥

커뮤니티에 Codex 를 쓰다가 샌드박스 권한 오류가 새로 생겼는데 뭘 바꿔야 하냐는 질문이 올라온다. 나도 윈도우에서 Codex 가 명령을 하나도 못 띄운 적이 있어서 그 막막함은 안다. 그때 일은 setup refresh had errors 글에 적어 뒀다. 근데 설정을 건드리기 전에 이 설정들이 각각 뭘 정하는 건지부터 알아야 덜 헤맨다.

먼저 답부터. Codex 의 안전장치는 두 겹이다. 샌드박스는 명령이 실제로 뭘 할 수 있는지를 막고, 승인 정책은 Codex 가 언제 나한테 물어볼지를 정한다. 둘은 따로 돈다. 그래서 승인을 never 로 꺼도 샌드박스가 read-only 면 파일은 여전히 못 쓴다. 아래는 2026년 10월 18일에 연 Codex 문서와 이 PC 의 codex-cli 0.163.0-alpha.10.2 도움말 기준이다. 이름이 자주 바뀌는 쪽이라 버전이 다르면 codex --help 부터 보자.

Codex 샌드박스 세 가지, 뭘 막나

Agent approvals & security 문서에 나오는 샌드박스 모드는 셋이다.

workspace-write 라도 네트워크는 기본으로 꺼져 있다. 켜려면 config.toml 에 [sandbox_workspace_write] 아래 network_access = true 를 넣는다. 그리고 쓰기가 되는 폴더 안이라도 .git, .agents, .codex, .aws 는 읽기 전용으로 남는다. 하위 폴더까지 전부. 샌드박스 안에서 Codex 가 커밋을 못 하는 것도 .git 을 못 쓰게 막아 둔 이 보호 때문일 수 있다. 이건 문서를 읽고 한 추측이고 따로 시험하진 않았다.

danger-full-access 는 문서도 권하지 않는다고 적어 뒀다. 도움말에 있는 --dangerously-bypass-approvals-and-sandbox 도 마찬가지다. 샌드박스와 승인을 같이 끄는 옵션인데, 도움말에는 바깥에서 이미 격리된 환경에서만 쓰라고 대문자로 경고가 붙어 있다. 문서엔 --yolo 라는 줄임 이름도 있다.

Codex 승인 모드, on-request 와 never

승인 정책은 -a 또는 --ask-for-approval 로 정하는데, 이 버전 도움말에 나오는 값은 둘뿐이다.

on-request 는 샌드박스가 허용한 명령은 묻지 않고 돌리고, 그 경계를 넘는 권한이나 막혀 있는 네트워크가 필요할 때 묻는다. 설정으로 이미 열어 둔 네트워크를 쓸 때마다 묻는 건 아니다. never 는? 아예 안 묻는다. 대신 샌드박스가 막는 일은 실패로 끝나고 그 실패가 Codex 한테 그대로 돌아간다. 문서에는 분류별로 물을지 정하는 granular 표도 있다.

옛 글에서 자주 보이는 untrusted 는 은퇴했다. 문서에 지금은 지원하지 않고, 설정에 남아 있으면 시작이 막힐 수 있으니 지우라고 나온다. 오래된 config.toml 을 옮겨 왔다면 approval_policy = "untrusted" 줄부터 찾아보자. 비슷하게 예전 글에 보이는 --full-auto 도 이 버전 도움말에는 없다. 대신 승인 요청을 자동 검토로 넘기는 --approve-for-me 가 있다.

아무 옵션 없이 켜면 어떤 모드인가

문서 기준으로 git 같은 버전 관리가 걸린 폴더에서는 Auto 를 권한다. Auto 는 workspace-write 에 on-request 를 묶은 것. 버전 관리가 없는 폴더면 read-only 를 권하고, 아직 믿지 않은 폴더는 믿는다고 표시하기 전까지 read-only 로 시작할 수 있다고 한다. 그러니까 같은 Codex 인데 폴더에 따라 갑자기 파일을 못 쓰는 일이 생길 수 있다는 것.

세션 안에서는 /permissions 로 모드를 바꾸고 그 폴더를 믿는다고 표시할 수 있다. /status 를 치면 작업 공간에 들어 있는 폴더가 보인다. 다만 작업 공간 안이라도 read-only 모드거나 앞에서 말한 보호 경로면 쓰기는 막힌다. 권한 오류가 나면 이 둘부터 보는 게 빠르다.

명령줄에서 한 번만 정하려면 이렇게 넘긴다. 문서에 나오는 예시 모양이다.

codex --sandbox read-only --ask-for-approval on-request
codex exec --sandbox workspace-write

나는 Codex 한테 파일을 읽고 의견만 받을 때 codex exec 에 -s read-only 를 붙여 둔다. 고칠 일이 없으면 쓰기 권한을 줄 이유도 없으니까.

config.toml 에서 Codex 샌드박스 설정 읽는 법

기본 사용자 설정은 사용자 폴더의 .codex\config.toml 에 있다. 근데 설정 파일이 이것 하나만 읽히는 건 아니다. Config basics 문서에 적힌 순서로는 명령줄 -c 나 --sandbox 같은 옵션이 제일 먼저고, 그다음이 프로젝트 폴더의 .codex\config.toml, --profile 로 고른 설정 파일, 그리고 사용자 설정 순이다. 프로젝트 쪽 설정은 그 폴더를 믿는다고 표시했을 때만 읽힌다. 회사에서 쓰면 조직이 requirements.toml 로 거는 제한이 따로 있을 수 있는데, 문서는 이걸 기본값이 아니라 동작 자체를 묶는 제한이라고 설명한다. 어느 파일에서든 볼 줄은 sandbox_mode, approval_policy, [sandbox_workspace_write] 아래 network_access 정도.

헷갈리는 게 하나 있다. 요즘 문서에는 권한 프로필이라는 새 방식이 따로 있다. 아직 베타라 바뀔 수 있다고 적혀 있다. Permissions 문서를 보면 기본 프로필이 :read-only, :workspace, :danger-full-access 셋이고, default_permissions 로 기본값을 고르고 [permissions.이름] 으로 직접 만든다. 근데 이 방식은 옛 sandbox_mode 와 섞이지 않는다. 문서에 따르면 보통은 sandbox_mode 가 읽힌 설정 파일 어디에든 있거나 --sandbox 로 넘기면 Codex 는 옛 설정 쪽을 쓴다. 조직이 관리하는 설정에 allowed_permission_profiles 가 있으면 반대로 프로필을 쓰는 예외도 있다. 프로필을 만들었는데 안 먹는다면 어딘가 남은 sandbox_mode 줄을 의심해 보자. 문서는 둘 중 하나만 쓰라고 하니, 프로필로 옮길 거면 sandbox_mode 와 [sandbox_workspace_write] 를 같이 정리하는 게 맞다.

프로필이 실제로 뭘 막는지 이 PC 에서 돌려 봤다. 빈 폴더에서 codex sandbox 로 cmd 명령을 띄운 거다.

휴대폰에선 그림 글자가 작으니 같은 명령과 출력을 글자로도 붙여 둔다. exit 와 파일 유무 줄은 PowerShell 에서 따로 찍은 거다.

PS> codex sandbox -P :read-only -C . -- cmd /c "echo hi> a.txt"
액세스가 거부되었습니다.
exit=1 a.txt=False

PS> codex sandbox -P :workspace -C . -- cmd /c "echo hi> b.txt"
exit=0 b.txt=True

PS> codex sandbox -P :read-only -C . -- cmd /c "type b.txt"
hi
exit=0

:read-only 로 파일을 만들려니 액세스가 거부됐고 파일도 안 생겼다. :workspace 로는 바로 생겼다. 그 파일을 :read-only 로 다시 읽는 건 됐다. 문서에 적힌 그대로다. 참고로 처음엔 -c 로 sandbox_mode 를 넘겨서 codex sandbox 를 돌렸는데, 이 버전에선 --permission-profile 이 꼭 필요하다는 사용법 오류로 끝났다.

윈도우 샌드박스 종류, mxc 와 elevated

Windows sandbox 문서를 보면 윈도우에서는 WSL 없이 PowerShell 에서 도는 자체 샌드박스를 쓴다. 구현이 셋이다. mxc 는 지원되는 PC 면 권하는 쪽이고 관리자 설정이나 따로 만드는 윈도우 계정, 방화벽 규칙이 필요 없다. 문서는 mxc 가 Windows 11 24H2(빌드 26100.9278)와 25H2(빌드 26200.9278)에서 들어왔다고 설명한다. 다만 빌드 번호만 맞으면 되는 건 아니고, PC 에 필요한 기능이 이미 있어야 한다고 따로 적혀 있다. elevated 는 예전 방식 중 먼저 쓰는 쪽인데 처음 설정에 관리자 승인이 든다. 명령 자체는 관리자 권한 없이 돈다. unelevated 는 elevated 설정을 쓸 수 없고 조직 정책도 허용할 때만 고르는 임시 대안이다. 네트워크 격리가 더 약하고 읽기 거부 경로도 지원하지 않는다.

고르는 설정은 config.toml 의 [windows] 아래 sandbox = "elevated" 나 "unelevated", mxc 를 먼저 쓰려면 [features] 아래 prefer_mxc = true 다. 이번 시험에서 내 PC 가 셋 중 어느 걸로 돌았는지는 확인 못 했다.

문서에 적힌 윈도우 쪽 오류도 몇 개 옮겨 둔다. elevated 설정이 실패하는 건 UAC 창을 거절했거나, 로컬 사용자나 그룹을 만들 수 없게 막혔거나, 방화벽을 못 바꾸는 경우가 많다고 한다. 오류 1385 는 윈도우 정책이 샌드박스 계정의 로그온 방식을 막는 거라, 회사 PC 면 관리자한테 그 로그온 권한을 확인해 달라고 하는 게 먼저다. 정책이 허용할 때만 원인을 찾는 동안 unelevated 를 임시로 쓸 수 있다. 폴더가 Everyone 쓰기 가능이라는 경고는 그 폴더 권한이 너무 넓어서 샌드박스가 제대로 지켜 주지 못한다는 뜻이다. 표시된 폴더를 보고 그 권한을 거둬도 되는 환경인지 따진 다음 바꾸면 되고, 공유 폴더라 잘 모르겠으면 관리자한테 맡기는 게 낫다. 샌드박스가 갑자기 안 되면 Codex 재시작부터.

문의할 때 보낼 건 CODEX_HOME 아래 .sandbox\sandbox.log 와 고른 모드, 윈도우 빌드, 오류 내용이다. 같은 곳의 .sandbox-secrets 폴더 내용은 절대 보내지 말라고 따로 적혀 있다.

WSL 은 언제 쓰나? 문서는 기본은 윈도우 자체 샌드박스로 하고, 리눅스 도구가 꼭 필요하거나 이미 WSL2 에서 작업하고 있을 때 WSL 을 고르라고 한다.

권한 오류가 나면 보는 순서

순서는 이렇다. 먼저 codex --version 으로 버전을 보고, /status 로 작업 공간에 든 폴더를 확인한다. 그다음 /permissions 에서 지금 모드가 read-only 로 잡혀 있지 않은지, 폴더를 믿는다고 표시했는지 본다. 막힌 곳이 .git 같은 보호 경로인지도 같이. 네트워크가 안 되면 workspace-write 의 기본값이 꺼짐이라는 걸 떠올리면 된다. 그래도 안 되면 config.toml 에 남은 untrusted 나 sandbox_mode 줄, 윈도우라면 [windows] 설정과 sandbox.log 를 본다.

danger-full-access 는 샌드박스 제한을 없앨 뿐이고, 윈도우 파일 권한이나 조직 정책 때문에 생긴 오류까지 풀어 주지는 않는다. 그러니 어디서 막혔는지 먼저 확인하는 게 순서다.

다음엔 AI 로 만든 그림을 게임 에셋으로 쓸 때 크기와 투명 배경, 스프라이트 시트 기본을 적으려고 한다.