클로드 코드(Claude Code)를 길게 쓰다 보면 가장 자주 부딪히는 짜증 포인트가 매번 뜨는 “허용/거부” 프롬프트입니다. 같은 git status를 매번 허용하는 것도 피곤하고, 흐름이 끊겨 작업 속도도 떨어집니다. 다행히 이 프롬프트는 settings.json의 permissions.allow 규칙으로 통제할 수 있습니다. 자주 쓰는 안전한 명령은 사전에 허용해 두고, 위험한 명령은 명시적으로 차단해 두는 식입니다. 이 글에서는 안전하게 자동 승인 범위를 넓히는 방법을 단계별로 정리해 드립니다.
목차
왜 매번 허용을 누르게 되는가
클로드 코드는 기본적으로 도구를 호출할 때마다 사용자의 승인을 받도록 설계되어 있습니다. 운영 환경 사고를 막기 위한 안전장치이지만, 신뢰된 작업까지 모두 묻는 것은 효율을 떨어뜨립니다. 그래서 클로드 코드는 사용자가 설정 파일에 안전한 패턴을 미리 등록해 두면 그 범위 안에서는 자동으로 통과시키도록 만들어 두었습니다.
이 자동 승인은 단순히 “전부 허용”이 아니라, 어떤 도구·어떤 명령·어떤 파일 경로에서만 허용할지 세분화해서 지정할 수 있다는 점이 핵심입니다.
설정 파일 위치 짚고 가기
먼저 어떤 파일에 적느냐부터 정하셔야 합니다. 적용 범위가 다릅니다.
| 위치 | 경로 | 적용 범위 | 권장 용도 |
|---|---|---|---|
| 사용자 글로벌 | ~/.claude/settings.json | 본인의 모든 프로젝트 | 개인 공통 명령(git, ls 등) |
| 프로젝트 공유 | .claude/settings.json | 저장소 전체, 팀 공유 | 프로젝트 공통 빌드·테스트 명령 |
| 프로젝트 로컬 | .claude/settings.local.json | 본인 머신만, gitignore | 본인만의 임시 오버라이드 |
같은 규칙이 여러 위치에 있으면 좁은 범위가 우선합니다(local > project > user). 팀과 공유할 안전한 기본값은 .claude/settings.json에, 본인만 쓸 단축은 ~/.claude/settings.json에 두시는 것이 깔끔합니다.
permissions.allow 기본 형식
구조는 단순합니다. permissions 아래 allow·deny·ask 세 배열을 두는 형태입니다. 가장 단순한 예는 다음과 같습니다.
{ "permissions": { "allow": ["Bash", "Read", "Edit", "Write", "Grep", "Glob"] } }
이렇게 도구 이름만 적으면 그 도구의 모든 호출이 자동 허용됩니다. 그러나 Bash를 통째로 허용하는 것은 위험합니다. 더 안전한 방법은 도구 이름 옆에 패턴을 함께 적는 것입니다.
패턴 문법: 도구별 안전한 자동 승인
패턴은 도구별로 의미가 약간 다릅니다. 자주 쓰이는 형태를 정리해 드립니다.
| 패턴 | 의미 | 안전도 |
|---|---|---|
| Bash(git:*) | 모든 git 서브커맨드 허용 | 안전 (읽기 위주) |
| Bash(git status) | 정확히 git status만 허용 | 매우 안전 |
| Bash(npm test*) | npm test로 시작하는 모든 명령 | 안전 |
| Bash(ls:*) | 모든 ls 변형 허용 | 매우 안전 |
| Read(**/*.ts) | 모든 .ts 파일 읽기 허용 | 안전 |
| Edit(src/**/*.js) | src 폴더 안 .js 파일만 수정 허용 | 중간 |
| Bash(*) | 모든 Bash 명령 허용 | 위험 (권장 안 함) |
핵심 원칙은 “읽기·점검 명령은 넓게, 수정·삭제 명령은 좁게“입니다. git status, git log, ls, cat, grep 같은 명령은 안전하게 허용해도 부담이 적습니다. 반대로 git push, rm, npm install처럼 외부에 영향을 주는 명령은 case-by-case로 허용하시는 편이 안전합니다.
실전 예시: 처음 깔 때 추천하는 한 묶음
처음 자동 승인을 도입하실 때 부담 없이 시작하실 수 있는 안전 묶음입니다. ~/.claude/settings.json에 그대로 넣어 보십시오.
{ "permissions": { "allow": ["Read", "Glob", "Grep", "LS", "Bash(git status)", "Bash(git log:*)", "Bash(git diff:*)", "Bash(git branch)", "Bash(ls:*)", "Bash(pwd)", "Bash(cat:*)", "Bash(head:*)", "Bash(tail:*)"], "deny": ["Bash(rm -rf:*)", "Bash(git push:*)", "Read(./.env)", "Read(**/.env)"] } }
이 묶음의 의도는 다음과 같습니다.
- 읽기·검색 도구는 모두 자동 허용: Read·Glob·Grep·LS는 파일을 수정하지 않으므로 부담이 없습니다.
- git의 읽기 명령은 자동 허용: status·log·diff·branch는 안전합니다.
- 위험한 명령은 deny에 명시:
rm -rf,git push,.env읽기는 절대 자동 허용하지 않습니다.
적용 후 한 주 정도 써 보시면서 자주 묻는 명령 중 안전하다고 판단되는 것을 하나씩 추가해 가시는 흐름이 가장 후회가 적습니다.
defaultMode로 모드 자체를 바꾸는 방법
패턴 하나하나 적기 번거로우시면 defaultMode로 자동 승인의 강도를 한 번에 조절하실 수 있습니다. 세 가지 옵션이 있습니다.
| 모드 | 동작 | 권장 환경 |
|---|---|---|
| acceptEdits | 파일 편집만 자동, 셸 명령은 여전히 묻음 | 코드 작성 중심 작업 |
| auto | 모델이 위험도를 판단해 저위험만 자동 승인, 안전 검사 유지 | 일상 권장 |
| bypassPermissions | 거의 모든 프롬프트 비활성화 (보호 디렉터리 제외) | 샌드박스·CI 등 신뢰 환경 한정 |
예를 들어 auto 모드는 다음처럼 적습니다.
{ "permissions": { "defaultMode": "auto" } }
실무에서는 auto 정도가 균형이 좋습니다. bypassPermissions는 운영 환경에서는 절대 권하지 않습니다. 다만 auto 상태에서도 본인이 자주 쓰는 안전한 명령은 allow에 명시적으로 적어 두시면 더 빠르게 통과합니다.
deny가 allow보다 우선한다는 점
같은 도구가 allow와 deny에 모두 들어 있으면 deny가 항상 이깁니다. 이 규칙 덕분에 “Bash 전반은 허용하되 위험한 몇 가지만 차단”이라는 안전망을 만들 수 있습니다.
대표적으로 항상 막아 두시면 좋은 항목입니다.
Bash(rm -rf:*)— 디렉터리 통째 삭제Bash(git push:*)— 원격 저장소 변경Bash(git reset --hard:*)— 작업 손실 위험Bash(sudo:*)— 시스템 단위 변경Read(./.env),Read(**/.env)— 시크릿 노출Edit(./.env),Write(./.env)— 시크릿 변경
이 정도만 deny에 박아 두셔도 자동 승인을 넓게 풀어도 큰 사고를 피할 수 있습니다.
설정한 규칙 확인하는 법
현재 어떤 규칙이 적용되고 있는지는 클로드 코드 안에서 다음으로 확인하실 수 있습니다.
/permissions— 현재 활성 권한 규칙과 적용 위치를 한눈에 보여 줍니다./permissions add같은 서브 명령으로 즉석에서 규칙을 추가할 수도 있습니다.- 새 규칙 적용 후에도 동작이 안 보이면 클로드 코드 세션을 한 번 재시작하십시오.
설정 파일을 직접 편집하실 때는 JSON 문법 오류 한 줄로 클로드 코드 실행이 막힐 수 있으니, 변경 전 백업을 떠 두시는 습관이 안전합니다.
흔한 실수와 트러블슈팅
“분명 추가했는데 여전히 묻는다”는 상황의 대표 원인입니다.
- 패턴 오타:
Bash(git status)대신Bash:git status처럼 적은 경우. 콜론 위치와 괄호를 정확히 확인하십시오. - scope 충돌: project 설정의 deny가 user 설정의 allow를 덮어쓰는 경우.
/permissions로 어느 위치의 규칙이 활성인지 확인. - 도구 이름 대소문자:
Bash·Read·Edit처럼 첫 글자 대문자가 표준입니다. - JSON 문법 오류: 마지막 콤마, 이중 따옴표 누락. 수정 후 클로드 코드가 안 뜨면 일단 원본으로 되돌려 보십시오.
- 세션 캐시: 변경 후 세션을 재시작해야 반영되는 경우가 있습니다.
자주 묻는 질문
전부 허용해도 되나요?
가능은 하지만 권하지 않습니다. "allow": ["Bash(*)"]이나 defaultMode: "bypassPermissions"로 모든 프롬프트를 끄면 의도치 않은 명령(예: 잘못 매칭된 rm) 사고를 막을 안전망이 사라집니다. 신뢰된 샌드박스·CI 환경이 아니라면 deny에 위험 명령을 박아 두는 형태로 운영하시는 편이 안전합니다.
특정 프로젝트에서만 자동 승인하고 싶습니다.
해당 저장소의 .claude/settings.json에만 규칙을 두시면 됩니다. 본인만 쓰고 싶으시면 .claude/settings.local.json에 두시고, gitignore에 포함시켜 외부 노출을 막으십시오.
같은 명령이 가끔만 묻힙니다.
패턴이 너무 좁아 일부 호출만 매칭됐을 가능성이 큽니다. 예를 들어 Bash(git status)로 좁게 적었는데 클로드가 git status -sb를 호출한다면 매칭이 깨집니다. Bash(git status:*)처럼 넓혀 보십시오.
auto 모드는 정말 안전한가요?
모델이 매 호출의 위험도를 판단해 저위험만 자동 승인하고 위험한 작업에서는 여전히 묻도록 설계되어 있습니다. bypassPermissions보다 훨씬 안전하지만 100% 보장은 아니므로, 운영 환경 작업이나 민감 데이터를 다룰 때는 평소대로 직접 확인하시는 것을 권합니다.
정리
매번 허용을 누르는 피로는 permissions.allow 한 곳을 손보면 즉시 줄어듭니다. 핵심은 두 가지입니다. 읽기·점검 명령은 패턴으로 넓게 자동 허용하시고, 수정·삭제·외부 변경 명령은 deny에 명시적으로 차단해 안전망을 두시는 것입니다. 한 번에 모든 걸 풀려 하지 마시고, 자주 묻히는 명령부터 한두 개씩 allow에 추가하시는 점진적 접근이 가장 후회가 적습니다. 한 주만 다듬으셔도 작업 흐름이 눈에 띄게 매끄러워집니다.