이제 Copilot은 코드를 짜주는 비서가 아니라 명령을 실행하는 동료입니다. 터미널 명령을 돌리고, 파일을 고치고, 언어나 도구 서버를 띄웁니다. 편해진 만큼 질문이 하나 생깁니다. "이 명령이 내 컴퓨터 어디까지 건드릴 수 있지?"

GitHub이 10월 7일에 답을 내놨습니다. 로컬 샌드박스 정식 출시입니다. Copilot CLI, Copilot 앱, VS Code Agent Host 세 곳에서 쓸 수 있고, 추가 요금 없이 Copilot에 포함됩니다. 10월 9일 주간 릴리즈에서도 다시 소개됐습니다. 이 글은 켜는 법과 막히는 지점을 나눠서 읽습니다.

뭐가 나왔나: 세 곳에서 쓰는 가벼운 격리

개념부터 잡으면 이렇습니다.

로컬 샌드박스: 내 컴퓨터에서 Copilot이 돌리는 명령을 감시
  → 파일·네트워크·자격 증명 접근을 제한 (OS 수준 격리, 완전 VM 아님)
  → 추가 요금 없음, 기본값은 꺼짐(off)

클라우드 샌드박스: GitHub가 빌려주는 일회용 리눅스에서 통째로 실행
  → 내 컴퓨터와 완전 분리, 세션마다 새로 생성
  → 사용량 과금, copilot --cloud 로 시작

이번에 정식 출시된 건 로컬 쪽입니다. 실험 딱지를 뗐다는 뜻이지, 만능이 됐다는 뜻이 아닙니다. 공식 문서가 분명히 선을 긋습니다. "OS 수준 샌드박스 안에서" 돌 뿐, 완전한 가상머신이 아닙니다. 그래도 Ollama 로컬 모델 발견 글에서 본 흐름과 겹치면 의미가 큽니다. 모델은 로컬과 클라우드를 오가고, 실행은 샌드박스 안에 가두는 구조가 갖춰진 셈입니다.

Copilot CLI: /sandbox enable 한 줄

CLI가 가장 간단합니다. 세션 안에서 슬래시 명령으로 관리합니다.

# 켜기 (이 세션부터 즉시 적용, 이후 세션에도 유지)
/sandbox enable

# 상태 확인 (정말 걸려 있는지 여기서 확인)
/sandbox status

# 유효 정책 보기 (어떤 경로가 읽기·쓰기·차단인지)
/sandbox policy

# 설정 화면 열기 (/sandbox 만 쳐도 같음)
/sandbox config

# 끄기 (관리 정책이 강제하면 거부될 수 있음)
/sandbox disable

# 한 세션만 샌드박스로 (설정을 안 바꾸고 싶을 때)
copilot --sandbox -p "PROMPT"

# 한 세션만 샌드박스 없이 (--no-sandbox는 관리 정책을 못 이김)
copilot --no-sandbox

동작 방식을 그림으로 그리면 이렇습니다.

샌드박스 ON:
  Copilot이 시키는 일 (셸·파일 검색·기본 MCP·LSP 서버)
    → OS 샌드박스 안에서 실행
    → 막히면 "더 넓은 권한으로 다시 시도할까요?" 승인 요청
    → 승인 / 차단 유지 / 이번 세션 샌드박스 끄기 중 선택

자격 증명:
  git push·gh pr create 같은 작업은 프록시가 낀 구조
  → 샌드박스 안에는 가짜 자격 증명(placeholder)만 전달
  → 허용된 HTTPS 목적지일 때만 진짜로 바꿔서 전송
  → gh는 github.com·api.github.com·uploads.github.com에만 사용

엔터프라이즈 관리 설정이 샌드박스를 강제하면 /sandbox disable이 거부됩니다. 우회가 허용된 정책에서는 이번 세션만 끄는 식으로 완화됩니다. "껐다"는 말보다 status와 policy로 실제 적용을 확인하는 습관이 필요합니다.

Copilot 앱과 VS Code Agent Host: 기본 꺼짐에 주의

Copilot 앱은 세션 단위입니다.

/sandbox on   → 이 세션에 즉시 켜짐 (재시작 후에도 유지)
/sandbox off  → 이 세션에 즉시 꺼짐
프로젝트 기본값은 안 바뀜, 클라우드·원격 세션에서는 사용 불가
밖에서 실행 요청(Run outside the sandbox?)이 뜨면 정책에 따라 승인 여부 결정

VS Code Agent Host가 설정이 가장 많습니다. 핵심만 뽑으면 이렇습니다.

설정 기본값 의미
chat.agent.sandbox.enabled off 켜야 격리 시작, 새 세션부터 적용
chat.agent.sandbox.network.allowNetwork true 바깥 인터넷이 기본 허용이라 따로 막아야 함
chat.agent.sandbox.network.allowLocalNetwork false 내 컴퓨터·사내망 접속은 기본 차단
chat.agent.sandbox.fileSystem.userConfiguredPaths 빈 목록 읽기·쓰기·읽기전용·거부를 직접 지정
chat.agent.sandbox.mcpServers / lspServers true MCP·언어 서버도 샌드박스 안에서
chat.agent.sandbox.credentials.authenticateGit/gh true Git·gh 인증을 샌드박스에 전달
chat.agent.sandbox.allowUnsandboxedCommands true 막히면 밖에서 실행할지 물어봄 (false면 묻지 않고 실패) 
플랫폼 전제 조건 (에이전트가 도는 기계 기준):
 macOS → 없음
 Linux·WSL2 → bubblewrap + socat 설치
 Windows → 2026년 9월 8일 보안 업데이트 필요

확인 순서:
 1. 전제 조건 설치 → 2. enabled를 on → 3. 새 세션 시작
 4. /sandbox policy 로 유효 정책 확인 (보고서 저장 가능)

제일 놓치기 쉬운 줄이 allowNetwork: true입니다. 샌드박스를 켠다고 인터넷이 막히지 않습니다. 허용·거부 도메인을 따로 적어야 합니다. Windows에서 프록시·도메인 제한·자격 증명 마스킹을 쓰려면 로컬망 허용을 켜야 하는데, 그러면 사내망 접근도 함께 열리니 작업이 끝난 뒤에는 다시 닫으세요.

CodeBridge Mini Lab: 테스트 저장소에서 검증하기

본 프로젝트에 켜기 전에 별도 저장소에서 검증하세요. 브리핑의 액션 그대로입니다.

① 빈 테스트 저장소 1개 만들기 (본 프로젝트 절대 아님)
② CLI에서 /sandbox enable → /sandbox status·policy로 확인
③ 파일 경계 테스트:
   [ ] 작업 디렉터리 밖 읽기·쓰기가 막히는가
   [ ] 상위 경로·홈 디렉터리 접근이 차단되는가
④ 네트워크 테스트:
   [ ] allowNetwork를 false로 바꾸면 바깥 요청이 막히는가
   [ ] 허용·거부 도메인이 의도대로 동작하는가
⑤ 자격 증명 테스트:
   [ ] git push·gh 명령이 프록시 구조로 동작하는가
   [ ] 끄지 않은 세션에서 키가 밖으로 나가지 않는가
⑥ 승인 흐름 테스트:
   [ ] 막힌 명령에서 승인 요청이 뜨는가
   [ ] allowUnsandboxedCommands를 false로 하면 묻지 않고 실패하는가

보안 4층 글의 격리 층에 이 체크리스트를 붙이면 됩니다. 샌드박스는 만능이 아니라 한 층입니다. 범위·승인·검토와 함께 가야 합니다.

결론: 실행 권한을 기본값에 맡기지 마세요

한 줄로 정리합니다.

샌드박스는 켜는 순간부터가 아니라, 막히는 걸 확인한 순간부터 믿을 수 있다.

정식 출시의 의미는 "이제 실험이 아니다"이지 "이제 안전하다"가 아닙니다. 기본 꺼짐, 네트워크 기본 허용, OS 수준 격리라는 세 조건을 기억하세요. 테스트 저장소에서 켜고, policy로 확인하고, 파일·네트워크·자격 증명을 하나씩 막아보는 것. 그 표가 다음에 이 도구에 어디까지 맡길지를 정해줍니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

Agent와 Plan 모드를 실제 프로젝트에 붙이고 실행 환경까지 흐름으로 연결하는 연습이 필요하다면, Java·Spring 프로젝트에 Copilot을 적용하는 과정이 이 글의 검증 실험과 바로 이어집니다.