Copilot YOLO 모드 분석: --yolo, /yolo 및 Allow all이 실제로 건너뛰는 것

TL;DR

• Copilot CLI: copilot --yolo (이는 --allow-all과 동일한 플래그임), 또는 실행 중인 세션에서 /yolo. 이는 --allow-all-tools + --allow-all-paths + --allow-all-urls의 약어입니다.
• VS Code: 채팅 권한 선택기에서 **모두 허용(Allow all)**을 선택하거나, /yolo를 입력하거나, "chat.tools.global.autoApprove": true로 설정하여 영구적으로 만들 수 있습니다.
• 건너뛰는 것: 승인 프롬프트입니다. 하지 않는 것: 사용자의 --deny-tool 규칙과 (VS Code에서 명시적으로 문서화된) 활성화된 샌드박스입니다.
• Autopilot은 다른 스위치입니다. 이는 에이전트가 반복하도록 유지하며, YOLO는 해당 에이전트의 도구 호출을 승인합니다. 비감시 실행(Unattended runs)은 보통 둘 다를 원합니다.

여기에 있는 모든 내용은 2026년 10월 7일 기준으로 GitHub의 Copilot CLI 레퍼런스, github/copilot-cli 변경 로그 (1.0.93), 그리고 microsoft/vscode-docs의 VS Code 에이전트 문서를 통해 확인되었습니다.

Copilot에서 "YOLO"가 두 가지 다른 의미를 갖는 이유는 무엇인가요?

Copilot은 두 가지 권한 시스템을 가진 두 가지 에이전트 런타임(agent runtimes)을 제공하기 때문입니다. Copilot CLI는 플래그 기반의 권한을 가진 터미널 에이전트입니다. VS Code의 Copilot Chat은 선택기(picker)와 settings.json에 의존하는 편집기 에이전트입니다. 이들은 어휘( /yolo가 둘 다에 존재함)는 공유하지만 설정 방식은 공유하지 않습니다. VS Code에서 설정한 것이 CLI를 변경하지 않으며, 그 반대도 마찬가지입니다.

두 시스템이 동의하는 유일한 점은 계층화(layering)입니다. 모델과 사용자의 기기 사이에는 세 개의 분리된 게이트가 있습니다:

모델이 행동하기 원함
   │
   ▼
...

이 그림을 염두에 두십시오. 아래의 모든 플래그는 레이어 2에 관한 것입니다.

copilot --yolo는 정확히 무엇을 활성화하나요?

copilot --yolo

--yolo와 --allow-all은 동일한 플래그이며, "모든 권한(도구, 경로 및 URL) 활성화"로 문서화되어 있습니다. 이는 개별적으로 사용할 수 있는 세 가지 더 좁은 스위치로 분해됩니다:

주목할 만한 기술적인 부분은 경로(paths)와 URL이 도구와는 별개의 신뢰 차원이라는 점입니다. 만약 귀하의 위협 모델이 "에이전트가 npm test를 실행할 수는 있지만, ~/.ssh 파일을 읽거나 임의 호스트로 데이터를 유출해서는 안 된다"라면, --allow-all-tools만 사용하는 것은 --yolo와 실질적으로 다른 보안 태세입니다.

세션 내 명령어들은 서로 어떻게 매핑되나요?

/permissions가 이제 표준 명령어로 자리 잡았으며, 네 가지 인자(default, assisted, allow-all, show)를 가집니다. 나머지 모든 것은 별칭(alias)입니다:

• /yolo와 /allow-all → /permissions allow-all
• /yolo는 또한 off, auto, 그리고 show도 받습니다.
• /reset-allowed-tools (또는 /permissions default)를 사용하면 설정을 초기화합니다.

이 기능이 활성화된 동안, 푸터에는 YOLO 표시기가 나타나므로 안전망 없이 작동하고 있다는 사실을 잊지 않을 수 있습니다.

다른 에이전트에서 온 사용자들을 위한 주의사항: Shift+Tab은 Copilot CLI에서 YOLO를 토글하지 않습니다. 이는 표준 → 계획(plan) → 자동 조종(autopilot) 순서로 사이클합니다. 이것은 권한 전환 스위치가 아니라 작업 모드(mode-of-work) 전환 스위치입니다.

왜 Autopilot이 YOLO와 같지 않은가요?

두 개의 직교 축(orthogonal axes)이 있습니다:

• Autopilot (--autopilot, /autopilot, 또는 Shift+Tab): "에이전트가 저에게 확인하지 않고 계속 진행해도 될까요?"라는 질문에 답합니다.
• YOLO: "에이전트가 저에게 묻지 않고 도구를 실행해도 될까요?"라는 질문에 답합니다.

Autopilot만 있고 YOLO는 없는 경우: 에이전트는 계속 작업하다가 첫 번째 승인 단계에서 중단됩니다. YOLO만 있고 Autopilot은 없는 경우: 승인은 원활하게 이루어지지만, 에이전트는 확인을 위해 멈춥니다. 일반적으로 방치된(unattended) 실행에는 둘 다 필요합니다. VS Code의 보안 문서는 다른 관점에서 같은 점을 지적합니다: Autopilot은 "자동 승인과 자율적인 반복을 결합"하며 "중간 단계를 검토할 수 있는 능력을 줄입니다."

모든 것을 승인하지 않고도 대부분의 속도를 얻을 수 있을까요?

네, 그리고 바로 이 지점에서 Copilot의 설계가 정말 훌륭합니다. 두 개의 중간 계층(halfway layers)이 있습니다:

패턴 규칙. --allow-tool과 --deny-tool은 지정된 패턴을 사용합니다:

copilot --allow-tool 'shell(git:*)' --deny-tool 'shell(git push)'

다른 형태들: write(src/*.ts), read(.env), url(github.com), MyMCP(create_issue). 중요한 규칙은 다음과 같습니다: 거부는 항상 승리합니다. 이는 --yolo를 포함하여 모든 경우에 해당됩니다. 이를 통해 비용 효율적인 "YOLO지만 보안 허점(footguns)이 제거된" 프로필을 얻을 수 있습니다: --yolo --deny-tool 'shell(git push)'.

지원되는 권한 (Assisted permissions). /permissions assisted를 사용하면 프롬프트 앞에 안전 모델이 배치됩니다. 이 모델은 일상적인 요청을 승인하고 나머지 요청만 사용자에게 에스컬레이션합니다. 이는 격리 환경(sandbox)이라기보다는 2번째 계층에 있는 분류기(classifier)이기 때문에, 고립성을 추가하지 않으면서 프롬프트를 줄여줍니다.

관리자들은 최종 결정권을 가집니다: permissions 아래의 "disableBypassPermissionsMode": "disable"는 이 모든 것을 무력화시키고, "allow-auto-only"는 사용자를 지원 모드(assisted mode)로 제한합니다.

VS Code 버전은 어떻게 작동하나요?

Copilot Chat에서는 이를 **모두 허용 (Allow all)**이라고 부르며, 세 가지 권한 수준 중 하나입니다:

진입하는 방법은 세 가지가 있습니다:

1. 채팅 입력창의 권한 선택기(permission picker).
2. 현재 세션에서 채팅창에 /yolo 또는 /autoApprove 사용. 취소는 /disableYolo 또는 /disableAutoApprove로 합니다.
3. 영구적으로, settings.json 파일에서:

{ "chat.tools.global.autoApprove": true }

이 마지막 설정은 모든 작업 공간의 모든 도구를 승인하며, VS Code 자체 문서에서도 이 설정을 "중요한 보안 보호 기능을 비활성화하는" 설정으로 표시하고 있습니다. 문서는 모든 곳에 자동 승인이 필요하지 않을 때는 세션 범위의 '모두 허용'을 권장합니다. 실험적인 chat.permissions.default (default, autoApprove, autopilot)는 새 채팅이 시작될 때 사용되는 레벨을 지정하며, 조직(orgs)은 ChatToolsAutoApprove 정책으로 전역 자동 승인을 차단할 수 있습니다.

터미널 화이트리스트만으로 안전할까요?

그것들은 VS Code의 중간 옵션입니다:

키는 접두사 또는 정규식입니다. true는 자동 승인하고; false는 다른 규칙이 승인하더라도 프롬프트를 강제합니다. 참고로, false는 **차단(block)**하는 것이 아니라 **질문(ask)**을 의미합니다.

하지만 세부 사항을 읽어보세요: VS Code의 보안 문서는 자동 승인 규칙이 '최선의 노력 명령 구문 분석을 사용하며 셸 별칭(shell aliases), 따옴표 연결(quote concatenation), 복잡한 셸 구문에 알려진 한계가 있다'고 명시합니다. 셸 파서를 작성해 본 사람이라면 그 이유를 알 것입니다: g'it' push와 같은 별칭이나 bash -c "$(…)"는 모두 접두사 일치 검사를 우회할 수 있습니다. 허용 목록(allowlists)을 편의 기능으로 취급하고, 실제 경계는 OS 수준에서 강제하는 곳에 두어야 합니다.

샌드박스는 실제로 무엇을 강제하며, YOLO가 건드리지 않는 것은 무엇인가?

VS Code에서 chat.agent.sandbox.enabled (또는 피커의 터미널용 샌드박싱(Sandboxing for terminal) 토글)을 활성화하세요. 문서는 Allow all과 Autopilot이 프롬프트를 건너뛰지만, '활성화된 샌드박스는 여전히 터미널 파일 시스템 및 네트워크 액세스를 제한한다'고 명시합니다. VS Code의 문서에 따르면 내부적으로는 다음과 같습니다:

• macOS: Apple의 Seatbelt가 내장되어 있습니다.
• Linux / WSL2: 파일 시스템 격리를 위한 bubblewrap과 네트워크 프록시를 위한 socat을 사용합니다 (apt-get install bubblewrap socat). WSL1은 제외되는데, 이는 bubblewrap이 사용자 네임스페이스(user namespaces)를 필요로 하기 때문입니다.

같은 문서에서 나온 두 가지 주의사항이 있습니다: 아웃바운드 네트워크는 기본적으로 켜져 있습니다 (chat.agent.sandbox.network.allowNetwork가 true로 기본 설정되므로), 따라서 이를 별도로 잠가야 합니다; 그리고 샌드박스는 '가상 머신이나 사용자 계정 경계가 아니다'. 만약 블로그 게시물에서 이전 키인 chat.tools.terminal.sandbox.enabled를 본다면, 이는 더 이상 VS Code 문서에 포함되어 있지 않습니다.

Copilot CLI도 /sandbox / --sandbox를 가지고 있습니다. GitHub의 참고 문서는 여전히 이를 실험적(experimental)으로 표시하지만 변경 로그에서는 모든 사람이 사용할 수 있다고 말하며, CLI 문서는 --yolo가 이를 우회하는지 명시하지 않습니다. 우리는 이것을 VS Code와 같은 별도의 계층으로 취급하지만, 여기에 의존한다면 /sandbox가 무엇을 보고하는지 확인하세요.

클론된 레포지토리가 나를 위해 YOLO를 켜게 할 수 있을까?

VS Code에서 최전방 방어선은 Workspace Trust입니다. 신뢰하지 않는 폴더는 제한된 모드로 열리며, 이 모드는 '에이전트(agents) 비활성화'도 합니다. 따라서 에이전트를 사용하려면 저장소(repo)를 검토한 후에 신뢰해야 합니다. 전역 자동 승인 설정은 직접 설정하는 것이고, 문서는 대신 세션 범위 수준으로 안내합니다. CLI에도 신뢰할 수 있는 디렉터리 개념이 있습니다: COPILOT_ALLOW_ALL=true는 현재 디렉터리를 신뢰하고, /add-dir PATH는 다른 디렉터리에 파일 접근 권한을 부여하고 해당 디렉터리의 .github/skills와 .github/agents를 신뢰할 수 있는 설정으로 로드합니다. YOLO 세션을 읽어보지 않은 저장소에 연결하기 전에 이것을 기억하는 것이 좋습니다.

AgentRQ로 작업별 또는 워크스페이스별로 YOLO를 켜는 방법은 무엇인가요?

Copilot의 YOLO는 세션 범위(session-scoped)입니다. 한 번 활성화되면 해당 세션이 수행하는 모든 것에 적용됩니다. 만약 작업별로 결정하고 터미널 외의 곳에서 프롬프트에 응답하기를 원한다면, Copilot CLI를 AgentRQ를 통해 ACP Gateway (Copilot 설정 가이드)로 라우팅할 수 있습니다:

npx @agentrq/acp-gateway@latest --agent github-copilot-cli

이것은 Copilot CLI에만 해당하며, VS Code의 Copilot Chat은 자체 선택기를 유지합니다.

--yolo 없이 Copilot 시작하기. 이 게이트웨이는 새로운 세션을 스스로 승인할 수 있는 모든 모드에서 벗어나 Copilot이 사람에게 요청하는 모드로 이동시킵니다. 그러면 모든 권한 요청은 첨부된 명령이나 편집과 함께 AgentRQ 작업(웹, 전화 또는 Slack)에 도착하며, 사용자가 응답합니다:

• 일회 허용 (Allow Once): 이 호출에만 해당합니다.
• 항상 허용 (Always Allow): 도구를 워크스페이스의 자동 승인 목록에 추가하여 일상적인 요청이 묻지 않게 합니다.
• 거부 (Deny): Copilot은 거부를 받고 계속 진행합니다.

30분 이내에 아무도 응답하지 않으면, 게이트웨이는 추측하는 대신 해당 턴을 취소합니다. 이는 --permission-timeout으로 조정할 수 있습니다.

작업별(Per task). 작업의 YOLO 토글을 켜거나, 작업을 생성할 때 설정하여 해당 작업만 YOLO 모드에 넣을 수 있습니다. 이 모드에서는 모든 권한 요청이 자동 승인되며 Copilot은 기다리지 않지만, 워크스페이스의 다른 모든 작업들은 여전히 승인을 요청합니다. 이 설정은 에이전트가 연결되었다가 다시 연결하더라도 작업에 유지됩니다. 예약된 작업(Scheduled tasks), 이벤트 트리거(event triggers) 및 워크플로우 단계(workflow steps)도 동일한 스위치를 가지므로, 야간 배치 작업(nightly job)은 YOLO 모드로 실행되면서 사용자의 대화형 작업은 감독을 받도록 할 수 있습니다.

워크스페이스별(Per workspace). 워크스페이스 설정에는 **YOLO 모드 (모두 실행)**가 있습니다 (UI 경고:

또는 일반 영어 규칙을 통해 모델이 승인하고 거부하도록 할 수 있습니다. '매번 물어보기(ask me every time)'와 '모두 승인하기(approve everything)' 사이에는 세 번째 옵션, 즉 AgentRQ 데스크톱 확장 프로그램이 있습니다. 이 확장 프로그램은 권한 요청이 사용자에게 도달하기 전에 각각 검토합니다. 확장 프로그램은 AgentRQ 데스크톱 앱에 의해 로드되는 신뢰할 수 있는 Node 모듈입니다. 하나는 ctx.hooks.add({ id, review(request) { ... } })로 검토자를 등록하고 보류 중인 호출을 받습니다: 도구 이름, 하네스에서 전송한 인자 미리보기, 그리고 작업 공간입니다. 이는 { behavior: 'deny', reason }, { behavior: 'allow' }, 또는 아무것도 보내지 않아 기권할 수 있습니다. TypeSafe의 Jev와 같은 외부 결정 API를 review()에 지정합니다. 이는 텍스트를 생성하는 대신 보정된 확률(probabilities)과 밀리초 단위의 신뢰도(confidence)를 가진 타입화된 선택(choice)을 반환하는