Codex CLI YOLO 모드: 두 개의 노브와 하나의 플래그, 그리고 왜 --yolo가 샌드박스를 파괴하는지

요약 (TL;DR)

• codex --yolo는 --dangerously-bypass-approvals-and-sandbox의 짧은 별칭입니다. 이는 승인(approvals)을 never로, 그리고 샌드박스(sandbox)를 danger-full-access로 설정합니다.
• 두 번째 부분이 특이합니다. Claude Code와 Gemini CLI의 YOLO 모드는 프롬프트를 건너뛰지만 샌드박싱은 그대로 유지합니다. 반면, Codex는 둘 다 제거합니다.
• 이 두 가지 조절 장치(knobs)는 독립적입니다: -a never -s workspace-write를 사용하면 "요청하지 않으면서도 격리된 상태를 유지"할 수 있으며, 이것이 대부분의 사용자가 실제로 원하는 설정입니다.
• 샌드박스는 실제 OS 수준의 격리 기능입니다: macOS에서는 Seatbelt (sandbox-exec), Linux/WSL2에서는 bubblewrap + seccomp, Windows에서는 네이티브 샌드박스가 적용되며, WSL1에서는 적용되지 않습니다(nothing).
• codex exec는 승인을 요청하지 않기 때문에, CI 환경에서는 샌드박스만이 유일하게 중요한 조절 장치입니다.

아래의 모든 플래그는 2026년 10월 7일 기준으로 openai/codex 커밋 72c9595 (릴리스 0.161.0), @agentclientprotocol/codex-acp 2.1.1, 그리고 OpenAI의 Codex 문서를 통해 확인되었습니다.

두 가지 조절 장치란 무엇인가요?

Codex 모델은 안전성을 두 개의 독립적인 차원으로 간주합니다:

on-request는 모델이 샌드박스가 차단할 만한 작업을 수행하려고 할 때 원할 때마다 멈추고 사용자에게 물어볼 수 있다는 의미입니다. 이때 샌드박스는 OS 수준에서 어떤 파일에 쓰기 권한이 있는지, 그리고 네트워크 연결 여부가 있는지를 결정합니다.

두 조절 장치가 독립적이기 때문에, 사용자는 2×3 그리드의 동작 방식을 얻게 됩니다. 흥미로운 조합은 다음과 같습니다:

codex -a never -s danger-full-access   # == codex --yolo
codex -a never -s workspace-write      # 요청하지 않지만 여전히 격리됨 (fenced)
codex -a on-request -s danger-full-access  # 격리가 없으며, 그래도 물어볼 수 있음 (드물게 발생)

중간의 기능은 매력적인 실패 모드를 가지고 있습니다. 명령이 샌드박스가 허용하는 것보다 더 많은 것을 필요로 할 때, 단순히 실패하며, 이 오류가 모델에게 돌아가서 우회합니다. 인간 개입(human in the loop)은 없지만, 탈출구도 없습니다.

CLI(명령줄 인터페이스)에서, -a는 on-request와 never만 허용합니다. 두 가지 설정값을 모두 지정하는 플래그를 결합하면 거부됩니다: --yolo는 -a와 함께 사용할 수 없으며, --approve-for-me는 -a, -s 또는 --yolo와 함께 사용할 수 없습니다.

Codex의 YOLO는 왜 샌드박스를 무시할까요?

해당 플래그 자체의 도움말 텍스트에 따르면 이 기능은 외부에서 이미 샌드박스 처리된 환경을 위한 것이라고 명시되어 있습니다(자신을 "극도로 위험함(EXTREMELY DANGEROUS)"이라고 부릅니다). 설계상의 가정은 다음과 같습니다: 만약 사용자가 Codex에게 "절대 묻지 마라"고 지시한다면, 아마도 내부 샌드박스는 그저 방해 요소일 뿐인 컨테이너, VM 또는 CI(지속적 통합) 러너에 있을 가능성이 높다는 것입니다. 이 가정은 CI 환경에서는 좋지만, 개인 노트북에서는 치명적입니다.

danger-full-access가 실제로 의미하는 바는 다음과 같습니다. "프로젝트"를 의미하는 것이 아닙니다. 사용자 계정이 접근할 수 있는 모든 것을 의미합니다:

• 읽거나 쓸 수 있는 모든 파일: ~/.ssh, ~/.aws, ~/.config/gcloud, 브라우저 프로필, 다른 리포지토리(repo), 설정 파일(.dotfiles).
• 제한 없는 네트워크: 다운로드 및 실행, 발견하는 모든 토큰으로 API 호출, 모든 데이터 유출(exfiltrate).
• 사용자 git 신원(identity): .git이 더 이상 보호되지 않기 때문에 히스토리 재작성 및 git push --force가 사용자의 이름으로 나갑니다.
• Codex를 시작한 셸(shell)에 내보내진 모든 환경 변수(env var).

여기에 프롬프트 주입(prompt injection)을 추가해 봅시다. README, 이슈 또는 가져온 웹 페이지에 있는 악의적인 지침은 모델을 유도할 수 있으며, YOLO가 활성화된 상태에서는 멈춰서 사용자에게 물어보지 않습니다.

샌드박스는 실제로 어떻게 구축되나요?

workspace-write 모드에서도 Codex는 .git, .codex, 그리고 .agents를 **읽기 전용(read-only)**으로 유지하므로, 요청 없이 히스토리를 다시 쓰거나 자체 설정을 변경할 수 없습니다. 이것은 흥미로운 세부 사항입니다: 에이전트 자신의 제어 평면(control plane)이 쓰기 경계(write fence) 밖에 있다는 것입니다.

펜스를 해제하지 않으면서 YOLO의 대부분을 얻는 방법은 무엇인가요?

대부분의 YOLO 욕구는 두 가지 workspace-write 제한 사항에서 비롯됩니다: 네트워크 접근 불가, 그리고 프로젝트 외부 쓰기 불가. 이들을 개별적으로 열어보세요:

sandbox_mode = "workspace-write"
approval_policy = "never"

...

network_access는 npm install/pip install이 작동하도록 합니다. writable_roots (또는 실행 시 --add-dir <DIR>를 사용)는 폴더를 추가합니다. exclude_tmpdir_env_var와 exclude_slash_tmp는 더 엄격하게 만들고 싶을 때 $TMPDIR과 /tmp를 쓰기 가능한 집합에서 제거합니다.

설정 우선순위(config precedence)는 어떻게 작동하며, 프로젝트 신뢰성은 어디에 속하나요?

Codex는 ~/.codex/config.toml (또는 $CODEX_HOME/config.toml)을 읽습니다. YOLO의 기본값은 다음과 같습니다:

approval_policy = "never"
sandbox_mode = "danger-full-access"

알아두면 좋은 몇 가지 우선순위 규칙이 있습니다:

• -c key=value: 한 번의 실행에 대해 모든 키를 재정의합니다.
• 권한 프로필 (Permission profiles): default_permissions = ":danger-full-access" (또한 :workspace, :read-only)가 더 새로운 형식이며, 설정 시 sandbox_mode보다 우선권을 가집니다.
• 프로필 (Profiles): codex -p yolo는 일반 구성 위에 ~/.codex/yolo.config.toml 파일을 계층적으로 로드합니다. YOLO를 프로필로 유지한다는 것은 실행 시마다 선택적(opt-in)이라는 의미입니다. (이전의 [profiles.yolo] 테이블도 여전히 로드되지만, -p는 이제 별도의 파일을 의미합니다.)
• 관리되는 requirements.toml: 관리자는 never 또는 danger-full-access를 금지할 수 있으며, Codex는 허용된 기본값으로 폴백(fallback)합니다.
• 폐기된 값 (Retired value): approval_policy = "untrusted"는 이제 시작 시 하드 에러입니다. on-failure는 여전히 on-request의 다른 이름으로 받아들여집니다.

**프로젝트 신뢰도 (Project trust)**는 Codex가

알아두세요: 설정은 세션 시작 시 읽힙니다. 세션 중간에 config.toml을 수정해도 재시작하거나 /permissions를 사용하기 전까지는 아무것도 변경되지 않습니다.

codex exec에서 CI가 변경되는 점?

codex exec은 하나의 작업을 비대화형으로 실행합니다. 물어볼 사람이 없기 때문에 절대 묻지 않으며 -a 플래그도 없습니다. 샌드박스가 유일한 조절 장치이며, 기본값은 **읽기 전용(read-only)**입니다:

codex exec "open TODOs 요약"                        # 읽기 전용
codex exec --sandbox workspace-write "실패하는 테스트 수정"
codex exec --yolo "전체 릴리스 스크립트 실행"              # 샌드박스 없음

exec는 --skip-git-repo-check (또는 이를 건너뛰는 --yolo)를 전달하지 않는 한 git 저장소 외부에서는 실행을 거부합니다. --json은 JSON Lines 이벤트를 스트리밍하고, -o <파일>은 최종 메시지를 작성합니다. 워크플로우가 신뢰할 수 없는 코드를 체크아웃하는 경우, 작업 전체가 아닌 해당 단일 단계에 한정하여 CODEX_API_KEY를 사용하세요.

GitHub에서는 openai/codex-action@v1이 키를 프록시 뒤에 숨기고(기본적으로 sudo를 제거함(safety-strategy: drop-sudo)), permission-profile: ":workspace"를 사용합니다. 호스팅 러너는 --yolo가 가정하는 정확한

AgentRQ를 사용하여 작업별 또는 워크스페이스별로 YOLO 기능을 활성화하는 방법은 무엇인가요?

위에 언급된 모든 Codex 스위치는 세션 범위(session-scoped)입니다. 만약 특정 작업에만 YOLO가 필요하고 다른 모든 것은 승인이 필요한 경우, 그 결정을 Codex 외부의 작업으로 옮겨야 합니다.

1. ACP Gateway를 통해 Codex 연결하기 (Codex CLI ACP 설정 가이드):

npx @agentrq/acp-gateway@latest --login --agent codex-acp   # 한 번만 실행
npx @agentrq/acp-gateway@latest --agent codex-acp

이 게이트웨이는 새로운 세션마다 모든 자체 승인 모드(Auto review, Full access)에서 벗어나 읽기 전용(read-only) 상태로 만듭니다. 따라서 모든 편집 및 명령어는 AgentRQ 작업 내에서 웹, 휴대폰 또는 Slack을 통해 권한 요청으로 사용자에게 전달됩니다. 사용자는 다음과 같이 응답합니다:

• Allow Once (일회 허용): 이 호출에만 해당.
• Always Allow (항상 허용): 도구를 워크스페이스의 자동 승인 목록에 추가함.
• Deny (거부): Codex가 거부를 받으며, 사용자는 대신 무엇을 할 수 있는지 회신할 수 있습니다.

30분 이내에 아무도 응답하지 않으면, 게이트웨이는 추측하는 대신(--permission-timeout으로 변경 가능) 해당 턴을 취소합니다.

2a. 작업별 설정. 특정 작업에서 YOLO 토글을 켜거나 생성 시 설정할 수 있습니다. 해당 작업의 모든 권한 요청은 자동 승인되지만, 다른 모든 작업은 여전히 사용자에게 요청합니다. 예정된 작업(Scheduled tasks), 이벤트 트리거(event triggers) 및 워크플로우(workflow) 단계도 동일한 스위치를 가집니다. 작업별 플래그는 에이전트 연결 해제와 재연결을 거쳐도 유지됩니다.

2b. 워크스페이스별 설정. 워크스페이스 설정에는 **YOLO 모드(모두 실행)**가 있습니다 (UI 경고: "Agent는 권한을 요청하지 않습니다"). 내부적으로 이는 전역 재정의가 아닌 기본값입니다. 승인 확인은 작업 자체의 YOLO 플래그를 읽으며, 워크스페이스 스위치가 해당 플래그의 초기값을 결정합니다. 웹 양식에서 새로 생성하는 작업은 YOLO 토글이 이미 켜진 상태로 열리며 (작업별로 여전히 끌 수 있음), 에이전트가 워크스페이스 MCP 서버를 통해 자체적으로 생성하는 작업은 이를 상속받습니다. 스위치를 전환한다고 해서 이미 존재하는 작업을 재작성하지는 않습니다.

또는 일반 영어 규칙을 기반으로 모델에게 승인 및 거부를 맡길 수도 있습니다. "매번 나에게 묻기"와 "모두 승인하기" 사이에는 세 번째 옵션이 있습니다: AgentRQ 데스크톱 확장 프로그램으로, 권한 요청이 사용자에게 도달하기 전에 각각 검토합니다. 확장은 AgentRQ 데스크톱 앱에 의해 로드되는 신뢰할 수 있는 Node 모듈입니다. 사용자는 ctx.hooks.add({ id, review(request) { ... } })를 사용하여 리뷰어를 등록하고 보류 중인 호출(도구 이름, 하네스가 전송한 인자 미리보기, 워크스페이스)을 받게 됩니다. 이는 { behavior: 'deny', reason }, { behavior: 'allow' } 또는 아무것도 하지 않아 기권하는 방식으로 응답합니다. review()를 TypeSafe의 Jev와 같은 외부 결정 API에 연결할 수 있습니다. 이는 텍스트를 생성하는 대신 보정된 probabilities와 밀리초 단위의 confidence를 가진 타입이 지정된 choice를 반환하는 "System One" 모델입니다. 도구 호출을 상태로 보내고, 일반 영어로 작성된 워크스페이스 규칙("기능 브랜치에서는 git push는 괜찮지만, main에서는 절대 안 됨", "~/.aws 아래의 어떤 것도 읽지 않음")을 허용/거부/나에게 질문하는 Choice 질문으로 보냅니다. 그런 다음 임계값을 설정합니다: 높은 확신도의 '허용'일 때만 승인하고, 확실한 '거부'일 때는 거부하며, 그 외 모든 경우에는 기권하여 요청이 평소처럼 휴대폰에 도착하도록 합니다.

규칙은 확장 프로그램이 그려지는 워크스페이스별 설정 탭에 존재할 수 있으며, 번들된 guardrail 예제는 문자 그대로의 패턴으로 정확히 그렇게 작동합니다.