Copilot CLI 1.0.83이 샌드박스 명령의 로컬 서비스 접근을 막았다. 같은 릴리스에서 파일 도구는 ~/.npmrc 같은 토큰 경로를 읽게 열렸다. 네트워크와 파일은 별개 축이니 릴리스노트를 축별로 읽어야 한다.
교육 현장에서 에이전트 샌드박스를 설명하면 질문이 거의 하나로 모인다. "그거 켜면 안전한 거죠?" 샌드박스를 전등 스위치처럼 보는 질문이다. 켜면 잠기고 끄면 열린다고 생각하면, 벤더가 릴리스노트에 적는 변경 대부분이 읽히지 않는다.
실제로는 스위치가 아니라 축이 여러 개인 정책이다. 그리고 축이 여러 개면, 한 릴리스가 어떤 축은 좁히고 어떤 축은 넓히는 일이 아무렇지 않게 일어난다. 지난주 릴리스 하나가 그걸 그대로 보여줬다.
한 릴리스가 네트워크는 좁히고 파일은 넓혔다
GitHub Copilot CLI 1.0.83 체인지로그(2026-09-04)에 두 줄이 나란히 있다. 하나는 macOS와 Linux에서 샌드박스 명령이 내 머신에서 돌고 있는 서비스에 더 이상 닿지 못한다는 것이다. macOS에서는 그 명령이 스스로 띄운 127.0.0.1 서버까지 막힌다. 체인지로그가 결과를 직접 적어뒀다 — 로컬 포트를 바인딩하는 테스트 스위트는 실패한다. 되돌리려면 /sandbox에서 Allow local network를 켜야 한다.
다른 하나는 반대 방향이다. 샌드박스 파일 도구가 이제 샌드박스 셸 명령과 같은 개발도구 경로를 읽는다. 체인지로그가 예로 든 것이 토큰이 들어 있는 레지스트리 설정, 즉 ~/.npmrc다. 끄려면 sandbox.allowDevToolAccess를 false로 둬야 한다.
두 변경은 "샌드박스가 강해졌다/약해졌다"로 요약되지 않는다.
| 축 | 1.0.83의 방향 | 켜고 끄는 곳 |
|---|---|---|
| 네트워크(로컬) | 좁아짐 — localhost 차단 | /sandbox의 Allow local network |
| 파일(개발도구 경로) | 넓어짐 — ~/.npmrc 읽기 | sandbox.allowDevToolAccess |
같은 릴리스에 Linux 전제조건도 바뀌었다. 샌드박스가 slirp4netns, nsenter, iptables, ip6tables, iptables-restore, ip6tables-restore를 PATH에서 찾는다. 베이스 이미지에 없으면 샌드박스 명령이 실행 자체를 못 한다. CI에서 에이전트를 돌리는 팀이 먼저 만날 실패다.
축을 나눠 보는 시각은 이미 제품에 들어와 있다
이게 Copilot만의 사정이 아니라는 근거는 두 곳에 있다. GitHub의 9월 8일 JetBrains 공지는 관리자가 중앙에서 거는 정책을 샌드박스 활성화, 파일시스템·네트워크 접근, 프록시, 개발도구 접근, macOS 키체인 접근으로 나눠 열거한다. 관리 화면이 이미 축별로 쪼개져 있다.
Claude Code의 샌드박스 문서는 더 명시적이다. 샌드박스에 "독립된 두 계층"이 있다고 적고, 파일시스템 계층만 끄고 네트워크 격리를 유지하는 설정(sandbox.filesystem.disabled)을 따로 둔다. 문서의 경고 문장이 핵심이다 — 기본값을 넓힐 때는 allowWrite 경로나 넓은 allowedDomains 항목이 반대쪽 축의 제한을 무효로 만들지 않는지 확인하라고 쓴다. 쓰기가 열려 있으면 셸 시작 파일을 고쳐 다음 실행의 네트워크를 넓힐 수 있기 때문이다.
작업장의 크기가 결과를 정한다는 이야기는 코딩 에이전트는 격리된 작업장만큼만 일한다에서 한 번 다뤘다. 6월과 달라진 건, 이제 그 작업장이 한 덩어리가 아니라는 점이다.
가져갈 것
- 우리 테스트 스위트가 로컬 포트를 바인딩하나? (macOS에서 1.0.83 이후 실패한다)
- 실패했을 때 Allow local network를 켜기로 결정한 사람이 누구인지 기록돼 있나?
-
sandbox.allowDevToolAccess를 켠 채 둘지,~/.npmrc의 레지스트리 토큰을 보고 정했나? - CI 베이스 이미지에
slirp4netns·nsenter·iptables·ip6tables와 두*-restore가 들어 있나? - 에이전트 도구별로 파일 축과 네트워크 축을 각각 누가 관리하는지 한 줄로 적을 수 있나?
- 한 축을 넓히는 변경을 승인할 때 반대 축 제한이 살아 있는지 같이 확인하나?
안 되는 경우
- 샌드박스를 쓰지 않고 전용 VM이나 일회용 컨테이너 안에서만 에이전트를 돌리는 팀에는 이 구분이 덜 중요하다. 경계가 이미 프로세스 밖에 있다.
- 체인지로그는
sandbox.allowDevToolAccess의 기본값을 숫자로 명시하지 않는다. "false로 두면 끈다"는 문구에서 켜져 있다고 읽은 것이고, 조직 관리 설정이 이미 덮고 있다면 다를 수 있다. - JetBrains의 관리형 샌드박스는 Editor Preview 플래그나 관리 설정이 있어야 화면에 나타난다고 공지에 적혀 있다. 모든 조직이 오늘 바로 쓸 수 있는 상태는 아니다.
- Claude Code의 설정 이름은 Copilot에 그대로 적용되지 않는다. 축이 나뉘어 있다는 구조만 공통이고, 키 이름과 기본값은 제품마다 다시 확인해야 한다.
이번 주에 바꿀 것은 정책 문서가 아니라 읽는 방식이다. 에이전트 도구 릴리스노트를 "보안 강화/완화" 한 줄로 요약하지 말고, 네트워크·파일·개발도구·자격증명 축을 나눠 적은 표에 각 변경을 배치해 보라. 그 표가 비어 있는 칸이 지금 아무도 관리하지 않는 축이다.