Gemini CLI YOLO 모드: 소스에서 읽기 - settings.json으로 켜지 못하는 이유

요약 (TL;DR)

• YOLO를 시작하려면 gemini --approval-mode=yolo를 사용하거나 실행 중인 세션에서 Ctrl+Y를 누르세요. --yolo / -y도 여전히 작동하지만, 이제는 사용이 권장되지 않으며(deprecated), --yolo와 --approval-mode을 함께 사용하는 것은 오류입니다.
• settings.json에 YOLO를 기본값으로 설정할 수 없습니다. 이는 의도적인 설계 선택이며, 이를 강제하는 코드는 세 줄로 되어 있습니다.
• YOLO는 승인 프롬프트만 제거합니다. 샌드박스(Seatbelt, Docker, Podman, gVisor, LXC)는 별도의 스위치이며, 현재 소스에서는 YOLO가 이 기능을 절대 켜지 않습니다.
• 신뢰할 수 없는 폴더에서는 default를 제외한 다른 모드는 강제로 default로 돌아갑니다. 만약 security.disableYoloMode 또는 관리자 보안 모드가 설정되어 있다면, YOLO를 요청하는 것은 조용한 다운그레이드가 아니라 치명적인 구성 오류입니다.

아래 내용은 2026년 10월 7일~8일에 Gemini CLI 소스(google-gemini/gemini-cli, 0.65.0-nightly.20261006)와 문서를 기반으로 확인되었습니다.

2026년 후반에 누가 이것을 사용하나요?

간단히 말해: Gemini Code Assist Standard 또는 Enterprise 라이선스를 가진 Gemini CLI 사용자입니다.

2026년 6월 18일 이후로 Gemini CLI는 Google AI Pro, Ultra 또는 무료 Code Assist 사용자를 더 이상 지원하지 않습니다. Google은 이들을 Antigravity CLI (agy)로 이동시켰으며, 여기에는 다른 YOLO 방식이 있습니다(이는 agy --dangerously-skip-permissions이며, --yolo가 전혀 없습니다). 하지만 Gemini CLI는 여전히 개발되고 있으며, 승인 코드는 그 자체로 읽어볼 가치가 있습니다. 이는 코딩 에이전트들 사이에서 가장 깔끔한 권한 설계 중 하나입니다.

Gemini CLI는 실제로 어떤 방식으로 승인 모드를 처리하나요?

네 가지 모드가 있습니다: default, auto_edit, plan 및 yolo. CLI가 시작 시 이들을 선택하는 순서는 다음과 같습니다:

1. 명령줄의 --approval-mode <x>
2. 그렇지 않으면 --yolo / -y (이는 yolo로 매핑됩니다)
3. 그렇지 않으면 settings의 general.defaultApprovalMode, 단, 그 값이 yolo인 경우에는 건너뜁니다
4. 그렇지 않으면 default

3단계가 흥미로운 부분입니다. resolver는 settings에서 "yolo" 값을 거부하지 않습니다. 단지 그 키가 없는 것처럼 건너뛰고 읽을 뿐입니다. settings 스키마에 명확히 나와 있습니다: YOLO는 "명령줄(command line)을 통해서만 활성화될 수 있다".

모드가 해결된 후에는 두 개의 게이트가 작동합니다:

• 킬 스위치(Kill switch). 만약 security.disableYoloMode 또는 admin.secureModeEnabled가 설정되어 있고, 해결된 모드가 YOLO라면, 시작 시 FatalConfigError를 발생시킵니다. 조용히 default로 떨어지지 않습니다. 금지된 것을 요청했기 때문에 CLI가 알려주는 것입니다.
• 폴더 신뢰(Folder trust). 현재 폴더가 신뢰되지 않으면, default가 아닌 다른 모든 모드는 경고와 함께 강제로 default로 돌아갑니다. 이것은 YOLO뿐만 아니라 auto_edit과 plan에도 적용됩니다.

왜 settings.json에 그냥 "yolo"를 넣을 수 없나요?

위협 모델(threat model)은 클론된 리포지토리입니다.

Gemini CLI는 여러 계층의 설정을 병합하며, 그중 하나가 워크스페이스 자체의 .gemini/settings.json입니다. 만약 프로젝트 파일이 defaultApprovalMode: "yolo"를 설정할 수 있다면, git clone evil-repo && cd evil-repo && gemini 명령은 공격자가 제어하는 GEMINI.md에게 셸 명령어 실행 전에 절대 질문하지 않는 에이전트를 넘겨줄 것입니다. 프롬프트 주입(Prompt injection)에 자동 승인(auto-approval)이 결합된 것은 에이전트 보안에서 최악의 조합입니다.

따라서 규칙은 이렇습니다: YOLO는 사람이 이 과정에서 플래그(flag)나 키를 직접 타이핑해야만 합니다. 설정 파일은 더 신중하게 만들 수 있습니다 (disableYoloMode, secureModeEnabled, 폴더 신뢰). 하지만 절대로 덜 신중하게 만들 수는 없습니다. 항상 YOLO를 원한다면, 지원되는 답변은 셸 별칭(shell alias)입니다:

alias gemini-yolo='gemini --approval-mode=yolo --sandbox'

이를 Gemini CLI의 포크 버전인 Qwen Code와 비교해 보세요. Qwen Code는 settings에서 tools.approvalMode: "yolo"를 허용합니다. 대신 보호 기능을 폴더 신뢰로 내립니다.

YOLO가 샌드박스를 활성화하나요?

현재 코드에서는 그렇지 않습니다. 예전 설정 페이지에 무엇이라고 쓰여 있든 상관없습니다.

Gemini CLI는 두 개의 독립적인 계층을 가지고 있습니다:

샌드박스 리졸버는 승인 모드를 읽지 않습니다. 아무것도 설정되지 않은 경우 "no sandbox"를 반환합니다. 이 기능을 켜면 다음과 같은 결과가 나타납니다:

• macOS, sandbox: true: 가장 먼저 sandbox-exec (Seatbelt)이 선택됩니다. 기본 프로필은 permissive-open입니다. 이름에도 불구하고, 이는 (deny default)에서 시작하여 모든 곳의 파일 읽기를 허용하고 프로젝트 디렉토리, 임시(temp), 캐시(cache), ~/.npm, ~/.cache 및 --include-directories에 지정된 모든 곳에만 쓰기를 허용합니다. 또한 Docker 소켓과 ~/.gemini 자격 증명 파일(oauth_creds.json, mcp-oauth-tokens.json, …)에 대한 쓰기는 명시적으로 차단합니다. SEATBELT_PROFILE을 사용하여 다른 내장 프로필을 선택할 수 있습니다: permissive-*와 restrictive-*는 각각 -open, -closed, -proxied 네트워크 플래버로 제공되며, strict-*은 -open과 -proxied에서 사용 가능합니다. 이 목록에 없는 것은 거부되므로, 변수를 통한 경로 탐색(path traversal)도 차단됩니다.
• Linux/기타, sandbox: true: Docker가 먼저, 그 다음 Podman이 존재할 경우 선택됩니다.
• 명시적만 가능: runsc (gVisor, Linux 전용, Docker의 --runtime=runsc를 통해 실행), lxc (이미 실행 중인 컨테이너가 필요하므로 자동 감지되지 않음) 및 windows-native (Windows 전용).

잘못된 값은 즉시 실패합니다. Mac에서 GEMINI_SANDBOX=runsc를 사용하거나, Docker나 Podman이 설치되어 있지 않은 상태에서 true를 사용하는 것은 사일런트하게 샌드박스 없이 실행되는 것이 아니라 치명적인 오류(fatal error)입니다.

핵심은 다음과 같습니다: YOLO에 샌드박스를 추가하는 것은 합리적인 구성입니다. 샌드박스 없는 YOLO는 "내 사용자의 모든 권한으로 무엇이든 실행한다"는 의미입니다. 직접 --sandbox를 전달하십시오.

Ctrl+Y와 Shift+Tab은 어떻게 상호 작용하나요?

• Ctrl+Y는 YOLO와 default 사이를 전환합니다. 이는 세션 내에서 YOLO로 진입할 수 있는 유일한 방법입니다.
• Shift+Tab은 default → auto_edit → plan 순환을 수행합니다 (plan이 활성화된 경우에만). 이 키 조합으로는 절대 YOLO 모드로 진입하지 않습니다. 만약 YOLO 모드에서 Shift+Tab을 누르면 auto_edit으로 전환됩니다.

작지만 사려 깊은 설계 선택입니다: 자주 사용하는 키가 실수로 위험한 모드로 이동하는 것을 방지합니다.

또 한 가지: --yolo와 --approval-mode를 함께 사용하면 어느 쪽도 선택되지 않습니다. 이는 검증 오류(validation error)입니다. 의도가 모호하면 문 앞에서 실패하게 됩니다.

CI 및 헤드리스 실행 시 발생하는 일은?

이 예외 상황 때문에 많은 사람이 어려움을 겪습니다. 비대화형 모드(gemini -p "…")에서는 프롬프트에 응답할 사람이 없기 때문에, 정책 엔진은 ask_user 결정을 **deny(거부)**로 변환하여 처리합니다. 따라서 헤드리스 default 모드에서는 질문을 요청했을 도구 호출이 아예 실행되지 않습니다.

만전을 기하기 위해: CLI는 또한 모델이 사용자에게 질문하는 데 사용하는 도구인 ask_user를 헤드리스 및 ACP 모드의 도구 세트에서 제거합니다. 소스 주석에는 그 이유가 명시되어 있습니다: "사람이 없는 경우 고우선순위 정책 규칙을 통해 절대 허용되어서는 안 되기 위해서"입니다. ACP 모드에서는 IDE나 클라이언트가 대신 질문하는 역할을 합니다.

따라서 헤드리스 환경에서 사용 가능한 옵션은 다음과 같습니다:

• --approval-mode=yolo, 이상적으로는 --sandbox와 함께 사용
• --approval-mode=auto_edit, 그리고 필요한 셸 명령을 허용하는 정책 규칙 추가
• 또는 작업이 사용하는 도구에 대해 정확히 allow를 명시한 정책 파일

중간 단계 옵션들은 무엇인가요?

• auto_edit: 파일 편집은 승인하지만, 셸 명령어 실행 전에는 여전히 질문을 요청합니다.
• tools.allowed: run_shell_command(git)와 같이 프롬프트를 건너뛰는 도구 패턴 목록입니다.
• 정책 엔진(policy engine): 권장되는 경로입니다. ~/.gemini/policies/에 있는 TOML 파일에서 allow / deny / ask_user 규칙을 사용하여 모드별로 (YOLO 포함) 범위를 지정할 수 있습니다. 명령줄의 --allowed-tools는 이 정책 엔진이 도입되면서 더 이상 사용되지 않습니다(deprecated).

VS Code의 Gemini Code Assist 확장 프로그램에서는 사용자 설정에 "geminicodeassist.agentYoloMode": true를 설정하고 창을 새로고침하세요. 익숙한 규칙을 다시 한번 기억하십시오: 오직 신뢰할 수 있는(trusted) 작업 공간에서만 작동합니다. IntelliJ에서는 이에 해당하는 옵션이 **변경 사항 자동 승인(Auto-approve changes)**입니다.

AgentRQ를 사용하여 작업별 또는 작업 공간별로 YOLO를 켜는 방법은 무엇인가요?

Gemini CLI의 스위치는 프로세스 단위입니다: --approval-mode=yolo와 함께 시작했거나 그렇지 않았습니다. AgentRQ는 이 결정을 작업(task)으로 옮깁니다.

1. Gemini CLI 연결. 이는 ACP Gateway를 통해 이루어집니다. Gemini CLI 설정 가이드와 단계별 게시물에 자세한 내용이 있습니다:

npx @agentrq/acp-gateway@latest --agent gemini

--approval-mode=yolo 없이 시작하세요. 이 게이트웨이는 또한 모든 새 세션을 자체적으로 승인할 수 있는 모드에서 벗어나, Gemini CLI가 사용자에게 요청하는 모드로 전환합니다.

2. 어디서든 응답하기. 각 권한 요청은 AgentRQ 작업 내, 웹상, 휴대폰 또는 Slack에 표시되며, 관련 명령어 또는 편집 내용을 함께 보여줍니다. 사용자는 일회 허용(Allow Once), 항상 허용(Always Allow) (도구를 작업 공간의 자동 승인 목록에 추가) 또는 **거부(Deny)**로 응답합니다. 30분 이내에 아무도 응답하지 않으면 게이트웨이는 추측하는 대신 해당 작업을 취소합니다. --permission-timeout으로 이 제한 시간을 변경할 수 있습니다.

3a. 하나의 작업에 대한 YOLO. 작업에서 YOLO 토글을 켜거나, 또는 작업을 생성할 때 켭니다. 해당 작업의 모든 권한 요청은 자동으로 승인되는 반면, 작업 공간의 다른 모든 작업은 여전히 사용자에게 요청합니다. 이 플래그는 작업에 존재하므로 에이전트 연결 끊김 및 재연결에도 유지됩니다. 예약된 작업(Scheduled tasks), 이벤트 트리거(event triggers) 및 워크플로우(workflow) 단계도 동일한 스위치를 가지고 있습니다.

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

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

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

리뷰 계약은 하나의 비대칭성에 기반합니다: 거부(refusing)는 도구 호출 비용을 발생시키고, 승인(approving)은 도구 호출이 수행하는 모든 것을 비용으로 발생시킵니다. 따라서 한 번의 거부가 요청을 확정하고; 침묵(기권, 예외, 또는 5초 마감 시간을 놓친 리뷰어)은 결코 허용(allow)이 아니며, 요청은 그저 당신 앞에 남아있습니다; 그리고 확장 프로그램은 승인하려면 decide 동의 수준이 필요하며, deny 동의는 거부만 할 수 있습니다. 설치 화면은 모든 확장 프로그램을 none으로 시작합니다. 리뷰는 데스크톱 앱이 열려 있고 로그인된 상태에서만 발생하므로, 이를 보안 경계가 아닌 빠른 첫 번째 검토로 간주하십시오.