Claude Code를 쓰는 개발자라면 누구나 같은 벽에 부딪힙니다. 파일 수정, 셸 명령, 네트워크 호출마다 에이전트가 승인을 기다리며 멈춥니다. 반사적으로 떠올리는 해결책인 --dangerously-skip-permissions는 그 불편을 줄이는 대신, 아마 포기하고 싶지 않을 무언가를 내주게 만듭니다.
bypassPermissions가 실제로 포기하는 것
--dangerously-skip-permissions(별칭 --permission-mode bypassPermissions)는 모든 승인 관문을 한꺼번에 끕니다. 파일 수정, 임의의 Bash 실행, 네트워크 요청이 모두 확인 없이 실행됩니다. 공식 문서는 그 대가를 명확히 말합니다. 이 모드는 "prompt injection or unintended actions"에 대한 보호를 제공하지 않으며, Anthropic은 이를 격리된 컨테이너, VM, dev container 용도로만 문서화하고 있습니다. 라이브 개발 세션을 실행하는 일반 호스트 머신용이 아닙니다.
불편 자체는 실제입니다. Anthropic의 seed video에서 한 엔지니어가 말하듯, "manually approve every single batch command"해야 하는 것은 "super annoying as an engineer"입니다(source). 하지만 그 짜증을 해결하는 도구로 bypass는 맞지 않습니다. 지우고 싶은 관문만 없애는 것이 아니라, 다른 모든 관문까지 함께 없애기 때문입니다.
그래도 하나는 남습니다. bypassPermissions에서도 deny 규칙은 계속 적용됩니다. 의도된 동작으로 문서화되어 있어서, Bash(git push *) 같은 조직 수준 차단은 그대로 유지됩니다(permissions docs). 하지만 그 밖의 것은 모두 열립니다. 이 가이드의 나머지 부분에서는 그런 양보 없이 프롬프트를 줄이는 더 좁은 조절 수단을 다룹니다.
네 가지 모드와 각각을 써야 할 때
거친 bypass 대신 쓸 수 있는 더 좁은 조절 수단은 네 가지이며, 각각 특정 작업에서 승인 요청을 줄여 줍니다. acceptEdits는 범위 안의 경로에 대해 파일 수정과 고정된 파일시스템 Bash 명령 세트(mkdir, touch, rm, mv, cp, sed)를 자동 승인합니다. 반면 다른 Bash 명령과 .git, .claude 같은 보호 경로는 여전히 확인을 요청합니다 . 로컬에서 수정이 많은 세션에 가장 적합합니다. dontAsk는 permissions.allow에 매칭되는 항목과 내장 읽기 전용 Bash만 실행합니다. 그 외 모든 것은 입력을 기다리지 않고 조용히 거부됩니다 . 그래서 CI와 헤드리스 배치에 적합한 fail-closed 선택지입니다.
auto 모드는 더 새로운 중간 경로로, 2026년 7월 10일에 정식 출시되었습니다 . 각 동작 전에 별도의 분류기가 실행되어 요청 범위를 넘어서는 권한 상승을 차단합니다. 예를 들어 curl | bash, 강제 push, terraform destroy, 대량 삭제, secret 유출 같은 경우입니다. 반면 rm -rf /와 rm -rf ~는 애초에 분류기로 보내지 않고 확인을 요청합니다 . 한 세션에서 분류기 차단이 연속 3회 또는 총 20회 발생하면 다시 확인 요청 방식으로 전환됩니다 .
이 모든 것의 바닥에는 가장 위험이 낮은 기본 조절 수단인 allow rules가 있습니다. /permissions 또는 settings.json에서 Tool(specifier) 문법으로 편집합니다. 예를 들어 Bash(npm run lint), Write(src/**), WebFetch(domain:docs.anthropic.com)처럼 쓸 수 있습니다 . 터미널 UI에서는 Shift+Tab으로 여섯 가지 모드를 즉시 순환할 수 있습니다 .
| 모드 | 자동 승인 대상 | 계속 확인하는 항목 | 주요 사용 사례 |
|---|---|---|---|
acceptEdits | 파일 수정 + 고정된 파일시스템 Bash(mkdir, touch, rm, mv, cp, sed) | 그 밖의 Bash, 보호 경로(.git, .claude) | 수정이 많은 로컬 세션 |
dontAsk | allow 규칙 매칭 + 내장 읽기 전용 Bash | 없음. 매칭되지 않으면 대기 없이 조용히 거부 | CI와 헤드리스 배치 |
auto | 분류기가 통과시킨 동작 | 명시적 ask 규칙, root/home 삭제, 차단 임계값 도달 후 | 분류기가 중재하는 자율 실행 |
| allow rules | 사용자가 지정한 Tool(specifier) 매칭만 | 매칭되지 않은 모든 것 | 결정적으로 안전하다고 아는 명령 |
상황에 맞는 레버 고르기: allow, acceptEdits, dontAsk, auto
가장 넓은 모드를 기본값처럼 쓰기보다 작업에 맞춰 모드를 고르세요. 실제 작업 대부분은 네 가지 상황으로 정리됩니다. 내 컴퓨터에서 긴 편집 작업을 할 때, 헤드리스 CI 배치를 돌릴 때, 안전망을 둔 채 넓게 실행할 때, 네트워크에 민감한 환경에서 작업할 때입니다. 각각은 프롬프트를 줄이면서도 전면 신뢰까지 넘기지 않는 특정 레버에 대응합니다.
긴 편집 작업(로컬). acceptEdits를 켜면 범위 안 경로에 대한 파일 수정과 고정된 파일시스템 Bash 명령 집합(mkdir, touch, rm, mv, cp, sed)은 자동 승인되고, 그 밖의 Bash 명령이나 .git 같은 보호 경로는 계속 확인을 요청합니다 . 여기에 테스트 러너와 포매터용 좁은 Bash 허용 목록을 함께 두세요.
"permissions": {
"allow": [
"Bash(npm run test)",
"Bash(npx prettier --write *)"
]
}헤드리스 CI 배치. 명시적인 --allowedTools 범위와 함께 claude --permission-mode dontAsk를 실행하세요. 이 모드에서는 allow 규칙과 일치하는 호출, 내장 읽기 전용 Bash, PreToolUse 훅이 승인한 호출만 실행됩니다. 그 외의 모든 것은 조용히 거부되며 입력을 기다리지 않습니다 . 규칙이 없으면 프롬프트가 아니라 거부가 되므로, 먼저 수동 세션을 관찰해 실제 도구 범위를 나열한 뒤 이를 설정에 넣으세요. 또는 /permissions로 허용 목록을 점진적으로 만들어도 됩니다 .
안전망을 둔 넓은 실행. 각 작업을 분류기가 검토하는 auto 모드로 전환하세요. v2.1.207부터 이전의 CLAUDE_CODE_ENABLE_AUTO_MODE=1 요구사항이 사라졌기 때문에 개인 플랜에서는 별도 플래그가 필요 없습니다. Team과 Enterprise에서는 소유자가 활성화해야 합니다 . 단, 저장소가 스스로 auto 권한을 부여할 수는 없습니다. v2.1.142 이상에서는 프로젝트 또는 로컬 설정의 defaultMode: "auto"를 무시합니다 .
네트워크에 민감한 환경. curl, wget 같은 Bash 네트워크 도구를 명시적으로 거부한 다음, 외부 가져오기는 WebFetch(domain:...) 허용 규칙을 통해 처리하세요. 문서는 Bash 허용 규칙 안의 URL 패턴이 취약하다고 지적하므로, 도메인 규칙, 훅, 샌드박싱이 더 오래 버티는 경로입니다 .
네 상황 모두에서 소음을 줄이는 지름길도 있습니다. 하나의 복합 명령을 “don't ask again”으로 승인하면 한 번에 최대 5개의 하위 명령 규칙을 기록할 수 있습니다. 규칙은 체인의 모든 하위 명령과 일치해야 하기 때문입니다 .
주의할 점: 단순한 허용 규칙이 여전히 발목을 잡는 경우
가장 흔한 의외의 지점은 평가 순서입니다. 규칙은 deny → ask → allow 순서로 해석되고, 먼저 일치한 범주가 이기며, 더 구체적인 규칙이라고 해서 이 순서를 뒤집지는 못합니다 . 넓은 Bash(aws *) 거부 규칙은 더 좁은 허용 규칙으로 다시 열 수 없고, deny 규칙은 bypass 상태에서도 계속 적용됩니다. 따라서 나중에 더 촘촘한 allow 규칙을 추가해도 조용히 밀립니다. deny는 허용 목록이 협상할 수 있는 대상이 아니라 반드시 지킬 하한선으로 작성하세요.
공백도 의미가 있습니다. Bash(ls *)는 ls -la와 일치하지만 lsof와는 일치하지 않습니다. 이 공백은 장식이 아니라 패턴의 일부입니다 . 또한 Bash 매칭은 최선형 패턴 로직이지 커널 수준 샌드박스가 아닙니다. Bash를 통한 cat .env는 Read(./.env) 거부를 손쉽게 우회하고, npm run *은 임의 스크립트 실행을 위임합니다. npm run에 대한 허용 목록은 사실상 저장소가 정의한 모든 것에 셸 수준 신뢰를 부여하는 것과 같습니다 . 실제 격리가 필요하다면 deny 규칙을 OS 수준 샌드박싱과 함께 쓰세요.
auto 모드도 과신하지 마세요. Anthropic 내부 평가에서 실제 과잉 실행 52건에 대해 17%의 거짓 음성률을 보였고, 합성 유출 사례 1,000건에서는 5.7%를 보였습니다 . 마찰은 줄여 주지만, 명시적으로 형식적 안전 경계는 아닙니다.
마지막으로 지속성의 비대칭을 주의하세요. 파일 수정에 대한 “Yes, don't ask again”은 세션이 끝날 때까지만 유지되지만, Bash 명령 승인은 저장소와 명령 패턴 단위로 영구 적용됩니다 . 핵심은 deny 규칙과 샌드박싱으로 경계를 정하고, 모든 allow 항목은 의도적으로 부여하는 신뢰로 다루는 것입니다.
자주 묻는 질문
Claude Code에서 dontAsk와 bypassPermissions는 어떻게 다른가요?
두 모드는 실패하는 방향이 정반대입니다. dontAsk는 닫힌 쪽으로 실패합니다. permissions.allow와 일치하는 호출, 기본 제공 읽기 전용 Bash, 그리고 PreToolUse 훅에서 승인된 호출만 실행하고, 그 밖의 모든 것은 프롬프트 없이 조용히 거부합니다 . bypassPermissions는 열린 쪽으로 실패합니다. 모든 것을 실행하며, 문서에 따르면 "prompt injection or unintended actions"에 대한 보호를 제공하지 않습니다 . 그래서 dontAsk는 CI와 제한된 환경에 권장되는 모드이고, bypass는 격리된 컨테이너, VM, dev container에서만 문서화되어 있습니다. 일반 호스트에서 쓰면 안 됩니다.
2026년에 개인 Claude Code 플랜에서 auto mode를 사용할 수 있나요?
예. Anthropic은 2026년 3월 24일 auto mode를 발표했고, 2026년 7월 10일 일반 사용 가능 상태로 표시했습니다 . 버전 2.1.207에서는 여러 제공자와 개인 플랜에 대해 이전의 CLAUDE_CODE_ENABLE_AUTO_MODE=1 요구 사항이 제거되었으므로, --enable-auto-mode를 언급하는 예전 페이지는 더 이상 최신 기준이 아닙니다 . Team 및 Enterprise 플랜은 여전히 소유자의 활성화가 필요하며, 저장소가 스스로 auto 권한을 부여할 수는 없습니다. v2.1.142 이상은 프로젝트 또는 로컬 설정의 defaultMode: "auto"를 무시합니다.
deny 규칙은 bypassPermissions에서도 유지되나요?
예. deny 규칙은 bypassPermissions에서도 계속 적용되며, 이는 우연이 아니라 문서화된 동작입니다 . 규칙은 엄격한 범주 순서로 평가됩니다. deny, ask, allow 순서이며, 먼저 일치한 범주가 이기고 구체성이 이 순서를 뒤집지는 않습니다 . 따라서 Bash(git push *)처럼 넓은 deny는 더 좁은 allow로 다시 열 수 없습니다. 이것이 계속 남는 유일한 경계이므로, 절대 양보할 수 없는 제한은 deny 규칙이나 managed settings에 두어야 합니다.
복합 Bash 명령에 대한 allow 규칙은 어떻게 작성하나요?
복합 명령을 한 번 "Yes, and don't ask again"으로 승인하면 필요한 하위 명령 규칙이 저장됩니다. 한 번의 승인으로 최대 다섯 개의 별도 하위 명령 항목을 저장할 수 있습니다 . 규칙은 복합 명령의 모든 하위 명령과 일치해야 합니다. Claude가 인식하는 구분자는 &&, ||, ;, |, |&, &, 그리고 줄바꿈입니다. 와일드카드 하나가 여러 인수를 포함할 수 있다는 점에 유의하세요. 그래서 Bash(safe-cmd *)는 의도적으로 safe-cmd && malicious-cmd와 일치하지 않습니다. 일치는 최선의 노력일 뿐, 샌드박스가 아닙니다.
CI runner의 프로젝트 전체 권한 설정은 어디에 두어야 하나요?
.claude/settings.json을 버전 관리에 포함해 모든 runner가 같은 동작을 공유하게 하세요. 팀에서는 일관된 CI 결과를 위해 이렇게 하는 경우가 많습니다 . 개인 오버라이드는 비공개로 유지되고 커밋되지 않는 .claude/settings.local.json에 두세요. 규칙은 managed, user, project, local 범위 전반에서 병합되지만, 더 권위 있는 범위의 deny는 아래 범위에서 느슨하게 만들 수 없습니다. 따라서 조직 전체 managed 범위의 경계는 프로젝트나 로컬 파일이 무엇을 요청하든 유지됩니다 .
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.
