클로드 코드 자동 승인, 권한 모드 6개 안전한 선택법

3줄 요약

• 클로드 코드 권한 모드 6개(default, acceptEdits, plan, auto, dontAsk, bypassPermissions)의 자동 승인 범위를 정리했다(2026년 9월 11일 공식 문서 대조).
• Pro·Max·Team은 auto가 내장 시작 모드라 Pro도 자동 승인을 쓸 수 있다. 예전 v2.1.83 시절 Pro 미지원 얘기는 지금과 다르다.
• bypassPermissions는 모든 권한 검사를 건너뛰므로 격리된 환경이 아니면 권하지 않는다.

클로드 코드 자동 승인을 아무 생각 없이 켜면 편하긴 한데, 그만큼 위험도 같이 켜진다. 이 블로그 자동화의 권한 경계를 다시 설계하면서 공식 문서의 모드 6개와 auto의 classifier 방식을 대조했다. 서버 변경과 로컬 편집을 같은 승인 범위로 묶으면 안 된다는 점이 핵심이었다.

클로드 코드 자동 승인은 모드 하나를 고르는 문제가 아니라, 작업 위험도에 맞춰 권한 경계를 나누는 문제다.

클로드 코드 권한 모드 6개, 뭐가 다를까

클로드 코드 권한 모드는 default, acceptEdits, plan, auto, dontAsk, bypassPermissions 6개이며, 승인을 묻는 범위가 단계별로 넓어진다. 자세한 기준은 공식 문서에서 확인할 수 있다(2026년 9월 11일 확인).

모드	자동 승인 범위	적합한 상황
default	읽기만, 편집·실행·외부 요청 전에 묻는다	처음 쓰는 저장소, 낯선 코드베이스
acceptEdits	읽기·파일 편집·기본 파일 명령(mkdir·mv·cp 등)	신뢰하는 저장소의 반복 편집
plan	읽기 중심, 실행 전 계획부터 세운다	설계 검토, 영향 범위 점검
auto	전부, classifier가 백그라운드에서 검토	장시간 작업, 프롬프트 피로 줄이기
dontAsk	사전 승인한 도구만	잠긴 CI·스크립트
bypassPermissions	모든 권한 검사를 건너뛴다	격리된 컨테이너·VM, 일반 환경엔 비권장

CLI에서 Shift+Tab을 누르면 default → acceptEdits → plan 순으로 순환하고, auto는 지원될 때 나타난다. dontAsk는 순환에 없고 플래그로만 지정한다.

기본 모드와 acceptEdits, 자동 승인 범위 차이는 무엇일까

기본(default) 모드는 읽기를 제외한 편집·실행·외부 요청 전에 묻지만, acceptEdits는 파일 편집과 mkdir·mv·cp 같은 기본 파일 명령까지 자동 승인하고 나머지는 그대로 남긴다. acceptEdits로 넘어가기 전에 클로드 코드 시작 가이드에서 기본 흐름부터 확인해두면 좋다.

그럼 acceptEdits만 켜두면 안전할까? 아니다. 파일 삭제 중 중요 경로나 명령 실행, 외부 요청은 여전히 승인이 필요하다.

반복 편집이 많은 저장소에서는 acceptEdits가 현실적인 절충이었다. 나는 신뢰하는 저장소라면 acceptEdits를 먼저 켜보라고 권하고 싶다.

Plan 모드는 언제 써야 할까

Plan 모드는 읽기·분석 중심으로 동작해, 코드를 바꾸기 전 설계와 영향 범위부터 점검할 때 적합하다. 계획 단계에서는 classifier가 셸 명령을 대신 검토하고, 승인된 것만 실행된다.

실제로 이 블로그의 배치 작업을 짤 때도 블로그 자동화 사례처럼 plan으로 구조부터 확인한 뒤 실행 모드로 넘어갔다. 나는 새 저장소를 처음 열면 plan부터 켜보라고 말하고 싶다.

Auto mode 자동 승인, 지원 조건과 한계

Auto mode는 별도 classifier 모델이 요청을 대신 검토하는 방식으로, Pro·Max·Team 플랜에서는 내장 시작 모드다(공식 문서, 2026-09-11 확인). 예전 research preview 시절의 Pro 미지원 얘기는 지금과 다르다. 다만 모델·버전 조건(지원 모델 필요)과 조직의 disableAutoMode 설정에 따라 바뀔 수 있다.

그럼 Auto를 켜두면 위험한 명령도 그냥 통과될까? 아니다. classifier가 요청 범위를 벗어나거나 위험한 작업을 막고, 명시한 ask 규칙은 Auto에서도 그대로 묻는다. 판단 기준을 세밀하게 뜯어본 적은 없어서, 어느 명령까지 자동 통과되는지는 직접 확인하지 않았다.

권한 판단이 넓어지는 기능은 클로드 코드 스킬 활용법과 함께 보면 전체 그림이 잡힌다.

권한 요청이 계속 뜰 때 allow·ask·deny 진단 순서

더 구체적인 allow 규칙을 추가해도 권한 창이 계속 뜬다면, 규칙의 길이보다 deny → ask → allow 순서를 먼저 확인해야 한다. 세 종류가 모두 같은 도구 호출에 맞으면 deny가 먼저 막고, deny가 없으면 ask가 묻는다. 구체적인 allow도 더 넓은 ask나 deny를 뒤집지 못한다.

예를 들어 아래 설정에서는 git status를 정확히 allow했지만 Bash(git *) ask에도 함께 맞는다.

{
  "permissions": {
    "allow": ["Bash(git status)", "Bash(git log *)"],
    "ask": ["Bash(git *)"],
    "deny": ["Bash(git push *)"]
  }
}

결과는 다음처럼 읽으면 된다.

요청	함께 맞는 규칙	최종 결과
git status	정확한 allow, 넓은 ask	ask: 계속 확인한다
git log -1	allow, 넓은 ask	ask: 계속 확인한다
git push origin main	넓은 ask, deny	deny: 실행하지 않는다

이 결과는 Claude Code 2.1.268에서 로그인 세션을 실행해 캡처한 값이 아니다. Anthropic 공식 문서의 우선순위를 같은 JSON에 적용한 독립 로컬 예제다. 실제 계정과 조직 정책에 적용된 규칙은 아래 순서로 확인해야 한다.

1. /permissions에서 규칙 출처부터 찾기

Claude Code에서 /permissions를 열면 현재 규칙과 규칙이 들어온 설정 파일을 함께 볼 수 있다. 반복되는 요청과 같은 도구 이름을 찾아 다음 위치 중 어디에서 왔는지 확인한다.

• 모든 프로젝트에 적용하는 사용자 설정: ~/.claude/settings.json
• 저장소와 공유하는 프로젝트 설정: .claude/settings.json
• 내 컴퓨터의 해당 저장소에만 적용하는 로컬 설정: .claude/settings.local.json
• 조직 관리 설정: 사용자가 프로젝트 allow로 덮어쓸 수 없는 정책일 수 있다

“계속 묻지 않기”로 저장한 Bash나 WebFetch 규칙은 현재 버전에서 보통 저장소 루트의 .claude/settings.local.json에 들어간다. 예전 버전에서 하위 폴더에 저장한 규칙이나 Windows 등 공식 문서가 밝힌 예외가 있으므로, 파일을 추측해서 지우기보다 /permissions에 표시된 출처를 먼저 본다.

2. allow를 더하지 말고 넓은 ask를 좁히기

위 예제의 git status를 묻지 않게 하려면 같은 allow를 하나 더 넣어도 달라지지 않는다. 실제 목적이 “push는 막고 상태 확인과 로그는 묻지 않기”라면 Bash(git *) 같은 넓은 ask를 제거하거나, 정말 확인이 필요한 하위 명령만 ask로 좁혀야 한다. Bash(git push *) deny는 그대로 두면 된다.

조직 관리 설정이나 사용자 설정에 deny가 있다면 프로젝트 설정의 allow로 예외를 만들 수 없다. 이 경우에는 정책 소유자에게 규칙 변경을 요청하거나, 막힌 작업을 승인 범위 안의 다른 절차로 바꿔야 한다.

3. 한 규칙만 바꾸고 다음 호출로 확인하기

1. /permissions에서 문제 규칙과 출처 파일을 적는다.
2. 해당 JSON 파일을 복사해 백업한다.
3. 가장 넓게 겹치는 ask 또는 deny 한 줄만 수정한다.
4. 같은 세션의 다음 도구 호출에서 결과를 확인한다. 현재 공식 문서상 /permissions에서 바꾼 규칙은 다음 도구 호출부터 적용된다.
5. 예상보다 범위가 넓어졌다면 백업한 설정으로 되돌린다.

CLAUDE.md에 “묻지 말고 실행해”라고 써도 권한 규칙은 바뀌지 않는다. 프롬프트는 Claude가 무엇을 시도할지에 영향을 주지만, 실제 허용과 차단은 Claude Code의 권한 규칙이 결정한다.

공식 근거: Claude Code Permissions (2026년 9월 18일 확인)

bypassPermissions는 왜 위험할까

bypassPermissions는 파일 삭제나 외부 요청을 포함한 모든 권한 검사를 건너뛰므로, 격리된 환경이 아니면 권하지 않는다. 일반 로컬 환경이나 회사 저장소에서 켜두면 실수 하나가 그대로 실행된다.

그럼 언제는 써도 될까? CI 샌드박스나 컨테이너처럼, 문제가 생겨도 통째로 되돌릴 수 있는 환경 정도로 좁혀 생각하면 된다.

흔한 오해: Auto mode 켜면 다 알아서 해준다

“Auto mode 켜두면 위험한 명령도 다 자동으로 넘어가는 거 아니야?”라고 생각하기 쉽다. 빠르게 이름만 보면 그렇게 느껴질 수 있다.

공식 문서에 따르면 Auto는 classifier가 매 작업마다 검토하는 방식이라 무조건 통과가 아니다. 게다가 Pro를 포함한 전 플랜이 대상이지만(2026-09-11 확인), 모델·버전 조건과 조직 설정에 따라 켜지지 않을 수 있다.

자주 하는 질문

acceptEdits와 Auto mode, 뭐가 더 안전한가?

acceptEdits는 파일 편집과 기본 파일 명령만 자동 승인하고 다른 요청은 남긴다. Auto mode는 범위가 더 넓지만 classifier가 위험한 작업을 막고, ask 규칙은 그대로 묻는다. 둘 다 무제한 자동 승인은 아니다.

bypassPermissions는 언제 써도 괜찮은가?

격리된 컨테이너·VM처럼, 문제가 생겨도 통째로 되돌릴 수 있는 환경 정도다. 일반 로컬 개발 환경이나 회사 저장소에서는 권하지 않는다.

Pro 요금제에서도 Auto mode를 쓸 수 있나?

쓸 수 있다. Pro·Max·Team 플랜에서는 auto가 내장 시작 모드다(공식 문서, 2026-09-11 확인). 다만 지원 모델·버전 조건을 충족하지 않는 세션이나 조직에서 꺼둔 경우, auto는 Manual로 떨어진다.

dontAsk 모드는 뭐가 다른가?

dontAsk는 사전 승인한 도구만 쓰는 잠금 모드로, CI·스크립트처럼 정확히 정해진 일만 돌릴 때 쓴다. Shift+Tab 순환에 없고 플래그로만 지정한다.

정리

• default 읽기 외에는 물어, 처음 쓰는 저장소에 안전하다.
• acceptEdits 파일 편집·기본 파일 명령까지 자동 승인, 반복 편집에 현실적이다.
• plan 읽기 중심 계획부터, classifier가 계획 중 명령을 검토한다.
• auto classifier가 대신 검토, Pro·Max·Team 내장 시작 모드다.
• dontAsk 승인 목록만, CI·스크립트용이다.
• bypassPermissions 모든 검사를 건너뛰어, 격리된 환경이 아니면 권하지 않는다.

지금 쓰는 저장소에서 권한 모드가 무엇으로 설정돼 있는지 한 번 확인해보면 좋다. 실제로 Auto mode나 acceptEdits를 써본 경험이 있다면 댓글로 알려주면 좋겠다.

검증 기준

• 마지막 업데이트일: 2026-09-11
• 확인 환경: 공식 권한 모드 문서를 직접 열어 6개 모드와 auto 조건을 대조한 문서 기준 정리. 구버전(v2.1.83 research preview) 서술은 현행 문서로 정정했다.
• 주요 근거: Claude Code 권한 모드 문서 · Claude Code 인증 문서