Claude Code Auto mode와 bypassPermissions: 확인 창보다 먼저 정할 권한 경계

권한 확인이 작업을 끊는다면 먼저 Auto mode에 명시적인 deny/ask 규칙을 더하는 방법을 선택하세요. Bash 명령의 파일과 네트워크 범위까지 제한하려면 샌드박스를 함께 사용합니다. bypassPermissions는 더 편한 자동 모드가 아니라, 컨테이너나 VM이 이미 피해 범위를 제한한 뒤에만 고려할 실행 모드입니다.

두 모드 모두 확인 창은 크게 줄이지만 책임 구조는 다릅니다. Auto mode에서는 별도 분류기가 실행 전 작업을 검토합니다. bypassPermissions에서는 일반 권한 확인과 안전 검사 경로를 건너뜁니다.

확인 창이 없다는 사실만으로는 모드를 구분할 수 없다

현재 Anthropic의 권한 모드 문서에 따르면 Auto mode는 별도의 classifier 모델이 작업을 실행 전에 평가합니다. 사용자의 요청을 벗어나는 변경, 인식하지 못한 인프라, 파괴적 작업, Claude가 읽은 적대적 콘텐츠에 이끌린 것으로 보이는 작업을 차단할 수 있습니다. 명시적인 ask 규칙은 계속 확인을 요청하고, permissions.deny는 모든 모드에서 classifier보다 먼저 적용됩니다.

bypassPermissions는 일반 permission prompt와 safety check를 비활성화해 보호 경로 쓰기를 포함한 tool call을 즉시 실행합니다. 아래 두 명령은 같은 의미입니다.

bash
claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions

그렇다고 Claude Code 내부의 모든 불변 조건이 사라지는 것은 아닙니다. 명시적인 ask 규칙, 조직이 확인을 요구한 connector, 사용자 상호작용이 필요한 tool, critical path를 지우는 rm/rmdir, 일부 cross-session 메시지에는 별도 처리가 남습니다. deny 규칙도 계속 동작합니다. 이 예외는 계약을 정확히 설명할 뿐 bypass를 안전하게 만들지 않습니다. 공식 문서는 이 모드가 prompt injection이나 의도하지 않은 작업을 보호하지 않는다고 밝힙니다.

Auto mode도 안전을 보장하지 않습니다. classifier는 문맥을 판단하므로 위험을 놓치거나 정상 작업을 막을 수 있습니다. 통과했다는 사실은 코드가 정확하거나 조직 승인을 받았다는 증거가 아닙니다.

작업 시간이 아니라 손상 반경으로 선택한다

몇 분짜리 production 변경은 밤새 도는 로컬 테스트보다 더 큰 권한을 쓸 수 있습니다. 모드를 고르기 전에 다음 네 가지를 구체적으로 답하세요.

1. 잘못된 명령이 접근할 수 있는 파일, 네트워크, cloud resource는 무엇인가?
2. 어떤 credential이 있고 각각 무엇을 변경할 수 있는가?
3. host를 복구하지 않고 실행 환경만 폐기하고 다시 만들 수 있는가?
4. 되돌릴 수 없거나 외부에 영향을 주는 작업 전에 사람의 checkpoint가 남는가?

직접 관리하는 repository에서 최종 diff와 test를 확인하는 일상 작업이라면 Auto mode가 실용적입니다. 일반 승인 피로를 줄이면서 문맥 검토자를 유지할 수 있습니다.

낯선 코드, 개인정보, production 인프라, 목적이 계속 변하는 작업에는 Manual 또는 Plan이 맞습니다. 이 경우 필요한 것은 더 강한 자동화가 아니라 의미를 판단할 사람입니다.

고정 명령만 실행하는 CI라면 dontAsk가 더 명확할 수 있습니다. 사전 승인한 tool만 실행하고 나머지를 거부하므로 문맥 기반 classifier보다 감사하기 쉽습니다.

bypassPermissions는 외부 격리가 실제 보안 경계일 때만 사용합니다. 공식 출발점은 인터넷이 없는 container, VM, dev container입니다. non-root user로 실행하고 host home과 credential을 mount하지 않으며, 작업 copy와 결과 directory만 전달하고 환경을 폐기 가능하게 만드세요. Linux와 macOS에서는 인식된 sandbox 밖에서 root나 sudo로 bypass를 시작할 수 없지만, 이 검사는 컨테이너를 대신하지 않습니다.

터미널 종료, 절전, session 재개 뒤에도 프로세스가 살아 있어야 하는 문제라면 권한 모드는 일부만 해결합니다. Claude Code 장시간 작업 설계에서 runtime, 지속 상태, 완료 증거, 복구를 별도로 확인하세요.

Auto mode 설정은 실제로 적용되는 범위에 둔다

한 번의 CLI session은 다음처럼 시작합니다.

bash
claude --permission-mode auto

개인 terminal의 기본값은 ~/.claude/settings.json에 둡니다.

json
{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(git push --force *)",
      "Bash(terraform destroy *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(terraform apply *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}

현재 terminal 계약에서는 repository 안의 .claude/settings.json이나 .claude/settings.local.json에 있는 defaultMode: "auto"를 적용하지 않습니다. checkout한 repository가 스스로 Auto mode를 켜지 못하게 하기 위한 경계입니다. VS Code와 다른 interface는 시작 모드 제어가 별도이므로 실제로 사용하는 surface에서 확인해야 합니다.

deny와 ask 예시는 공식 권한 규칙 문법에 맞춰 실제 command와 target으로 좁히세요. 너무 넓은 allow rule은 classifier가 보기 전에 위험한 인자를 승인할 수 있습니다. 문맥과 상관없이 금지할 작업은 managed permissions.deny에 두는 편이 결정적입니다.

Auto mode environment에는 신뢰할 repository, 내부 domain, bucket, package registry, 민감한 remote target을 설명할 수 있습니다. 설정 파일 하나만 보고 precedence를 추측하지 말고 병합된 결과를 출력합니다.

bash
claude auto-mode config

claude auto-mode defaults는 내장 규칙을, claude auto-mode critique는 사용자 규칙의 모호함을 확인하는 데 쓸 수 있습니다. 지원 model, provider, version, plan, 기본 모드는 바뀔 수 있으므로 “설정이 존재함”과 “현재 사용 가능함”을 같은 뜻으로 보지 마세요.

승인과 도달 범위는 다른 보호 계층이다

Auto mode는 “작업을 누가 승인하는가”를 결정합니다. Bash sandbox는 승인된 Bash와 child process가 “어떤 파일과 network까지 도달할 수 있는가”를 OS 수준에서 제한합니다.

내장 sandbox는 macOS, Linux, WSL2에서 동작하며 native Windows는 WSL2가 필요합니다. 실패 시 열리는 구성이 아니라 닫히는 구성을 만드세요.

• 쓰기는 repository와 session temp directory로 제한합니다.
• 필요한 domain만 network allowlist에 넣습니다.
• SSH, cloud credential, 고권한 token은 deny 또는 mask합니다.
• allowUnsandboxedCommands: false로 host 재시도를 막습니다.
• failIfUnavailable: true로 sandbox를 만들 수 없으면 작업을 중지합니다.

Bash sandbox는 Bash와 child process를 다루며 Claude Code의 모든 tool을 격리하지는 않습니다. 무인 bypass에서는 외부 container나 VM이 여전히 최종 경계입니다. 승인 모드와 실행 후 도달 범위를 각각 검증해야 합니다.

자리를 비우기 전에 실제 상태를 확인한다

Auto mode의 사용 가능 여부와 시작 기본값은 Claude Code version, plan, model, provider, feature flag, 조직 정책, interface에 따라 달라집니다. 기억한 기본값 대신 실행 중 상태를 확인하세요.

1. status bar의 권한 모드. CLI에서는 Shift+Tab으로 현재 session에 있는 모드를 확인합니다.
2. /permissions의 effective allow, ask, deny와 최근 거부 기록.
3. claude auto-mode config의 병합된 classifier context.
4. /sandbox의 filesystem, network, mode, unsandboxed retry.

Auto mode에서 거부가 반복되면 interactive session은 사람의 prompt로 돌아갈 수 있습니다. permission prompt tool이 없는 non-interactive -p에서는 거부된 작업이 실행되지 않지만 다른 단계가 이어질 수 있습니다. 따라서 프로세스가 살아 있다는 사실은 성공 증거가 아닙니다. 관찰 가능한 완료 조건과 실패 artifact를 먼저 정하세요.

방향을 신뢰하면서 검토자를 남기려면 Auto mode, 고정 allowlist가 필요하면 dontAsk, 사람의 판단이 필요하면 Manual/Plan을 선택하세요. host, internet, credential, 지속 데이터가 agent의 도달 범위 밖에 있을 때만 bypassPermissions를 고려하는 순서가 안전합니다.