Claude Code 권한 설정,
빠른 실행보다 먼저 정할 것

권한 모드는 기본선, 규칙은 예외입니다

Claude Code에서 먼저 정할 것은 “무엇을 한 번도 묻지 않게 할까”가 아니라 “이 세션에서 어느 수준까지 사람의 확인을 둘까”입니다. permission mode는 읽기·파일 편집·셸·네트워크 접근 같은 도구 호출을 기본적으로 어떻게 승인할지 정합니다. 반면 permission rule은 특정 명령이나 경로에 allow, ask, deny를 더하는 세부 정책입니다.

예를 들어 평소에는 파일 편집을 빠르게 진행하되 배포만 확인받고 싶다면, 먼저 acceptEdits처럼 작업 성격에 맞는 모드를 고릅니다. 그 뒤 Bash(git push *)를 ask 규칙으로 두는 식입니다. 모드만 바꾸면 너무 넓어지고, 규칙만 쌓으면 왜 이 세션이 계속 묻는지 파악하기 어려워집니다.

작업 성격에 맞는 모드부터 고릅니다

모드 이름만으로 안전성이 보장되지는 않습니다. default에서도 읽기 외 작업은 보통 확인을 받지만, 이미 저장된 allow 규칙이 있으면 특정 작업은 승인 없이 실행될 수 있습니다. 반대로 auto나 bypassPermissions를 골랐더라도 명시적 ask 규칙, 사용자 상호작용이 필요한 도구, critical path를 대상으로 한 rm·rmdir 삭제는 아무 모드나 자동 승인하지 않습니다.

acceptEdits는 개발용 기본값으로 검토할 만하지만, 배포까지 자동 허용하는 모드는 아닙니다. 파일을 고치고 테스트를 돌리는 흐름이 잦다면 편하지만, 셸 명령과 외부 네트워크가 포함된 단계는 별도로 보게 됩니다. 권한 창이 귀찮아서 auto나 bypassPermissions로 건너뛰기 전에, 어떤 종류의 창이 반복되는지 먼저 분류하는 편이 낫습니다.

규칙은 deny → ask → allow 순서로 읽습니다

settings의 permissions에는 allow, ask, deny 배열을 둘 수 있습니다. 규칙 형식은 Tool 또는 Tool(specifier)입니다. 예를 들어 Bash(npm run build), Read(./.env), WebFetch(domain:example.com)처럼 작업 범위를 좁힐 수 있습니다.

위 예시는 빌드 명령은 매번 묻지 않게 하고, 원격 저장소에 반영하는 명령은 확인을 남기며, 환경변수 파일 읽기는 차단하는 구조입니다. 실제 저장소의 명령은 팀 규칙에 맞게 바꾸어야 합니다. 가장 중요한 점은 deny가 allow보다 앞선다는 것입니다. Bash(aws *)를 deny로 넣은 뒤 Bash(aws s3 ls)만 allow로 되살릴 수는 없습니다. 더 구체적인 allow라도 broad deny를 이기지 못합니다.

규칙은 모델에게 보내는 프롬프트가 아닙니다. Claude Code가 강제하는 경계입니다. 따라서 CLAUDE.md에 “이 명령을 실행해도 된다”고 적는 것만으로 deny를 무시할 수 없습니다. 현재 적용된 규칙을 확인하거나 추가·삭제하려면 /permissions를 사용합니다. 막힌 이유를 모르겠을 때는 모드를 바꾸기보다 먼저 이 화면에서 어떤 설정 파일의 규칙이 적용됐는지 확인하세요.

같은 settings.json도 저장 위치에 따라 영향 범위가 다릅니다

공유 프로젝트 설정에 allow 규칙을 추가하는 일은 단순한 편의 설정이 아니라 팀 전체의 실행 범위를 넓히는 변경입니다. Claude Code는 프로젝트 .claude/settings.json의 allow와 additionalDirectories처럼 권한을 넓히는 설정을 workspace trust를 수락한 뒤 적용합니다. 반대로 ask·deny는 제한 규칙이어서 같은 조건의 영향을 받지 않습니다.

여러 범위의 설정이 섞이면 managed settings가 가장 강합니다. 그 다음에는 CLI 인수, project local, shared project, user 설정 순으로 적용됩니다. allow 배열은 범위별로 합쳐질 수 있지만 어느 범위에서든 deny된 작업은 다른 위치의 allow로 되살릴 수 없습니다. 회사 정책으로 bypassPermissions를 막아야 한다면 개인 설정이 아니라 managed settings에서 disableBypassPermissionsMode를 관리하는 편이 맞습니다.

권한 요청을 줄이는 안전한 순서

예를 들어 로컬 기능 개발이라면 default로 시작해 파일 구조를 읽고, 계획이 맞으면 acceptEdits로 전환합니다. 테스트 명령만 반복적으로 확인받는다면 Bash(npm test)처럼 좁은 allow 후보를 검토합니다. 배포는 ask로 유지합니다. 이 흐름이면 ‘전부 허용’보다 조금 느려 보이지만, 잘못된 대상에 쓰거나 외부로 전송하는 순간을 분리해 검토할 수 있습니다.

CI에서 사람이 없는 실행을 만들 때는 dontAsk와 정확한 allowlist가 더 적합할 수 있습니다. 허용되지 않은 호출은 묻지 않고 거부되므로, 필요한 명령을 넓은 Bash(*)로 풀기보다 테스트·빌드 명령을 개별적으로 나열해야 합니다. 실행기는 여전히 별도의 격리와 최소 권한을 가져야 하며, Claude Code의 권한 규칙이 다른 도구의 접근 권한까지 통제하는 것은 아닙니다.

자주 묻는 질문

Q. 권한 창이 너무 많이 뜨면 bypassPermissions를 쓰면 되나요?
공식 문서는 bypassPermissions를 격리된 컨테이너·VM 환경에만 권장합니다. 먼저 반복되는 작업을 좁은 allow 규칙으로 만들거나 acceptEdits, dontAsk의 목적이 맞는지 확인하세요.

Q. deny와 allow를 함께 쓰면 특정 명령만 예외로 허용할 수 있나요?
아닙니다. deny가 ask와 allow보다 먼저 평가됩니다. broad deny 아래에 allow 예외를 두는 방식은 기대대로 동작하지 않으므로, 차단 범위와 허용 범위를 처음부터 겹치지 않게 설계해야 합니다.

Q. 팀에 공유할 규칙은 어디에 두나요?
팀이 함께 검토해 커밋할 규칙은 .claude/settings.json에, 개인별 편의나 예외는 .claude/settings.local.json에 두는 구분이 기본입니다. 권한을 넓히는 규칙은 코드 리뷰 대상으로 다루는 편이 안전합니다.