Claude Code의 6가지 권한 모드 차이점 (auto는 무엇을 막고 무엇을 통과시킬까? dontAsk 사용처)

Claude Code를 사용하다 보면, 권한 확인(permission confirmation) 처리 방식 때문에 혼란스러울 때가 있습니다.

• 확인 요청이 너무 많아서 작업할 때마다 손이 멈춘다.
• auto로 설정하면 편할 것 같지만, 무엇을 막아주고 무엇은 막지 않는지 모르겠다.
• bypassPermissions는 무섭다. dontAsk라는 모드도 있는 것 같은데 Shift+Tab으로는 나오지 않는다.

Claude Code에는 권한 확인 요청 수준을 결정하는 '권한 모드(permission mode)'가 6가지 있습니다. 본문에서는 이 6가지 모드의 차이점과 전환 방법, auto가 막는 것/통과시키는 것, 규칙과의 관계, 그리고 상황별 선택 방법을 공식 문서를 기반으로 소개합니다. 마지막으로는 실제로 작동시켜 확인해본 결과도 함께 담았습니다.

권한 모드가 결정하는 것

Claude(모델)는 파일 읽기/쓰기, 명령어 실행, 네트워크 접근과 같은 작업을 '도구(tool)'를 통해 수행합니다. Claude Code는 Claude가 도구를 사용하려고 할 때마다 사람에게 물어보지 않고 사용해도 되는지를 결정합니다.

본문에서는 Claude Code의 답변 방식을 다음 세 가지 용어로 구분하여 부릅니다.

• 확인: 사람에게 '사용해도 되는지'를 묻는다.
• 거부(Deny): 사람에게 묻지 않고, 사용하지 못하게 한다.
• 차단(Stop): auto 모드에서 분류기(classifier, 나중에 설명)가 사용하지 못하게 막는다.

권한 모드는 이 '사람에게 묻지 않고 사용할 수 있는 범위'의 기본을 결정하는 설정입니다. 그 위에, 설정 파일에 작성하는 규칙(allow・ask・deny)을 덧대어 도구별로 세밀하게 결정합니다.

6가지 모드

공식 문서의 표를 기반으로, 확인 요청 없이 작동하는 것들을 정리했습니다. 분류기는 auto에서 사용되는, 사람 대신 조작을 확인하는 별도의 모델입니다.

현재 모드 확인 및 전환 방법

현재 모드 보기

대화 화면에서는 입력창 아래에 현재 모드가 표시됩니다 (예: ⏸ manual mode on 등).

• ⏵⏵ accept edits on
• ⏸ plan mode on
• ⏵⏵ auto mode on
• ⏵⏵ don't ask on
• ⏵⏵ bypass permissions on

아무것도 결정하지 않은 상태에서 시작하는 모드는 사용 방식에 따라 다릅니다.

2.1.283 버전 이상에서는 터미널에서 아무것도 결정하지 않고 시작하면 auto 모드입니다. '확인 요청이 거의 나오지 않는다'고 느낀다면, auto로 작동하고 있을 수 있습니다. auto를 사용할 수 없는 경우는 대응하지 않는 모델을 사용하거나, 조직 설정에서 auto 기능을 꺼둔 경우 등입니다.

Shift+Tab으로 전환하기

대화 화면에서는 Shift+Tab 키로 모드를 전환합니다.

auto가 사용 불가하고 bypassPermissions도 허용되지 않은 상태라면, plan 다음에는 default로 돌아갑니다.

모든 모드가 이 순서대로 나타나는 것은 아닙니다.

• auto: auto를 사용할 수 있을 때만 나타납니다.
• bypassPermissions: 시작할 때 --permission-mode bypassPermissions 또는 --dangerously-skip-permissions를 붙였을 때만 나타납니다. 만약 --allow-dangerously-skip-permissions를 붙이면, bypassPermissions로 진입하지 않고 순서상으로 추가될 뿐입니다. 허용 없이 시작한 세션에서 도중에 bypassPermissions로 들어갈 수는 없습니다.
• dontAsk: 나오지 않습니다.
  --permission-mode dontAsk 또는 설정 파일로 결정합니다.

dontAsk가 공식 문서에 언급되지 않은 이유는 명시되어 있지 않습니다. dontAsk는 사람이 화면 앞에 없는 환경(예: CI)에서 사용하기 위한 모드입니다. 화면 앞에서 중간에 전환하더라도 확인이 필요한 작업은 묻지 않고 거부되기만 하므로, 순서상 포함하지 않았다고 생각합니다 (자리 비움 모드 기사에서도 언급했습니다).

시작할 때와 기본 설정으로 지정할 때

시작할 때는 --permission-mode로 결정합니다.

claude --permission-mode plan

매번 같은 모드로 시작하고 싶을 때는 설정 파일의 permissions.defaultMode에 작성합니다.

{
"permissions": {
"defaultMode": "acceptEdits"
...
}

다만, 프로젝트의 .claude/settings.json과 .claude/settings.local.json에 작성된 auto와 bypassPermissions는 적용되지 않습니다. auto나 bypassPermissions를 기본값으로 하고 싶을 때는 자신의 ~/.claude/settings.json에 작성해야 합니다.

auto: 분류기(Classifier)가 사람 대신 확인

auto 모드에서는 분류기가 사람이 대신하여 작업을 확인합니다. 판단 흐름을 간단히 설명하면 다음과 같습니다.

기본적으로 차단되는 것

분류기는 요청된 범위를 초과하는 작업, 신뢰할 수 있는 대상으로 등록하지 않은 외부 환경(운영 서버나 클라우드 등)에 접근하는 작업, 파일이나 웹 페이지에 심어진 지시(프롬프트 인젝션)를 따르는 것으로 보이는 작업을 차단합니다. 기본적으로 차단되는 것의 예시는 다음과 같습니다 (공식 문서에는 더 많이 나열되어 있습니다).

• curl | bash와 같이 다운로드하여 그대로 실행하는 작업 - 기밀 데이터를 외부로 전송하는 작업
• 운영 환경(Production)에 대한 배포나 마이그레이션
• 강제 푸시(Force Push)
• git reset --hard
  ・커밋하지 않은 변경 사항을 버리는 작업 -
  git clean -fd와 같은 작업 -
  terraform destroy와 같이 리소스를 파괴하는 작업 - 사람이 승인하지 않은 PR의 병합(Merge)
• 토큰이나 인증 정보를 대화 기록이나 파일에 작성하는 작업

기본적으로 통과되는 것

반면에 다음과 같은 것은 기본적으로 확인 없이 통과됩니다.

• 작업 폴더 내의 파일 조작
• lock 파일 등에 쓰여진 의존성 설치
• 읽기 전용(Read-only) HTTP 요청
• .env 파일을 읽어 해당 API에 인증 정보를 보내는 것 - 작업 중인 리포지토리의 어떤 브랜치로의 push (기본 브랜치를 포함)

main으로의 push 역시 auto 모드에서는 기본적으로 확인 없이 통과됩니다. 만약 push 전에 반드시 자신이 보고 싶다면, Bash(git push *)를 ask 규칙에 작성해 두어야 합니다 (다음 절 참조). 대화 중에 "push 하지 마세요"라고 전달해도 분류기는 이를 지키지만, 대화가 압축되어 해당 발언이 사라지면 효과가 없을 수 있습니다. 확실하게 하고 싶은 것은 규칙에 작성하는 것이 좋습니다.

차단되었을 때

차단된 작업은 그 이유와 함께 Claude에게 반환됩니다. 차단된 작업은 /permissions의 'Recently denied' 탭에 나열되며, r 명령어로 직접 허가하여 재실행할 수 있습니다.

분류기가 연속으로 차단하면(3회 연속 또는 총 20회), auto는 일시 정지하고 허가 확인을 요청합니다. 확인에 응답하여 허가하면 auto 모드로 돌아갑니다.

공식 문서에는 auto에 대해 "확인을 줄여주지만, 안전성을 보장하는 것은 아니다"라고 명시되어 있습니다. 따라서 방향성을 신뢰할 수 있는 작업에 사용하고, 중요한 작업의 확인을 대체하는 용도로는 사용하지 않는 것이 좋습니다.

dontAsk와 bypassPermissions

dontAsk: 결정한 것만 허용하기

dontAsk는 확인이 필요한 작업을 사람에게 묻지 않고 현장에서 모두 거부합니다. 작동하는 것은 작업 폴더 내의 읽기(Read) 작업, 읽기 전용 명령어, allow 규칙이나 후크(도구를 사용하기 전에 실행되는 자체 스크립트)로 미리 허가된 것들뿐입니다. ask 규칙에 해당되는 것도 확인 없이 거부됩니다.

CI 환경에서, 무엇을 허용할지 결정하고 작동시키는 용도가 적합합니다. --allowedTools는 그 회차만의 allow 규칙을 전달하는 옵션입니다.

claude -p "테스트를 실행" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

bypassPermissions: 격리된 환경 내에서만 사용 가능

bypassPermissions는 허가 확인 및 안전 점검을 거의 모두 건너뜁니다. 보호된 경로에 대한 쓰기 작업도 통과시킵니다. 그럼에도 불구하고, deny 규칙, ask 규칙, 그리고 중요한 경로를 삭제하는 rm (나중에 설명)은 작동합니다.

공식 문서는 인터넷에 연결되지 않은 컨테이너나 VM 내부에서만 사용하도록 경고하고 있습니다. Linux와 macOS에서는 root 또는 sudo로 실행할 경우 다음과 같이 거부됩니다(개인 장치의 컨테이너에서도 root 권한으로는 거부되었습니다).

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

공식 문서는 root가 아닌 사용자로 작동하는 dev container를 권장합니다.

규칙(allow・ask・deny)과의 관계

모드 위에 도구별 규칙을 덧씌울 수 있습니다. allow는 질문 없이 허용하고, ask는 매번 반드시 질문하며, deny는 사용하지 못하게 하는 규칙입니다.

{
"permissions": {
"allow": ["Bash(npm test)"],
...
}

규칙은 deny → ask → allow 순서로 확인하며, 가장 먼저 일치하는 것이 결정됩니다. allow가 더 세밀하게 작성되어 있더라도, deny나 ask에 해당하면 그것이 우선합니다. 어떤 규칙에도 해당하지 않으면, 권한 모드가 결정합니다.

모드와의 조합은 다음과 같습니다:

규칙은, 명령어 작성 방식에 대입할 뿐

Bash 규칙은 Claude가 작성한 명령어 문자열에 대입하여 판정합니다. 같은 프로그램이라도 작성 방식이 다르면 일치하지 않습니다.

규칙은 확인 방식을 결정하는 도구일 뿐, 프로그램 자체를 막는 벽은 아닙니다. 공식 문서에서도 파일이나 네트워크를 확실하게 보호하고 싶을 때는 명령어 작성 방식에 의존하지 않는 샌드박스를 사용할 것을 권장합니다.

어떤 모드에서도 자동으로 허용되지 않는 것

모드에 관계없이 Claude Code가 자동으로 허용하지 않는 작업이 있습니다. 어떤 모드에서도 확인을 요청하거나 거부하는 둘 중 하나입니다.

• ask 규칙에 해당되는 작업
• 중요한 경로를 삭제하는 rm

・rmdir

: 중요한 경로는 루트(/)나 /usr와 같은 최상위 폴더, 홈 디렉터리, 작업 폴더 및 그 부모 등을 의미합니다. rm -rf ~ 또는 작업 폴더 전체를 삭제하는 작업이 해당됩니다. allow 규칙이나 훅(hook)으로는 허용할 수 없습니다.

중요한 경로를 삭제하는 rm은 default, acceptEdits, bypassPermissions 모드에서는 확인을 요청합니다. auto 모드에서는 터미널에서 2분 시간 제한이 있는 확인 메시지가 나타나고, 응답하지 않으면 거부됩니다(VS Code 또는 데스크톱 앱, claude -p에서는 거부됩니다). dontAsk 모드에서는 거부됩니다. bypassPermissions에서 이 확인을 요청하지 않으려면, 시작 시 환경 변수 CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1를 사용합니다(Claude Code 2.1.311 이상. 설정 파일의 env에 작성해도 작동하지 않습니다).

모드별 처리 방식 변화: 보호된 경로

중요한 경로와 별개로 '보호된 경로(Protected Paths)'가 있습니다. 중요한 경로가 '삭제'하는 것을 보호한다면, 보호된 경로는 '쓰기(Write)'를 보호합니다. 이 경로는 리포지토리의 상태나 Claude 및 도구의 설정을 손상시킬 수 있는 곳입니다.

• 폴더:
  .git

・.claude

・.vscode

・.idea

・.husky

・.devcontainer

등

• 파일:
  .gitconfig

・.bashrc

・.zshrc

・.npmrc

・.mcp.json

등

직접 테스트하며 확인한 내용

지금까지의 설명에 대한 검증으로, 4가지 모드에서 동일한 6가지 작업을 수행했습니다. Claude Code는 실제 환경을 사용하고, 모델 부분만 지정된 도구를 한 번 호출하는 목(Mock)으로 대체했습니다 (목 제작 방법은 이전 기사에서 소개했습니다).

claude -p
를 stream-json으로 실행하여, --permission-prompt-tool stdio로 확인 절차를 받을 수 있도록 했습니다 (stream-json 기사 참고). 표의 '확인'은 확인 절차가 도착했음을 의미합니다. 확인을 받을 수 없는 claude -p에서는, 확인이 필요해야 하는 작업은 거부됩니다.

| 작업 | default | acceptEdits | dontAsk | bypassPermissions |
|---|---|
| 작업 폴더에 파일 쓰기(Write) | 확인 절차 | 확인 절차 없음 | 거부 | 확인 절차 없음 |
mkdir newdir |
확인 절차 | 확인 절차 없음 | 거부 | 확인 절차 없음 |
git status | 확인 절차 없음 | 확인 절차 없음 | 확인 절차 없음 | 확인 절차 없음 |
node -e "console.log(1)" | 확인 절차 | 확인 절차 | 거부 | 확인 절차 없음 |
.git 안에 파일 쓰기 | 확인 절차 | 확인 절차 | 거부 | 확인 절차 없음 |
git push origin main (ask 규칙에 해당) | 확인 절차 | 확인 절차 | 거부 | 확인 절차 |

git status는 읽기 전용 명령어이므로, 어떤 모드에서도 확인 절차 없이 실행됩니다. acceptEdits에서 확인 절차가 없어지는 것은 파일 쓰기와 파일 조작 명령에 한정된 것입니다.
node와 같은 다른 명령어는 확인 절차가 발생합니다.
.git은 보호된 경로이므로, acceptEdits에서도 확인 절차가 발생합니다. ask 규칙(
Bash(git push *)를 ask로 수정한 경우)은 bypassPermissions에서도 확인 절차가 발생합니다. dontAsk는 읽기 전용인 것을 제외한 모든 것을 거부했습니다. 거부된 도구의 결과에는 "Permission to use Bash has been denied because Claude Code is running in don't ask mode."라고 반환됩니다.

auto와 plan은 판정에 모델(분류기)을 사용하기 때문에, 목으로는 확인할 수 없었습니다. 이 2가지는 공식 문서를 기반으로 작성되었습니다.

어떤 것을 선택할까

보너스: tanacode에서의 권한 모드

저는 'Claude Code의 내부를 볼 수 있다. 할 수 있는 일이 늘어난다.'라는 슬로건을 가진 macOS 앱 'tanacode'를 개인적으로 제작하고 있습니다 (Anthropic 공식 제품은 아닙니다). Claude Code를 앱 내에서 실행하여 여러 세션을 목록으로 나열하고, 채팅 화면에서 다룰 수 있게 만든 앱입니다.

tanacode에서는 하나의 세션의 Claude(부모)가 다른 세션(자식)을 실행하여 작업을 맡길 수 있습니다(부모-자식 세션 기사 참조). 이때 자식의 권한 모드는 부모보다 강하게 설정할 수 없도록 제한합니다(plan・default ＜ acceptEdits ＜ auto ＜ bypassPermissions). 이는 자식이 부모가 허용한 범위를 초과하지 못하도록 하기 위함입니다.

또한, 자리를 비운 사이에 승인 확인 단계에서 멈춰버리는 문제에는 '자리 비움 모드(Away Mode)'로 대응하고 있습니다. 권한 모드는 그대로 유지하면서, 답이 없는 확인 요청을 일정 시간 후에 거절하고 Claude를 계속 진행시키는 기능입니다. auto에서도 ask 규칙 확인 시 사람을 기다리는 등, 권한 모드만으로는 부족한 부분까지 포함하여 자리 비움 모드 기사에서 소개하고 있습니다.

맺음말

권한 모드에서 확인을 어느 정도까지 생략할지 기본을 정하고, 규칙으로 세부적인 추가와 삭제를 합니다. 우선 현재 모드를 화면 하단에서 확인하고, 반드시 확인하고 싶은 작업을 ask 규칙에 작성하는 것부터 시작해 보세요.

tanashun

toB SaaS 개발 부장입니다. 개발 조직 관리와 생성 AI를 개발에 통합하는 시스템 구축을 담당하고 있습니다. 개인적으로는 Claude Code의 내부가 보이는 macOS 앱 tanacode를 만들고 있습니다.

Claude Code 도입 지원, AI를 통합한 개발 및 웹 앱 개발, 기술 컨설팅 등의 업무를 수행하고 있습니다. 의뢰나 상담은 여기로 연락 주십시오.

토론 (Discussion)