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

> Claude Code Auto mode와 bypassPermissions를 검토 주체, 남는 제어, 격리 요건, 무인 실행 동작으로 비교하고 안전한 시작점을 고릅니다.

- Source: https://www.aifreeapi.com/ko/posts/claude-code-auto-mode-vs-bypass-permissions
- Language: ko
- Published: 2026-08-20
- Updated: 2026-08-20
- Publisher: AI Free API (https://www.aifreeapi.com)

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

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

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

현재 Anthropic의 [권한 모드 문서](https://code.claude.com/docs/ko/permission-modes)에 따르면 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 | `bypassPermissions` |
|---|---|---|
| 일반 작업을 검토하는 주체 | 별도 classifier | 일반 검토자 없음 |
| 권한 확인 창 | 대부분 없음, ask는 유지 | 대부분 없음, 문서화된 예외는 유지 |
| 결정적 deny | 적용됨 | 적용됨 |
| 보호 경로 쓰기 | 일반적으로 자동 승인되지 않음 | 일반 보호 경로 검사를 거치지 않고 실행 |
| 적합한 환경 | 방향을 신뢰할 수 있는 작업과 다층 방어 | 인터넷 없는 격리 container/VM/dev container |
| OS 수준 격리 | 모드가 제공하지 않음 | 모드가 제공하지 않음 |

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 장시간 작업 설계](/ko/posts/claude-code-long-running-tasks)에서 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에서 확인해야 합니다.

![Auto mode 기본값이 적용되는 설정 범위와 병합된 실제 상태를 확인하는 절차](https://www.aifreeapi.com/posts/ko/claude-code-auto-mode-vs-bypass-permissions/img/effective-scope.webp)

deny와 ask 예시는 공식 [권한 규칙 문법](https://code.claude.com/docs/ko/permissions)에 맞춰 실제 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](https://code.claude.com/docs/ko/sandboxing)는 승인된 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.

![classifier 거부 뒤 대화형 세션과 비대화형 실행이 서로 다르게 진행되는 과정](https://www.aifreeapi.com/posts/ko/claude-code-auto-mode-vs-bypass-permissions/img/runtime-denials.webp)

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

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