Codex CLI와 Gemini CLI 안전 설정: 비교 분석 가이드

OpenAI의 Codex CLI와 Google의 Gemini CLI는 모두 터미널에서 파일을 읽고, 코드를 편집하며, 명령을 실행할 수 있는 에이전트를 구동합니다. 두 도구 모두 샌드박스(sandboxes), 승인 모드(approval modes), 도구 제한(tool restrictions)과 같은 실제 안전 제어를 갖추고 있지만, 이를 명명하고 계층화하는 방식이 달라 사용자가 한쪽을 다른 쪽처럼 잠갔다고 착각하기 쉽습니다. 이 가이드는 Codex CLI와 Gemini CLI의 안전 설정을 나란히 비교하며, 대화형 사용과 CI 환경에 대한 구성을 다룹니다.

설정은 릴리스마다 변경됩니다. 여기에 제시된 모든 내용은 각 프로젝트의 현재 문서를 기반으로 합니다 (Codex: agent approvals & security, Gemini CLI configuration); 설치된 버전을 통해 반드시 검증하십시오.

두 도구가 공유하는 두 가지 계층

두 도구 모두 다음의 두 질문을 분리하여 다룹니다:

에이전트가 기술적으로 무엇을 할 수 있는가? — 샌드박스: 어떤 경로가 쓰기 가능한지, 네트워크 연결이 가능한지 여부.
언제 먼저 물어봐야 하는가? — 승인 정책: 어떤 행동은 인간의 확인을 위해 일시 중단되는지.

안전을 확보하려면 두 가지를 모두 의도적으로 설정해야 합니다. 제한 없는 샌드박스 위에 엄격한 승인 정책을 적용하는 것은 사용자가 모든 프롬프트를 읽는 것에 전적으로 달려 있으며, 승인이 없고 빡빡한 샌드박스를 사용하는 것은 샌드박스가 정확하다는 것에 전적으로 달려 있습니다.

Codex CLI

샌드박스 모드

`sandbox_mode` / `--sandbox`	효과
`read-only`	읽기 전용 샌드박스 내에서 파일을 읽고 명령을 실행할 수 있음
...
로컬 환경에서 샌드박스는 OS가 강제합니다: macOS에서는 Seatbelt, Linux에서는 `bwrap`과 `seccomp`를 사용합니다. `workspace-write` 모드에서도 쓰기 가능한 루트 내부의 일부 경로는 `.git`, `.codex`, `.agents`를 포함하여 읽기 전용으로 유지되는데, 이는 에이전트가 자체 설정을 재작성하거나 사용자 git 내부 구조를 건드리는 것을 막아 유용합니다.

승인 정책

`approval_policy` / `--ask-for-approval`	효과
`on-request`	샌드박스를 벗어나기 전 요청함 (예: 작업 공간 외부 작성, 네트워크 사용)
...
참고: 이전의 `approval_policy = "untrusted"` 값은 폐지되었으며 Codex가 시작되는 것을 막을 수 있습니다. 더 엄격한 명령어 승인을 위한 문서화된 대체 방법은 `~/.codex/config.toml` 파일 내 프로젝트별 신뢰 수준입니다:

[projects."/path/to/project"]
trust_level = "untrusted"

네트워크 (Network)

workspace-write에서는 기본적으로 네트워크가 비활성화되어 있습니다. 이 기능을 켜려면 네트워크 프록시도 함께 켜야 합니다. 그렇지 않으면 아웃바운드 트래픽이 제한되지 않습니다:

[sandbox_workspace_write]
network_access = true

...

도메인 규칙은 허용 목록(allowlist) 우선이며 deny가 항상 승리합니다. 프록시는 샌드박스 내부의 명령어를 필터링하지만, 웹 검색, MCP 서버 연결 또는 앱/커넥터 도구 호출은 자체적인 제어 장치가 있으므로 필터링하지 않습니다. 웹 검색은 라이브 페이지 대신 캐시된 인덱스를 기본으로 사용하므로 임의 사이트로부터의 프롬프트 주입(prompt injection) 노출이 줄어듭니다.

피해야 할 플래그 (The flag to avoid)

--dangerously-bypass-approvals-and-sandbox (별칭 --yolo)는 이 두 가지 계층을 모두 제거합니다. 만약 이것이 필요하다면, 그 자체가 보안 경계인 컨테이너 또는 devcontainer 내부에서만 실행하십시오.

권장 Codex 설정 (Recommended Codex configs)

대화형 개발:

sandbox_mode    = "workspace-write"
approval_policy = "on-request"

CI에서의 읽기 전용 검토:

codex exec --sandbox read-only --ask-for-approval never "Review this diff for bugs"

Gemini CLI

승인 모드 (Approval modes)

`--approval-mode`	효과
`default`	도구 호출 시 승인을 요청함
...
`settings.json`의 `general.defaultApprovalMode`는 `default`, `auto_edit`, 그리고 `plan`을 허용합니다. YOLO는 명령줄에서만 활성화할 수 있으며, 독립형 `--yolo` 플래그는 `--approval-mode=yolo`로 대체되었습니다. 어떤 플래그와 관계없이 장치에서 YOLO를 불가능하게 만들려면:

{
  "security": { "disableYoloMode": true }
}

샌드박싱 (Sandboxing)

-s 또는 --sandbox를 사용하거나, GEMINI_SANDBOX 환경 변수를 설정하거나, settings.json에서 tools.sandbox를 지정하여 샌드박스를 활성화할 수 있습니다 (예: "docker" 또는 "podman"). 문서에 따르면 YOLO 모드로 실행할 때는 기본적으로 샌드박스가 활성화됩니다. 또한 전체 프로세스 대신 개별 도구를 격리하는 새로운 옵션인 security.toolSandboxing도 있습니다.

{
  "tools": { "sandbox": "docker" }
}

도구 허용 및 제외 목록 (Tool allow and exclude lists)

tools.exclude: 도구를 검색 과정에서 완전히 제거합니다. 이 경우 모델은 해당 도구를 절대 볼 수 없습니다.
tools.allowed: 확인 대화 상자를 우회하는 도구 목록을 지정합니다. 예를 들어 "run_shell_command(git)" 또는 "run_shell_command(npm test)"가 있습니다.

tools.allowed를 사용할 때는 주의해야 합니다. run_shell_command(git)과 같은 항목은 단순히 git status보다 훨씬 많은 것을 사전에 승인합니다. 여기에는 git push --force도 포함됩니다. 가능한 가장 좁은 범위의 명령만 허용 목록에 추가하고, 읽기 전용 워크플로우에서는 셸 도구 자체를 제외하는 것을 선호하세요. 이전 Gemini CLI 문서는 셸 도구에 대한 특정 명령어 제한이 단순 문자열 일치(simple string matching)에 기반하며 우회될 수 있다고 경고했습니다. 이는 모든 에이전트의 명령어 패턴에 대한 좋은 참고 규칙입니다.

폴더 신뢰 (Folder trust)

security.folderTrust.enabled는 기본값이 true로 설정되어 있어, 프로젝트 자체의 구성 및 도구가 로드되는지 여부를 제어합니다. 이 설정을 그대로 두세요. 클론된 저장소(repository)가 사용자의 에이전트를 구성할 수는 없습니다.

권장 Gemini 설정 (Recommended Gemini configs)

대화형 개발:

{
  "general": { "defaultApprovalMode": "default" },
  "tools": { "sandbox": "docker" },
...

읽기 전용 분석:

gemini --approval-mode plan

나란히 비교 (Side by side)

고려 사항 (Concern)	Codex CLI	Gemini CLI
읽기 전용 모드 (Read-only mode)	`--sandbox read-only`	`--approval-mode plan`
...

두 설정 모두 제공하지 않는 것 (What neither setting gives you)

두 도구 모두 제어는 개별 도구 및 세션 단위로 이루어집니다. 어느 쪽도 자체적으로 팀이 실행하는 모든 에이전트에 적용되는 테스트 가능한 단일 정책, '비밀을 읽은 후 외부 송신 금지'와 같은 세션 인식 규칙, 또는 나중에 조회할 수 있는 결정 로그가 있는 프로덕션 작업에 대한 지정된 승인자 대기(named-approver hold)를 제공하지는 않습니다.

Cirvix의 역할

Cirvix AgentControl은 두 CLI와 함께 작동할 수 있는 오픈 소스 정책 레이어입니다. 현재 적용 가능한 기능 두 가지가 있습니다:

인벤토리(Inventory): cirvix scan은 Codex CLI 및 Gemini CLI 구성을 인식하며 (Claude Code, Cursor 등과 함께), 광범위한 파일 시스템 범위를 가진 MCP 서버, 인라인 비밀(inline secrets)을 포함하는 경우, 또는 중복 정의가 있는 경우를 플래그 지정합니다. 이는 실행 중인 에이전트의 동작에 대한 증거가 아니라 설정 파일에 대한 로컬 휴리스틱 스캔입니다.
MCP 게이트웨이(gateway): 두 CLI 모두 MCP 서버를 사용할 수 있습니다. 이들을 유일한 MCP 진입점인 cirvix gateway로 지정하면, 라우팅되는 모든 MCP 도구 호출은 실제 서버에 도달하기 전에 하나의 정책 파일(허용(permit), 지정된 승인자 대기(hold for a named approver), 또는 기본 거부(deny by default))을 기준으로 평가됩니다.

npx @cirvix_ai/agent-control scan
npx --yes @cirvix_ai/agent-control check --action fs.read --resource .env.production

경계는 다음과 같습니다: 게이트웨이가 이를 통해 라우팅되는 MCP 호출을 관리합니다. 각 CLI에 내장된 셸 및 파일 도구는 본 기사의 설정에 의해 관리되므로, 이 설정을 먼저 구성해야 합니다.

GitHub: https://github.com/CIRVIX/agent-control
Website: https://cirvix.com