60초 만에 보는 Claude Code 권한
- Claude Code는 Bash, Edit, WebFetch, Write 앞에서 확인을 요청합니다. Read, Glob, Grep, LS는 묻지 않고 실행됩니다.
- "Yes, and don't ask again"을 고르면 Bash(git add:*) 같은 규칙이 .claude/settings.local.json에 저장됩니다 — 그 저장소 전용, git에서 자동 제외되는 개인 규칙장입니다.
- 규칙은 deny → ask → allow 순서로 평가됩니다: 어떤 설정 파일의 deny든 이기고, 어떤 allow 규칙도 거기에 예외를 낼 수 없습니다.
- 모드로 신뢰의 폭을 조절합니다: 편집이 많으면 acceptEdits(alt+m), 읽기 전용 정찰은 plan, CI는 --permission-mode bypassPermissions — 단, defaultMode의 auto와 bypassPermissions는 사용자 또는 관리 설정에 있어야만 효력이 있습니다.
Claude Code Tutorial #4 - Tools & Permissions
채널:The Net Ninja4:55
Permission Modes Head to Head
채널:ttywood6:20
Permissions — Claude Code documentation
공식 문서:code.claude.com
Settings files — Claude Code documentation
공식 문서:code.claude.com
스틸 컷은 전부 Net Ninja 녹화에서 왔습니다 — 캠도, 겹쳐 그린 자막도 없는 깔끔한 화면 캡처입니다. 권한 모드들을 정면으로 비교한 ttywood 회차는 모드·레시피 섹션의 교차 검증으로 썼지만 프레임은 한 장도 가져오지 않았습니다(번인 자막이 있어서입니다). 규칙 문법, 평가 순서, 모드 동작, 설정 파일 우선순위는 공식 문서 두 페이지로 검증했습니다.
영상 © The Net Ninja, ttywood(링크만 사용). 문서 © Anthropic. 스크린샷은 이 가이드의 해설을 위해 인용했습니다.
Claude Code 권한, 단계별 설정하기
Claude Code가 움직이기 전에 묻는 것들
- 1
어떤 도구가 권한 프롬프트를 띄우는지 보기
Claude Code는 도구를 스스로 고릅니다 — 파일 열기는 Read, 수정은 Edit, 셸 명령은 Bash. Anthropic 설정 문서는 각 도구에 Permission Required 열을 붙입니다: Bash, Edit, WebFetch, Write는 멈춰서 묻고, Read, Glob, Grep, LS는 그냥 실행됩니다. 도구 이름을 직접 칠 일은 없고, 중요한 것은 어떤 행동이 여러분을 기다리며 멈출지 미리 아는 것입니다.
Claude Code 설정 문서는 내장 도구마다 Permission Required 판정을 붙여 목록으로 보여줍니다.1:05부터 시청 - 2
수정을 시켜 보고, 먼저 읽는 모습 관찰하기
영상의 요청은 의도적으로 작게 잡았습니다: src/app/globals.css에 파스텔 옐로 --highlight 변수를 추가하라는 것. Claude Code는 먼저 파일을 읽습니다 — Read는 권한이 필요 없으니까요 — 그리고 손대려는 순간에야 멈춥니다. 이 분리가 권한 모델 전체의 축소판입니다: 보는 건 공짜, 만지는 건 승인.
VS Code의 Claude Code 입력창에 입력된 하이라이트 변수 요청.1:45부터 시청 - 3
답하기 전에 세 가지 선택지 읽기
수정 프롬프트에는 매번 세 가지 답이 붙습니다. 1. Yes는 이번 수정 한 건만 승인. 2. Yes, and don't ask again this session은 이 세션의 남은 수정을 승인(영상 빌드에서는 alt+m). 3. No, and tell Claude what to do differently(esc)는 변경을 거부하고 지시로 방향을 잡습니다. 3번은 실패가 아니라 — 코드가 박제되기 전에 궤도를 바로잡는 방법 그 자체입니다.
globals.css 수정 프롬프트, 세 가지 권한 옵션이 모두 보입니다.2:17부터 시청
한 번만 yes 말하기: allow 규칙 저장하기
- 4
작업당 한 번이 아니라, 수정당 한 번씩 묻는다
승인은 다음 변경으로 이어지지 않습니다. 데모에서는 같은 파일의 서로 다른 세 곳 수정에 Yes 세 번이 필요했고, 다음 변경도 또 물었습니다. 매번 승인하는 방식도 되긴 하지만 두 줄짜리 작업을 넘기면 감당이 안 됩니다 — allow 규칙과 모드가 존재하는 이유가 바로 이것입니다.
첫 번째 수정 승인 직후 globals.css의 두 번째 수정이 다시 프롬프트를 띄우는 장면.2:32부터 시청 - 5
Bash 명령은 별도의 관문을 거친다
셸 명령에는 자기만의 게이트가 있습니다. 데모에서 Claude에게 커밋을 시키면 Bash(git add src/app/globals.css)가 Waiting 상태로 답을 기다립니다. 어떤 명령의 yes가 다음 명령의 yes는 아닙니다 — 뒤이은 git commit도 자기 몫의 확인을 또 요구합니다.
승인을 기다리는 git add 명령, 위에는 이미 실행된 git 출력이 흐릅니다.3:16부터 시청 - 6
"don't ask again"에게 규칙 쓰기를 맡기기
git add 명령에 Yes, and don't ask again을 고르면 두 가지가 동시에 일어납니다: 현재 명령이 풀리고, 규칙 하나가 저장됩니다. 만들어지는 파일은 저장소 루트의 .claude/settings.local.json이고, permissions 객체의 allow 배열 — 여기서는 "Bash(git add:*)" — 와 빈 deny·ask 배열이 들어 있습니다. 이제 이 프로젝트의 모든 git add는 프롬프트 없이 실행됩니다.
.claude 아래 생성된 settings.local.json, Bash(git add:*) allow 규칙이 저장된 상태.3:40부터 시청 - 7
대화상자로 안 되는 규칙은 직접 파일 고치기
allow 배열은 평범한 JSON이므로 스스로 규칙을 추가할 수 있습니다. 단일 명령은 정확한 문자열 — Bash(npm run test) — 로, 같은 접두사의 명령 전체는 끝에 :*를 붙여 — Bash(npm run test:*) — 표기합니다. 공식 문서도 :*가 끝 와일드카드의 축약 표기임을 확인합니다. 파일은 개인용으로: Claude Code는 settings.local.json을 전역 git 제외에 자동 등록하고, 영상도 같은 조언을 합니다 — 이건 저장소가 아니라 여러분의 워크플로를 위한 파일입니다.
파일을 직접 고치는 가운데 permissions.allow에서 선택된 저장된 규칙.4:22부터 시청
모드로 위임 범위 조절하기
- 8
수정이 몰리는 구간엔 accept edits로 전환
alt+m(최신 빌드는 shift+tab으로 모드 순환)을 누르면 세션 배지가 accept edits on으로 바뀝니다. 파일 수정이 프롬프트 없이 바로 반영되고, 문서는 덧붙입니다: mkdir, touch, mv, cp 같은 흔한 파일시스템 명령도 자동 승인된다고. 이 면제는 세션 한정입니다 — 새 세션을 열면 다시 수정마다 프롬프트로 돌아가고, 다시 켜기 전까지는요.
허용된 git 명령들이 커밋을 마무리하는 동안 accept edits on 배지가 표시됨.4:35부터 시청 - 9
올라가기 전에 모드 사다리 전체를 파악하기
모드는 세션의 기본 자세를 정합니다. default는 각 도구 첫 사용 시 프롬프트; plan은 아무것도 수정하지 않는 읽기 전용 탐색; acceptEdits는 파일 수정을 자동 승인; dontAsk는 물었을 작업을 전부 자동 거부; auto는 백그라운드 안전 점검과 함께 도구 호출을 승인; bypassPermissions는 어떤 모드도 자동 승인할 수 없는 소수 행위를 제외하고 프롬프트를 생략합니다. 세션별로는 --permission-mode로, 영구적으로는 permissions.defaultMode로 고릅니다.
- 10
defaultMode는 올바른 파일에 넣기
설정 문서가 명확합니다: defaultMode의 auto와 bypassPermissions는 프로젝트·로컬 설정에서는 효력이 없습니다 — 사용자(~/.claude/settings.json)나 관리 설정에 두거나, 한 세션만이라면 --permission-mode를 넘기세요. 우선순위는 관리 설정 → CLI --settings → .claude/settings.local.json → .claude/settings.json → 사용자 설정 순으로 흐르고, 어느 층위의 deny든 아래의 모든 allow를 이깁니다.
실전 프로젝트용 복붙 레시피
- 11
레시피: 테스트는 허용, 파괴는 차단
팀이 공유하는 .claude/settings.json에서 테스트 루프는 "Bash(npm run test:*)"로 허용하고, 위험한 부분은 "Bash(rm -rf *)"와 "Read(./.env)"로 울타리 쳐 시크릿이 절대 읽히지 않게 합니다. 웹 리서치도 같은 요령: "WebFetch(domain:example.com)"는 도메인 하나, "WebFetch(domain:*.example.com)"는 서브도메인 전체. deny가 먼저 평가되므로 어떤 allow 규칙도 거기에 예외를 파내려 갈 수 없습니다.
- 12
레시피: CI에서 안전하게 프롬프트 건너뛰기
비대화형 실행에는 우연이 아니라 의도된 자세가 필요합니다: CI 작업에 --permission-mode bypassPermissions를 넘기거나, 사용자·관리 설정에 defaultMode를 두세요 — 프로젝트 파일은 이 값을 허가할 수 없습니다. 가드레일을 영구화하려면 관리 설정에서 permissions.disableBypassPermissionsMode를 "disable"로 두고, /permissions로 각 머신을 감사하면 활성 규칙 전부와 출처 파일까지 목록으로 나옵니다.
deny → ask → allow: 규칙은 실제로 어떤 순서로 적용되나
권한 문서는 단호합니다: 규칙은 deny, 그다음 ask, 그다음 allow 순서로 평가되며, 첫 번째로 일치한 규칙이 결과를 정합니다. 규칙이 얼마나 구체적이든 이 순서는 절대 안 바뀝니다. allow 규칙은 아무리 정밀해도 deny 규칙에 예외를 낼 수 없습니다.
deny는 파일을 넘어 전역이기도 합니다. 사용자 설정이 허용하고 프로젝트 설정이 거부하면 deny가 이깁니다 — 모든 범위의 deny 규칙은 allow 규칙보다 먼저 평가되고, 관리 설정의 deny는 명령줄 플래그로도 뒤집을 수 없습니다. "Bash" 같은 맨이름 도구를 deny하면 더 멀리 갑니다: 문서 말로, 그 도구를 Claude의 컨텍스트에서 통째로 제거한다고 합니다.
실무적 결론: 안전 규칙 — rm 금지, .env 읽기 금지, 강제 푸시 금지 — 는 저장소와 함께 다니는 프로젝트 .claude/settings.json에 싣고, allow 목록은 그 위에 얹는 편의장치로 취급하세요. allow 목록은 범위를 넘어 덮어쓰기가 아니라 병합되므로, 개인 settings.local.json은 누구의 deny도 약화시키지 않으면서 자신만의 허용을 얹을 수 있습니다.
그대로 가져와도 되는 세 가지 레시피
각 레시피는 들어가야 할 파일을 명시합니다. 모두에 적용되는 상수 하나: deny는 어디서나, 언제나 이깁니다.
테스트는 자유롭게, rm과 .env는 굳게
.claude/settings.json에: "permissions.allow": ["Bash(npm run test:*)"](스택에 맞춰 "Bash(npx vitest:*)"나 "Bash(uv run pytest:*)"로 교체), "permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]. 테스트와 그 콜백은 손 놓고 돌고, 파괴적인 삭제와 시크릿 읽기는 평가가 allow 목록에 닿기 전에 막힙니다.
리서치는 신뢰하는 도메인에 못 박기
문서 위주 작업이라면: allow에 "WebFetch(domain:developer.mozilla.org)"와 "WebFetch(domain:claude.com)", 또는 서브도메인 전체는 "WebFetch(domain:*.example.com)". 맨이름 "WebFetch" 도구를 deny하면 웹 읽기를 완전히 꺼버릴 수도 있습니다 — 로컬 컨텍스트만으로 끝내야 하는 재현성 중시 실행에 유용합니다.
CI는 무인으로, 다만 폭주 없이
CI 작업이 --permission-mode bypassPermissions를 넘기게 하거나, 사용자·관리 설정에 "permissions.defaultMode": "bypassPermissions"를 두세요 — 프로젝트·로컬 설정은 이 값을 줄 수 없습니다. 모드 자체를 봉쇄하려면 관리 설정의 "permissions.disableBypassPermissionsMode": "disable"이 모든 저장소와 모든 플래그를 밀어냅니다. 그래도 bypassPermissions는 어떤 모드도 자동 승인할 수 없는 짧은 목록의 행위는 계속 막습니다.
규칙이 안 먹히나요? 이 네 가지부터
"allow 규칙이 무시된다"는 보고 대부분은 규칙이 어느 파일에 떨어졌는지, 어느 파일이 이기는지로 귀결됩니다.
- 1규칙은 맞고, 파일이 틀렸다. 세션 승인은 .claude/settings.local.json에 떨어집니다; 팀 규칙은 .claude/settings.json; 머신 전체 규칙은 ~/.claude/settings.json으로. /permissions를 실행하세요 — 활성 규칙 전부와 각각의 출처 설정 파일이 목록으로 나옵니다.
- 2상위 파일이 deny하고 있다. 값은 아래로 덮어쓰지만, 어느 층위의 deny든 allow보다 먼저 평가되므로 사용자 수준 allow는 프로젝트 수준 deny를 구하지 못합니다 — 관리 설정은 명령줄 플래그까지 이깁니다.
- 3allow 규칙이 신뢰를 기다리는 중. deny와 ask는 즉시 적용되지만, 커밋된 프로젝트 파일에서 온 allow 규칙은 워크스페이스 폴더를 신뢰한 뒤에야 효력이 있습니다 — 클론해 온 저장소를 위한 의도된 관문입니다.
- 4모드가 잘못된 파일에 들어갔다. defaultMode의 auto와 bypassPermissions는 프로젝트·로컬 설정에서는 무시됩니다(문서는 이 변경이 v2.1.257부터라고 적습니다 — 그 전에는 bypassPermissions가 어느 파일에서든 효력이 있었습니다). 사용자·관리 설정으로 옮기거나, 단일 세션이면 --permission-mode를 쓰세요.