Codex를 처음 접할 때 가장 먼저 생겨나는 불안함은 아마 이것일 것입니다.

"터미널에서 AI에게 부탁했을 때, 내가 보고 있지 않은 사이에 파일을 바꿔버리거나 이상한 명령어를 실행하지 않을까...?"

솔직히 말씀드리겠습니다. 그 불안함은 매우 건강한 것입니다. 오히려 그런 점을 신경 쓰는 사람일수록 AI에게 개발을 맡기는 자질이 뛰어나다고 생각합니다. 왜냐하면, 어디까지 자동으로 하게 하고 어디서부터 인간이 확인할지 —— 그것을 결정하는 것이 AI를 도구로서 능숙하게 다루는 사람의 일이기 때문입니다.

그리고 Codex에는 그 "어디까지 맡길 것인가"를 스스로 제대로 결정하기 위한 메커니즘이 처음부터 마련되어 있습니다. 그것이 오늘 이야기의 주인공인 승인 모드 (approval mode)와 샌드박스 (sandbox) 입니다.

이 기사에서는 Codex를 아직 접해보지 않은 분들을 위해, 이 두 가지만을 철저하게 풀어서 설명하겠습니다. 이것저것 너무 많이 담지는 않겠습니다. 다 읽고 나면 "AI가 멋대로 움직이는 것이 무섭다"에서 "스스로 맡길 범위를 결정할 수 있다"로 바뀌어 있을 것입니다. 마지막에는 10분 만에 할 수 있는 연습도 준비해 두었습니다.

이 기사의 전제:

Codex CLI (CLI = 터미널에서 문자를 입력하여 조작하는 방식)를 대상으로 합니다. 명령어 이름, 기본 동작, 플래그 값은 기사 끝에 언급한 OpenAI의 공식 문서와 대조하였습니다.

갑자기 두 가지 용어가 나왔으므로, 우선 여기만 천천히 넘어가겠습니다. Codex의 안전 메커니즘은 역할이 다른 두 겹의 가드가 조합되어 만들어져 있습니다.

샌드박스 (sandbox)… Codex가 기술적으로 "무엇을 할 수 있는지"를 제한하는 모래 놀이터를 말합니다. 예를 들어 "파일을 수정할 수 있는 곳은 현재 작업 폴더 내부뿐이다", "인터넷에는 연결하지 않는다"와 같이, 할 수 있는 범위 그 자체를 결정합니다. 모래 놀이터 밖으로는 손을 뻗을 수 없다는 이미지입니다. -
승인 정책 (approval policy)… Codex가 무언가를 하기 전에 "언제 인간에게 확인을 받을지"를 결정하는 규칙입니다. 예를 들어 "작업 폴더 외부를 건드릴 때는 반드시 물어봐 줘", "잘 모르는 명령어를 실행하기 전에는 멈춰줘"와 같이, 확인 타이밍을 결정합니다.

이 부분이 섞이기 쉬우므로 한 번만 정리하겠습니다.

• 샌드박스 = 할 수 있는 일의 넓이 (어디까지 손을 뻗을 수 있는가)
• 승인 정책 = 멈춰서 물어보는 빈도 (어디서 인간에게 확인하는가)

이 두 가지가 겹쳐져야 비로소 "안심하고 맡길 수 있는 상태"가 만들어집니다. 한쪽만 있다면 불충분합니다. 양쪽을 세트로 생각하는 것이 요령입니다.

덧붙여, 이 기사에서 자주 등장하는 용어도 미리 정의해 두겠습니다.

• 리포지토리 (Repository)… Git으로 버전 관리되고 있는 프로젝트 폴더를 말합니다. 대략 "변경 이력을 남길 수 있는 작업 폴더" 정도로 이해하면 OK입니다. -
• 워크스페이스 (Workspace)… Codex가 "써도 된다"고 간주하는 범위입니다. 기본적으로 현재 있는 커런트 디렉토리(current directory)와 /tmp와 같은 임시 폴더가 포함됩니다.

결론부터 말하자면, 승인 모드와 샌드박스가 편리한 이유는 AI의 무서움을 자신의 손으로 다이얼(조절 장치)처럼 조절할 수 있기 때문입니다.

AI에게 개발을 맡길 때의 불안함은 궁극적으로 "제어할 수 없다는 느낌"에서 옵니다. 무엇을 할지 알 수 없기 때문입니다. 그래서 무서운 것입니다.

하지만 Codex는 그 "무엇을 할지"를 당신이 사전에 선을 그어둘 수 있습니다.

• 상담만 하고 싶은 날은, 읽기만 하기 · 파일 수정시키지 않기로 한정.
• 코드를 계속 작성하게 하고 싶은 날은, 작업 폴더 안은 자유, 외부로 나갈 때만 확인으로 설정.
• CI나 자동화로 돌리고 싶을 때는, 일절 묻지 않고 읽기만 하기로 설정.

같은 Codex임에도 그날의 태스크에 맞춰 "맡기는 넓이"를 바꿀 수 있습니다. 이것은 자동차의 액셀러레이터와 브레이크를 스스로 밟는 것과 같아서, 제어할 수 있기 때문에 안심하고 빠르게 달릴 수 있는 것입니다. "AI가 대단하니까 전부 맡긴다"가 아니라, "인간이 범위를 정하고 그 안에서 마음껏 일하게 한다". 이 점이 핵심이라고 생각합니다.

세부 설정은 많이 있지만, 처음에 파악해야 할 것은 3가지 모드뿐입니다. 이것만 알면 나머지는 응용입니다.

Codex는 당신이 아무것도 지정하지 않으면 Auto로 동작합니다. 정확하게는 "작업 폴더 내는 쓰기 OK · 승인은 필요할 때만 요청(on-request) · 네트워크는 기본적으로 OFF"라는, 딱 적당한 중간 설정입니다.

게다가 실행 시 Codex는 해당 폴더가 Git으로 관리되고 있는지 확인하여 권장 설정을 바꿔줍니다.

버전 관리되는 폴더 $\rightarrow$ Auto 권장 (변경 이력이 남으므로 되돌릴 수 있기 때문)
버전 관리되지 않는 폴더 $\rightarrow$ read-only 권장 (되돌릴 수 없으므로 신중하게)

"되돌릴 수 있는지 여부"에 따라 안전한 쪽을 선택해 준다는 설계 사상이 엿보이는데, 개인적으로 이 부분이 꽤 마음에 드는 포인트입니다.

가장 기본적인 방법은 Codex를 실행하는 명령에 플래그(Flag, 즉 옵션 지정)를 붙이는 것입니다. 사용하는 것은 이 두 가지입니다.

--sandbox

... 샌드박스(Sandbox) 모드를 선택. 값은 read-only / workspace-write / danger-full-access

--ask-for-approval

... 승인 타이밍을 선택. 값은 on-request / untrusted / never (짧게 -a로도 쓸 수 있음)

예를 들어, 기본값인 Auto를 명시적으로 지정하면 다음과 같습니다.

# Auto (작업 폴더 내는 자동, 외부·네트워크는 확인) — 사실 지정하지 않아도 이것과 같음
codex --sandbox workspace-write --ask-for-approval on-request

"오늘은 읽기만 하고 싶다"라면 다음과 같습니다.

# 읽기 전용. 편집도 명령 실행도 하기 전에 반드시 확인을 거침
codex --sandbox read-only --ask-for-approval on-request

공식 문서에서는 이 두 가지 조절 장치의 조합을 대표적인 패턴으로서 표로 정리해 두었습니다. 자주 사용하는 것들을 뽑아보면 다음과 같습니다.

--ask-for-approval untrusted는 눈에 띄지는 않지만 편리합니다. 파일 읽기/쓰기는 막힘없이 자동으로 해주면서, 상태를 망가뜨릴 수 있는 명령(예를 들어 파괴적인 Git 조작 등)을 실행하기 직전에만 제대로 멈춰서 물어봐 줍니다. "속도"와 "위험한 조작만 확인"이라는 장점을 모두 챙긴 셈이죠.

참고로, 승인을 일절 하지 않는 --ask-for-approval never는 어떤 샌드박스 모드와도 조합할 수 있습니다. "승인은 묻지 않지만, 샌드박스(Sandbox)라는 울타리 밖으로는 나가지 못하게 한다"는 운영도 가능하다는 뜻입니다. 이 부분에서 never

＝위험하다"라고 성급하게 판단하기 쉽지만, 샌드박스 (Sandbox)로 둘러싸인 상태에서의 never라면 범위는 보호된 상태입니다.

"실행한 뒤에, 역시 읽기 전용으로만 하고 싶다"라는 상황, 다들 있으시죠? Codex를 다시 실행하지 않아도, 대화 도중에 모드를 변경할 수 있습니다. 그것이 /permissions 명령어입니다.

Codex가 실행 중인 화면에서 다음과 같이 입력하기만 하면 됩니다.

/permissions

이를 통해 현재의 샌드박스 모드나 "쓰기 권한이 있는 범위 (writable roots)"를 확인하거나, read-only (읽기 전용)로 전환할 수 있습니다. "지금은 상담 모드로 해두자"라고 생각되면, /permissions를 통해 읽기 전용으로 낮추는 식입니다. 이러한 간편함이 실제로 사용할 때 매우 유용합니다.

함께 기억해두면 편리한 것이 /status입니다.

/status

이를 통해 현재 워크스페이스 (Workspace)에 어떤 디렉터리 (Directory)가 포함되어 있는지 확인할 수 있습니다. "Codex가 어디까지 쓸 수 있는가?"를 한눈에 알 수 있어, 작업을 맡기기 전 확인용으로 적합합니다.

"매번 플래그 (Flag)를 입력하는 것은 번거롭다. 항상 같은 설정이면 좋겠다"라고 생각하는 분은 설정 파일인 config.toml (위치는 ~/.codex/config.toml)에 작성해 둘 수 있습니다. TOML (Toml)은 설정을 작성하기 위한 심플한 표기법이라고 생각하시면 됩니다.

# 매번 "확인 위주·읽기 전용"으로 시작하고 싶은 경우의 예
approval_policy = "untrusted"
sandbox_mode = "read-only"
...

approval_policy … 승인 정책 ("on-request" / "untrusted" / "never" 등)

sandbox_mode … 샌드박스 ("read-only" / "workspace-write" 등)

나아가, 용도에 따라 설정을 "프로파일 (Profile)"로 저장하여 실행 시 선택할 수도 있습니다.

# 저장해둔 프로파일을 지정하여 실행
codex --profile readonly_quiet

요약하자면, 맡길 범위를 결정하는 방법은 3단계로 생각하면 헤매지 않습니다.

말로만 들으면 감이 잘 오지 않으므로, 실제로 직접 움직여 보며 "맡길 범위를 스스로 결정하는" 감각을 익혀봅시다. 망가져도 상관없는 연습용 빈 폴더에서 진행하는 것을 추천합니다.

# 1. 연습용 폴더를 만들고 그 안으로 이동
mkdir codex-permission-practice
cd codex-permission-practice
...

Codex가 실행되면 먼저 현황을 살펴봅니다.

/status

→ 현재 어떤 폴더가 "쓰기 권한이 있는 범위"에 포함되어 있는지 표시됩니다. "아하, 이 안쪽만 해당되는구나"라고 확인되면 OK입니다.

다음으로, 의도적으로 **읽기 전용 모드 (read-only mode)**로 전환해 봅시다.

/permissions

→ 여기서 read-only를 선택합니다. 이제 "Codex는 읽고 대답만 한다. 파일은 수정하지 않는다" 상태가 되었습니다. 테스트 삼아 "이 폴더에 hello.txt를 만들어줘"라고 부탁해 보세요. read-only 상태이므로, Codex는 마음대로 만들지 않고 확인을 요청할 것입니다.

이 "부탁해도 즉시 손을 대지 않고 멈추는 것" —— 이것이야말로 당신이 범위를 제어하고 있다는 증거입니다. 여기까지 왔다면 승인 모드와 샌드박스의 본질은 이미 몸으로 이해하신 것입니다.

보충: 위의 명령어 열은 공식 문서의 사양에 따라 작성되었으나, 실제 표시나 선택지는 버전에 따라 조금씩 달라질 수 있습니다. 본 기사에서는 로컬에서의 연속 실행까지는 확인하지 않았으므로, 세부 사항은 화면의 안내를 따라주세요 (동작 미확인·공식 사양 준거).

Q. 매번 "이거 실행해도 돼?"라고 물어보니, 솔직히 좀 번거롭습니다.

A. 그것은 당신이 제대로 안전한 쪽에 서 있다는 증거입니다. 계속 확인 과정이 많다고 느껴진다면, --ask-for-approval untrusted 옵션을 사용해 보세요. 일반적인 읽기/쓰기는 자동으로 진행되고, 의심스러운 명령 직전에만 멈춰줄 것입니다. 속도와 안심 사이의 가장 현실적인 타협점이라고 생각합니다.

Q. 반대로, 아무것도 묻지 않고 진행하는 것이 불안합니다.

A. Codex가 아무것도 묻지 않고 진행하는 것이 불안하다면, 승인(Approval)을 더 엄격하게 설정하세요. --ask-for-approval on-request 상태를 유지하면서 --sandbox read-only를 설정하면, 편집이나 실행을 하기 전에 반드시 물어볼 것입니다. "먼저 읽기만 하기"부터 시작해서, 신뢰할 수 있게 되면 조금씩 맡기는 범위를 넓혀가는—이 순서가 안심할 수 있습니다.

Q. Codex가 인터넷에 접속할 수 없어서 설치 관련 명령어가 실패합니다.

A. 이것은 오류가 아니라, 기본값(Default)으로 네트워크가 꺼져 있기 때문입니다. 안전을 위한 초기 설정입니다. 꼭 필요한 경우에만 config.toml의 [sandbox_workspace_write]에서 network_access = true로 설정하여 열 수 있지만, 설정했다면 그만큼 외부 세계와 연결된다는 점은 반드시 의식해야 합니다.

Q. .git 폴더는 건드리지 않았으면 좋겠습니다.

A. 걱정하지 마세요. 쓰기 가능한 워크스페이스(Workspace) 안에서도 .git이나 .agents, .codex와 같은 폴더는 읽기 전용(Read-only)으로 보호되어 있습니다. 실수로 히스토리가 망가지지 않도록 설계되어 있습니다.

Q. --yolo (풀 액세스)는 사용해도 괜찮은 건가요?

A. 기본적으로 사용하지 마세요. 이유는 다음 장에서 설명하겠습니다.

편리한 기능일수록 한계와 리스크도 함께 알고 있어야 하기에, 마지막으로 솔직한 의견을 적습니다.

풀 액세스 (--sandbox danger-full-access / --yolo)는 가볍게 사용할 수 있는 것이 아닙니다. 이는 샌드박스(Sandbox)와 승인 절차를 모두 해제한 상태이며, 공식 문서에서도 **"Elevated Risk (높은 리스크)", "비권장 (Not Recommended)"**라고 명시되어 있습니다. 사용하더라도 Docker나 dev 컨테이너처럼 외부에서 확실히 격리된 환경 안에서만 사용하는 것이 철칙입니다. 평소 사용하는 자신의 PC에서, 히스토리가 남는 중요한 리포지토리(Repository)에 대해 갑자기 YOLO 모드로 실행하는 것은 피해야 합니다.

그리고 애초에 대부분의 사람에게는 기본 설정인 Auto로도 충분합니다. "더 자유롭게 설정하지 않으면 불편할지도 몰라"라고 생각하기 전에, 먼저 Auto 모드로 몇 번 사용해 보세요. 승인 프롬프트가 뜨면, 내용물인 명령어를 딱 한 번만 직접 눈으로 읽고 나서 허가하세요. 이것을 습관화하는 것만으로도 맡기는 감각이 훨씬 안정될 것입니다.

또 하나 중요한 한계가 있습니다. 샌드박스는 OS의 메커니즘 (macOS의 Seatbelt, Linux의 bwrap + seccomp 등)에 의존하며, 만능이 아닙니다. Docker 구성에 따라서는 애초에 샌드박스가 제대로 작동하지 않을 수도 있습니다. 게다가 네트워크나 웹 검색을 활성화하면, 외부 페이지에 숨겨진 악의적인 지시(프롬프트 인젝션, Prompt Injection)를 AI가 읽어버릴 리스크도 발생합니다. 따라서 "샌드박스에 넣었으니 무조건 안전하다"가 아니라, 외부에서 가져오는 정보는 기본적으로 의심한다는 자세가 적당합니다.

하지만 너무 겁먹을 필요는 없습니다. 여기까지 읽은 당신은 이미 "맡길 범위를 스스로 결정하는" 조절 노브를 손에 쥐고 있습니다. 두려움은 없애는 것이 아니라, 설정으로 길들이는 것입니다. 그 첫걸음을 오늘 내디뎠다면 그것으로 충분합니다.

• Codex의 안전은 **샌드박스 (할 수 있는 범위의 넓이)**와 **승인 정책 (언제 사람에게 물어볼 것인가)**이라는 두 가지 요소로 결정된다.
• 기억할 것은 딱 3단계뿐: 읽기 전용 / Auto / 풀 액세스. 고민된다면 Auto.
• 결정 방법은 3층 구조: 그 자리에서는 /permissions, 실행 시에는 --sandbox · --ask-for-approval, 영구 적용은 config.toml.
• 풀 액세스 (--yolo)는 격리된 환경에서만. 대부분의 사람은 Auto로 충분하다.
• 우선 연습용 폴더에서 /status $
  ightarrow$ /permissions를 통해 read-only를 체감해 볼 것.

「AI가 멋대로 움직이는 것이 두렵다」는 설정을 모를 때 느끼는 불안이었습니다. 범위를 스스로 결정할 수 있다는 것을 알게 된 지금, 그 두려움은 당신이 조절할 수 있는 다이얼로 바뀌었습니다. 오늘은 우선 평소 사용하는 프로젝트에서 한 번 Auto 모드인 상태로 실행해 보고, 승인 프롬프트(approval prompt)의 내용을 딱 한 번만 주의 깊게 읽어보세요. 그것이 AI와 안전하게 공존하는 가장 좋은 연습이 될 것입니다.

• Codex CLI 개요 — OpenAI 공식: https://developers.openai.com/codex/cli
• Agent approvals & security (샌드박스 · 승인 · 네트워크) — OpenAI 공식: https://developers.openai.com/codex/agent-approvals-security

※ 본문 중의 플래그(flag) 명칭 · 기본값 · 조합표는 위 공식 문서(2026년 8월 시점)와 대조하였습니다. 핸즈온(hands-on) 명령어 열은 공식 사양에 기반하여 작성되었으며, 직접 전체 실행을 완료하여 검증한 것은 아닙니다. 표시 방식이나 선택지는 버전에 따라 달라질 수 있습니다.

생성형 AI 활용 엔지니어 & 세 아이의 아빠. AI × 개발의 실천적 지식을 매일 발신하고 있습니다. X (구 Twitter)에서도 활동 중이니, 괜찮으시다면 구경해 보세요 → https://x.com/akira_papa_AI