클로드 코드 권한 설정 allow·ask·deny: 규칙 적는 형식과 덜 묻게 하는 방법

이 글 순서

1. 권한을 정하는 두 가지
2. 권한 모드 여섯 가지
3. 권한 확인 창에서 고르는 것
4. 규칙 적는 형식
5. Bash 규칙의 별표
6. Bash 규칙의 한계
7. 파일 경로 적는 형식
8. 겹치면 deny가 먼저
9. 설정 파일 네 곳
10. 여러 파일에 적으면
11. /permissions 화면
12. 덜 묻게 하는 방법
13. 건너뛰기 모드 주의
14. 윈도우에서 다른 점
15. 코덱스·제미나이 CLI는
16. 한국에서 되나
17. 누구에게 맞나
18. 다시 확인할 날짜
19. 참고한 자료

클로드 코드를 쓰다 보면 “이 명령을 돌려도 될까요”라는 창을 하루에도 여러 번 만나요. 반대로 건드리면 안 되는 파일을 Claude가 읽으려 해서 놀랄 때도 있죠. 둘 다 권한 설정에서 정해요. 무엇은 묻지 않고, 무엇은 꼭 묻고, 무엇은 아예 못 하게 할지를 규칙으로 적어 두는 곳이에요.

이 글은 클로드 코드 문서 “Configure permissions”(permissions), “Choose a permission mode”(permission-modes), “Settings files and precedence”(settings), 샌드박스 문서를 2026년 10월 8일에 읽고 옮긴 거예요. 모드 이름과 규칙, 명령은 문서의 영어 그대로 두었고, 문서에 없는 것은 “공식 안내 없음”으로 적었어요. 훅으로 막는 것과 권한 규칙으로 막는 것을 비교한 얘기는 클로드 코드 훅(hooks) 글의 “꼭 지켜야 하면 무엇” 절에 있어서 여기서는 반복하지 않아요.

권한을 정하는 두 가지

클로드 코드에서 “물을지 말지”를 정하는 것은 둘이에요. 하나는 권한 모드(permission mode)로, 세션 전체의 기본값을 정해요. 다른 하나는 권한 규칙(permission rule)으로, 도구 하나하나를 미리 허락하거나 막아요. 문서는 모드가 기본값을 깔고 그 위에 규칙을 얹는다고 적었어요.

문서가 Note 상자로 따로 적은 문장이 하나 있어요. 권한 규칙은 모델이 아니라 Claude Code가 지키게 한다는 거예요. 프롬프트나 CLAUDE.md에 적은 말은 Claude가 무엇을 하려 드는지를 바꿀 뿐, Claude Code가 무엇을 허락하는지는 바꾸지 않아요.

권한 모드 여섯 가지

10월 8일 문서의 표에는 모드가 여섯 가지예요. 이름은 설정에 적는 값 그대로 옮겼어요.

모드	묻지 않고 하는 것	문서가 든 용도
default (화면에는 Manual)	읽기만	하나하나 직접 볼 때
acceptEdits	읽기, 파일 고치기, mkdir·mv·cp 같은 명령	고친 것을 나중에 볼 때
plan	읽기(고치지는 않음), auto를 쓸 수 있는 세션이면 분류 모델이 허락한 명령도	바꾸기 전에 둘러볼 때
auto	전부, 분류 모델이 뒤에서 살핌	긴 작업
dontAsk	읽기와 미리 허락한 도구, 나머지는 거절	CI와 스크립트
bypassPermissions	전부	격리된 컨테이너·VM에서만

출처: 클로드 코드 문서 “Choose a permission mode”의 “Available modes” 표. 10월 8일 확인.

• 하나하나 묻는 모드는 화면과 claude --help에 Manual로 나와요. 설정 값은 default이고, manual이라고 적어도 받아요.
• 세션 도중에는 터미널에서 Shift+Tab으로 바꿔요. 문서가 적은 차례는 default, acceptEdits, plan이고, 쓸 수 있으면 그 뒤에 auto가 붙어요. dontAsk는 이 차례에 나오지 않아요. 문서의 예시는 --permission-mode dontAsk로 켜요.
• VS Code 확장은 입력 칸 아래 모드 표시를 눌러요. 라벨은 Manual, Edit automatically, Plan, Auto, Bypass permissions예요.
• 시작할 때의 모드는 claude --permission-mode plan처럼 인자로 주거나 settings.json의 permissions.defaultMode에 적어요.
• 표의 plan 줄에는 문서가 붙인 예외가 하나 있어요. 건너뛰기 모드(bypassPermissions)를 고를 수 있게 띄운 터미널 세션에서는 Claude Code가 plan 모드의 막기를 지키지 않는다고 적혀 있어요. 문서 문장은 “In interactive terminal sessions with bypass permissions available, Claude Code also doesn’t enforce plan mode’s blocks”예요. 셸 명령이 갈리는 세 가지는 클로드 코드 plan 모드 글에 있어요.

처음 켰을 때 어떤 모드로 시작하는지는 버전에 따라 달라요. 문서에 적힌 기준 버전은 둘이에요. v2.1.228(macOS·리눅스·WSL, 윈도우 그대로는 v2.1.233)부터 Pro·Max·Team 요금제에서 기본 시작 모드가 auto가 됐고, v2.1.283부터는 요금제를 가리지 않고 터미널과 VS Code 세션이 auto로 시작해요. 그보다 낮은 버전은 Manual로 시작해요. 그래서 “매번 묻는다”는 사람과 “거의 안 묻는다”는 사람이 같이 있을 수 있어요. 내 버전은 claude --version으로, 지금 모드는 입력 칸 아래 상태 줄에서 봐요.

권한 확인 창에서 고르는 것

Manual 모드에서 Claude가 셸 명령을 돌리려 하면 창이 떠요. 문서에 실린 예시의 선택지는 Yes, “Yes, and don’t ask again for: npm test *”, “Yes, and switch to auto mode”, No 네 가지예요. 세 번째는 auto 모드를 쓸 수 있을 때만 나와요.

도구	Manual에서 묻나	don’t ask again을 고르면
읽기(파일 읽기, Grep)	작업 폴더 안은 확인 안 함	해당 없음
셸 명령(Bash)	확인 요청(읽기 전용 명령은 빼고)	저장소·명령마다 계속 남음
파일 고치기	확인 요청	세션이 끝날 때까지만
WebFetch	확인 요청(미리 허락된 문서 도메인은 빼고)	저장소·도메인마다 계속 남음

출처: 클로드 코드 문서 “Configure permissions”의 “Permission system” 표. 10월 8일 확인.

• 계속 남는 허락은 저장소 맨 위의 .claude/settings.local.json에 allow 규칙으로 적혀요. 하위 폴더나 워크트리에서 연 세션에도 걸려요. v2.1.211보다 앞선 버전은 시작한 폴더에 적었다고 해요. 윈도우는 예외라서 저장소 맨 위가 아니라 .claude/settings.json이 있는 자리에 둔다고 적혀 있어요.
• ls, cat, grep, pwd, 읽기만 하는 git 같은 명령은 문서가 읽기 전용으로 쳐서 어느 모드에서도 묻지 않아요. 이 목록은 바꿀 수 없고, 묻게 하려면 그 명령에 ask나 deny 규칙을 적으라고 해요.
• Yes나 No에 놓고 Tab을 누르면 Claude에게 한마디 붙일 수 있어요. No에 붙인 말은 거절한 이유로 전해져요.
• 한 번만 허락하는 선택지만 뜨는 창도 있어요. 그럴 때는 한 번 허락하거나 /permissions에서 규칙을 직접 더하라고 적혀 있어요.

규칙 적는 형식

규칙은 Tool 또는 Tool(specifier) 형식이에요. 도구 이름만 적으면 그 도구 전부, 괄호 안에 조건을 적으면 그 조건에 맞는 호출만 걸려요.

규칙	걸리는 것
Bash	모든 Bash 명령(Bash(*)와 같음)
Bash(npm run build)	글자가 똑같은 그 명령 하나
Bash(npm run *)	npm run으로 시작하는 명령
Read(./.env)	지금 폴더의 .env 읽기
WebFetch(domain:example.com)	example.com으로 가는 요청
mcp__puppeteer	puppeteer MCP 서버의 모든 도구
Agent(Explore)	Explore 서브에이전트

출처: 클로드 코드 문서 “Configure permissions”의 “Permission rule syntax”·”Tool-specific permission rules”. 10월 8일 확인.

아래는 문서 “Wildcard patterns”에 실린 예시 그대로예요. npm 스크립트와 git commit은 묻지 않고 돌리고, git push로 시작하는 명령은 막아요.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

문서는 이 예시 바로 옆에 한계를 같이 적었어요. git -C . push처럼 다르게 쓴 push는 이 deny에 걸리지 않는다는 거예요. 이유는 아래 “Bash 규칙의 한계” 절에 있어요.

Bash 규칙의 별표

Bash 규칙의 *는 띄어쓰기까지 넣어 아무 글자에나 맞아요. 별표가 없는 규칙은 글자가 똑같은 명령 하나에만 맞고요. 문서가 든 세 가지를 옮기면 이래요.

• 별표는 서브커맨드 뒤에 둬요. Bash(git log *)는 git log만 허락하지만 Bash(git *)는 git의 모든 명령을 허락해요. Bash(git * main)처럼 서브커맨드 자리에 별표를 둔 allow 규칙은 시작할 때 경고가 뜬다고 적혀 있어요.
• 끝의 별표 앞 띄어쓰기도 규칙의 일부예요. Bash(ls *)는 lsof에 안 맞고, Bash(ls*)는 맞아요.
• 띄어쓰기 뒤에 별표 하나로 끝나는 규칙은 별표 없는 명령에도 맞아요. Bash(ls *)는 그냥 ls에도 걸려요.
• Bash(ls:*)처럼 끝에 :*를 적는 형식은 Bash(ls *)와 같아요. 권한 확인 창이 저장해 주는 것은 띄어쓰기 형식이에요.
• &&, ||, ;, |로 이은 명령은 조각마다 따로 맞춰 봐요. Bash(safe-cmd *)를 허락했다고 safe-cmd && other-cmd가 통째로 허락되지는 않아요.
• timeout, time, nice, nohup 같은 앞 단어는 떼고 맞춰요. Bash(npm test *)는 timeout 30 npm test에도 걸려요. 반면 npx, docker exec, devbox run은 떼지 않아서, Bash(devbox run *)를 허락하면 그 뒤에 오는 어떤 명령이든 허락한 것이 된다고 문서가 짚었어요.

Bash 규칙의 한계

문서는 Bash 규칙이 Claude가 적은 명령의 글자를 맞춰 볼 뿐이라고 적었어요. 같은 프로그램을 다른 형식으로 실행하면 걸리지 않아요. 그래서 deny나 ask 규칙은 “Claude가 보통 적는 형식”을 막는 것이지 그 프로그램 주변에 친 보안 경계가 아니라고 해요.

• Bash(rm *) deny는 rm -rf build/는 막지만 /bin/rm -rf build/나 bash -c 'rm -rf build/'는 못 막아요. 이런 명령은 다른 규칙과 권한 모드가 정해요.
• 명령의 인자까지 좁히려는 규칙은 깨지기 쉽다고 경고 상자에 적혀 있어요. Bash(curl http://github.com/ *)는 옵션을 앞에 두거나 https로 바꾸기만 해도 안 맞아요.
• 명령 글자와 상관없이 파일과 네트워크를 막으려면 샌드박스를, 명령 전체를 내 기준으로 살펴보려면 PreToolUse 훅을 쓰라고 해요.

파일 경로 적는 형식

파일 규칙은 Read(경로)와 Edit(경로) 둘이에요. 경로는 gitignore와 같은 무늬로 적고, 맨 앞 글자에 따라 어디서부터 재는지가 달라요.

적는 형식	재는 곳	예시
//path	파일 시스템 맨 위(절대 경로)	Read(//Users/alice/secrets/**)
~/path	홈 폴더	Read(~/Documents/*.pdf)
/path	프로젝트·로컬 설정은 프로젝트 폴더, 사용자 설정은 ~/.claude	Edit(/src/**/*.ts)
path, ./path	지금 폴더	Read(*.env)

출처: 클로드 코드 문서 “Configure permissions”의 “Read and Edit” 표. 10월 8일 확인.

이 표에서 가장 틀리기 쉬운 곳을 문서가 경고 상자로 짚었어요. /Users/alice/file처럼 슬래시 하나로 시작하면 절대 경로가 아니에요. 그 규칙을 어느 설정에 적었느냐에 따라 재는 곳이 달라요. 프로젝트 설정이나 로컬 설정에 적으면 프로젝트 폴더 아래이고, 사용자 설정(~/.claude/settings.json)에 적으면 ~/.claude/ 아래예요. 문서의 예시로 프로젝트 설정의 Edit(/docs/**)는 프로젝트의 docs 폴더예요. 컴퓨터 맨 위의 /docs도, 프로젝트의 .claude/docs도 아니에요. 절대 경로는 슬래시 둘로 시작해요.

• 파일 이름만 적으면 어느 깊이에든 맞아요. Read(.env)와 Read(**/.env)는 같아요. 다만 지금 폴더 아래까지예요. 컴퓨터 어디에 있든 막으려면 Read(//**/.env)예요.
• src/**처럼 폴더 이름 하나로 된 무늬는 규칙 종류에 따라 깊이가 달라요. allow에서는 지금 폴더 바로 아래의 src만, deny와 ask에서는 어느 깊이의 src든 맞아요.
• *는 폴더 한 단계 안에서, **는 폴더를 넘어서 맞아요.
• 경로 규칙은 Edit과 Read로만 적어요. Write(docs/**)나 Glob(docs/**)처럼 적으면 받기는 하되 한 번도 들여다보지 않고, 시작할 때 경고를 낸다고 해요(v2.1.210 이상).
• Read deny는 같은 경로의 Edit과 Write 도구도 막아요. 고칠 때는 v2.1.208, 새로 쓸 때는 v2.1.228 이상에서요.
• 프로젝트에 .claudeignore 파일이 있어도 아무 일도 하지 않는다고 적혀 있어요. 거기 적은 것은 Read deny 규칙으로 옮기라고 해요.

파일 규칙에도 빈틈이 적혀 있어요. Read·Edit deny는 Claude의 파일 도구와, cat·head·sed처럼 Claude Code가 알아보는 Bash 명령, > file 같은 리디렉션에 걸려요. 하지만 파일 이름을 대지 않고 읽는 명령(그 폴더에서 돌린 grep -r pattern .)이나 파일을 스스로 여는 Python·Node 스크립트에는 걸리지 않아요. 모든 프로세스를 운영체제에서 막으려면 샌드박스를 켜라고 해요.

겹치면 deny가 먼저

한 호출에 규칙 여럿이 맞으면 deny, ask, allow 순서로 보고, 먼저 맞은 쪽이 정해요. 문서는 규칙이 얼마나 좁은지는 이 순서를 바꾸지 않는다고 적었어요.

• Bash(aws *)를 deny에 넣으면 allow에 Bash(aws s3 ls)를 더 좁게 적어 두어도 막혀요. allow로 deny에 구멍을 낼 수는 없어요.
• ask와 allow 사이도 같아요. 맞는 ask 규칙이 있으면 더 좁은 allow가 있어도 물어요.
• 도구 이름만 적은 deny(Bash)는 그 도구를 Claude가 아예 못 보게 빼요. Bash(rm *)처럼 좁힌 deny는 도구는 두고 맞는 호출만 막아요.
• deny 규칙은 bypassPermissions를 넣어 모든 모드에서 막아요. ask 규칙도 어느 모드에서든 묻고, dontAsk 모드에서는 묻는 대신 거절해요.
• allow 규칙으로도 풀리지 않는 것이 있어요. .git, .claude, .vscode 같은 보호 경로에 쓰는 것, 그리고 rm -rf ~처럼 홈 폴더나 맨 위 폴더를 지우는 명령이에요.

훅이 이 순서의 어디에 끼는지, 설치한 mod가 deny를 넘길 수 있는 경우는 클로드 코드 훅(hooks) 글에 문서 문장과 함께 적어 두었어요.

설정 파일 네 곳

권한 규칙은 settings.json의 permissions 필드에 적어요. 문서는 클로드 코드가 읽는 설정 파일을 네 곳으로 적었어요.

자리	파일	걸리는 범위
사용자(User)	~/.claude/settings.json	이 컴퓨터의 내 모든 프로젝트
프로젝트(Shared project)	.claude/settings.json	그 폴더에서 일하는 모두(커밋하면)
로컬(Project local)	.claude/settings.local.json	그 프로젝트의 나만
회사(Managed)	managed-settings.json 등	회사가 내려 준 모든 컴퓨터

출처: 클로드 코드 문서 “Settings files and precedence”의 “Settings files and who they affect” 표. 10월 8일 확인.

클로드 코드를 깔아도 설정 파일은 자동으로 생기지 않아요. 사용자 파일은 /config 메뉴에서 값을 바꿀 때, 로컬 파일은 권한 확인 창에서 “don’t ask again”을 처음 고를 때 만들어진다고 적혀 있어요. 로컬 파일은 클로드 코드가 만들 때 git에서 빠지게 해 주지만, 손으로 만들었으면 .gitignore에 직접 넣으라고 해요.

여러 파일에 적으면

여기가 헷갈리기 쉬운 부분이에요. 설정에는 “높은 위치가 우선 적용되는 것”과 “모두 더해지는 것”이 따로 있어요.

무엇이	여러 파일에 있을 때
defaultMode 같은 값 하나	높은 자리의 값이 이김
allow·ask·deny 목록	파일마다의 목록이 모두 더해짐
더해진 규칙끼리 부딪침	어느 파일 것이든 deny, ask, allow 순서
회사가 내려 준 규칙	명령줄로도 못 덮음

출처: 클로드 코드 문서 “Settings files and precedence”의 “Settings precedence”·”Lists merge instead of overriding”, “Configure permissions”의 “Settings precedence”. 10월 8일 확인.

• 값 하나짜리 설정의 순서는 높은 쪽부터 회사(Managed), 명령줄(--settings로 넘긴 값), 로컬, 프로젝트, 사용자예요.
• 권한 목록은 이 순서로 하나만 남지 않아요. 사용자 파일이 허락하고 프로젝트 파일이 막으면 막혀요. 거꾸로 사용자 파일의 deny도 프로젝트 파일의 allow를 막아요. 문서는 어느 한 곳에서 막힌 도구는 다른 곳에서 허락할 수 없다고 적었어요.
• “don’t ask again”을 골랐는데 같은 도구를 또 묻는다면, 프로젝트나 회사 파일에 ask 규칙이 있는지 보라고 문제 해결 절에 적혀 있어요. 로컬 파일의 allow는 다른 파일의 ask보다 우선 적용되지 않아요.
• 프로젝트 파일(.claude/settings.json)의 allow 규칙과 additionalDirectories는 그 폴더를 믿는다고 누른 뒤에야 걸려요. deny와 ask는 막기만 하는 규칙이라 바로 걸려요.
• defaultMode에 "auto"나 "bypassPermissions"를 프로젝트·로컬 파일에 적으면 듣지 않아요. 사용자 설정이나 회사 설정에 적거나 그 세션만 --permission-mode로 줘요. bypassPermissions가 이렇게 된 것은 v2.1.257부터예요.
• 회사가 allowManagedPermissionRulesOnly를 걸어 두면 회사 설정의 규칙만 쓰여요.

/permissions 화면

입력 칸에 /permissions를 치면 지금 걸린 규칙을 보고 고치는 창이 열려요. 별칭은 /allowed-tools예요. 문서가 이 창에서 할 수 있다고 적은 일은 다음과 같아요.

1. 모든 권한 규칙과, 규칙마다 어느 settings.json에서 왔는지를 봐요.
2. allow·ask·deny 규칙을 더하거나 지워요. 더한 규칙의 /path 형식 경로는 어느 설정 파일에 저장했느냐에 따라 위 표대로 재요.
3. 작업 폴더(working directories)를 더하거나 빼요.
4. auto 모드를 쓸 수 있는 세션이면 Auto mode 탭에서 분류 모델의 규칙을 보고 고치고, 최근에 auto 모드가 거절한 것도 봐요.

Claude가 일하는 도중에도 열 수 있어요. 규칙을 더하거나 지우면 같은 턴 안의 다음 도구 호출부터 걸린다고 적혀 있어요. v2.1.234보다 앞선 버전은 그 차례가 끝날 때까지 기다렸다고 해요.

설정 파일을 직접 고치는 쪽이 편하면 아래 형식을 봐요. 문서의 설정 참고 페이지(settings-reference)에 실린 예시 그대로예요. npm run은 묻지 않고, git push는 꼭 묻고, .env 읽기는 막고, 세션은 acceptEdits로 시작해요.

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "acceptEdits"
  }
}

덜 묻게 하는 방법

문서 “Common setups” 표와 모드별 절에 적힌 길을 풀어 주는 폭이 좁은 것부터 놓았어요. 순서는 제가 매겼고, 칸의 내용은 문서 문장이에요.

길	묻지 않게 되는 것	그래도 남는 것
allow 규칙	적어 둔 명령·도구만	나머지는 그대로 확인 요청
acceptEdits	작업 폴더 안 파일 고치기, mkdir·mv·cp·rm·sed	다른 셸 명령, 보호 경로
샌드박스 auto-allow	샌드박스 안에서 도는 셸 명령	deny 규칙, 명령을 적은 ask 규칙
auto	평소의 권한 확인 창 대부분	ask 규칙, 분류 모델이 막은 것
bypassPermissions	보호 경로 쓰기까지 전부	deny·ask 규칙, 홈·맨 위 폴더 지우기

출처: 클로드 코드 문서 “Choose a permission mode”의 “Common setups”·”Available modes”·모드별 절, “Sandboxing”의 “Sandbox modes”. 10월 8일 확인.

• 샌드박스는 /sandbox를 쳐서 auto-allow를 고르거나 설정의 sandbox.enabled를 true로 둬요. 셸 명령이 건드릴 수 있는 파일과 네트워크를 운영체제에서 막아 두는 대신, 그 안에서 도는 명령은 묻지 않아요.
• auto 모드는 따로 도는 분류 모델이 행동을 먼저 살펴요. 문서의 경고 상자는 auto 모드가 권한 확인 창을 줄여 주지만 안전을 보장하지는 않는다고 적었어요. 큰 방향을 믿을 수 있는 일에 쓰고, 민감한 작업의 검토를 대신하는 것으로 쓰지 말라고 해요.
• auto 모드는 모든 요금제에서 되지만 모델을 가려요. Anthropic API 쪽은 Claude Opus 4.6 이상, Sonnet 4.6 이상, Haiku 5.5, Fable 모델이라고 적혀 있어요.
• dontAsk는 덜 묻는 모드가 아니라 묻지 않고 거절하는 모드예요. 미리 허락한 것만 돌고 나머지는 막혀서, 문서는 CI처럼 사람이 없는 곳에 쓰라고 해요.

건너뛰기 모드 주의

--dangerously-skip-permissions는 --permission-mode bypassPermissions와 같은 뜻이에요. 문서는 이 모드에 경고 상자를 세 번 달았어요. 어느 문서의 어느 문장인지 나눠 옮겨요.

• permissions 문서: 이 모드는 .git과 .claude 같은 보호 경로에 쓰는 것까지 묻지 않아요. Claude Code가 피해를 낼 수 없는 컨테이너나 VM 같은 격리된 환경에서만 쓰라고 적혀 있어요.
• permission-modes 문서 첫 경고: 인터넷에 닿지 않는 컨테이너, VM, dev container처럼 호스트 시스템을 망가뜨릴 수 없는 격리된 환경에서만 쓰라고 해요.
• permission-modes 문서 둘째 경고(위 그림): 이 모드는 프롬프트 인젝션이나 뜻하지 않은 행동을 막아 주지 않아요. 권한 확인 창을 크게 줄이면서 뒤에서 안전을 살피게 하려면 auto 모드를 쓰라고 적혀 있어요.

이 모드에서도 남는 것이 있어요. deny 규칙은 그대로 막고, ask 규칙은 그대로 물어요. rm -rf /나 rm -rf ~처럼 맨 위 폴더, 홈 폴더, 작업 폴더를 지우는 명령도 권한 확인 창이 떠요. 터미널에서는 이 창에 2분 시간 제한이 붙고, 답이 없으면 거절돼요(v2.1.281 이상). 사람 없이 도는 -p 실행에서는 물어야 할 호출이 묻는 대신 거절된다고 적혀 있어요. 반대로 allow 규칙은 이 모드에서 아무 일도 하지 않아요.

• 세션을 이 모드 없이 시작했다면 도중에 들어갈 수 없어요. 시작할 때 인자나 설정으로 켜야 해요.
• 처음 켜면 권한 확인 없이 일어나는 일의 책임을 수락하는지 묻는 확인 창이 뜨고, 거절하면 클로드 코드가 끝나요.
• 리눅스와 macOS에서는 root나 sudo로 띄우면 시작을 거부해요.
• 클라우드 세션은 설정 파일의 defaultMode: "bypassPermissions"를 듣지 않아요. 저장소에 커밋된 설정이 클라우드 세션을 이 모드로 띄우지 못하게 하려는 거예요.
• 내가 실수로 켜는 것을 막으려면 permissions.disableBypassPermissionsMode를 "disable"로 적어요. 회사 설정에 주로 쓰지만 내 사용자 설정에 적어도 된다고 해요.

윈도우에서 다른 점

권한과 설정 문서가 윈도우를 따로 적은 부분을 모았어요.

항목	윈도우에서
~/.claude	%USERPROFILE%\.claude
경로 규칙	POSIX 형식으로 바꿔 맞춤, C:\Users\alice는 /c/Users/alice
로컬 설정 파일의 자리	저장소 맨 위가 아니라 .claude/settings.json 옆
샌드박스	윈도우 그대로는 안 됨, WSL2 안에서만
네트워크(UNC) 경로	읽기 전용 명령이어도 확인 요청
auto 기본 시작(Pro·Max·Team)	윈도우 그대로는 v2.1.233부터, WSL은 v2.1.228부터

출처: 클로드 코드 문서 “Configure permissions”의 “Read and Edit”·”Read-only commands”·”PowerShell”, “Settings files and precedence”, “Sandboxing”, “Choose a permission mode”. 10월 8일 확인.

• 어느 드라이브에서든 .env를 막으려면 //**/.env, C 드라이브만이면 //c/**/.env로 적으라고 문서에 예시가 있어요.
• PowerShell 도구의 규칙은 Bash 규칙과 형식이 같아요. PowerShell(Get-ChildItem *)처럼 적고, 대소문자를 가리지 않아요. cmdlet 이름으로 적은 규칙은 흔한 별칭에도 맞아서 이 규칙이 gci, ls, dir에도 걸려요.
• 문서의 PowerShell 예시는 PowerShell(Remove-Item *)를 deny에 넣은 것이에요. 설치 문서(Advanced setup)는 Git for Windows가 깔려 있으면 PowerShell 도구가 Bash와 나란히 켜진다고 적었어요(claude.ai·Console 계정은 기본으로). 그래서 제 생각에는 막는 규칙을 두 형식으로 다 적어 두는 쪽이 마음 편해요.
• PowerShell의 Remove-Item은 따로 살펴요. 드라이브 맨 위와 그 바로 아래 폴더, 홈 폴더를 겨눈 것과 *로 끝나는 것은 어느 모드에서든 묻지 않고 거절한다고 적혀 있어요.
• 샌드박스가 윈도우 그대로는 돌지 않으니, 위 표의 “샌드박스 auto-allow”는 WSL2 안에서 클로드 코드를 띄울 때만 쓸 수 있어요.
• C:\와 C:\Windows 같은 드라이브 맨 위와 그 바로 아래 폴더는 지우기 명령에서 따로 지켜 주는 경로(critical paths)에 들어 있어요.
• \\server\share 같은 네트워크 경로는 작업 폴더로 더할 수 없어요. 드라이브 글자로 이어 놓고 --add-dir로 넘기라고 적혀 있어요.

코덱스·제미나이 CLI는

터미널에서 쓰는 다른 두 도구도 승인과 샌드박스를 설정으로 정해요. 깊이 비교하지는 않고, 무엇을 어디에 적어 무엇을 막는지만 놓았어요.

도구	적는 곳	규칙이 겹치면	근거
클로드 코드	settings.json의 permissions(allow·ask·deny)	deny, ask, allow 순서	permissions 문서
코덱스	config.toml의 approval_policy·sandbox_mode, rules 폴더의 .rules 파일	.rules끼리는 forbidden, prompt, allow 가운데 가장 엄한 쪽	Agent approvals & security·Rules 문서
제미나이 CLI	~/.gemini/policies의 .toml 파일([[rule]])	priority 숫자가 큰 규칙이 이김	Policy engine 문서

도구	샌드박스	윈도우 그대로	다 건너뛰는 길
클로드 코드	/sandbox로 켬(macOS·리눅스·WSL2)	없음	--dangerously-skip-permissions
코덱스	기본으로 켜짐, 네트워크는 꺼짐	윈도우 샌드박스 있음	--dangerously-bypass-approvals-and-sandbox
제미나이 CLI	-s나 GEMINI_SANDBOX로 켬	Windows Native Sandbox 있음	yolo 승인 모드

출처: 클로드 코드 문서 “Configure permissions”·”Sandboxing”, OpenAI 코덱스 문서 “Agent approvals & security”·”Rules”·”Permissions”, 제미나이 CLI 문서 “Policy engine”·”Sandboxing in Gemini CLI”. 10월 8일 확인.

• 코덱스는 샌드박스가 먼저이고 승인은 그 바깥으로 나갈 때 물어요. 문서가 적은 기본 모드(Auto)은 작업 폴더 안에서는 읽고 고치고 명령을 돌리되, 폴더 밖을 고치거나 네트워크를 쓸 때 묻는 것이에요. .rules 파일의 prefix_rule은 샌드박스 밖에서 돌릴 명령을 정하는 규칙이라 클로드 코드의 allow·deny와 용도가 똑같지는 않아요. 문서는 Rules가 실험 단계라고 적었어요.
• 코덱스 문서는 approval_policy = "untrusted"를 더는 받지 않는다고 적었어요. 설정에 남아 있으면 시작이 안 될 수 있으니 지우라고 해요. 파일과 네트워크를 이름 붙여 묶는 permission profiles는 베타라고 적혀 있어요.
• 제미나이 CLI는 규칙마다 decision(allow, deny, ask_user)과 priority를 적어요. 숫자가 큰 규칙이 우선 적용되는 방식이라 deny가 자동으로 먼저 오지 않아요. 프로젝트 폴더의 정책(Workspace 단계)은 지금 듣지 않는다고 문서의 주의 상자에 적혀 있어요.
• 코덱스 문서에도 CLI에서 /permissions를 쳐서 바꾸라는 문장이 있어요. 제미나이 CLI에 같은 이름의 명령이 있는지는 확인하지 못했어요(미확인).
• 구글이 제미나이 CLI 뒤를 잇는다고 밝힌 안티그래비티 CLI의 승인 설정은 확인하지 못했어요(미확인). 옮겨 가는 얘기는 안티그래비티 CLI 설치·로그인 글에 있어요.
• 세 도구의 다른 기능 비교는 클로드 코드·코덱스·제미나이 CLI 비교 글에 있어요.

한국에서 되나

항목	공식 문서에 적힌 것
나라	지원 나라 목록에 South Korea 있음
요금제	Pro·Max·Team·Enterprise 또는 Console 계정
Free	클로드 코드를 쓸 수 없음
권한 규칙에 드는 돈	따로 적힌 것 없음
auto 모드	모든 요금제, 모델 조건 있음
문서 언어	이 글이 본 것은 영어 문서

출처: Anthropic “Supported countries and regions”, 클로드 코드 문서 “Advanced setup”·”Choose a permission mode”. 10월 8일 확인.

권한 문서에는 나라를 가리는 문장이 없어요. 클로드 코드를 쓸 수 있으면 권한 규칙도 적을 수 있어요. auto 모드의 분류 모델이 사용량에 반영되는지는 계정 종류에 따라 달라요. 권한 모드 문서의 “Cost and latency” 상자는 Enterprise 요금제와 Claude API를 쓰는 계정에서 분류 호출이 토큰 사용량에 잡힌다고 적었어요. Pro·Max·Team 쪽은 주간 소식(8월 3~7일 주)에 auto 모드의 분류 호출이 더는 사용 한도에 반영되지 않는다고 적혀 있고, 분류 요청 요금 문서(auto-mode-classifier-billing)도 Pro·Max·Team 요금제에는 요금 안내 창이 뜨지 않는다고 했어요(10월 8일 확인). 계정별로 나눈 표는 클로드 코드 auto 모드 글에 있어요. 이 글에 나온 버전 번호(v2.1.208, v2.1.210, v2.1.211, v2.1.228, v2.1.233, v2.1.234, v2.1.257, v2.1.283)보다 내 클로드 코드가 낮으면 그 부분은 다르게 움직일 수 있어요.

누구에게 맞나

여기부터는 위 문서를 놓고 본 제 생각이에요.

이런 분	먼저 할 것	이유
같은 명령을 자꾸 허락함	그 명령만 allow 규칙으로	풀어 주는 폭이 가장 좁음
.env·키 파일이 걱정됨	Read deny부터	어느 모드에서든 막음
push·배포는 꼭 보고 싶음	ask 규칙	auto·bypass에서도 확인 요청
팀이 같이 쓰는 저장소	.claude/settings.json에 deny·ask	믿기 전에도 바로 걸림
윈도우에서 권한 확인 창이 많음	allow 규칙과 auto 모드	샌드박스는 WSL2에서만

• 처음에는 deny 몇 줄부터 적는 쪽이 좋겠어요. 사용자 설정에 Read(//**/.env)처럼 슬래시 둘로 시작하는 경로로 적어 두면 어느 프로젝트에서든 걸려요. 슬래시 하나로 적으면 엉뚱하게 ~/.claude 아래를 가리킨다는 점만 잊지 않으면 돼요.
• allow는 넓게 한 줄보다 좁게 여러 줄이 낫다고 봐요. Bash(git *) 한 줄이면 편하지만 push와 reset까지 묻지 않게 돼요. 문서도 별표를 서브커맨드 뒤에 두라고 했어요.
• Bash deny 규칙을 믿고 마음을 놓지는 않는 게 좋겠어요. 문서가 스스로 보안 경계가 아니라고 적었으니까요. 꼭 막아야 하는 것은 파일이면 Read·Edit deny, 명령이면 샌드박스나 훅을 같이 쓰는 쪽이 문서의 권고와 맞아요.
• 건너뛰기 모드는 내 컴퓨터에서 평소 쓰는 방법으로 삼지 않는 게 좋겠어요. 문서가 같은 자리에 auto 모드를 대신 쓰라고 적어 두었어요.

다시 확인할 날짜

• 11월 7일: 권한 모드가 여섯 가지 그대로인지, auto가 기본 시작 모드인 버전 조건
• 11월 7일: 샌드박스가 윈도우 그대로도 되게 바뀌었는지
• 11월 7일: Write·Glob 경로 규칙을 들여다보지 않는 것이 그대로인지
• 12월 8일: 코덱스 Rules·permission profiles가 실험·베타에서 벗어났는지, 제미나이 CLI Workspace 정책, 안티그래비티 CLI 승인 설정

이 글의 내용은 2026년 10월 8일 기준이에요.

같이 보면 좋은 글: 클로드 코드 훅(hooks), 매번 돌아야 할 일에: 적는 곳과 종료 코드 2로 막기

같이 보면 좋은 글: 클로드 코드 스킬 만들기: SKILL.md 프론트매터 칸 스무 가지와 설명 쓰는 요령

같이 보면 좋은 글: AI 비교 2026: 클로드·챗GPT·제미나이 요금제·한도·기능 표

이 글이 들어간 총정리: 클로드 코드 사용량 아끼는 법

같이 보면 좋은 글: 클로드 코드 auto 모드, 무엇을 막나: 기본 모드가 된 조건과 끄고 바꾸는 법

같이 보면 좋은 글: 클로드 코드 깃 커밋·PR 맡기는 법: 연습 폴더부터 /diff·push 막기·서명 줄까지

같이 보면 좋은 글: 클로드 코드 settings.json 설정하는 법: /config 부터 파일 네 곳 순서, 오류 고치기까지

참고한 자료

2026년 10월 8일에 확인했어요.

• Configure permissions (클로드 코드 문서, 권한 확인 창·규칙 형식·Bash와 파일 규칙·순서·폴더 믿기)
• Choose a permission mode (클로드 코드 문서, 모드 여섯 가지·시작 모드·auto·bypassPermissions 경고·보호 경로)
• Auto mode classifier request charges (클로드 코드 문서, 분류 요청 요금 안내 창이 뜨는 계정)
• Week 32 · August 3–7, 2026 (클로드 코드 주간 소식, Pro·Max·Team의 분류 호출과 사용 한도)
• Settings files and precedence (클로드 코드 문서, 설정 파일 네 곳·순서·목록은 더해짐·윈도우 경로)
• Settings reference (클로드 코드 문서, permissions 필드 보기)
• Sandboxing (클로드 코드 문서, auto-allow·되는 운영체제)
• Commands (클로드 코드 문서, /permissions)
• Advanced setup (클로드 코드 문서, 쓸 수 있는 요금제·윈도우의 PowerShell 도구)
• Agent approvals & security (OpenAI 코덱스 문서, 샌드박스와 승인·기본 모드·운영체제별 샌드박스)
• Rules (OpenAI 코덱스 문서, prefix_rule과 겹칠 때 순서)
• Permissions (OpenAI 코덱스 문서, permission profiles 베타)
• Policy engine (제미나이 CLI 문서, 규칙·priority·승인 모드)
• Sandboxing in Gemini CLI (제미나이 CLI 문서, 켜는 법·운영체제별 방식)
• Supported countries and regions (Anthropic, 지원 나라)