Codex Auto Mode 완전 무인 실행 가이드: 직접 테스트한 설정법

Codex가 파일을 고치고 명령을 실행한 뒤, 매 단계마다 승인을 기다리지 않고 계속 작업해 주길 바랄 때가 있다. 그런데 "Full Access"를 켰는데도 다시 묻는 경우가 있다. 결론부터 말하면 자동 실행은 단일 스위치가 아니기 때문이다. 아래는 Codex CLI v0.145.0에서 직접 확인한, 완전 무인 실행 설정법이다.

계속 승인을 묻는 이유: Codex의 "Auto mode"는 하나의 설정이 아니다. 샌드박스는 어디까지 접근할 수 있는지를, 승인 정책은 언제 작업을 멈추고 물어볼지를 따로 결정한다. 네트워크 접근도 별도의 관문이다. 한쪽 제한만 풀어서는 다른 제한이 함께 풀리지 않으며, Codex 업데이트 뒤 세션이 기본 정책으로 조용히 돌아갈 수도 있다.

CLI에서 완전 무인으로 실행하려면: 모든 관문을 한 번에 없애는 플래그는 --yolo뿐이다. 샌드박스는 유지하면서 조금 더 안전하게 쓰려면 두 축을 모두 명시해야 한다. 세션을 시작할 때 설정하고, 업데이트 후에는 반드시 다시 확인하는 편이 좋다.

# 완전 무인 실행 — 샌드박스와 승인 프롬프트 모두 없음(일회용 환경에서만 사용):
codex --yolo
# 더 안전한 방식 — 프로젝트 안에서는 자유롭게 수정하고, 밖으로 나갈 때만 확인:
codex --sandbox workspace-write --ask-for-approval on-request

앱에서 완전 무인으로 실행하려면: 승인 메뉴를 열어 Full access를 선택한다. 업데이트하면 모드가 초기화되므로, 업데이트 후에는 다시 선택해야 한다.

여기까지가 빠른 답이다. 이제 각 모드의 실제 동작, 내부 설정과의 대응 관계, 상황별 선택 기준을 자세히 살펴보자.

Codex 승인 모드 3가지, 한눈에 비교

샌드박스는 에이전트가 파일과 네트워크 등 어디까지 건드릴 수 있는지를 정하고, 승인 정책은 언제 멈춰 사용자에게 물을지를 정한다. Auto mode는 이 두 설정을 조합한 프리셋일 뿐이다. 데스크톱 앱과 CLI는 같은 조합을 서로 다른 이름으로 표시한다.

CLI를 주로 쓴다면 --sandbox와 --ask-for-approval로 이 값을 직접 지정하면 된다. 세션 중에는 /permissions 선택기에서 프리셋을 바꿀 수도 있다. 아직 클라이언트 자체를 고르는 단계라면 이는 별개 문제다. Codex와 Claude Code 비교는 여기에서 확인할 수 있다. 이 글은 설정 자체에 집중한다.

"Full Access"인데도 승인 요청이 뜨는 이유

원인은 세 가지이며, 동시에 겹칠 수 있다.

샌드박스와 승인은 별개의 축이다. workspace-write + on-request 조합에서는 Codex가 프로젝트 내부를 자유롭게 수정할 수 있지만, 네트워크 호출·저장소 밖의 파일·sudo처럼 경계를 넘는 작업에서는 멈춘다. 샌드박스만 느슨하게 하고 승인 정책을 on-request로 남겨두면, 경계를 넘을 때마다 계속 프롬프트가 뜬다.

네트워크는 별도 관문이다. Full Access에서도 인터넷 접근은 파일 시스템과 별도로 통제될 수 있다. @mxcl은 2026년 7월 16일 Codex가 "cannot use the Internet without full access, ending task until the user enables full access"라고 지적했다. 파일 쓰기 권한과 네트워크 권한은 같은 것이 아니다.

업데이트가 모드를 초기화한다. 2026년 7월 말 여러 사용자가 Codex를 업데이트한 뒤 활성 세션이 기본 정책으로 조용히 되돌아가는 문제를 겪었다. @s_rafcon은 7월 22일 스레드가 "switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit" 상태가 된다고 전했다. 세션 시작 시 모드를 지정하고, 업데이트할 때마다 다시 확인하자.

CLI의 --full-auto는 사라졌다: 지금은 이렇게 설정한다

codex --full-auto는 예전에 "프로젝트 안에서 묻지 말고 작업"하는 단축 명령이었다. 즉 approval_policy = "on-request"와 sandbox_mode = "workspace-write"를 묶은 설정이다. 하지만 대화형 명령에서는 더 이상 받을 수 없다. v0.145.0에서 테스트한 결과는 다음과 같다.

$ codex --full-auto
error: unexpected argument '--full-auto' found

이제는 두 축을 명시적으로 설정하면 된다. 아래 설정이 과거 플래그와 정확히 같은 동작을 한다.

# --full-auto의 현재 대체 설정
codex --sandbox workspace-write --ask-for-approval on-request
# 또는 비대화형 실행: 프롬프트 없이, 샌드박스는 유지
codex -a never -s workspace-write exec "your task"

스크립트에서는 codex exec --full-auto가 여전히 동작하며, 대화형 명령에서만 오류가 난다. codex --help 기준으로 --ask-for-approval에는 untrusted / on-request / never를, --sandbox에는 read-only / workspace-write / danger-full-access를 지정할 수 있다. 앱의 모든 "모드"는 결국 이 두 값의 조합이다.

--yolo를 써야 할 때: 모든 제한 우회

--yolo는 --dangerously-bypass-approvals-and-sandbox의 짧은 별칭이다. 진짜 "손 뗀 채 실행" 스위치로, danger-full-access와 never를 함께 적용한다. 파일 시스템 경계도 승인 관문도 없다. 위험성이 이름에 명확히 드러나기 때문에 --full-auto가 사라진 뒤에도 남았다. v0.145.0에서 codex --yolo는 정상 처리되지만, codex --full-auto는 오류를 낸다.

경험 많은 사용자 중에는 이를 기본으로 쓰는 사람도 많고, 환경 자체가 안전장치라면 그 판단은 맞을 수 있다. 다만 컴퓨터를 소모 가능한 환경으로 취급해야 한다.

• 평소 쓰는 머신이 아니라 일회용 VM이나 개발 컨테이너에서 실행한다.
• 먼저 환경에서 프로덕션 자격 증명을 제거한다.
• 작업 범위를 좁게 잡고, 계속 진행하기 전에 git diff를 확인한다.

--yolo는 모든 관문을 없애므로, 엉뚱한 rm -rf, git push, DROP TABLE도 승인 없이 실행된다. 속도를 얻는 대가다. 커스텀 모델 프로바이더를 통해 Codex를 자체 호스팅 엔드포인트나 Anthropic 호환 엔드포인트에 연결해도 이 점은 달라지지 않는다. 샌드박스는 API 뒤에 어떤 모델이 있는지 신경 쓰지 않는다.

"Approve for me"와 Auto-review: AI가 승인을 대신하는 방식

가장 최신 모드이자 현재 앱 기본값은 Auto-review다. 승인 대상이 되는 상향 요청은 별도의 검토 에이전트, 즉 GPT-5.4 Thinking (low)를 실행하는 소형 Codex로 전달된다. 이 에이전트는 근거와 함께 승인 또는 거절을 결정한다. OpenAI는 이를 "권한 부여가 아니라 검토자 교체"라고 설명한다. 쓰기 가능한 디렉터리를 넓히거나 네트워크를 열지는 않고, 단지 승인자가 사용자에서 AI로 바뀐다.

OpenAI가 2026년 4월 30일 공개한 자체 평가에 따르면, Auto-review는 수동 승인보다 사람이 개입해야 하는 빈도를 약 200배 낮춘다. 검토한 상향 요청의 약 99.1%를 승인하며, 전체 작업 기준 승인율은 99.93%다. 10,000개 작업을 예시로 든 스냅샷에서는 9,280개가 샌드박스 안에서 별도 처리 없이 실행됐고, 720개가 검토자로 넘어갔으며, 거절된 것은 7개뿐이었다.

거절이 연쇄적으로 이어지는 상황을 막는 보호 장치도 있다. 연속 3회 거절되거나 최근 50회 검토의 이동 구간에서 10회 거절되면 해당 턴은 중단된다. 이때 /approve를 실행하면 Auto-review Denials 선택기가 열리며, 한 작업을 승인한 뒤 재시도할 수 있다.

문제는 이런 안전 확인이 장시간 작업을 멈출 수 있다는 점이다. 2026년 7월 말, 수 시간짜리 /goal 작업을 돌리던 사용자들은 주기적으로 뜨는 "keep waiting?" 프롬프트 때문에 과거에는 며칠씩 무인 실행되던 워크플로가 끊긴다고 보고했다. OpenAI도 이것이 "보안을 보장하는 수단으로 취급되어서는 안 된다"고 명확히 밝힌다. 레드팀 재현율은 높지만 완전하지 않다. 90.3% overreach, 99.3% prompt injection, 96.1% misaligned-model이다. 기본값으로는 괜찮지만, 중요한 작업에서 샌드박스를 대체할 수는 없다.

UI 대신 설정 파일에서 켜려면 다음과 같이 지정한다.

approvals_reviewer = "auto_review"

[auto_review]
policy = """
검토자가 허용하거나 차단해야 할 작업을 여기에 설명합니다.
"""

상황별로 어떤 모드를 선택해야 할까?

• 일상적인 로컬 코딩: workspace-write + on-request ("Ask for approval")를 권한다. 저장소 밖으로 나가는 작업에 대한 거부권을 유지할 수 있으며, 실제로 큰 피해가 나는 지점도 대개 여기다.
• 길고 무인으로 돌리는 작업: "Approve for me"(Auto-review)가 맞다. 다만 플래그된 작업에서는 여전히 멈추므로, 완전한 무개입 모드는 아니다.
• 일회용 환경에서 하는 거친 단발 작업: --yolo가 가장 빠르지만 가장 위험하다. 환경에 피해가 갈 수 없을 때만 안전하다.
• 코드베이스를 읽거나 리뷰할 때: read-only를 쓴다. 쓰기가 없으니 예상치 못한 변경도 없다.

솔직한 결론은 이렇다. 완전 자율적이면서 완전히 안전한 설정은 없다. 손을 뗄수록 자신의 판단을 분류기의 판단과 맞바꾸게 된다. 일상 작업에서는 그 교환이 가치 있을 수 있지만, 프로덕션 인프라에서는 좋지 않은 선택이다. 한 번 정해 영구히 쓰지 말고, 작업마다 고르자.

FAQ

Codex에 자동 모드가 있나?

있다. 다만 단일 토글이 아니라 여러 프리셋으로 구성된다. 앱에서는 "Ask for approval", "Approve for me", "Full access"가 자동 모드이며, CLI에서는 --sandbox와 --ask-for-approval를 조합하거나 /permissions를 사용해 같은 동작을 만들 수 있다.

Codex가 모든 명령을 자동 승인하게 하려면?

approval_policy = "never"로 설정한다. workspace-write와 조합하면 샌드박스 안에서 프롬프트가 사라지고, danger-full-access와 조합하면(--yolo) 모든 프롬프트가 사라진다. 후자는 모든 안전장치를 제거하므로 격리된 환경에서만 실행해야 한다.

Codex Auto-review 모드란?

Auto-review(approvals_reviewer = "auto_review", 앱에서는 "Approve for me")는 승인 결정을 사용자 대신 AI 검토 에이전트에게 맡기는 기능이다. 검토 대상의 약 99%를 승인하고 사람 개입 빈도를 약 200배 낮추지만, 보안을 보장하지는 않는다.

--full-auto는 아직 작동하나?

대화형 CLI에서는 작동하지 않는다. v0.145.0에서 테스트한 결과 codex --full-auto는 "unexpected argument"를 반환한다. 스크립트용 codex exec --full-auto는 deprecated 별칭으로 여전히 허용된다. 대화형 사용에서는 대신 --sandbox workspace-write --ask-for-approval on-request를 지정하면 된다.

--yolo 모드는 안전한가?

아니다. 이름 자체가 그 점을 말해 준다. 샌드박스와 모든 승인을 동시에 비활성화한다. 프로덕션 자격 증명을 제거하고 작업 범위를 좁힌 일회용 VM 또는 컨테이너 안에서만 고려할 만하다.