Claude Code를 위험하게(안전하게) 실행하기

(blog.emilburzo.com)

18P by GN⁺ 19시간전 | ★ favorite | 댓글 1개

클로드 코드의 --dangerously-skip-permissions 플래그를 안전하게 사용하는 방법
Docker, VM, Firejail 등 다양한 격리 실행 환경을 검토한 뒤 Vagrant 기반 가상머신(VM) 이 가장 적합하다고 판단
Vagrant를 통해 완전한 VM 격리, 재현 가능한 설정, 로컬 폴더 공유를 유지하면서도 Docker-in-Docker 문제를 피함
Claude Code가 VM 내에서 sudo 권한으로 자유롭게 시스템 조작을 수행하도록 설정, 실제로 웹앱 실행·DB 구성·테스트 자동화 등을 수행함
이 방식은 실수로 인한 파일시스템 손상 방지에 효과적이며, 필요 시 VM을 삭제·재생성해 안전하게 초기화 가능

배경

Claude Code를 사용할 때 매번 권한 요청을 확인해야 하는 불편함을 해소하기 위해 --dangerously-skip-permissions 플래그 사용을 시도함
- 이 플래그는 패키지 설치, 설정 변경, 파일 삭제 등 모든 작업을 사전 승인 없이 자동 수행
- 작업 흐름이 끊기지 않아 효율적이지만, 파일시스템 손상 위험이 존재함
이를 방지하기 위해 호스트 OS 계정과 분리된 환경에서 실행할 필요성을 인식함

고려한 방법들

Docker를 통한 격리를 우선 검토했으나, Claude가 Docker 이미지를 빌드하고 컨테이너를 실행해야 하므로 Docker-in-Docker 구성이 필요
- 이 경우 --privileged 모드가 요구되어 샌드박싱 목적이 무의미해짐
- 네트워크 중첩, 볼륨 마운트 권한 문제 등으로 복잡성과 불안정성이 증가함
기타 대안으로는 다음을 검토함
- 베어메탈 실행: Reddit 사례에서 데이터베이스나 홈 디렉터리 삭제 등 심각한 손상 사례 존재
- sandbox-runtime: ACL 기반 접근 제어로, Claude가 코드 외에는 접근 불가하지만 완전한 자유도 부족
- Firejail: Docker와 유사한 제약 존재
- 수동 VM 설정: 재현성 부족
- 클라우드 VM: 비용·지연·코드 업로드 필요성 문제

Vagrant 기반 접근

Vagrant를 이용해 완전한 VM 격리와 재현 가능한 설정을 확보
- 공유 폴더를 통해 로컬처럼 접근 가능
- Docker-in-Docker 문제 없음, 필요 시 VM을 손쉽게 삭제·재생성 가능
VirtualBox 7.2.4 버전 사용 중 CPU 100% 점유 버그를 발견, GitHub 이슈를 통해 원인 확인
최종 Vagrantfile 구성은 다음과 같은 특징을 가짐
- bento/ubuntu-24.04 베이스 이미지 사용
- 4GB 메모리, 2 CPU 할당
- Docker, Node.js, npm, git, unzip 설치
- @anthropic-ai/claude-code 전역 설치
- vagrant 사용자를 Docker 그룹에 추가

실제 사용 방식

프로젝트 디렉터리에서 vagrant up → vagrant ssh → claude --dangerously-skip-permissions 순으로 실행
첫 부팅 시 프로비저닝에 몇 분 소요되며, 프로젝트별로 한 번만 Claude 로그인 필요
작업 종료 시 vagrant suspend로 VM 일시 중단 가능
Claude는 VM 내에서 sudo 권한을 부여받아 다음과 같은 작업 수행
- 웹앱 API 실행 및 curl로 점검
- 브라우저 설치 후 앱 수동 검사 및 E2E 테스트 생성
- PostgreSQL DB 설정 및 마이그레이션 테스트
- Docker 이미지 빌드 및 실행
이러한 환경 덕분에 Claude가 명령 실행·출력 확인·반복 과정을 스스로 처리 가능

성능 및 안전성

Linux + VirtualBox 환경에서 리소스 여유 충분, 파일 동기화 지연 없음
보호 가능한 항목
- 실수로 인한 파일시스템 손상
- 무분별한 패키지 설치 및 설정 변경
보호 불가능한 항목
- 프로젝트 폴더 삭제(양방향 동기화)
- VM 탈출 취약점을 악용한 공격
- 네트워크 수준의 문제
- 데이터 유출(VM은 인터넷 접근 가능)
이 구성은 사고 방지용이며, 고급 공격 방어 목적은 아님
Git 기반 프로젝트라 손상 시에도 복구 용이, 필요 시 rsync 단방향 동기화로 더 엄격한 격리 가능

결론

VirtualBox CPU 버그 해결 후 마찰 없는 실행 환경 완성
Claude Code를 완전한 VM 샌드박스 내에서 자유롭게 실행 가능
문제가 발생하면 VM을 삭제 후 재생성하면 되며, Vagrantfile 하나로 재현성 확보
--dangerously-skip-permissions 플래그를 사용하는 경우, 이와 같은 격리 환경 구성이 강력히 권장됨

▲

GN⁺ 19시간전 [-]

Hacker News 의견들

Claude를 쓰다 보면 결국 결정 피로(decision fatigue) 때문에 몇 달 후엔 그냥 엔터를 눌러버리게 됨
그래서 나는 YOLO 모드로 돌리되 샌드박스 환경을 만들어두는 게 훨씬 안전하다고 느낌
Ubuntu 22.04에서 bubblewrap과 Landlock LSM을 조합해 계층형 샌드박스를 구성했음
Landlock은 파일시스템 접근을 화이트리스트 기반으로 제한하고, TCP 포트 접근도 제어함
bubblewrap은 마운트 네임스페이스를 분리해 프로젝트별 /tmp를 만들고 비밀키를 숨김
dnsmasq로 DNS 화이트리스트를 설정해 필요한 도메인만 해석되게 함
이런 구조 덕분에 에이전트를 계속 감시해야 한다는 스트레스가 줄었음
- 나도 비슷한 환경에서 여러 Claude 인스턴스를 YOLO 모드로 돌리고 있었는데, Emacs TRAMP 플러그인을 로컬 NUC에서 직접 빌드해야 했을 때 정말 피로했음
  Claude가 제안한 elisp 조각들을 일일이 승인하는 게 너무 지치는 경험이었음
  Bash 명령어로 엉뚱한 걸 설치하지 않게만 주의했는데도 힘들었음
- 나는 Windows라 직접 써보진 못했지만, Linux에서는 /sandbox 명령으로 Claude Code에 샌드박싱 기능이 내장된 걸로 알고 있었음
Docker의 Srini임
많은 개발자들이 이 문제를 해결하려고 Docker를 사용하고 있고, Docker-in-Docker 제약에 대한 피드백도 많이 들었음
그래서 실험적으로 Docker Sandboxes를 미리보기 형태로 공개했음
아직 초기 단계지만, MicroVM 기반으로 다음 버전을 개발 중이며 Docker-in-Docker 문제를 피하려고 함
- Docker Sandbox가 Docker-in-Docker 문제를 어떻게 해결하는지 궁금함
  Claude가 Docker Sandbox 안에서 다른 컨테이너를 권한 없이 띄울 수 있는지 알고 싶음
대부분 로컬 VM을 직접 돌리는 걸 피하려는 것 같은데, 왜 그런지 모르겠음
사실 로컬 VM이 가장 단순하고 모든 문제를 해결함
Mac에서 Docker를 쓴다면 이미 Linux VM 위에서 돌아가고 있으니, 실제 환경과는 한 단계 차이밖에 없음
IDE에서 SSH로 바로 접속해 코드 확인도 가능함
나는 --dangerously-skip-permissions 옵션을 켜고 모든 변경은 PR로 처리함
여기에 workmux를 조합해 몇 달째 쓰고 있는데, 여러 PR을 동시에 처리할 수 있어 매우 효율적임
클라우드 VM보다 좋은 이유는, 여러 컨테이너를 동시에 띄우면 메모리를 많이 먹기 때문임
고사양 클라우드 VM을 24/7로 돌리면 비용이 너무 큼
악성 AI가 VM 탈출 취약점을 이용하지 않아도, Vagrantfile에 임의 코드를 추가해 호스트 접근을 얻을 수 있음
단순한 실수만 걱정하더라도, Claude가 커밋 훅을 수정해 버리면 그게 실행될 때 문제가 생김
완전한 격리를 유지하면서도 편리하게 개발하기란 정말 어렵다는 걸 느낌
- Claude를 특정 하위 디렉토리에만 가두면 됨
  예를 들어 Docker 볼륨 마운트를 이용해 sandbox/ 폴더만 수정 가능하게 하고 .git은 접근 불가하게 설정함
- 하지만 이건 VM과 호스트 간에 디렉토리를 양방향 공유한다는 전제가 필요함
  나는 스냅샷을 찍고, 작은 VM을 띄워 에이전트를 실행한 뒤, 다시 스냅샷을 비교하는 식으로 작업함
  자동 동기화는 격리 목적을 무너뜨리므로 절대 하지 않음
- 또 다른 위험은, 악성 코드가 저장소에 추가되고 나중에 VM 밖에서 실행될 때 감염될 수 있다는 점임
- “ec2 노드?”라고 짧게 물어봄
나는 다른 접근을 시도 중임 — Claude가 실행하려는 걸 가로채는 방식임
Shannot은 실행 전 의도를 캡처하고, PyPy 샌드박스에서 시스템 호출을 가로챔
명령과 파일 쓰기가 로그에만 남고 실제로 실행되지 않음
사용자가 TUI에서 검토 후 승인하면 그제야 실행됨
VM과의 차이는, VM은 완전 격리된 환경에서 자유롭게 실행시키는 반면 Shannot은 실제 시스템에 인간 승인 기반 변경을 적용함
서버 수정 같은 작업에 적합함
Claude MCP 통합, SSH 원격 실행, 체크포인트/롤백 기능도 있음
- 이 접근이 문제 해결에는 직접적이지 않지만, Claude Code의 내장 제어 기능과 비슷한 방향이라고 느낌
  결국 첫 승인 요청에서 멈추는 구조라, 에이전트가 자유롭게 탐색하지 못함
  내가 원하는 건, 에이전트가 중간에 멈추지 않고 끝까지 시도한 뒤 결과를 평가하는 방식임
  그래야 시간 절약이 큼
- Leash와 비슷한 철학으로 보임
  Leash의 mac-native 시스템 확장 모드와 유사하지만, 완전한 인터랙티브 승인 모드는 아직 없음
  흥미로운 프로젝트임
- “명령과 파일 쓰기가 로그에만 남고 실제 실행되지 않는다”는 부분은 사실 Claude가 이미 기본적으로 제공하는 기능임
- 이름이 정말 재치 있음
승인 피로가 쌓이면 결국 --dangerously-skip-permissions를 쓰고 싶어짐
그래서 나는 Claude Code를 devcontainer 안에서 돌림
파일 접근은 저장소만, 네트워크는 화이트리스트만 허용함
이후 docker compose로 일반화했고, 다음은 Codex나 OpenCode 같은 다른 에이전트 지원을 추가할 예정임
네트워크는 호스트의 프록시를 통해 강제 라우팅해 로깅과 제어를 강화하려 함
현재 iptables로 임시 처리 중임
아직 초기지만 꽤 잘 작동함
코드: agent-sandbox
- 나도 비슷한 구성을 실험 중임
  네트워크 프록시로 mitmproxy를 사용하고 있는데, 아직 완벽하진 않지만 거의 다 됨
- 친구들과 하루 저녁에 앱을 vibe coding으로 만들었는데, Claude에게 서버 클러스터의 root 권한을 줬음
  Claude가 몇 시간 동안 시스템을 스스로 설정하고 앱을 완성했음
  우리는 코드 한 줄도 안 썼고 결과가 놀라울 정도로 좋았음
  AI 개발의 속도가 정말 대단하다고 느낌
나의 솔루션은 간단함
```
sandbox-run npx @anthropic-ai/claude-code
```
이렇게 하면 npx 명령이 Bubblewrap 샌드박스 안에서 투명하게 실행되고, 현재 디렉토리만 노출됨
순수 POSIX 셸 몇 줄로 구현 가능함
sandbox-run
- Bubblewrap 접근이 마음에 들지만, Linux 전용이라는 점이 아쉬움
  한 번 권한을 내려놓으면 다시 복구할 수 없는 것도 단점임
나는 그냥 비권한 LXC 컨테이너에 넣고 끝냄
내 위협 모델은 복잡한 공격보다 “실수로 홈 디렉토리를 지워버리는” 상황임
나는 프로젝트의 run/ 디렉토리에 유틸리티 스크립트를 두고, compose 기반으로 컨테이너를 띄움
devcontainer는 호스트 디렉토리와 볼륨 매핑되어 있음
서비스 설정, 스크립트 업데이트, 런타임 문제 진단까지 Claude가 잘 처리함
브라우저 통합은 없지만, Playwright나 Puppeteer로 충분히 가능할 것 같음
Claude Code의 내장 샌드박싱에 대한 의견이 궁금함
공식 문서 링크
Claude Code에는 필요 시 샌드박스를 해제할 수 있는 escape hatch가 있음
명령이 샌드박스 제한으로 실패하면 Claude가 원인을 분석하고 dangerouslyDisableSandbox로 재시도할 수 있음
에이전트가 스스로 샌드박스를 해제할 수 있다는 점이 취약점처럼 보이는데, 이 경우 사용자 승인 절차가 있는지 궁금함
- 아쉽게도, 종종 사용자 확인 요청을 우회하는 사례가 있음
  관련 이슈: #14268, #13583, #10089

답변달기