권한, Sandbox, 신뢰의 문제

신뢰 다이얼

모든 AI CLI 가 똑같은 설계 결정을 해: "모든 거 물어봐" 와 "알아서 해" 사이 다이얼이 어디에 놓이느냐. Claude Code 는 권한 룰 (allow / ask / deny) 이라 부르고, Codex 는 approval mode (untrusted / on-request / never) + sandbox (read-only / workspace-write / danger-full-access), Gemini 는 sandbox + tool exclusion 이라 부르지. 어휘만 다르고 멘탈 모델은 같아.

모든 다이얼 위치가 같은 두 비용을 trade-off 해. 너무 "ask" 쪽이면 네가 병목이 돼 — 매 npm install 마다 멈춰. 너무 "auto" 쪽이면 확률적 시스템한테 rm -rf 권한 주는 거고. 정직한 답은 일마다 다른 설정: 방금 clone 한 남의 repo 에는 빡빡, Docker sandbox 안에서는 느슨, 이미 격리된 CI runner 에서는 "never ask".

새 사용자가 가장 늦게 받아들이는 교훈: 한 번 골라서 끝이 아냐. 각 도구의 설계는 신뢰가 자라거나 줄어듦에 따라 mid-session 으로 다이얼을 옮길 거란 가정 위에 있고, slash command (/permissions, /approvals) 가 정확히 그걸 위해 존재해.

Code

Same idea, three syntaxes·bash

# Claude Code — rule-based, deny → ask → allow
# .claude/settings.json
{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(git diff *)", "Read"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Bash(rm -rf *)", "Read(./.env)"]
  }
}

# Codex CLI — approval mode + sandbox mode
codex --ask-for-approval on-request --sandbox workspace-write

# Gemini CLI — sandbox container + tool exclusion
gemini --sandbox -e "WriteFile,RunShellCommand"

Tight to loose, same task·bash

# 1. Brand-new repo, you don't trust the code yet
codex --sandbox read-only "explain what this project does"

# 2. Familiar repo, normal coding
codex                                    # default: workspace-write + on-request

# 3. Inside a Docker container, fully isolated
codex --sandbox danger-full-access --ask-for-approval never \
      "fix all eslint errors and rebuild"

# Same CLI, three trust levels — one per situation

권한, Sandbox, 신뢰의 문제

신뢰 다이얼

Code

External links

Exercise

Progress

댓글 0