Claude Code·Codex·Gemini CLI 샌드박스 비교: 경계가 감싸는 범위

Claude Code, Codex CLI, Gemini CLI를 한 환경에 나란히 깔고 아무 옵션 없이 돌려 봤습니다. Codex CLI는 세션 헤더에 sandbox: read-only를 찍으며 시작하더라고요. 켜는 절차 없이 이미 샌드박스가 걸려 있었던 거죠.

Claude Code는 설정하지 않으면 샌드박스 없이 명령을 돌리고, Gemini CLI는 -s를 붙여도 샌드박스까지 가지 못하고 인증부터 요구하며 멈췄습니다.

셋 다 “샌드박스”라고 부르지만, 기본값만 다른 게 아니라 감싸는 단위부터 다릅니다. Claude Code는 셸 명령과 그 자식 프로세스만 감싸고(파일 도구·MCP 서버·훅은 밖), Codex CLI는 모델이 만든 셸 명령을 옵션 없이도 read-only로, Gemini CLI는 CLI 프로세스 전체나 개별 도구 실행을 감쌉니다. 그래서 도구를 바꿀 때 “샌드박스를 켰다”는 습관을 그대로 옮기지 말라고 말씀드리고 싶어요.

2026년 9월 19일에 Ubuntu 24.04 · bash 테스트 환경에서 Claude Code 2.1.276, Codex CLI 0.155.0, Gemini CLI 0.60.0을 설치해 버전, --help, 옵션 없는 실행의 기본값을 직접 확인하고 공식 문서와 대조했습니다.

승인 창이 뜨는 흐름과 Gemini CLI의 샌드박스 동작은 공식 문서가 근거입니다. 10월 14일에는 Windows 11 · Claude Code 2.1.296에서 /sandbox를 직접 열어 봤습니다. 이 사이트에 Claude Code 글이 가장 많다는 점도 감안해 읽어 주세요.

도구별 설정은 Claude Code 샌드박스 켜는 법과 권한 규칙 차이와 Codex CLI 샌드박스 모드와 승인 정책에서 따로 다뤘습니다.

감싸는 단위부터 다르다

도구	경계가 감싸는 것	경계 밖
Claude Code	Bash·PowerShell·Monitor 명령과 자식 프로세스	Read·Edit·Write, MCP 서버, 훅
Codex CLI	모델이 만든 셸 명령	—
Gemini CLI	CLI 프로세스 전체, 또는 개별 도구 실행	도구 단위면 UI 렌더링·설정 로딩

Codex CLI의 —는 경계 밖이 없다는 뜻이 아닙니다. --help는 경계가 모델이 만든 셸 명령에 적용된다고만 하고, 그 밖에 무엇이 남는지는 말하지 않아요.

Claude Code의 샌드박스는 셸 명령과 그 자식 프로세스만 격리합니다. 권한 규칙과는 맡는 일이 달라서, 샌드박스는 셸 명령이 닿는 파일·네트워크를 운영체제 수준에서 막고, 어떤 도구를 쓰게 할지는 권한 규칙이 정해요.

Gemini CLI는 셸 명령이나 파일 수정처럼 위험할 수 있는 작업을 호스트에서 떼어 놓는 것을 샌드박스로 보고, 감싸는 단위를 둘로 나눕니다. 컨테이너나 Seatbelt로 CLI 자체를 감싸는 방식과, shell_exec·write_file 같은 개별 도구 실행만 감싸는 도구 단위 방식이에요. 도구 단위 방식을 끄는 설정(security.toolSandboxing)도 있으니, Gemini CLI에서 “켰다”고 할 때는 어느 단위인지부터 정해야 합니다.

Codex CLI는 근거가 다릅니다. 공개 저장소의 샌드박스 문서가 짧아서, 이 글의 Codex 설명은 직접 실행해 확인한 동작만 담았습니다.

옵션 없이 돌리면

codex exec "hi"

…
approval: never
sandbox: read-only
…

Codex CLI는 아무 플래그 없이 실행해도 세션 헤더에 이 두 줄을 찍었습니다. 켜는 절차 없이 read-only 샌드박스가 이미 걸린 상태로 시작한 거예요.

도구	옵션 없을 때	켜는 방법
Codex CLI	read-only 적용됨	-s, --sandbox로 모드 변경
Claude Code	샌드박스 없음(sandbox.enabled 기본 false)	/sandbox 또는 설정
Gemini CLI	로그인 전에는 시작하지 않음(-s를 붙여 실행)	-s → GEMINI_SANDBOX → tools.sandbox 순

Claude Code는 sandbox 설정이 비어 있으면 샌드박스 없이 명령을 돌리고, sandbox.enabled의 기본값도 false입니다. Gemini CLI는 명령줄 플래그 -s·--sandbox, 환경 변수 GEMINI_SANDBOX, settings.json의 tools.sandbox 순으로 우선해요.

막는 수단도 다릅니다. Claude Code는 macOS·Linux·WSL2에서 돌고, 네이티브 Windows에서는 샌드박스 없이 명령을 실행합니다(리눅스·WSL2는 패키지 두 개 필요).

Windows 11에서 /sandbox를 쳐 보니 메뉴에 ◯ sandbox disabled로 떴고, Enter를 누르자 켜는 화면 대신 이 한 줄이 나왔습니다.

Error: Sandboxing is currently only supported on macOS, Linux, and WSL2.

Windows에서 셸 명령을 경계 안에 두고 싶다면 WSL2에서 Claude Code를 돌려야 한다는 뜻이에요.

Gemini CLI는 방식 자체를 고르게 합니다. macOS 전용 Seatbelt, Docker나 Podman이 설치돼 실행 중이어야 하는 컨테이너 방식(프로세스 전체를 격리하는 크로스 플랫폼 방식), 리눅스 전용 gVisor(runsc)와 실험적인 LXC/LXD, 그리고 Windows 전용 방식이 있습니다.

Gemini CLI는 방식마다 전제와 부작용을 먼저 읽으세요. LXC/LXD는 Gemini CLI를 띄우기 전에 컨테이너를 직접 만들어 실행해 둬야 하고, Windows 전용 방식은 파일·폴더의 무결성 수준을 낮추며 그 변경이 세션이 끝나도 파일 시스템에 남습니다.

경계와 승인은 따로 논다

샌드박스가 “무엇에 닿을 수 있나”라면 승인은 “물어볼 것인가”입니다. 세 도구 모두 이 둘을 따로 둡니다.

도구	경계를 정하는 축	승인을 정하는 축
Claude Code	/sandbox·sandbox 설정	권한 규칙·권한 모드, 샌드박스 모드 둘
Codex CLI	-s: read-only·workspace-write·danger-full-access	-a: on-request·never
Gemini CLI	-s(켜기·끄기)	--approval-mode: default·auto_edit·yolo·plan

--help에서 직접 확인한 줄입니다. Codex CLI는 경계 쪽 값이 셋이에요.

  -s, --sandbox <SANDBOX_MODE>
          Select the sandbox policy to use when executing model-generated shell commands
          [possible values: read-only, workspace-write, danger-full-access]

Gemini CLI는 반대로 경계는 켜고 끄는 값 하나뿐이고, 값이 네 개인 쪽은 승인입니다.

  -s, --sandbox                   Run in sandbox?  [boolean]
      --approval-mode             Set the approval mode: default (prompt for approval), auto_edit (auto-approve edit tools), yolo (auto-approve all tools), plan (read-only mode)  …

Claude Code는 claude --help에 샌드박스 옵션이 없습니다. sandbox라는 단어는 다른 옵션 설명 속에서 두 번 나올 뿐이고, 대신 샌드박스 모드 두 개(auto-allow, regular permissions)가 있어요.

두 모드는 파일·네트워크 경계가 똑같고 샌드박스 명령을 자동 승인하느냐만 다릅니다.

그래서 Claude Code에서 모드를 바꾼다고 경계가 넓어지지는 않습니다. “모드를 올리면 경계가 넓어진다”는 Codex식 감각으로 읽으면 여기서 어긋나요.

네트워크와 읽기 기본값도 비교해 볼 만합니다.

도구(방식)	읽기	쓰기	네트워크
Claude Code	일부 폴더 뺀 전체	작업 폴더 등	허용 도메인 0개에서 시작
Gemini CLI(macOS Seatbelt 기본 프로파일 permissive-open)	넓게	프로젝트 폴더	넓게

읽기는 둘 다 넓지만 네트워크 기본값은 정반대입니다. 단 Gemini CLI 쪽은 macOS Seatbelt 방식의 기본 프로파일 이야기이고, 다른 방식이나 CLI 전체의 기본값이 아닙니다.

경계에 부딪혔을 때

막힌 다음에 무슨 일이 일어나는지도 셋이 다릅니다.

• Claude Code는 위반 내용이 명령 결과에 담겨 모델에게 가고, 모델이 샌드박스를 끄는 인자를 붙여 다시 시도할 수 있습니다. 이 재시도를 막는 설정이 따로 있어요.
• Gemini CLI는 Sandbox Expansion Request를 사람에게 띄웁니다. 권한 때문에 실패했을 때뿐 아니라 npm install처럼 추가 권한이 필요하다고 미리 판단된 명령에서도 뜨고, 승인하면 그 실행에 한해 넓힌 권한으로 돕니다.
• Codex CLI는 승인 값이 on-request·never 둘이라 물어볼지가 미리 정해져 있습니다. never면 실패가 그대로 모델에게 돌아갑니다(--help 설명).

모델이 다시 시도하느냐, 사람에게 넓혀 달라고 묻느냐, 묻는지를 미리 정해 두느냐의 차이예요. 무인 실행을 계획한다면 이게 곧 “어디서 멈추느냐”의 차이라서, 기본값보다 이 부분을 먼저 보길 권합니다.

다른 사람들이 겪은 문제

아래 세 건은 각 작성자가 공개 저장소에 올린 보고입니다(2026년 9월 19일 확인). 서로 다른 도구인데 가리키는 곳이 같습니다. 설정에 적은 값과 실제로 적용된 경계가 어긋났다는 거예요.

• grant-mccarriagher(2026-03-19, claude-agent-sdk-typescript #239)는 TypeScript Agent SDK의 query()를 sandbox.enabled: true로 불렀는데, 리눅스에 bubblewrap이 없으면 오류도 경고도 결과 표시도 없이 샌드박스 없이 실행됐다고 했습니다. 오류를 던지거나 결과에 상태 필드를 넣자고 제안했고, 지금은 닫혀 있습니다. Claude Code 문서도 의존 패키지가 없으면 경고를 내고 샌드박스 없이 실행한다고 설명하니, 어긋나는 지점은 “샌드박스 없이 돈다”가 아니라 그 사실이 호출한 쪽에 보이느냐입니다.
• vadimcomanescu(2026-03-18, claude-code #35986)는 반대 방향으로, sandbox.enabled: false인데도 모든 Bash 명령이 bwrap으로 감싸여 백그라운드 프로세스가 죽고 네트워크가 분리됐으며 SANDBOX_RUNTIME이 1이었다고 했습니다(2.1.79, Arch Linux, 커널 6.18.13-arch1-1). 개발 서버를 Claude Code 밖 터미널에서 띄우는 것이 우회였고, not planned로 닫혔습니다. 원인은 확정되지 않았습니다.
• MohammedADev(2026-03-08, gemini-cli #21600)는 Gemini CLI에서 SANDBOX 환경 변수가 '0'이면 비어 있지 않은 값이라 “이미 샌드박스 안”으로 취급돼 초기화가 건너뛰어진다고 했습니다. '0'은 거짓으로 보고 GEMINI_SANDBOX로 요청한 설정이 적용돼야 한다는 것이 보고자의 기대입니다. not planned로 닫혔습니다.

설정 파일에 적은 건 의도이고, 적용된 경계는 따로 확인할 사실입니다. 다행히 확인 수단은 도구마다 이미 있어요.

• Codex CLI: 실행마다 세션 헤더에 approval·sandbox 두 줄을 찍고, codex sandbox 하위 명령으로 같은 경계 안에서 명령을 돌려 볼 수 있습니다.
• Claude Code: /sandbox의 Config 탭과, 샌드박스 밖으로 떨어진 명령의 프롬프트 제목에 표시됩니다(네이티브 Windows에서는 /sandbox가 지원하지 않는다는 오류만 냅니다).
• Gemini CLI: 디버그 모드와 샌드박스 안의 환경 변수·마운트를 들여다보는 명령이 문서에 있습니다.

상황별로 먼저 볼 곳

우열을 매기는 표가 아니라 상황별로 먼저 볼 곳입니다.

상황	먼저 볼 곳
명령 실행만 묶고 파일 편집은 평소대로	Claude Code /sandbox
켜는 절차 없이 기본이 보수적	Codex CLI(옵션 없이 read-only)
CLI 프로세스까지 통째로 격리	Gemini CLI 컨테이너 방식, 리눅스면 gVisor
네이티브 Windows에서 그대로	Gemini CLI(Claude Code는 미지원)
로그인 전에 경계를 눈으로 확인	Codex CLI codex sandbox

Gemini CLI를 가리킨 두 줄에는 계정 조건이 붙습니다.

Gemini CLI 메인테이너가 2026년 5월 19일 공식 저장소 토론 글에서 무료 이용자와 Google AI Pro·Ultra 구독자의 요청을 2026년 6월 18일부터 처리하지 않는다고 공지했으므로, 이 두 줄은 같은 글이 접근 유지를 밝힌 조직 라이선스·Google Cloud·유료 Gemini API 키 사용자에게 해당합니다(2026년 9월 28일 확인).

Windows 전용 방식에는 앞에서 본 무결성 수준 부작용도 따라옵니다.

도입에서 말한 Gemini CLI의 인증 요구는 이렇게 나왔습니다.

gemini -s -p "hi"

Please set an Auth method in your ~/.gemini/settings.json or specify one of the following environment variables before running: GEMINI_API_KEY, GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_GENAI_USE_GCA

샌드박스를 켜면 권한 설정은 신경 안 써도 되느냐고 묻는다면, 세 도구 모두 아니라고 답합니다. 어디서도 경계와 승인이 한 설정으로 합쳐져 있지 않았거든요.

두 도구의 문서도 같은 경고를 남겼습니다. 샌드박스는 위험을 줄일 뿐 없애지 못하니, 어느 쪽을 고르든 샌드박스 하나를 유일한 방어선으로 두지 마세요.

마치며

세 도구를 나란히 놓고 보니, “샌드박스를 켰다”는 말 한마디가 도구마다 전혀 다른 범위를 가리키더라고요. 셸 명령만인지, 모델이 만든 명령인지, 프로세스 전체인지.

그래서 새 도구를 쓸 때는 켰는지보다 무엇이 감싸였는지를 확인하길 권합니다. 세 도구 모두 플래그와 기본값이 버전마다 바뀌어 왔으니, 명령을 옮겨 쓰기 전에 각 도구의 --help를 한 번 열어 보는 것도 잊지 마세요.

지금 쓰는 도구에서 적용된 경계를 한 번 확인해 보세요. Codex라면 세션 헤더의 sandbox: 줄, Claude Code라면 /sandbox의 Config 탭입니다(네이티브 Windows에서는 지원하지 않는다는 오류만 납니다). 지시 파일이 도구마다 어떻게 겹치는지는 CLAUDE.md·AGENTS.md·GEMINI.md가 겹치는 부분으로 이어 읽을 수 있습니다.