한 줄 요약: claude --dangerously-skip-permissions 플래그 하나로 클로드 코드(Claude Code) 의 모든 권한 질문을 없앨 수 있다. 로컬 개인 작업 환경에서만 사용하고, 프로덕션·공유 서버에서는 절대 쓰지 않는다. Claude Code는 기본적으로 파일 시스템 접근과 셸 명령 실행 전에 사용자 승인을 요구한다. 에이전트가 임의로 파일을 삭제하거나 외부 서비스에 요청을 보내는 것을 방지 하기 위해서다.
한 줄 요약: claude --dangerously-skip-permissions 플래그 하나로 클로드 코드(Claude Code)의 모든 권한 질문을 없앨 수 있다. 로컬 개인 작업 환경에서만 사용하고, 프로덕션·공유 서버에서는 절대 쓰지 않는다.
Claude Code를 쓰다 보면 파일 하나 고칠 때마다, 명령어 하나 실행할 때마다 "이 작업을 수행할까요?"가 뜬다. 자동화 스크립트에 넣거나 길게 돌려야 할 때는 이 질문들이 전부 블로킹 포인트가 된다. 이 글에서는 권한 모드의 구조를 설명하고, 상황에 맞는 설정 방법을 단계별로 정리한다. 2026년 3월 기준 최신 설정 기준이다.
Claude Code는 기본적으로 파일 시스템 접근과 셸 명령 실행 전에 사용자 승인을 요구한다. 이유는 하나다. 에이전트가 임의로 파일을 삭제하거나 외부 서비스에 요청을 보내는 것을 방지하기 위해서다.
권한 모드는 4가지다.
| 모드 | 파일 편집 | 셸 명령 | 외부 API | 특징 |
|---|---|---|---|---|
| Ask permissions (기본) | 매번 물어봄 | 매번 물어봄 | 매번 물어봄 | 가장 안전, 자동화 불가 |
| Auto accept edits | 자동 승인 | 매번 물어봄 | 매번 물어봄 | 파일 편집만 자동 |
| Plan mode | 읽기 전용 | 실행 안 함 | 읽기만 | 계획만 보고 실행은 직접 |
| dangerously-skip-permissions | 자동 승인 | 자동 승인 | 자동 승인 | 전부 자동, 위험 있음 |
📌 참고: Auto accept edits는 파일 편집은 넘기지만 npm install, git push 같은 셸 명령은 여전히 승인을 요구한다. 완전 자동화가 목적이라면 이 모드로는 부족하다.
이 플래그는 Claude Code가 다음 작업들의 승인 요청을 전부 건너뛰게 한다.
bash, npm, python, git 등)이름에 "dangerously"가 붙은 이유는 명확하다. Claude가 내리는 판단이 잘못되었을 때 사용자가 개입할 기회 자체가 없어진다. 예를 들어 프롬프트를 잘못 작성하면 의도하지 않은 파일이 삭제되거나, 외부로 데이터가 전송될 수 있다.
기본 실행 방법# 현재 디렉토리에서 권한 질문 없이 실행 claude --dangerously-skip-permissions # 특정 작업을 바로 실행 (headless) claude -p "package.json의 의존성을 최신 버전으로 업데이트해줘" --dangerously-skip-permissions
⚠️ 막히는 케이스: 공유 개발 서버, CI/CD 파이프라인, Docker 컨테이너에서 이 플래그를 쓰는 경우가 있다. 해당 환경에서 Claude가 의도하지 않은 파일을 건드리거나 외부 요청을 보낼 경우 복구가 어렵다. 프로덕션 환경에서는 절대 사용하지 않는다. 로컬 개인 작업, 테스트 환경에서만 사용해야 한다.
이 플래그를 써도 되는 상황과 쓰면 안 되는 상황을 명확히 구분한다.
| 상황 | 사용 여부 | 이유 |
|---|---|---|
| 로컬 개인 프로젝트 | OK | 본인만 영향, git으로 롤백 가능 |
| 테스트용 VM/컨테이너 | OK | 격리된 환경, 실환경에 영향 없음 |
| CI/CD 파이프라인 (읽기 전용) | 조건부 OK | allowedTools로 범위 제한 시에만 |
| 프로덕션 서버 | NO | 임의 파일 삭제, 서비스 중단 위험 |
| 공유 개발 환경 | NO | 다른 사람 작업에 영향 |
| 외부 API 키가 있는 환경 | NO | API 남용, 비용 폭탄 위험 |
🎓 유데미 강의 추천
Claude Code 실전 강의 — AI 코딩을 지금 시작하세요
설치부터 자동화·에이전트 활용까지, 실무에서 바로 쓰는 Claude Code 활용법을 단계별로 배울 수 있습니다.
--dangerously-skip-permissions가 너무 광범위하다면, 허용할 도구만 명시하는 방법이 더 안전하다. 두 가지 방법이 있다.
실행 시 --allowedTools 플래그로 허용할 도구 목록을 지정한다. 지정하지 않은 도구는 기본값(물어봄)으로 동작한다.
--allowedTools 플래그 사용 예시# Python 실행과 파일 편집만 자동 승인 claude -p "테스트를 실행하고 실패한 케이스를 수정해줘" \ --allowedTools "Bash(python *),Edit,Write" # npm 명령과 파일 편집만 자동 승인 claude -p "의존성 설치 후 빌드해줘" \ --allowedTools "Bash(npm *),Edit,Write,Read" # git 명령만 자동 승인 claude -p "변경사항을 커밋해줘" \ --allowedTools "Bash(git *)"
매번 플래그를 붙이기 번거롭다면 설정 파일에 고정해둘 수 있다. permissions.allow 배열에 허용할 도구를 추가한다.
.claude/settings.json — 프로젝트 단위 설정{ "permissions": { "allow": [ "Bash(python *)", "Bash(npm *)", "Bash(node *)", "Edit", "Write", "Read" ], "deny": [ "Bash(rm -rf *)", "Bash(curl *)", "Bash(wget *)" ] } }
💡 팁: deny 배열을 활용하면 위험한 명령어를 명시적으로 차단할 수 있다. rm -rf *, curl, wget처럼 의도치 않은 삭제나 외부 통신을 막는 데 유용하다. allow와 deny가 충돌하면 deny가 우선한다.
settings.json 파일을 어디에 두느냐에 따라 적용 범위가 달라진다.
| 파일 위치 | 적용 범위 | 용도 |
|---|---|---|
.claude/settings.json | 해당 프로젝트만 | 프로젝트마다 다른 권한 설정 |
~/.claude/settings.json | 모든 프로젝트 | 공통 기본값 지정 |
우선순위는 프로젝트 설정 > 전역 설정이다. 같은 키가 있으면 프로젝트 설정이 덮어쓴다.
권장 전략은 다음과 같다.
~/.claude/settings.json에는 공통으로 안전한 기본값만 넣는다 (예: Read만 허용).claude/settings.json에 해당 프로젝트에 맞는 허용 목록을 추가한다.claude/settings.json은 git에 커밋해두면 팀원이 동일한 설정으로 작업 가능하다
전역 기본 설정 예시 (~/.claude/settings.json){ "permissions": { "allow": [ "Read" ], "deny": [ "Bash(rm *)", "Bash(curl *)", "Bash(wget *)" ] } }
Headless 모드는 claude -p 플래그로 프롬프트를 직접 전달하고 결과를 받는 방식이다. 터미널 인터랙션 없이 스크립트 안에서 Claude를 호출할 때 쓴다.
셸 스크립트, cron job, CI/CD에서 Claude를 도구처럼 호출하는 게 목적이라면 이 모드가 맞다.
Headless 모드 기본 사용법# 단일 작업 실행 (-p = --print, non-interactive) claude -p "현재 디렉토리의 TODO.md를 읽고 완료된 항목을 체크해줘" \ --allowedTools "Read,Edit" # 출력 결과를 파일로 저장 claude -p "src/ 디렉토리의 함수 목록을 정리해줘" \ --allowedTools "Read" \ > function-list.txt # 환경변수로 API 키 지정 (CI/CD 환경) ANTHROPIC_API_KEY=$SECRET_KEY \ claude -p "린트 에러를 수정해줘" \ --allowedTools "Bash(npm run lint),Edit"
⚠️ 막히는 케이스: Headless 모드에서 Claude가 중간에 clarification을 요청하면 응답 없이 멈출 수 있다. 프롬프트를 작성할 때 "모르는 게 있으면 가장 합리적인 방법으로 진행해줘"를 명시적으로 포함하거나, 작업 범위를 충분히 구체화해야 한다.
권한 자동화 설정 전에 아래 항목을 확인한다.
--dangerously-skip-permissions 대신 --allowedTools로 범위를 좁힐 수 있는가?💡 팁: 처음 자동화를 설정할 때는 --dangerously-skip-permissions 대신 --allowedTools "Read,Edit,Write"로 시작하는 게 좋다. 셸 명령 없이 파일 편집만 자동화해도 대부분의 반복 작업은 해결된다. 셸 명령이 실제로 필요해진 시점에 범위를 넓힌다.
처음에는 --dangerously-skip-permissions로 모든 권한을 한 번에 열지 말고, --allowedTools 'Read,Edit,Write'로 파일 편집만 자동화하는 데서 시작하세요. 셸 명령 없이 파일 편집만 넘겨도 반복 작업의 상당수가 해결되며, npm·git 같은 셸 명령이 실제로 필요해진 시점에 'Bash(npm *)'처럼 범위를 한 줄씩 넓히면 됩니다. 그 전에 작업 폴더가 git 저장소로 초기화돼 있어 잘못된 수정을 롤백할 수 있는지부터 확인하시고, 외부 API 키가 들어 있는 환경이라면 settings.json의 deny 배열에 'Bash(curl *)' 'Bash(wget *)'를 넣어 데이터 유출 경로를 먼저 막아두는 것이 안전합니다.
가장 위험한 실수는 공유 개발 서버나 CI/CD 파이프라인, 프로덕션 환경에서 --dangerously-skip-permissions를 그대로 쓰는 것입니다. 이 플래그는 파일 삭제와 외부 API 호출까지 승인 없이 전부 통과시키므로, 잘못된 프롬프트 하나로 의도하지 않은 파일이 사라지거나 데이터가 외부로 전송돼도 사용자가 개입할 기회가 없습니다. 또 하나 자주 놓치는 점은 allow와 deny가 충돌할 때 deny가 우선한다는 규칙입니다. allow에 'Bash(rm *)'를 넣었더라도 deny에 'Bash(rm -rf *)'가 있으면 차단되므로, 위험한 명령은 항상 deny 배열에 명시적으로 적어 두는 편이 안전합니다.
--dangerously-skip-permissions는 git으로 롤백 가능한 로컬 개인 프로젝트나 격리된 테스트용 VM·컨테이너처럼 잘못돼도 본인만 영향받는 환경에서만 적합합니다. 반대로 공유 개발 서버, 프로덕션 서버, 외부 API 키가 살아 있는 환경에서는 임의 파일 삭제나 비용 폭탄 위험 때문에 쓰면 안 됩니다. 이런 곳에서는 --allowedTools로 Bash(npm *)처럼 허용 범위를 좁히거나 settings.json의 deny 배열로 위험 명령을 막는 방식이 맞습니다. 즉 안전망이 있느냐 없느냐로 갈리며, 안전망이 없으면 무조건 화이트리스트 방식을 택하는 것이 원칙입니다.
권한 모델을 제대로 파려면 Claude Code 공식 문서의 Settings·Permissions 페이지(docs.anthropic.com/en/docs/claude-code)에서 permissions.allow와 deny 배열의 매칭 규칙, 그리고 Bash(npm *) 같은 도구 패턴 문법을 정독하시길 권합니다. 다음 단계로는 이 시리즈 2편의 cron·GitHub Actions 스케줄링과 가이드 #17 보안·권한 관리 편을 이어보면 좋고, headless 모드를 본격적으로 쓸 거라면 -p, --allowedTools, --output-format 플래그가 정리된 CLI 레퍼런스를 함께 보면 설정이 한층 명확해집니다.
클로드 코드는 파일 편집과 셸 명령마다 승인을 묻는데, claude --dangerously-skip-permissions 한 줄이면 이 질문을 모두 끌 수 있지만 파일 삭제와 외부 호출까지 무방비가 됩니다. 그래서 핵심은 전부 열지 말고 필요한 것만 허용하는 것입니다. 로컬·테스트 환경에서만 전면 스킵을 쓰고, 그 외에는 --allowedTools나 settings.json의 allow/deny 배열로 도구 범위를 좁히는 것이 안전한 자동화의 출발점입니다.
🎓 관련 강의
Claude Code 완전 정복 — 유데미 강의
이 글에서 다룬 내용을 더 체계적으로 배우고 싶다면 강의를 확인해보세요. 실전 예제 중심으로 구성되어 있습니다.
